We are very interested in Jira Service Desk, but it looks like a fundamental architecture mistake has been made - namely, that there is a 1:1 correspondance between a service desk and a jira project.
This is not realistic. Projects are created with two considerations in mind:
- project roles: Different team, different project. Otherwise you end up with an admin mess and incorrect permissions, notifications, etc.
- subject matter: Different area, different project. Otherwise you end up with an unmanageable mismash of components and versions.
These considerations likely makes no difference for the poor customer of the service desk, who just wants his problem solved. So the key idea of the portal should apply here too: hide the complexity inside the service desk. But due to the architecture of the tool, this can't be done now.
Looking back, Atlassian also made this mistake with Greenhopper, aka Jira Agile. Originally it was thought that agile should be done at the project level, but soon it was realized this wouldn't fly and out came the Rapid Board, which is now The Board and Greenhopper "Classic" is a dinosaur...
Jira Service Desk needs the same architecture. You have a desk and the configuration of the desk says which projects it serves.* The portal maps the customer requests into the right project. SLAs, reporting, queues, etc. are done at the desk level, not at the project level. Just think through the idea of the Agile Board and apply it to the service desk. I'm hoping the data structures that implement each service desk instance aren't so bound up with the project data structures that they can't be untangled easily now.
Would be grateful to know Atlassian's and other's feedback here.
-David
*There could even be overlap between desks and projects, which means the SLA info in the issue would have to be displayed per desk.
