Changes in requirements can be regarded as the number one nightmare for programmers in Internet companies that pursue fast and unbreakable, and "996" is the direct culprit.
Ali's slogan embraces change. Since demand changes cannot be eliminated, it is necessary to master better ways to deal with demand changes through learning.
1 Common requirements change process
First, a change application must be initiated, which will be comprehensively evaluated by the change committee. The evaluation content includes:
- scope of change
- risk
- The degree of impact on existing plans, etc.
To determine whether to accept the change. The change committee is generally composed of product leader, technical leader, test leader and project manager. If the change is accepted, it is necessary to judge whether the project plan needs to be adjusted accordingly, and finally announce the processing result.
This process is simple, and it is written like this in the book, but in reality, no one in the team is willing to do this except me!
Facing the problem honestly is indeed the first step. It is easy to say, but the key lies in whether it can be effectively implemented.
This article introduces several practical methods that are useful in combat.
2 Achieving Minimal Consensus: Change Has a Cost
When I first joined the A team, the interactive girl pulled me pitifully: "Two months have passed, and the first version is still being polished. 80% of the interactive drafts are completely different. The closer to the launch, the more changes will be made. If you Going to argue with the planner, the other party throws back a sentence of 'Boss wants to add', what do you think?"
This "boss" is the person in charge of A's business. He is from a PM background + perfectionism + one-sided personality, so product planning has the absolute right to speak in the team.
After some observation, wait until the moment. Before the review meeting at the end of the version, I told the person in charge: "You see, our project team is a brand new team. It has been established for more than two months. There are still many problems in such a long-term operation. We need an in-depth review. You must Come and participate!"
On the day of the review meeting, everyone wrote notes anonymously, listing the good and bad points of each link, and posted them on the whiteboard. Looking at the colorful sticky notes on the wall, filled with all kinds of complaints about the changes in requirements of various characters, the person in charge was silent for a long time.
Then, I took out the pre-prepared form, which recorded the various cost increases and rework caused by previous changes to the team:
At the end of the review meeting, the person in charge of the business said: "Starting from today, the change of requirements in the team must be strictly controlled, starting with myself!" After that, the behavior of random changes in product planning converged a lot. And I also took advantage of the opportunity to make three chapters with all team members at the next all-hands meeting, and detailed the consensus at the review meeting into specific procedures:
- All requirements and all changes must be billed, without a single demand, the development has the right not to accept
- Demand changes must be evaluated by the change committee. If the cost of the change is relatively large, the project manager must update the time plan and inform all staff
- For the confirmed changes, the product personnel should send emails to let all project team members know
In this way, everyone reached a consensus from top to bottom on the matter of demand changes, and the pressure of demand changes was instantly relieved. Therefore, if you want to change the status quo, first find the right time to establish a minimum consensus on the change . This consensus does not need to be achieved in one step. If your environment is really difficult, you can just take a small step forward. For example, all changes need to be recorded and announced.
Reaching a minimum consensus is to let the team begin to realize that there is a cost to changing requirements . But after all, the product is still in the exploratory period, and changes are inevitable.
what to do
Planning began to think of ways to allow technology to accept changes smoothly. The most useful trick after experimenting is to invite programmers to eat fried chicken. "There is no change that can't be solved with one bucket of fried chicken, and if it doesn't work, then two buckets!
When the overall project time is required, asking programmers to eat fried chicken is indeed an effective choice for the rapid advancement of the project. As project management, remember that we are after project goals, not zero change .
What to do when these changes occur.
What can the source of change do?
It is a good way to check the quality of requirements and avoid requirement problems from flowing downstream. The introduction of Bug Bash in Lecture 6 is a good way. It is recommended that in some large versions, when the requirements design draft is completed, the team should be mobilized to do a round of comprehensive requirements inspection, mobilizing the early and in-depth participation of each role, which is very effective in preventing and controlling requirements changes.
3 Source governance, do things right once
Plan 1 just now is great! It turns out that the requirement change process was established step by step in this way.
However, the quality of our team's needs is really urgent, and the launch time is fixed. I am worried that only these things will not be enough to deal with after the fact. In the end, changing and changing will still squeeze the development time. Can the hidden dangers be eliminated at the source?
If you want to really check the quality of demand, you still have to manage it from the source.
the case
A few years ago, a certain business group started a middle-end construction project. This business group has a history of three or four years. With the rapid development of multiple business lines, the public platform structure has frequently encountered constraints. After several considerations, the boss of the business group decided to make great efforts to quickly carry out the rectification of the middle and Taiwan. Put me in charge of this super complex project.
Within four months, we reorganized the entire business and technical architecture of the platform accumulated for four years. Time is tight, and the products and designs of four or five business lines will be involved. As a new middle-end structure, if it is changed in the subsequent implementation, it will often have a catastrophic impact. What to do?
"Centralized development in the small black room!" The difference is that it is no longer the programmers who are locked in the small black room this time, but the product and design. They have never experienced this before, and they muttered: "What? The project has not been done yet, and the deadline for the product and design is set first?!"
So, I found the boss platform, convened all the staff, and held a grand launch meeting. On the second day of the meeting, more than a dozen products and designers moved in.
In order to reduce later changes and do things right at the first time, we created a culture on the wall in the small black room, including product and design Deadline schedule diagrams, product module design diagrams, page logic jump diagrams... and various other The design sketches are all put on the wall.
Within a few days, it became a place where programmers stopped to watch after lunch. We began to prepare various small tags for tourists, allowing them to post various comments at any time while visiting. Everyone's enthusiasm for participation is unprecedentedly high, and many loopholes in requirements and designs are discovered in advance, discussed and modified in a timely manner, effectively guaranteeing the quality of early requirements and designs.
In fact, each business line in this project has its own planning. If the traditional method is used, these requirements will be drafted separately, plus the cost of repeated communication between different business line plans, between planning and design, between design and development , I don't know if it will be confirmed until the year of the monkey, and I don't know how many holes will be buried in the later stage.
This kit is a big move, and it is difficult to use. But it is actually the most efficient way to start governance from the source of the change, to be open and transparent from the source, and to get things right at one time . The effect of Little Black House + Deadline is excellent, and you can definitely consider complex projects with strict requirements on launch time.
4 Quick trial and error, force majeure to deal with skillfully
After learning the first two tricks, the change from PM is easy. But in reality, many changes come from big bosses or big customers. How to deal with these force majeure?
Don't push back directly, but analyze, grasp and satisfy the real demands of the boss or customer . It's easy to say, but what if the boss or client still has to change?
After half a year of being devastated by the boss’s willful changes, one of my teams learned from the pain: “We have been thinking of ways to resist changes, and we are exhausted physically and mentally. On the other hand, the boss is also a human being, and the boss is also suffering. We have to give the boss a try. Missed opportunity, no?"
Later, we no longer blindly resisted, but we did not give up our efforts. On the contrary, we try our best to reduce the cost of trial and error, in order to isolate the boss's demand from interfering with the progress of the entire team, outside the regular team:
- Set up a boss demand response team , and the team will take turns to be on duty, and cooperate to improve the response speed, so that the boss can try quickly and have fun!
- At the same time, for those bosses who do not agree with the needs, try quickly, release in a small range of gray scale, and use comparative data
After this series of mechanisms were running smoothly, I gradually discovered that the boss will not be in a hurry every time he raises a demand. Many people regard boss change as force majeure. In fact, there is still room for improvement behind it. You can start by establishing a fast and effective response mechanism, and at the same time summarize and analyze the reasons behind these requirements. After all, the boss wants results, so you have to speak with data to better respond to these demand changes.
5 summary
It is recommended that you start with a minimum consensus to make the team realize that change has a cost. Then take a step forward, start from the source, focus on ensuring the quality of demand, and strive to do things right the first time. In addition, regarding changes in requirements from your boss or customers, you have to try and make mistakes quickly and respond skillfully.
A summary of the motto of the demand change methodology in this section: "Treat the blockage with dredging, control the source, follow the trend, optimize the closed loop, and speak from the data."
If you treat demand changes as a scourge and strictly guard against them, then you are likely to be physically and mentally exhausted in the end. But if you change your perspective, learn from failures, and become blocked, then requirement changes are no longer your enemy. You will see the underlying motivation of a product to constantly pursue perfection, so as to find more tips to help this product achieve greater success!