Illustration: pixabay
In recent half a year, in addition to taking charge of routine work coding, I also took another role [BP]. As the name suggests, business partner. In my understanding, I took PM and PMO into account at the same time. This is a lot harder than quietly typing code, and the words razy, empowered, efficient, ideal, intermediate are constantly in my head. Deep experience, review, mutual encouragement.
Let’s think about it in a few dimensions in terms of personal understanding.
On the business
Find out what the business side wants to do.
Understanding the needs of the business side is both difficult and simple. The simplicity lies in the fact that you only need to hear what the business side is saying. The difficulty lies in how you can describe what the business side is going to do in the simplest and most direct terms after thinking about it in your head. If you’re clear, you understand.
Get clear about the business side’s goals, results and benefits.
Why should the business party do this requirement and what is the benefit of doing this thing? The business side is more concerned about the business value, so what technology benefits or precipitation can we have outside of meeting the business side’s concerns, outside of normal delivery. That’s something we need to think about.
Divergent thinking, expand business side needs.
I actually made this up. How to expand the revenue, in the scheduling, manpower, market, data based on compromise. Multiple requirements can be merged, code, process can be abstract generic. Technology ultimately empowers the business. This way of thinking is impossible for highly skilled people to escape.
On the product
Find out who is involved and who can make the decision.
The simple answer is to find a boss who is responsible. Make the participants understand the importance of the project and mentally increase the urgency and priority.
Need point cognition laqi.
Sometimes the requirements have been told so many times that the students in each module don’t know what they are going to do. The best way to do this is for each module to output the technical solution separately for review. The perspective of the boss’s attention can be used to control the project at a higher level.
Make overall technical scheme and review, technical scheme and review of each module
Following the above said, let each module their own sorting out what to do, where is the boundary of their responsibility. And how to collaborate with upstream and downstream, and what to focus on when you collaborate. At the same time, is the technical solution reasonable? What are the compromises? Whether it is reasonable to decide on the spot. The boss will hold the line for you.
Set a schedule and leave a buffer.
Finally, it’s time to make a schedule. Each module is required to give its own scheduling, but most of the time there is no uniform output time point. You can try adjacent upstream and downstream laqi, and finally overall laqi. Even if there is a gap in the end, the adjacent upstream and downstream development can be started after the first adjustment.
The last and most important thing is to leave buffers. Avoid han batch to do quickly can let the boss sit up and take notice of the idea, may not be waiting to run away.
tempo
Don’t believe in “tight then loose,” but “tight all the time.”
I used to believe in the “tight first, loose later” principle. Feel the project early rhythm is more compact, later according to the progress can relax the rhythm, do not force so tight. It turns out I was wrong. When you work with multiple teams, the teams are not just there for your project. The consequence of the slow pace is that, for example, the project is 95% complete by Thursday, and the final touches must be done on Friday. Don’t put it off until next Monday, even if it’s scheduled. After a weekend, bridging costs at work are high. For example, during the peak of the epidemic, the control was particularly strict, with roads closed and grounded. In the later stage, the strength was not in place, leading to a lot of people feel that the end of nothing to worry about, they went to the park. If there is a case, complete GG.
Heavy communication. Including upward reporting, team to team transmission and other mechanisms.
Communication is super, super important. This includes reporting important issues or risks to your boss. The strategy of the boss and the business should also be passed on to the teams in a timely manner. Organize meetings to resolve cross-team differences and ambiguities. The principles of the meeting are:
- Prior to the meeting, clearly discuss the requirements point background, objectives, and cut-off points
- Feel can’t push the boss pull, see what the boss is done
- Conclusion of the simultaneous meeting after the meeting (email or group @ all members)
Daily meeting mechanism. Record and synchronize core information around core goals, progress, risks, etc. Give your boss important information.
Days can be a little gross. But it works. The purpose of the daily paper is to let all members of the project team know the current progress and risks, and to prepare themselves in advance.
Hold on
Find the right person.
When there’s a problem find someone who can solve it. The people who write the code can’t solve it. They go up and recurse back up. Finally, I can’t find my own boss and business.
What’s the problem? And the right person for the right solution.
Let’s figure out what the problem is. It’s best to have a few options in mind so you can approach each module’s boss with confidence. At the same time, the solution does not have to be ideal. It is the appropriate solution for the current phase that the teams agree on.
Anticipate risk. At least timely exposure.
It’s best to anticipate the risks before the project starts. Of course, it is difficult, at the very least, when there are problems or risks, we should timely expose them to all members of the project, and have a good inoculation.
On the summary
- Project management is risk management.
- Keep the rhythm tight.
- The meeting principle is to finish what you start.
- Understanding, thinking, communication, transmission, synchronization, system.
I actually made the whole thing up. The next article will cover how to write technical documentation.