Combine Create timezone groups' UJMs
🗺 Group UJM murals
🧐 Observations
- The
Execution
stage had the most action stickies and the least amount of questions/concerns. Do we really understand it well or are we missing important parts? - There were repeated questions about the boundaries of the journey, which is defined by the JTBD. Is this JTBD at the correct altitude? Is this really such a big job?
👎 Least confidence
These are the areas that the groups were not so confident on and that they would like to validate.
General
- What JTBDs usually take place in the
Before
andAfter
phases? - What happens in these stages?
- Pre-execution stages:
Define
,Locate
,Prepare
, andConfirm
. -
Conclude
(“End the job, wrap-up, and follow-up”)- Action: Create follow-up issues as needed
- Pre-execution stages:
Maintain development environment
- Action: Update dependencies/GDK as needed
- Action: Resolve GDK errors
- Negative feeling: Just want to get working but have to battle with GDK
- Pain point: Maintaining my dev environment is such a pain - there is always some dependency out of date.
- Is this universal to all moderately-complex codebases/environments or is this limited to our GDK? How often do other organizations have similar problems with their “GDK”? Do most developers experience this often?
- Most READMEs are about helping people set up and contribute. This is very important for open source projects.
- Do developers do these things every time?
Stay up-to-date
- Action: Monitor emails for alerts of feedback.
- Action: Inform reviewers of changes through comments.
- Maybe we need to research how other teams communicate between them.
- Kai: I don't have low confidence on notifications in general, but rather the specific notification types and signals, where, when, how.
- Action: Monitor deployment.
- Negative feeling: Confused; how do I know when it's in staging/production?
- Opportunity: Notifications when code is deployed to environments.
Understand code base
- Step: Locate appropriate location to make changes to.
- Pain point: Finding similar pieces in the codebase might not be straightforward
- Pain point: Need to clone repo locally to search the code line.
- Search capabilities are lacking today, compared to local environments/IDE.
Plan
- Pain point: Estimations can increase unnecessary pressure on my team.
- Pain point: Hard to figure out team capacity.
- Negative feeling: Don't know what we don't know to properly scope.
- Action: Add weight to issue weight in sidebar.
- Action: Weight the effort based on past throughput and LOE.
- Amy: important problem, the TW team specifically struggles with this and making this work for us.
Know my work stream
- Opportunity: Improve global overview of currently in-flight tasks
- What other opportunities, other than a dashboard, do we have to improve findability.
- MRs that I'm a participant.
- Opportunity: Improving what did I work on view
- The activity/heat map view is used for this but it's not fantastic, especially if there's a lot in one day.
- Difference between subscribing to new activity vs. interacting with an object.
➡ Recommendations
To move forward and build one or more research-based maps, we need to do more investigation. Our recommendations, in order:
- Validate the JTBDs for Code Review. In particular, looking at the JTBD that was chosen for this exercise to understand if it's at the right altitude and properly phrased.
- After the JTBDs are validated, we should be in a better place to answer the general questions.
- Depending on what we've learned, we may need to dig deeper into the other least confidence areas.
Edited by Pedro Moreira da Silva