4 ms·

I hate to be the "but it looks so easy" guy, but why are all these "behemoths" such a huge mass of things for essentially CRUD-y stuff with e-mailing bolted on?

• hobonumber1 6y ago
  JIRA offers an almost limitless amount of customization to fit any workflow. I think the custom attributes/fields/reporting part of it adds a lot of complexity.
  • slater 6y ago
    Got it, thanks.
  • tandr 6y ago
    Yeah... and once it comes down to a company's pm level, they all lock it down to what they think is the best, leaving teams using something that is guided towards PM and reporting, instead of getting job done.
• bingo_cannon 6y ago
  Scaling is only half of it. There is a lot more to Jira than just CRUD over a few entities. It's trying to be issue tracking and project management rolled into one. For example: - Workflows - Access control over fields - Custom fields - Release management - 3P plugins and integrations - API access I am far from being a fan of Jira but they do have a rather large set of features. Every time I evaluate the hottest new issue tracking and/or project management solution, there is something lacking as compared to Jira.
  • slater 6y ago
    Got it, thanks.
  • sethhochberg 6y ago
    I've often half-joked that the road to JIRA is paved with other project management tools and ticketing systems. I don't think anybody really sets out with the intent of using the one reputedly cumbersome tool that can do anything - but after growth and pivots and new requirements and new teams and special workflows... you end up needing a combination of features that is literally impossible to get with any other tool, and who wants to fracture into multiple tools? So you get JIRA. And it just does it all, and even if nobody is overjoyed, nobody feels like they lost, either. There's value in that.
  • johnx123-up 6y ago
    https://restya.com/core-jira-slack-alternative https://restya.com/core-jira-slack-alternative seems to have covered all these area. (I'm on their beta program)
  • jirasux2020 6y ago
    May I suggest you to check the Jira alternatives here https://whyjirasucks.com/ https://whyjirasucks.com/
• 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 ago
    Role based UI can be the answer.