Question for y'all:
Do you consider Jira to be a single product with different "flavors" of projects to support different types of teams, or a set of distinct products which share a common (for lack of a better term) platform?
Why I am asking this somewhat pedantic question? Glad you asked (and sorry for how long this is about to be):
Since the end-of-life announcement for Server, I have noticed a dramatic uptick in feature development for Jira Cloud. However it feels like a majority of those new features are restricted by project type despite having pretty universal applicability. In a bunch of cases, it seems like more work to bake them into a particular project type than it would be to simply do it for all of them.
Off the top of my head, a list of big ones that have been rolled out this way might include:
- The "forms" functionality, which was originally released only for Service Management projects; it since has been extended to Work Management, but is still absent in Software projects.
- The baked-into-workflow "Approvals" logic, which is restricted to Service Management projects.
- Kanban boards, which for WM and SM projects are severely deficient feature-wise compared to their SW cousin. While it is possible to use SW boards on non-SW projects, they have been slowly making this less and less friendly and I expect to lose this ability entirely at some point in the not-to-distant future.
- Custom domains; while there is finally some movement on the venerable CLOUD-6999, it is initially only for SM projects. On the ticket they indicate that they are currently planning on bringing this to SW as well, but I see no mention of WM.
I've also noticed over the years a small but noticeable divergence in user interface and experience as well. The biggest is around WM, which recently switched the project navigation bar from the left rail to a horizontal mid-screen, but WM projects also include 'calendar', 'list' and 'timeline' displays not available in SW or SM.
Recently, I started playing around with Jira Product Discovery and was immediately surprised by the custom field interface and "views". These are concepts that exist in Jira already, but JPD has come up with entirely new UX patterns to address them.
I submitted some feedback about it and ended up getting into a conversation with someone over in Atlassian's JPD Product group. In that conversation, they said:
Building a new product, we’ve tried to cherry pick specific parts of Jira to bring across to JPD and generally speaking customers have been happy with the differences, I appreciate that it has created a steeper learning curve for you as you get started with the product.
I've been lucky enough to be able to speak with a bunch of Atlassian folks over the years, and a lot of them have said variations of the same thing, namely:
These are different products, and so you should expect them to have distinct feature-sets and engage with them differently.
The issue I have is that, aside from Atlassian's assertions, I've never really seen any evidence to back this up:
- In the beginning, Jira was a single product. The key features of both Software (the Agile board) and Service Management (the customer portal) originally started out as add-ons to this Jira, and the entire concept of project "type" is not that old.
- I can't say I've ever encountered many end users who understood that there were differences between projects, let alone what the differences were. In my current environment we have a lot of team-managed JSM projects because, back when users were allowed to make their own projects, the only thing they were thinking about was the customer portal.
- I mentioned above the WM switch to a horizontal navigation par; I actually did not see this initially, and someone brought it to my attention because they jump between SW and WM frequently and found the difference jarring.
- From the perspective of someone who has to administer an instance with all three, all it seems to do is make my life harder by forcing me to remember which features exist for what project types and whether their particular implementation of it is worth using.
- While there are some UX\UI differences as I mentioned above, the majority of the look\feel\experience is the same, so there's very little to indicate that these are supposed to be different experiences. This is in addition to the fact that all projects live "within" the overarching Jira UI, which also includes features that naturally span projects (like search or dashboards).
- I've been doing some version of "Jira Solutions Architecting" for a while now, including a stint as an actual contractor, so I've seen a wild variety of use-cases for Jira. I cannot think of a time when I've not come up with a reason to use some feature in project type A that only exists in project type B or C.
However Atlassian keeps on doing this and when I ask why they say "everyone seems to be OK with it" so at this point I'm genuinely wondering if I am the crazy person here who just needs to get with the times.
Is anyone else frustrated by this or should I start testing out straightjackets?
