The project progress problems generally do not stand out in a small team, because at this time all members of the team have the same goals, and because of the small number of people, communication costs are also low, for the better team of running-in, this time can follow the way of small steps and fast running, and constantly polish the product. for product managers just starting out, this time should be the happiest time in their product careers.
But when the size of the team expands to two or three hundred people, because the system is larger and more complex, the task will be split to more people to do, and the original simple communication mode will be ruthlessly split, so the relationship between people and people will become complicated.
At this time, a seemingly simple small function is likely to involve the whole body and involve many people. so the project is not simply solved by having a meal together at night: there are too many people, you can't afford it.
since this article is about teaching product managers how to move forward with a project, let's start with how the project works. whether it is a rich contribution or a strong contribution, it is basically ineffective in the face of software development, which requires abstract logic, because he needs professional and technical personnel to continuously work together to complete it. the process of collaboration is actually the same as playing basketball, and it is a process of passing and receiving the ball for everyone involved.
you receive a ball (quest), dribble (do a quest), pass the ball (throw the task to the next person). so each project participant does 3 things, receives the task, completes the task, and passes it on to the next one. in the process of completing the task, if there is a problem and cannot continue, just like when the dribble is intercepted in the middle of the way, the ball must also be passed to the person who can solve the problem. for project participants, the core mission is to pass the ball out on time and on time, and your mission can only be completed if it is passed out.
what needs to be emphasized is what is called passing, the so-called passing we can understand as delivery, that is, the delivery of an output result from the upper house to the next home.
for example, the product manager's delivery to the development and design team is a detailed product requirements document, and the ux/ui delivery of the development is to design a complete interaction script, visual script, and cut drawing. the delivery of the back-end developer to the front-end developer is the safe and usable interface and detailed interface documentation, while the delivery of the front-end developer to the tester is the code submitted to the test environment, and the tester's delivery to the deployer is the test result that is not problematic, but the problematic test result is delivered to the front-end developer.
of course, not all passes are an obvious output result delivery, there will be some information to inform, for example, developers in the development of a third-party security certificate problem needs to be solved by the product manager, at this time the pass may be an email to inform the product manager that the project encountered obstacles, the product manager to solve, so the ball is passed to the product manager.
it needs to be said three times: passing is the most important part of the project to move forward.
at this point, we know that the essence of the project is a process of passing and receiving the ball by many people, and each participant is to do 3 things:
- catch the ball – task
- dribbling – complete the task
- pass – hand over to the next one
but sometimes due to the unclear task, or the unclear division of labor, or other various reasons, the ball will always stop in the hands of someone in the process of passing, and it will not be able to pass to the next link. what to do?
at this time, for the product manager, there are actually only 3 things to do.
- pick up the ball
- clear obstacle points
- re-pass the ball
when re-passing out, it may no longer follow the original transmission path. some product managers will become very anxious when the project enters a stagnant state, and will continue to push the project executor, but there is no effect, because the obstacles are real, not solving is not really to let the project continue to move forward, the result of the push will only make the result out of control.
the removal of obstacles is actually to follow the principle of passing and receiving the ball, find the problem point and the person who can solve the problem, and then pass the ball over. but sometimes, the passing object is not necessarily easy to find or clear, and you need to keep trying to pass the ball until you find someone who can catch the ball. being able to clear the obstacles smoothly is certainly a good thing, but as a product manager, you should expose these obstacles as much as possible before the project starts, and try to clear the obstacles in advance, and the more you find them later, the more likely it is to affect the progress of the project.
but what if the obstacle just can't be cleared? the easiest and most straightforward way is to pass the ball to your superiors as quickly as possible. in fact, if you are not the ultimate boss, you will always have a passing object.
there are three things to focus on for project participants:
- catch the ball – task
- dribbling – complete the task
- pass – hand over to the next one
for product managers, there is only one thing to focus on when moving forward with a project, where the ball (task) stops.
No comments:
Post a Comment