Why do we feel that we have made complete preparations before each release, but we cannot control the release time within the expected range?
navigation
- The general is incompetent, and the army is exhausted
- Don't know how to refuse temporarily increased demand
- non-debuggable code
- false information sharing
- technical debt
- Project time evaluation at will
- ambiguous release list
- Team members are unevenly busy
- Bug handling is not graded
- Insufficient joint debugging
- epilogue
- reference
Every release should be as serious as a rocket launch.
In the career of programmers in the past ten years, in order to ensure the launch of the project, it is common to work overtime. Especially when encountering a larger iterative version, it is often like an enemy. If you encounter some unexpected problems, sometimes it will even last all night.
However, most of the time, I always pay attention to the solution of project bugs, but never make a review of every overtime release that exceeds expectations from the system level.
Recently, the team also experienced several unsmooth publishing work (basically lasted until 2 or 3 in the morning), which aroused the author's attention and reflection.
The above is the testing process for each version we launch.
Why do we feel that we have made perfect preparations, but we can't control the release time within the expected range?
In this regard, the author used his spare time to sort out the factors that lead to overtime work in publishing, which may resonate with you.
The general is incompetent, and the army is exhausted
In a technical team, there must be at least one person who has a high degree of understanding and sensitivity to the team's overall technical structure and the business involved, or someone who wants to control the overall situation from a macro perspective.
Only by controlling the overall situation can we keep a clear mind and make some reasonable decisions at any time, and reasonable decision-making is the cornerstone to ensure the efficient development of team work.
The best candidate for this is the team leader.
The iterative release of a large version is definitely a touchstone for testing whether a technical team leader is qualified.
Don't know how to refuse temporarily increased demand
Knowing that saying no is an art.
Tech Man is not a soulless code tool. "This is a great product, I can't refuse." When problems arise, we often hear technical students say this.
Dare to refuse unreasonable demands, unfriendly demands on users, low-yield, high-investment demands. Of course, rejection is also an art, and this is the art of communicating with people. If after careful consideration, you can give a more reasonable explanation or propose a more constructive plan, I think this will be easier for people to accept.
On the day of the last few releases, there was even an increase in new demand.
Demands must be managed and verbal demands rejected.
If you increase demand at will without increasing R&D time and delaying the release, the pressure will eventually turn to R&D, which will also affect the progress of the release, which is a factor that leads to overtime.
non-debuggable code
Make sure the code you write is tunable.
How to ensure the quality of the code? That is self-testing. In so many years of career, I have gradually figured out a stupid way to ensure code quality - single-step debugging.
For example, the interface is provided to the front-end or third-party systems. I usually write some test cases and perform single-step debugging on the code. This method is very effective, and it does avoid major bugs after going online.
However, in the last iteration, in the project I took over, a new parameter was added to a function without single-step debugging. As a result, after the launch, an unexpected situation occurred in a specific scenario.
After increasing the log analysis step by step, it was found that this parameter appeared in the execution stage null.
The direct consequence is that it took an extra two hours to troubleshoot the problem.
Painful realization!
It is worth noting that for some cross-system or third-party connections, it may be difficult to debug the entire process. In this case, you can debug in sections to ensure the correctness of the final result.
false information sharing
Division of labor leads to information asymmetry.
In a team, differences in information will naturally result from differences in the division of labor or hierarchical issues in the organizational structure.
Although we use a lot of IM tools to reduce the cost of communication by pulling groups, this is still unavoidable.
At the same time, even for the same thing, coupled with uneven team members, there are differences in cognition itself.
In our daily research and development, some changes in requirements or plans are often not notified to each stakeholder by email, nor will they be printed into a document to publicize to relevant personnel.
In this case, I generally create a UI document and a project plan document, which are contributed by team members and can be edited.
In this way, the wisdom of team members is fully mobilized, and information is supplemented and shared around this project.
Of course, people are still needed here to be responsible for propulsion and landing. Otherwise, it is empty talk.
Documents and words are still the best way to communicate, and it is not easy to cause ambiguity.
technical debt
Software is very similar to a church—after we build it, we pray.
Sometimes I really admire our test classmates, because every time a new function is launched, they can always test some problems in the earlier iterative version.
This is a typical technical debt. It may be that the iteration time of some functions was relatively tight before, and some inelegant solutions were temporarily adopted, or some problems occurred. The data was temporarily repaired, and the root cause was not investigated.
These technical debts are like a time bomb, which may explode after a version is launched.
For programmers, a really good working atmosphere should be that everyone is quietly performing their duties, rather than everyone busy fighting fires.
For our project-based team, the team has a small number of people, but it undertakes more projects.
Only by working very hard to ensure that each iteration of each project is of high quality, that there are no major defects after launch, and that there are no frequent feedback issues, can we barely allow the team to operate normally.
Therefore, every plan will be repeatedly considered and verified, and then run in small steps instead of rushing forward.
At the same time, for each problem of feedback, we will find the root cause with the spirit of breaking the casserole and asking the bottom line.
Project time evaluation at will
If the PO says it's a small change, don't believe him. ——"Do you want to make an input box for a week?"
After each product prototype review meeting, it is time to evaluate the project development period.
We know that the more detailed the split of the task is, the more accurate the evaluation time will be.
Generally, we will ask the R&D personnel at each end of the team to split their respective tasks according to the prototype, and give an evaluation time.
Years of work experience tell us that there must be missing logic or hidden logic in the prototype.
At this stage, it takes a little more effort to fully explore the needs and fully communicate with the product in order to do a good job of task splitting and ultimately reduce the error in evaluation time.
However, I have seen too many head-slapping methods to generate evaluation time, and finally lead to a large difference between the actual time and the estimated time.
The direct consequence of this is that overtime to catch up with the progress, insufficient testing, more bugs on the day of launch or there is still a need for missed work, resulting in overtime releases.
ambiguous release list
Publishing is serious business.
Just like a rocket launch mission, the release of a software project has its own process. And this process also needs to be organized into a release list and made public. The purpose of doing this is to establish a common goal for everyone and at the same time know the current progress.
Team members are unevenly busy
In a technical team, if a job relies on one person for a long time, it is not conducive to efficient team collaboration.
This phenomenon is common in Internet companies.
For example, there is a project where the front and back ends are separated, with a surplus of staff at the back end and only one person at the front end. Then the delivery time of this project is likely to be determined by the end time of the development of the front-end students.
This embarrassment occurs when the number of bugs in different modules in the project is uneven when the version is released.
When the bugs are concentrated on one person, the rest of the team can only worry about it.
The more recommended method is to arrange at least two people to participate in a job, or at least two people are familiar with the job.
BUG processing is not graded
The initiative to release the version should be firmly in the hands of R&D.
At any time, R&D students must stay awake, the initiative should be firmly in their own hands, and they should not be led by the nose by bugs.
In the process of bug fixing, developers can easily get entangled with bugs, but it is worth noting that time is passing by every minute.
The management guru Drucker said, "An effective manager always puts the important things first (first things first), and only does one thing well at a time (do one thing at time)."
Through the four-quadrant rule, we classify the bug list according to the priority of importance.
Project managers must stand up and identify and prioritize the bug list to avoid wasting too much time on less important bugs.
After sorting out, you will find that there are actually some innocuous bugs that can be processed with delay.
Insufficient joint debugging
Software product development is a systematic and complex project.
Due to the lack of overall coordination and time constraints in reviewing this product iteration, the link of joint debugging has been greatly reduced.
In microservices, the separation of front-end and back-end is becoming more and more popular. In many cases, the completion of a project often requires the cooperation of multiple teams. In other words, our project is heavily dependent on external sources.
It is worth noting that the different teams and services are not working at the same time. Therefore, there are many project stakeholders involved in each big drop, but each has its own tasks to advance.
In addition to burying their heads in writing code, R&D students still have to use their spirit of "not afraid of hardship and shameless" to actively strive for resources and "strike up conversations".
Everything is only to fully realize the joint debugging of interfaces and services. The communication process is tortuous, but the smooth joint debugging is finally guaranteed.
epilogue
We are all running, but we stop and think for a short time, in order to start again better.
Managers like to quantify work.
Recently, I was thinking about whether there is a way to quantify the release. What indicators can reflect an efficient release?
Is there an intelligent bug system that automatically analyzes and predicts some defects in the project's release and launch and generates a launch forecast report.
This report can expose some major problems in advance, and automatically grade the problems, giving the R&D personnel a reference, thereby moving the release threshold forward.
A little thought and sharing, thank you for taking the time to read this post.