Supply Chain Project Management
Recently, we re-planned and redesigned the overall process of agile projects, and defined the goals, indicators, time points, and responsible persons from the beginning of the requirements to the launch of the project. But when we developed a more detailed plan, we found a serious problem: it was a "dream schedule". In the exploration and practice of project life cycle management, we have experienced waterfall, iterative, incremental and mixed Scrum agile. If only for project management, I believe that in a Sprint cycle, "everything can be achieved" It is feasible to have it under control, but when looking at the final goal of a quarter or even half a year, the perfectionist thinking of the dream plan has become the other extreme.
To make the plan more pragmatic, we need to manage the project with the shortest possible time box, 2 weeks is an ideal and challenging cycle, but we believe it can be achieved as long as Sprin is under control.
| If the project cycle is too long from beginning to end, it will cause psychological relaxation and lack of sense of crisis for the project, which will result in wasted time in the early stage and embarrassed by working overtime in the later stage. So we need to iterate continuously and complete deliverable increments in one cycle. Fact-based decision-making is far more effective than front-end predictive decision-making. —Reinhardt |
From a long-term perspective, our product launch goals and final operational goals are full of challenges, and there is only half a year left. To make Mission Impossible more convincing, I tried to make a plan for a full 6 months, but as soon as the plan started I ended the stupid idea - the future Idea is full of unknowns. Although scrum agility can give us more control, from the perspective of the product creation life cycle, the 2-week time box obviously brings great trouble to the output of requirements: if the definition of requirements is limited to 2 weeks, only The ghost knows whether the volume of these two weeks can satisfy the appetite of the next project Sprint, and this does not take into account the size of different functions and requirements. It is obviously unfair to place the demand for a user experience improvement and a growth system in two time boxes of the same length, not to mention that the product manager also needs to coordinate the page design, production and participate in the deployment acceptance at the end of the Spring cycle.
In a complex and challenging project, in order to avoid this problem and at the same time give full play to the advantages of Scrum agile project management, a "supply chain managed project management" method can be adopted.
In traditional manufacturing enterprises, in order to ensure the stability of production, manufacturers have a certain inventory of raw materials. However, with the in-depth development of supply chain management ideas, more and more manufacturers integrate supply chain resources and jointly manage inventory with suppliers to ensure that the production can meet market changes in the most economical case, that is, "flexible supply chain" .
In Internet project management, simple abstract requirements, design, and page production can be used as suppliers, general design, development, and testing as manufacturers, and inventory is the "demand pool to be developed". Unlike traditional manufacturing, the Internet project team can be simplified into two nodes in the supply chain. Suppliers provide manufacturers with production raw materials, and manufacturers process and test them and deliver them to the market.
Compared with Scrum agile project management, supply chain project management emphasizes the value of "inventory". The product needs to maintain the water volume of the "demand pool to be developed" before the start of the next time box; development needs to ensure that the Backlog in the inventory can be consumed in time . This makes it easier for team members to focus on the most important part (design or development) rather than ineffective communication. In other words, the traditional Scrum project management process is more like a big river. The upstream needs to ensure sufficient and stable water volume to ensure the downstream capacity; the downstream needs to maintain sufficient digestion capacity to avoid flooding or drying up. Supply chain project management is to build a dam on the river. As long as the water in the reservoir is within a safe range, regardless of flood peaks or severe droughts (surge in demand or sharp drop in demand), downstream production can ensure safety and efficiency. effectiveness. The focus of management can be on the security scope and priority of the "requirements pool to be developed".
Supply chain project management is a more macro management, which describes the upstream and downstream relationship between product management and project management. Pure Scrum may be more suitable for the entrepreneurial style of foreigners who are programmers and product managers. I have read almost all project management books that are regarded as bibles, and define requirements as the beginning of a project. This seems very correct on the surface, but Like a chicken rib, it does not clearly explain how to define requirements (recommended "The Elements of User Experience" ), but also causes trouble to domestic project managers and programmers.
Product (supplier):
From the "requirement pool" to the "requirement pool Backlog to be developed ", the product needs to go through four links: wireframe, requirements document, page design, and page production. The product manager is solely responsible for the iteration of product design, and selects high-priority ones in the demand pool. Goal, design and deliver the final complete requirements to the requirement pool to be developed. The requirements need to be packaged in units of " scenario stories " and prioritized; the priority of the requirement package needs to meet the normal distribution curve, such as the reservoir starts at each Spring Before, the safe range is 5-15 situational stories, when there are 10 stories, 2 are priority 1, 6 are priority 2, and 2 are priority 3.
Technology (manufacturer):
A week before the start of the next timebox iteration, the project manager confirms the Sprint Backlog together with the product according to the team's ability to bear , and conducts a requirement and use case review immediately. Once the scope is determined, the project can be rolled out (testing and architects can step in to do upfront work after the requirements are wireframed) and monitored with tools such as burndown charts . You only need to maintain a good rhythm later, and I believe that the feeling of being in control of the project will make you feel comfortable physically and mentally.
I don't know if anyone has tried similar ideas of supply chain project management. Its essence is to decouple the requirements and development in the time box of agile projects, which requires the requirements to be completed at least one time box in advance and redundant to the requirements to be developed. In the pool, the 2-week Sprint compressed in order to enhance the control of the project is returned to the project programmers and test engineers. The difficulty is that the requirements must bear enough pressure in order to ensure the safe range of the demand pool to be developed. Fortunately, I believe this pressure can be tolerated.
This is just a product manager's idea of project management, which will be further summarized after practice. If you have a better idea, please share with me.