Managing data model updates and reporting/analysis requests


#1

How do you all manage data model updates and reporting/analysis requests? Intake forms, emails, Slack messages? Do you maintain a list of ongoing and upcoming projects that’s visible to external teams? I’ve been bouncing around to-do lists, Asana, and Google docs but haven’t found a solution I’ve loved.


#2

I’m wondering as well. I work in a pretty small company, so I’m able to handle ad hoc data requests via Slack messages as they come in, and manually create JIRA tickets to track my work if it’ll take me longer than 5 or 10 minutes’ turnaround. I have thought about directing people to our JIRA help ticket system to file data requests (like how they’d file IT requests) but I’m not confident these tickets get routed to me quickly, nor do I like putting space between potential requestors and me. I like that they can reach out to me directly and almost always it’s a simple thing (“pull that call center agent’s login/logoff records for a specific date”).

For data model building and updating, I make JIRA tickets detailing what needs to be done.


#3

Slightly different take on this:
I don’t use a “request” model, since to me taking data requests is akin to running a hamburger stand. Instead, I construct data teams like a group of internal consultants who proactively work with their business partners to identify tools or analyses they need to make decisions for their part of the business. The emphasis is always on the business partner doing the final analysis, while the data analyst’s job is to build reusable tools, or when warranted create a deeper level analysis geared at quantifying the risk/uncertainty around a business question.

Internally then, the teams would use either Jira, Trello or Github issues to manage their work, but we never let internal customers simply assign tickets. When an analysts becomes aware of an issue or bug, they decide whether it’s worth tracking or quicker to just fix it. If an internal customer has a new business question they need help answering, they communicate that to the analysts using whatever communication channel they’ve already established (regular meetings, Slack, email etc).


#4

At GitLab, we use issues to track all inbound requests. People often come to us with an ask but get pointed to our looker repository to create an issue. We have a couple of templates there to help get to the root of the problem they’re trying to solve, but often there are clarifications that happen, either in the issue itself or in a recorded call that becomes part of the issue.

We can take an ask submitted into an issue- make it into a meta issue (if necessary) and scope all the different pieces appropriately. We work in two-week milestones. We can plan our work for what is reasonable (ish) for that time frame.

This is also useful for the “requester” because he/she knows where to go to check in- the original issue he/she submitted. It’s the single source of truth for progress. Are we working on it? Well, does it have a milestone assigned to it? Is there an open merge request (called pull request in other applications) attached to it? They can answer their own questions, so there is no back and forth “following up” and “updating people.”

It’s certainly not a perfect system, but it’s the best system I’ve ever used!

I hope that helps!

Some resources:
[1] Submitting an issue: https://gitlab.com/meltano/looker/issues/new?issue[assignee_id]=&issue[milestone_id]=
[2] Issue Templates: https://gitlab.com/meltano/looker/tree/master/.gitlab/issue_templates
[3] Our page in the company handbook: https://about.gitlab.com/handbook/business-ops/data-and-analytics/