I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.
I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together.
I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it.
The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced).
Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it.
If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.
It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.
However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.
Then your managers would buy a tool that did instead.
> maybe just try not to smush existing ms CRM workflows into a tool for devs.
If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get.
Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.
A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.
The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value.
But, in either case, not having that realization is management issue, not a tool vendor issue.