Director Level Management Dashboard
Description
This feature was requested during user interviews (https://gitlab.com/gitlab-org/ux-research/issues/24). A feature request has been raised following discussion with the product team.
Users discussed that their managers want a dashboard that allows them to see, at a glance, how well their teams are performing in releases and which provides them with a top level overview of project status. The users who requested this feature were typically Team Leads and their managers had roles at a Director level.
During the user interviews, the majority of pain points expressed by users related to their managers and their inability to track project status at a high level within GitLab's interface. If management isn't happy with GitLab, then it slows down the adoption of GitLab within a company and there's a potential for that to have an impact on purchasing licenses, upgrading, ditching legacy tools, etc.
Proposal
-
Create a dashboard which is aimed at users who are Directors.
-
Design a dashboard which is suitable for use on large monitors/television screens and contains all information on 1-page.
-
Allow users to select which projects they would like to report on within the dashboard.
-
Report on the following statistics within the dashboard:
- A list of projects (as defined by the user) with:
- When the last release to production was
- What the last merge request was and it's current state.
- What version number the latest release is running
- Total amount of issues
- Total number of issues closed last week
Links / references
-
Jenkins has a 1-page dashboard which lists all projects and states when the last release went for production, when the last merge request for production was and what the state of that was. Jenkins also uses build badges (for example, Develop, Master, Production, Branches) to quickly illustrate project status.
-
https://github.com/capitalone/Hygieia was shared by one user.
Related issues
Activity
added EE Ultimate label
@joshlambert : How do you think this should integrate with the monitoring dashboards? Maybe this dashboard has the information described in the description (which are high-level roll-ups), and there's link(s) to the monitoring dashboard for details?
@sarahod : At first glance, I think this should be at a group-level. Or do you think it should even be more enterprise-y, and thus, at the entire instance level?
I believe @timzallmann and @jschatz1 were prototyping this in https://gitlab.com/gitlab-org/gitlab-ce/issues/31456.
@victorwu I'm tempted to say the entire instance level, but I'm interested in understanding your thoughts behind why you think this should be at a group-level?
@stanhu I think the work in https://gitlab.com/gitlab-org/gitlab-ce/issues/31456 might be more closely aligned to: https://gitlab.com/gitlab-org/gitlab-ce/issues/37195.
@sarahod : No particular reason. I was just thinking of group-level use cases, which are usually one or a handful of teams can be represented by a group.
So how about a director that has visibility into say a handful of groups. Each group represents a team. So this director could be like managing 5 teams. So the director would go this mgmt dashboard, and they would automatically see the items you've described for those particular 5 groups. Basically, it would suck in the data based on the permissions of that director. (And that would be one of the first iterations.) In subsequent iterations, GitLab would allow the director to customize and filter/collapse some of those 5 teams.
@sarahod : When you say the use case of showing the dashboard on a large monitor, what's the specific use case? If it is so that a director can view it in his private office, that makes sense, given all the permissions factors I mentioned in https://gitlab.com/gitlab-org/gitlab-ee/issues/3277#note_38819662.
But if the purpose of the large monitor is to give an overall operational health status to technical contributors / operators, then that's different right? If it is to show software development metrics for software teams, I would think that type of dashboard should be at a group level, since everyone in that team would have access to those projects. If the dashboard is showing real-time metrics (like Prometheus style monitoring), then I think it can totally be for the entire instance, but probably it would be for SRE (system reliability engineers / production engineers). So in that case, that is more for mission control, airport tower style dashboards right?
Any thoughts on how to differentiate / think about this?
@victorwu Thanks for the group-level explanation. I think what you have described makes complete sense and is a good solution.
When you say the use case of showing the dashboard on a large monitor, what's the specific use case?
One of the Team Leads explained that he is working across 30-40 projects and is constantly emailed for a quick update on where things are up to. He thought that by having the information available on a television screen that it's visible to anybody and would stop him being emailed. This user in particular reports into Director level but is managing multiple teams - so it isn't just his line manager who's pinging him for an update.
However, at the same time, it's not technical contributors/operators that are emailing him, it's senior management. The technical contributors/operators aren't bothered about the metrics I've detailed above, like you say operational health status is different. I haven't much insight into dashboards for SRE (I need to speak to more production engineers, etc) but you're right I'd imagine they'd be more mission control, airport tower style dashboards and reporting data across the entire instance.
If it is so that a director can view it in his private office
Yes, that's the impression I got from the user. Having said that, not everyone works in private offices - I think you've touched on an interesting point, there could be scenarios in open plan offices where there's a requirement for more than one dashboard to be displayed on large monitors (SRE dashboard and director dashboard). Perhaps, it worth me doing some more research with users who work in this kind of environment to find out if that scenario would ever exist.
Thanks @sarahod . That's some good information. My suspicion is that the put-dashboard-onto-public-monitor use case is something that people frequently request, but in reality, it's not that practical. It's like a nice-to-have, and I highly doubt it's driven by an actual use case.
For the particular person you cited, I really doubt that putting info on a television screen would stop senior management from emailing him. I don't think that's the right way to solve the problem.
Ultimately, senior management wants information that's in a format that they can consume, and is actionable/relevant to them. Senior management often wants the executive summary. Sometimes they actually don't even care about what's going on. They just want assurance that everyone is fine. So going into their mindset a bit, they trust their direct report. So they just ask, "What's the status of the project? Is everything okay? Let me know if there's a problem. Who do I need to bother?" We can solve that problem. But I think it might take a bit more research to fully understand. For example, we could just show some colors. Green means that project is going along fine. Yellow means there's some open risks. Red means there's significant delays and demands attention. Is that sufficient? I think it's hard to know at this point and any design may be too prescriptive of certain use cases.
So I think what we could reasonably build is just a list view of projects that a user has access to, and some relevant information you've cited. It could very well be this project view (https://gitlab.com/dashboard/projects), but re-invented to have more dynamic filters, similar to the issue list view. I'm not sure that's a "director level dashboard". But if you have that list view, and maybe you can save some of the configs/filters, then it could slowly morph into a director dashboard view over time as we add more features to it.
Thoughts?
Edited by Victor Wu
Yah this is a dup of https://gitlab.com/gitlab-org/gitlab-ce/issues/31456. We can close ours or yours. We started work on this. Would love to do this more officially @victorwu
@jschatz1 : I think https://gitlab.com/gitlab-org/gitlab-ce/issues/31456 is closer to https://gitlab.com/gitlab-org/gitlab-ce/issues/37195. Close your issue and we can meet at https://gitlab.com/gitlab-org/gitlab-ce/issues/37195?
Edited by Victor Wu
@victorwu Sure, I even started a little bit of a PoC as a side project so far and have a couple of brainstorming ideas written down. As the lack of having something like that bothered me from the first day and having worked in a multi level enterprise thing just before. I prioritised for the last release cycles mainly as the performance work was more important and that was just a starting point for a side thing to resolve our main own problem for team mgmt.
changed milestone to %Next 2-3 months
@victorwu sounds like a good plan to me! Releasing what you have suggested will allow us to collect further feedback from users and hopefully provide the additional research we need
changed milestone to %Next 3-6 months
removed portfolio management label
