The project manager is not an indispensable role in the project plan, nor is it just a role such as helping everyone draw a timeline, but the role of the project manager is not so obvious, but it is indispensable.
when i first started working in project management, i often had this feeling about making a project plan: it was all about development and testing. they say it takes three days, just three days, and they say they can go live whenever they want. this obsession has been pestering me, and for a while i was very entangled in this, and even felt very lost at one time and began to doubt my own value. but as the experience increases and the number of projects experienced increases, there is gradually a new experience in this regard: there is still a lot that the project manager can do in the project plan.
first of all, let's introduce how the current team of authors is planning. after the requirements are determined, the development will decompose the tasks according to the requirements, estimate the different tasks, and confirm the testing time. the schedule is then sent to the test, and the test supplements the test time of each task and the arrangement of regression, compatibility and other tests, so as to formulate a preliminary plan (including the time to go online).
at first glance, perfect! the team made the plan itself! what's the matter with a project manager?! not really. let me share with you the role that i think project managers can play in this process.
1. confirm the version cycle
2. refine and optimize the preliminary plan given by the team
the planned point in time needs to be determined based on the effort assessment of the development, but the project manager needs to determine how long the approximate cycle of this release is, whether it is a two-week version or a january version. before development begins to assess effort and confirm the test point, the project manager synchronizes the release cycle to the team. factors that influence a project manager's determination of the release cycle are often:
- the situation of the previous version: if the previous version has just gone through a very tense large version, there are many small optimization features that have not been launched or after the large version has been launched, users have reported some problems that affect the experience. then the next version of the project manager may consider sending a smaller version, these optimizations and issues as soon as possible to get online.
- operational promotion plan: some versions may be in line with the operation of the promotion plan, so this should be taken into account when determining the version cycle to ensure that the mobile side can meet the promotion needs in the time of approval.
- cooperation with other ends: some versions require multi-terminal collaboration, so you need to take into account the release schedule of other ends when determining the cycle.
development and testing give you the time point for your own related tasks, but for a project, these are not enough. these tend to be overlooked by the team, including but not limited to the following:
schedule multiple test points: in the beginning, developers are accustomed to giving a final test point, which is not good news for delivery as soon as possible. therefore, the project manager needs to sort out with the development, whether there are some functional points that can be delivered in advance, so that the test can intervene in advance, thereby shortening the development cycle.
demand freeze point: in almost every team, requirements changes are always criticized by development and testing. for the demand change, we can not completely say no (one is to deal with changes in the market, and second, we also understand that there are always some unknown problems in the planning stage), but it is not the demand change that is proposed at any time that we accept, and we think that the requirements put forward after a certain point in time will affect the smooth launch of the version, so we may refuse. this time is the freezing point in time. considering that this time can not be too early nor too late, too early is unrealistic, too late and affects the plan. so we define the requirements freeze point as the day after the last test point.
arrangement of data burial points: buried points have always been considered by development as the least important work, it does not matter when to do it, as long as it is buried before going online. but once buried the point buried the problem. that time was a day before the launch, in the final version of the development of the buried work, eventually led to the software crash problem. since then, we have agreed that the burial site should be carried out as soon as possible, and we cannot wait until the last day. however, buried work is often forgotten at the planning stage, so it is necessary to reserve a part of the workload for development during the planning process for burial, and at the same time clarify the time node for the completion of the buried point and the time for the completion of the buried point acceptance.
the time point of code freezing: the so-called code freezing is of course that the code is not allowed to be changed, because the code changes at the last time may cause bugs and cause it to be unable to go online on time. now we agree to complete the code freeze work the day before going live.
Other time points: If there is a function of managing the background cooperation, it is necessary to agree on the time of the management of the background launch; the time of the API interface going online, because the bug bash of our mobile terminal is carried out online, so before the bugbash to ensure that the API interface has been online; the version of ios needs to consider the testing arrangement on the test flight, generally placed in the final regression stage of the test.
3. reasonable allocation of co-ordinators
reasonable distribution of workload. once the assessment of each task has been completed, the workload needs to be properly distributed. many times it is seen that the distribution of the workload in the development of their own scheduled plans will be uneven, some people more and some people less. but when asked why, there's no reason, it may just not be carefully considered, so the project manager has to help the team think more about this part and distribute the workload more reasonably.
the distribution of personnel across multiple projects. for example, when it is found that the plan discharged by development and testing can no longer meet the needs of the time node, on the one hand, it is of course necessary to optimize the current plan, but when it is found that there is no room for optimization, it is necessary to consider adjusting the allocation of personnel. because project managers know more about global priorities than specific members, they can consider temporarily moving people from low-priority projects to high-priority projects, of course, in agreement with functional supervisors.
4. consider the impact of the holiday
before starting a version, it is best to collect everyone's established leave requests and consider the workload arrangement. this is especially desirable around some statutory holidays. other special circumstances can also lead to a high number of people asking for leave: for example, the company will eliminate the annual leave left from the previous year every june, which will also lead to intensive leave in june. in addition to the consideration of leave arrangements, the project manager must also consider the "holiday syndrome" brought about by the holidays, such as the national day or the spring festival before and after the long holiday, everyone's work efficiency will be reduced, which will also become the risk of project postponement, so it needs to be considered in the planning stage.
5. know your plan
make sure that the people involved can get to this version of the plan. r&d teams are often confined to their own acres and acres, so in general, few people will think of knowing about other roles, and even if they consciously notify the relevant roles, it will be easy to miss. so the project manager needs to help everyone make up this part. so what other roles besides the r&d team will care?
the demand personnel (including the boss) will be very concerned about the plan, including the specific demand range (the demand range may be different from the original proposal of the plan, and will be fine-tuned according to the workload), and the specific time to go online.
operators, operation students need the plan to confirm the next wave of online content, so as to determine whether it is necessary to arrange operation promotion activities for certain functions or activities.
market students, market students need to prepare and submit the relevant materials for the application market review in advance through the program, and if there is a first listing arrangement, they also need to submit a first launch application.
if you are working with other business teams, you also need to notify the partners.
therefore, the project manager is not an indispensable role in the project plan, nor is it just a role such as helping everyone draw a timeline, but the role of the project manager in this is not so obvious, but it is indispensable. for example, without a project manager, the project plan can still be determined, but the plan will lack arms and legs, and in the end, it will be found that it will encounter various risks and problems when it is launched on time.
But for project managers, it's not like doing what this article mentions to make a perfect plan:
- First, the background of each project is different, and the way of execution will be different, so the matters that need to be paid attention to in the process of making plans need to be tailored to the situation of the project;
- Second, everything is constantly changing, we need to constantly sum up experience, every time a problem occurs, we must reflect on whether this problem can be avoided through a better plan at the planning stage. if so, then document this and note it on your next plan. in this way, the checklist of the project plan will become more and more abundant;
- Third, the author's experience is also limited, may be biased, so we still have to make a plan according to the situation of the team and the project, and embrace change is the right way.
No comments:
Post a Comment