Next steps for Auto DevOps vision
Step 1: Run user interviews for problem validation
We first need to identify user problems so that we know what opportunities we have to solve for with Auto DevOps. Some of our research questions are:
- what impedes or slows down or frustrates them in their daily jobs
- What is their current process? Does it deviate from the best practices of Devops? Why? What is the blocker in adopting modern and complete devOps processes?
- What specific difficulties do they face today with their DevOps lifecycle?
- What are the top JTBD that users expect from GitLab, instead of working on their own?
- What is the next step for them in adopting DevOps practices?
- What are the sane defaults that would work for 80% of the users? What are the most common practices?
As we don't know yet and we cannot define which persona we will focus on for our new Auto DevOps direction we need to interview a mix of personas: Lead engineers, platform engineers/sysadmins from organisations varying in size from startups to corporate.
Because different companies and different teams operate in many different ways and interpret the devops practices in different ways we need to gather rich information as well, which means for each persona and company size we need to run more than 5 interviews if we want to have a good understanding of the customers, users and market.
Step 2: Analyse the interviews and share with the team
As Auto DevOps touch many teams in the DevOps lifecycle we need to bring back our learnings and knowledge to the team. We can do that with a video presentation to walk through our learnings and documentation that could include some quantitative analysis.
As part of this step we will also document the JTBD for Auto DevOps and also create opportunity canvases to document the main problems and identify opportunities.
Step 3: Run an async design Sprint or similar workshop
In this phase the Configure team and other interested team members will collaborate asynchronously with the final goal of coming up with a proposal and high level solution for Auto DevOps. The purpose of the workshop will be to define the scope initially (can the entire vision be tackled with a single workshop or do we need to break the vision in more parts?), collaborate, brainstorm and ideate on solutions and finally create a final proposal that can be storyboarded and tested with users.
Question: Is the technical feasibility and details going to be part of this solutionizing process or will we first come up with the ideal solution and then work on the details.
The workshop format and activities is something that I will need to work on but we definitely want to be transparent and provide the opportunity to others to contribute as they are able to. For that purpose we can run office hours and release progress updates to keep everyone in the loop.
Step 4: Test vision with users
This phase will help us validate our vision and can go two ways: it might validate the idea and hopefully surface shortcomings that we might have not thought of and allow us to improve it or it can invalidate it and show us early that we have not taken the right direction. In order to achieve that level of feedback we really need to have thought of many details (eg security, access, compatibility etc) of how the vision will work as these details are the deciding factors to whether solutions are adopted.
Step 5: Next steps
This can be either restart the process if our solution was not well received or work on the direction and vision updates for Auto DevOps, create epics, issues, roadmaps etc.
Next steps for this issue is to create the tasks and start fleshing out the details.