Everyone is a product manager is the largest and most active product manager in china to learn, communicate and share the community. integrating media, community, recruitment, education, and community activities, it is a full-service product manager. this article was originally published by everyone is a product manager.
broadly speaking, the process of a project management is divided into the following stages:
project initiation - project planning - project execution and monitoring - project closure
if you use a diagram to represent it, it will probably look like this:
in the whole process of project operation, from the initial strategic planning from the leader to start the project, to the early project plan, demand transformation and medium-term project execution and follow-up, as well as the late project closing summary meeting, each link has a product manager. especially in startups, product managers also take on the role of project manager most of the time. therefore, for startup products, it is even more important to understand the general process of project management and allocate resources reasonably.
let's sort out one by one, if the product manager is responsible for the management of a project, what work to do at each stage.
the project initiation phase
any project that can be started, at least from the strategic level, is recognized and supported by the company, which means that the project is saddled with the realization of a certain strategic goal of the company. before the product manager starts the project, there are several issues that need to be understood and familiarized in advance:
the first question is, why set up a project?
AT THIS TIME, AS A PRODUCT MANAGER, YOU NEED TO UNDERSTAND THE INS AND OUTS OF THIS PROJECT, THE BEST WAY IS TO COMMUNICATE WITH YOUR SUPERIORS OR BOSSES, BECAUSE THEY HAVE FAR MORE INFORMATION THAN YOU AND MORE THAN YOU, SO BY COMMUNICATING WITH THEM AND UNDERSTANDING THEMSELVES, YOU CAN HAVE A CLEAR UNDERSTANDING OF THE REASONS FOR THE PROJECT. OF COURSE, SOMETIMES THE PROJECT ESTABLISHMENT MAY BE A REGULAR ITERATION OF THE PRODUCT VERSION, AND THE PRODUCT MANAGER IS PROBABLY MORE AWARE THAN ANYONE ELSE ABOUT WHY THE PROJECT SHOULD BE ESTABLISHED.
the second question is, what are the project objectives?
the product manager, as the person in charge of the project, must understand what the goals of the whole project are, and then find out the core goals in it. for example, some projects are time (the faster the better, it doesn't matter how much money is spent), and some projects are money (it doesn't matter if you do it slowly, but you have to spend the least amount of money). you can talk to your leader about this information, and after knowing the project goal, you need to write down the goal in accurate text.
yes, it must be written down, because there is no basis for verbal talk, and then another thing that is written down can become the direction and guideline for everyone to implement.
the third question is, who are the people involved in the project?
Regarding stakeholders, P&G's methodology is to find OUT PACE. P is Participant (Participant), A is Audience (Approver), C is Detail (Advisor), E is Excel (Performer). Of course, product managers (especially startup products) in the daily project work, I am afraid that there will not be such a cumbersome process, so it is to follow the principle of simplicity.
project related personnel can consider from these perspectives, such as which people or departments will be affected by the project results, and who can provide resources (people, money, materials) for the project. of course, in internet companies, common relevant personnel are bosses, product managers, project managers, project teams (including design, development, testing, operation and maintenance, etc.) and users.
Once you've found the people involved in the project, all you have to do now is tie the team members to your own boat. You need to understand the core KPIs of each member of the team, which is what their needs are for the project and what they can bring to the project. If the project is not included in the member's job evaluation list, you need to communicate with his boss. In my experience, 85% of the time you don't contribute is because your project doesn't do anything positive to the member's KPIs at all. Of course, if the communication with his boss is ineffective, there is a last resort, emotional investment, ask the member to string, eat, and use the feelings to let him help you do this project.
the fourth question is, how to set up a project?
usually, this is the time to hold a project kick-off conference. the purpose of this kick-off meeting is to bring together the project team members, get to know each other first, the product manager leads the meeting, and then clearly communicate what the project is going to do, what the goals are, why it should be done, how to do it, who will do it, and so on. in addition, like all kick-off meetings, the kick-off meeting of the project also needs to give the team members some chicken soup and chicken blood. product managers need to unify the team's thinking, clarify the management and operation mode of the team, and the communication mechanism of the team, etc. product managers need to mobilize team members to actively participate in the project and complete the project with high quality.
at this time, the project-related documentation should actually have been completed, because only when the detailed product requirements document is available, the development team can estimate the project time and milestones. there is also another case, that is, the project itself includes a requirements analysis phase, so the detailed requirements documentation is not started until after the project is established. in any case, clear product requirements and detailed requirements documents are the basic prerequisites for the smooth progress of the project, so the planning ability of the product manager and the ability to write documents are particularly important at this time.
project planning phase
after completing the start of the project, the next step is to start the project planning, the so-called project plan, its main work is the decomposition of work tasks, task prioritization, resources, duration, cost estimation, as well as risk planning and communication planning.
1. decomposition of work tasks
work task decomposition, also known as "work breakdown structure" (wbs) in project management, refers to the grouping of project elements oriented towards deliverables. it actually summarizes and defines the entire scope of work of the project, starting from the project goal, decomposing, descending layer by layer, and each layer of descent represents a more detailed definition of the project work.
product managers in each version of the iterative planning, need to fish out some of the more important requirements from the product demand pool to put into the project requirements, which is in line with the idea of agile development, the meal is to eat one bite at a time, the project is the same, it is impossible to get all the requirements at once. therefore, we need to complete through a version of a version, when doing the work task decomposition of the version, we must decompose the task until it can no longer be divided, the granularity of the task must be fine, if it is too coarse, it is likely that some tasks will be ignored, thus affecting the progress and planning of the entire project.
the general work task decomposition methods are: decomposition according to the physical structure of the product, decomposition according to the functional modules of the product, decomposition according to the implementation process, or according to the geographical distribution of the project. it is more commonly used to decompose according to functional modules, and then decompose them in combination with the implementation process of the product.
taking the development of wechat public account as an example, the development of wechat public account involves the development of wechat terminal and the development of pc management background, at this time, if the task is decomposed, the most basic direction should be divided into wechat terminal task development and pc management task development. wechat end task development, can be subdivided into demand carding, product design, front-end page implementation, background interface support, test tasks, etc.; the same is true for the task development of the pc management side, which is also subdivided into demand carding, product design, front-end page implementation, background interface support, test tasks, etc. if the functional module is subdivided, it can be divided into "mass messaging", "automatic reply", "user management", "message management" and other functional modules such as demand combing, product design, front-end page implementation, background interface support, test tasks, etc.;
it should be noted here that in the process of decomposing tasks, the tasks need to be described clearly, otherwise the team members will not be clear about what they want to do or what goals they want to achieve before the task is completed.
the decomposition of the work tasks of the project can also be checked using the mece principle we mentioned earlier, the work tasks must be comprehensive, clear and subdivided, the task responsibilities need to be people, and each sub-task can estimate the workload and duration.
2. task prioritization
tasks are assigned, but there is always a priority. the prioritization in the project requires the product manager to identify the interrelationships and dependencies of various tasks in the project task list, and arrange and determine the order of the tasks in the project according to his own judgment of the priority of the requirements.
in layman's terms, what a product manager defines is which tasks to do first and which tasks to do later. in fact, at this time, we often use the tool kano model we use in demand management, which sorts out the priority of the task by clarifying the importance and urgency of the task, and the priority is to deal with important and urgent tasks.
when dealing with the prioritization of tasks, there is another very important point to understand, that is, there is a front-and-back relationship between some tasks and tasks, and only when one task is completed can we start the next task. so when planning priorities, you need to take this situation into account.
3. plan presentation – gantt chart or other
Many project management books recommend the use of Gantt charts for the production and presentation of project schedules, generally through Microsoft's Project, OpenProj and other professional software for drawing, you can also directly view the critical path of the project through these professional software. There are also some product managers or project managers who directly use Excel to make project schedules, after all, their proficiency in the operation of tables is enough to control the schedule production of a project.
i'm a user experience person, so i don't really use the above two tools very much, in general, i prefer to use the project management function in the team collaboration software to achieve the presentation of the project plan.
for example, the following:
tower's project management interface
4. risk control
in layman's terms, risk is the probability of an unfortunate event occurring. any project has risks, just as any operation has risks, risk is actually ubiquitous, is a kind of thing that does not depend on the will of man, but exists independently of people's consciousness.
let's first take a look at some of the common sources of risk:
a. the customer is not involved in the project
if one of your company's projects happens to be a customized product for the customer, but in the project initiation, planning and execution stage, there is no customer participation, the customer just gives a document at the beginning, and then accepts it at the end of the project, without the slightest involvement in the project, then once the customer finds that the final result is far from the requirements he originally envisioned, the result will become very bad. therefore, the customer may not agree to the acceptance of the project and ask the project team to rework the development, and the loss of workload and time caused by this time, and the impact on related events are immeasurable.
b. the requirements are unclear or incomplete
product manager's requirements document is not clear or incomplete, the probability of project risk will be relatively large, because the development members of the project are around the requirements of the design document for development, testing, if the product manager can be on call, and the development of timely discussion of the requirements, it can also recover a certain loss; and if it is off-site development, the entire project will be more sad.
c. unreasonable project plan
if the project is not completed as scheduled, it is likely that the project plan itself is problematic. for example, the division of labor among team members is unreasonable, the schedule is unreasonable (generally 3 months to complete the task, you have to be required to go online within 1 month), the resources are not configured in place, the decomposition of the work task is not refined and there is no responsibility to the person (which will lead to the team members of the project team not being very clear about their tasks, even if they are decomposed, no one is specified, it will also be found to affect the progress of the project), and there is also an unreasonable prioritization of the task, resulting in the completion of the later tasks being affected.
d. the mental state of the team members
Whether a project can be completed on time and in quality, the most important factor is still the human factor, so the mental state of the team members is also one of the risks affecting the success or failure of the project. If the project members are like the team members mentioned in Scrum Agile Development, they are all self-organized and managed, and the enthusiasm for participating in the project is relatively high, and the project risk will be greatly reduced. If the project members have a problem with their work attitude, often shirk their responsibilities and complain to each other, then the results of the project are very worrying.
e. leadership change
the leadership change here mainly refers to the project development to the middle of the road, the leader suddenly said that this demand is not right, should be developed in another demand direction, then we call it a leadership change. the changes here are roughly divided into two situations, one is not too hurtful, that is, only a small demand modification, does not involve the reconstruction of the underlying architecture; the other is that the planning and positioning of the product is not clear enough, resulting in modifications that are more nerve-wracking, a change in the direction of demand, it is possible to let the development re-build the background architecture, and many pages in the front end also have to be modified. of course, sometimes product managers often make such a mistake, that is, change requirements in the middle, which requires product managers to think clearly about the requirements when planning the project, and minimize the sudden change of requirements in the project development to half.
f. technical risks
the technical risk mentioned here refers to the development team members of the project, they will use code to implement the project, there will be a series of unexpected situations, such as the development of a function that has never been done, this time may need to carry out technical research first, the final result may be that the research event alone costs a week or two, leaving almost little time left for development. for example, the website is hung, and once it is processed, it will go in one day, and the original project in hand will have to be delayed for a day.
here are some common technical risks, product managers in the process of project management, or a little understanding of the next is better:
having said all the sources of risk, is there any better way to avoid these risks?
the answer is yes, but it is still difficult to avoid all the risks.
do you share the same feeling: when a project deviates from the schedule, it is rarely because the work takes longer than expected, and more commonly, the work that is not planned at all makes the project muddy? if you, who are also project managers, feel the same way, then we can realize that the risks in the project are interchangeable. yesterday's problem is today's risk, and your problem is probably my risk.
therefore, one of the better ways we can do this is to refer to and check the above risk sources one by one at the beginning of the project to see if there is any problem. of course, the more hidden risks are probably not discovered by this method of checking one by one, but the more critical point is the insight into the state of the daily project, so that all the core risks can be presented.
Risk management is a very laborious thing, if the product manager does the project management work part-time, he must be prepared for the relevant psychological preparation, after all, the inner strength is also a personality trait that the product manager must have.
No comments:
Post a Comment