Automate everything! How many people have heard this sentence? How many people are required to do this work? If you are a software developer or DevOps engineer, then you will know exactly what I am talking about. Maybe you even want to automate some things yourself*, but you don’t have enough time to complete the work?
Any IT project strives to obtain the right amount of resources and perform the right work at the right time. So how can you help and communicate the highest priority issues that should be resolved now? The following is a simple process:
- Definition: find the pain point
- Scope: conduct demand analysis
- Experiment: Operational improvement
- Analysis: How much trouble will this bring? Is it worth the investment?
Find the pain point
This is usually the easiest part. Are they in the CI/CD pipeline? Are they in the tool? Are they processes? Do you often miss project deadlines? Clearly outline and define the pain points you see.
Generally, the more painful things are, the more valuable it is to invest time in solving problems.
Perform needs analysis
Let’s start with the definition of industry terms:
Demand analysis is a process. Although the production volume of an enterprise depends on its production capacity, it must strive to generate potential demand for its products.
For the engineering team, this actually means that we need to understand whether there is indeed a need to solve these pain points, or if this is just something a single resource is struggling with. This is usually where engineers and managers disagree. For someone with a strong engineering background like me, this requires really stepping out of your comfort zone and putting on another lens to see the work.
I’m very happy that one of the greatest business leaders I’ve worked with told me: “We cannot engage in IT work just because we value IT, but must engage in work that can bring value to the business.”
Therefore, it can be said that today’s deployment in multiple environments is done manually, which is a painful time for system engineers. They want to automate this work, and management is delaying its priority. Why is this so? Maybe it’s because we only release a new version of the software once a month? Maybe it’s because we only have 4 environments to push code into them? Maybe it’s because there is only one person who needs to do this and has never encountered a problem after finishing the work?
Although I cannot describe all possible situations and give examples, my best suggestion is to consider your pain points in terms of time, personnel, and money. The more people involved in something, the more time spent usually means more economic impact. The greater the economic impact, the more painful and most feasible the problem to solve first.
The easiest way to explain this is to call it the proof of concept phase. Take the time to create and define the plan. What is the actual current state of things? What is the goal state you want to achieve?
Don’t try to automate the whole process or everything at once. Just like agile principles, break it down into small changes, test the results and analyze the data. Using it can provide more evidence for the value management of continuing this work.
Now that you have a plan and some data, you can begin to calculate the value of the proposed work area. The analysis should be simple. How much trouble will this change be implemented? How long will it take? Is it worth the investment?
This should help you get support from your own team, management and the entire delivery team! The final successful change means that the relevant personnel have been integrated into the new process.
DevOps is difficult. The term covers all aspects of SDLC, and has never lacked any ideas for improvement. As DevOps engineers, we need to help reduce errors and find the true direction to bring benefits to the business. As long as you see the work items that should be completed, you can follow this process and you will quickly influence higher-level project tasks.