Team Lead Management Dashboard

changed the description

@sarahod : This is interesting. In the past, we've tried to use ideas like cycle analytics to introduce specific concepts to users, and have them leverage that to improve their process. Basically we tell them, "this is conversational development. These are the metrics you should care about."

But it seems like what you are describing are really "boring" table views with a bunch of filters. Essentially we are just writing a lot of SQL in the backend, and presenting it to users to consume. And it should be very flexible in terms of parameters. So what do you think about a design where essentially you give users a dynamic spreadsheet-style UI? For example, you could give a table/list view of all issues scoped a certain way. And then with a few clicks, you can roll-up those issues per certain conditions/filters (e.g. assignees, recency, labels, etc.) And then you can do further roll-ups into projects and groups. Same thing for merge requests.

I think a design like that could be very powerful because essentially your are giving them a free-for-all UI. But the danger I see is that now we are re-inventing excel, and and there would be a lot of complicated UI.

Thoughts?

@victorwu

we've tried to use ideas like cycle analytics to introduce specific concepts to users

Yes, a couple of the users I spoke to had tried to use cycle analytics but it just didn't fit their workflows. In this / previous rounds of testing Team Leads have explained how they're normally responsible for creating issues, assigning labels, etc. Sometimes, even moving issues on boards from one column to the next. This doesn't necessarily happen in real time.

For example, an issue might be completed by a developer on Monday, but the Team Lead doesn't have time to review the issue until Friday. On Friday, the Team Lead reviews the issue and moves it from 'Doing' to 'Done'. However, from what I understand, from the users I've spoken to, the Cycle Analytics data would be skewed - it would look like the developer had spent longer on the issue than he/she actually had.

If Team Leads were to utilize other features which relate to cycle analytics (time tracking, milestones, etc) it would be their responsibility to manage the data entered into the fields. It's an added responsibility they don't want/don't have time for. Some Team Leads have tried to ask their direct reports to maintain this information, however, they've told me that developers often forget to update the fields and therefore, they don't trust the data that's being reported.

So what do you think about a design where essentially you give users a dynamic spreadsheet-style UI?

Sounds interesting!

For example, you could give a table/list view of all issues scoped a certain way.

Yes, but let's not recreate the issues list view. Interestingly, this view seemed almost redundant during the testing, issue boards are taking over.

But the danger I see is that now we are re-inventing excel, and and there would be a lot of complicated UI.

I don't think it needs to be as complicated as Excel. The data isn't really being interrogated - it's not so much about the performance of the team and the impact of that upon a project's deadline/timescales, it's knowing what everyone is working on/assigned to across everything in GitLab. I think that's the difference between cycle analytics and the requirement for this dashboard.

Even metrics like The number of issues a direct report has closed recently isn't necessarily indicative of performance as issues can vary in scope and size. Again, it's more about managing resource e.g. I assigned 20 issues to Developer A and they've just completed 18 issues, so they'll have capacity soon to take on more work, what can I assign to them?

changed milestone to %Next 2-3 months

Thanks @sarahod . That makes sense. Let's try to start carving the smallest thing which we can iterate here.

This seems like a reasonable first stab:

All issues a direct report has assigned to them.

This page (https://gitlab.com/dashboard/issues?assignee_id=711023), pretty much has most of what you've described. In your research, do you know if users even knew about this page, and can use it for this purpose? If they weren't aware of it, do you think there's a good way to improve discoverability / navigation? For example, if a team lead just wants this information for a particular direct report theirs, they can simply bookmark that page (with the associated assignee they care about). Do users just not know that page exists?

@jschatz1 : Can you post some screenshots of your POC here? Let's iterate on a design based on that.

mentioned in issue #31456 (closed)

@victorwu We can go over the PoC and idea sketches when 10.0 is out of the door, if you want ?

Sounds good @timzallmann . Let me put something on your calendar.

@victorwu invite me too!

@victorwu

This page (https://gitlab.com/dashboard/issues?assignee_id=711023), pretty much has most of what you've described. In your research, do you know if users even knew about this page, and can use it for this purpose? If they weren't aware of it, do you think there's a good way to improve discoverability / navigation? For example, if a team lead just wants this information for a particular direct report theirs, they can simply bookmark that page (with the associated assignee they care about). Do users just not know that page exists?

The Team Leads didn't typically interact with the icon for issues (which takes them to: https://gitlab.com/dashboard/issues?assignee_id=711023), the reason being that as they create all issues for their teams, their issue count is enormous. It's hard for them to know from this view whether an issue needs follow-up action or not, so they don't use it. Therefore, no, they're not interacting with this page and therefore won't know that they can filter it.

The layout of the navigation won't be aiding discoverability either. The top right area of the navigation is designated to 'personal' content. It isn't a logical flow to visit your 'personal' issues first, in order to view issues assigned to a direct report, especially when you're not actively working on issues.

In terms of bookmarks, I did ask users during the interviews if they'd bookmarked/saved certain views that they use frequently and they hadn't. Some have starred projects, but that's about as far as saving/pinning goes. I think this view is great, but we need to expose it more, we shouldn't rely on people bookmarking pages (in fact I'd argue that more bookmarks = a poor navigation).

I think something that could be improved on the view is the ability to see what more than one direct report is working on, as if, for example, an urgent issue needs to be resolved, a Team Lead would look at the workload across all their direct reports and look for the person with the most capacity to take on the task. However, this is something that could be implemented later though. I guess a workaround is just to open the list in multiple tabs filtered by each of your direct reports and flick back/forth.

Also check this out https://gitlab.com/gitlab-org/gitlab-ee/issues/3043

mentioned in issue #27111 (moved)

changed milestone to %Next 3-6 months

mentioned in issue #3235 (moved)

Team Lead Management Dashboard

Description

Proposal

Related issues

Designs

Child items ...

Activity

Admin message

Admin message

Team Lead Management Dashboard

Description

Proposal

Related issues

Relates to

Activity