4 ms·
This is a fair question, you shouldn't be downvoted. Lean ticket trackers and productivity tools are perennially launched and invariably become as bloated as th
by fractionalhare 6y ago
This is a fair question, you shouldn't be downvoted. Lean ticket trackers and productivity tools are perennially launched and invariably become as bloated as the incumbents.
This is because the information in these tools is business critical and needs to be consumed by almost everyone in the company. Moreover, different people need access to the same information in different forms of presentation, with aggregation and emphasis of different data. In contrast it's easy to make a work tracker just for developers - GitHub and GitLab have pretty much solved that problem. Making a ticket tracker which works as a single source of truth for all members of an organization who need access to the tickets is much more difficult.
Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate. You can't just target a single group here, because then you're trying to get the company to adopt separate repositories of work (it's already an additional complexity that work is split between e.g. GitHub and Jira, for example).
So to obtain the critical mass of adoption they need for product market fit and growth, these tools organically evolve to become everything to everyone in an organization. And suddenly your tracking tool is stuffed with metrics, integrations, feeds, dashboards, reports, etc.
The other thing is that these tools become especially bloated by integrations and plugins. A brand new instance of any tracker or project manager feels clean and fast. A few years in, it feels slower and more crowded by all the custom/third party additions rolled into it.
- thaumasiotes 6y ago> Developers, PMs, VPs, support staff, data scientists and designers all need access to overlapping information which is ideally stored in the form of tickets. But each of those roles needs something different from the tickets, both individually and in aggregate. I realize this would be a lot of work, but I would be really interested to see some examples of "the ticket the developers want", "the ticket the VPs want", "the ticket the designers want", etc.
- zxienin 6y agoRole based UI can be the answer.
- fractionalhare 6y agoYeah, that would be the modern solution. As far as I can tell even Salesforce has tried that with role-specific views that are customizable. But somehow it just converges back to everyone having everything all over again, but this time with 8 different frontend views to be maintained.
- mattmanser 6y agoI've worked on these sort of problems, and I can guess why. What happens is that a new field gets added, and whoever's adding it claims it's really "important" and needs to be seen by everyone. It'll invariably set as mandatory to be filled in too. 2 years later and some integration breaks because the integration doesn't set that field and you end up looking at that really important field and every single project has it set to exactly the same value. Repeat ad nauseum. The other thing I've seen a few times is when assessments or a bonus depends on some field so they make it visible to everyone. Then the bonus scheme changes, but they never hide the fields that no-one cares about any more.
- monkeybutton 6y ago> when assessments or a bonus depends on some field Ugh, this reminds me of a mess I inadvertently participated in.. A certain employee, on an unrelated team to mine, decided to to go down the route of becoming an agile/scrum master/evangical and somehow got "reduce instances of X" as their personal KPI/development goal one year. Soon after this, they're pinging myself and other team leads on slack whenever X field is filled out on JIRA and demanding justification. Eventually because of this harassment I just stop filling out the field, leaving it as the default value and just verbally communicating the fact to whomever needed to know. Later on I find out that I wasn't the only one that took this route,And guess what happened next! The scrum master is promoted to a management position, in part due to their stellar KPIs! Excellent work all around!