How to make a meticulous project plan may not be the most difficult thing in the project, and dealing with unplanned situations is the most headache for everyone. in the actual process of advancing the project, uncontrolled changes in requirements often bring heavy burdens and unpredictable risks to the project. therefore, designing a suitable set of requirements change management processes and specifications is indispensable for both project and project managers.
problem analysis
first of all, a brief introduction to the author's project: product level, we are a c-end product, the demand mainly comes from operation and planning, in terms of product stage is in the transition period, the current stage is mainly to explore new functions; the project level, due to the complex and large function, the cutting space is not large, so each version cycle is longer (each version of the product preparation cycle, the research and development cycle are about 15 to 20 working days), from product design to research and development and the main process of going online is available, as follows:
the author defines the requirements change in two levels, one is in the product design stage: the requirements review is over, the prd document is finalized and then the requirements draft is changed, defined as the demand change; the second is the end of the r&d schedule, the final development and testing of the online plan, and then all unplanned changes are defined as demand changes.
at the beginning of the project, there is no clear definition of the process specification of the demand change, so there will be many problems caused by the change in the actual promotion process of the project, and the following is explained one by one in combination with the actual problems:
problem one: more changes: at the beginning, the biggest problem of the project was that there were many changes in demand, and if we just plunged into the process, it would waste time, so we tried to analyze the reasons for these changes to see if we could block the changes at the source. after judgment, it was found that a considerable part of the changes were due to the lack of robustness in the requirements design or the lack of understanding of the requirements of the interaction, and it was found in the subsequent stages, and then began to modify or add requirements.
problem two: change is not standardized: change is an inevitable problem, everyone sit down to chat, if you feel good then make this change, this is our previous approach. however, due to the lack of a clear basic process specification, when it comes to change, things are often lost, and the following problems will occur:
there are too many people who propose changes to the needs, and i don't know who to listen to
changes were made too late, leaving little time for the project
the information such as whether to do it or not, when to do it, etc., is not synchronized among the various roles
problem three: the problem brings risk: the project pays too much attention to discussing the change itself and the significance of the change, often ignoring the implementation of the change will often impact the original plan, lack of complete risk analysis; when the change is executed, there is no relatively fixed routine and rules, the implementation process is very loose, lack of some effective monitoring, the process risk evolution is unknown.
solution
while giving the solution, we also need to note that the processes and specifications relied on for project management are too strong to make the project run cumbersome and inefficient, but too weak to make the project loose and loose. therefore, when designing the corresponding method, it is necessary to fully consider various s
chemes and choose the simplest way to achieve standardized management.
in response to question 1, we decided to optimize the original backbone process and add a link to confirm the requirements; for questions 2 and 3, we standardized how to approve changes and how to implement the two processes; and established a way to monitor the project's bearing of the change workload.
backbone process optimization
According to the practical experience of the project, it is found that the requirements review alone cannot fully guarantee that the demand side clearly clarifies all the requirements, and the interaction party fully understands the requirements of the demand side, the essential reason is that the PRD cannot fully describe the entire scene, and many of the details and series of the requirements level may still be incomplete even after the end of the requirements review; only as the interaction designer improves the requirements into a well-structured logic diagram and scene description, Often it is found that the requirements design is not in place at the beginning, in the case of a large version, wait until the entire interactive draft is taken out and then make changes, the change cost is too large / the feeling is not good.
therefore, for more complex designs, a link will be split before the interactive review to do a review of the main interactive scene. through the addition of new links, we ensure the soundness and perfection of requirements, and reduce the number of demand changes flowing into subsequent stages.
this practice is suitable for planning two scenarios: frequent changes to the prd, and overly complex functions accompanied by a large potential change risk. frequent changes in prds are not entirely due to flaws in the functional logic design, and it may be that the pre-process such as product planning/business analysis demonstration is not done well, and it is useless to add a review of the main scene in this context, and the reader needs to analyze it carefully.
for the review of such an interactive main scene, the specific operation suggestions are as follows:
time point: this link is arranged after the end of the demand review, before the interactive review begins, and it is recommended to arrange it as soon as possible after the demand review, about 2 working days;
contents: after the interactive understanding planning prd explanation, the interactive draft is initially produced, the granularity reaches the coverage of the main scene and the complete logic process, and then the main scene review meeting is held to confirm with the planning/demand side to ensure that the demand understanding is correct and the requirements are sound.
participants: demand providers (such as operations, markets, etc.), planning, interaction
the change specification is clear
the specification of the change process covers two main aspects, one is to clarify the basic concept of change management, and the other is to clarify the steps that need to be implemented sequentially once the change is to be made.
the philosophy of managing change >>
the core of change management is to assess the value of the requirements change, and then decide whether to do it or not and whether to do it in the current version, we try to think from more perspectives, including the planning of the product, the characteristics of the requirements.
first analyze the characteristics of the product stage: we are in a new and old intersection period of product transformation (simply put, on the one hand, to maintain the original function, on the other hand, it is more necessary to explore and design new functions), so the demand changes in this period can be divided into four dimensions: the original core function, the original peripheral function, the new function core function, the new function peripheral function; the change is also classified according to the above dimensions, and then consider the version launch time and quality. consider the requirements change in the following order (the author assumes that the quality is constant, the scope and progress are variables, so the scope and progress are prioritized): the core function changes of the new function > the original core function change> the version is launched> the new function peripheral function change > the original peripheral function change.
at the same time, it is not recommended to delay the established launch time because of the urgent demand change, for the project, the online time is a very serious thing, can not be easily changed, is the goal of everyone to protect. therefore, we define the time point at which the demand change is frozen, and in principle, no changes are accepted after the freezing point. regarding how to set the demand freezing point, different projects need to be analyzed according to the actual situation, for example, our approach is: the freezing time point of the product stage is within two days after the end of the interactive scene review; the freezing time point of the research and development stage is about two days before the test point (the principle of setting is to do the version plan, the development in the estimation of the test time and confirm the showcase time point as the freezing point, and this time is generally about two days before the test point). in fact, for these two freezing points, we will focus on the management of the latter freezing point.
in the overall idea of responding to changes, in addition to the basic ideas summarized from the above practical experience, it is also recommended that conditional projects try to try to fix the r&d iteration time at a fixed time, and if the cycle can reach two weeks and one iteration, it is ideal. we also try to iterate on a week, which is obviously more relaxed when dealing with changes in requirements, but the applicable scenarios are limited, and the fine optimization requirements are the focus of the weekly iteration.
the steps to perform the changes >>
in fact, how to implement the change, there is no one-size-fits-all routine, but the structure is actually the same, the author gives some practices on the project for your reference:
the demand side proposes changes (it is recommended that the same role be centralized by one person to propose changes, such as the operation/market needs to designate a unique interface person for the output demand change), plan to evaluate the necessity of the change, and formulate a change plan (it is recommended that the change be uniformly collected and output by the planning responsible for the current version); if the interaction design is required, the implementation plan needs to be discussed with the interaction.
planning notice development, development students to assess the change workload, in general, development and planning jointly decide whether to implement changes in the current version, if the opinions can not be agreed, you need to submit a responsible stakeholder approval decision, but this situation is often less, most of the situation still depends on product and development to tear out a conclusion.
successful changes will go into r&d, the station will know about it, and the project manager will assess the risk; pk failed changes will enter the requirements pool and be re-prioritized in the pool. for pk successful changes, generally speaking, we will remove a low-priority requirement to ensure that the workload in the iteration is relatively constant; however, this is only a principle approach, and we will also flexibly analyze the current remaining workload to decide whether to directly add changes.
monitor status and risk during change execution: we use jira's dashboard to monitor the effort and remaining time of each development change during the project process, use the daily station to continuously review changes in the queue, and complete the changes within the allowable range of the project according to priority 。 description: there are often such cases on the project, large demand changes are often more formal process, the risk is better to control; for small changes, in the case of no packaging and unified processing, a single developer will continue to bear a number of small problems one by one, and these small problems are difficult for you to do time commitment, can only roughly feel very simple + can be changed, the final result may be like this: unconsciously, the changes in the queue will slowly increase, small points that have not been estimated in detail converge into greater risks.
Summary
finally, in addition to sorting out the strategy and process specifications to manage changes and implement changes, it is also necessary to choose the right time to guide the team to review the reasons for the changes and continuously improve the strategy and process specifications. in the review, it is necessary to exclude interference factors, focus on high-frequency changes and analyze the essence of the production. in addition to supporting continuous improvement and forming a closed loop of the process, the review also helps the team to reach consensus on the reasons and solutions for change, and improves the team's ability to manage changes and execute changes.
how to do a good job of change management in depth, simplify the steps of change, is still exploring and optimizing, welcome to communicate with me.
No comments:
Post a Comment