Shulou(Shulou.com)05/31 Report--

This article introduces you how to elegantly solve the problem of project Delay and poor delivery quality, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

Why are you writing this article?

After working on the project for so many years, I have participated in numerous project reviews inside and outside the team, and found a lot of project delays and customer delivery quality problems. These problems have brought a lot of emergency "fire fighting" troubles to the product and technical leaders. After analyzing these Case, it is found that the problems focus on the following aspects:

Unclear definition of requirements, defective system design, lack of assurance of R & D quality, and time-consuming ineffective communication lead to repeated and serious delays of the project.

Cross-team collaboration promotes high cost, multi-team delivery schedule appears Delay, and the overall project goal is out of control.

Summary design documents, API manuals, product user manuals and operation and maintenance manuals are of poor quality and high learning costs for customers.

Our team usually uses a project review (Case Study) approach to deal with these situations. The main purpose of the review is to solve the following two problems: first, to find feasible solutions for project delays and customer delivery risks; and second, to give team members some guidance to avoid repetition of the same problem. Of course, these reviews are generally carried out within a project team and need a way to be shared among multiple project teams, which is why I wrote this article.

Project management and R & D quality control is a relatively complex system engineering, this paper will not systematically explain some theories and principles, but take the actual case as the index to share the common problems in project management and the methods that must be taken. I hope it will be of some help to the new project management students.

Case 1: business projects in which multi-role personnel collaborate

Scene description

A monitoring product needs to provide multiple metrics trend chart comparison and view function for multiple cloud services of multiple Region (such as virtual machine, database component, cache component, message queue component). Product R & D requires PM to design product form and logic, UE to design product visual interaction, several FE R & D front-end pages, a number of RD R & D back-end business logic, QA to test business functions, and joint launch of FE and RD after passing the test. The project research and development was delayed from the expected one and a half months to the actual 3 months. After at least 5 rounds of testing in R & D, 2 product defects and 5 technical scheme defects were found. The convergence rate of low-level Bug prediction 20 years bug is very slow. This is an extremely typical case of project management and R & D quality out of control, most of the participants are new students, and there is a serious lack of awareness in the R & D process norms.

To facilitate your understanding of the project process, note the relevant product design, interface design, and low-level Bug examples:

Product design defects: PM product design omitted to mark the cloud service names of different Region on the trend chart, resulting in users being unable to locate the cloud service instance to which the metric belongs.

API design defects: the product requires a trend chart to support a maximum of 30 cloud service instances. The front-end FE API parameter verification is limited to 20, and the back-end RD API parameter verification is limited to 10. No matter how long the time period selected by the user, the granularity of the metric query is 60s, resulting in poor rendering performance of pages with too many data points returned.

Low-level Bug: you can view the trend chart after selecting instances and monitoring items, but the trend chart does not disappear after deselecting the monitoring items; the time selection box fails to control the time period of the index data displayed in the trend chart.

key problem

At what stage should product design and interface design defects be discovered?

Why are there so many low-level Bug? Why is Bug converging so slowly?

When there is a delay risk in the project, at what stage should the project leader control the risk?

Solution

The key to this project is that it does not strictly follow the conventional software development process specifications.

PRD was not reviewed, and PM simply drew several prototype diagrams to arrange front-end FE and business RD development, resulting in product defects not found in the PRD review stage.

The interface design between the front-end FE and the back-end RD is not fully documented and not fully communicated; when RD tests the code, it does not go through the joint debugging of the overall scenario and Demo Review, resulting in the low-level Bug only exposed in the testing phase.

The test admittance of QA is not strictly implemented. When there are many low-level Bug, QA does not implement test return.

Instead of reviewing the problem when the project was about to be postponed, the technical leader followed up the problem two weeks after the delay, missing the critical project repair time and adding a lot of unnecessary multi-person collaboration costs.

This case is common among many new team members of new projects. For multi-role collaborative projects need to implement strict R & D process specifications, requirements-related MRD, product design PRD,UE design drafts, overall design and detailed design documents need to be written in accordance with the specifications and reviewed by the team, only the previous link passed can move on to the next link. Early communication and continuous communication enable developers to get information about products and business, and always follow the principle of "early detection, early solution", so that we can correct problems at the lowest value stage of the software development process. RD needs to conduct system tuning and Demo Review before delivering QA to ensure that R & D and product design are consistent. The R & D quality needs to conform to the coding specification, and there is a single test index, and the line coverage and branch coverage of the single test are not up to the standard QA can refuse the test. QA needs to strictly implement test admittance. Students with more lower-level Bug not only refuse to test, but also publicize the code quality of each student in the project within the team.

Project managers need to implement strict R & D process norms and reasonably arrange the progress of the project. The usual experience is for 1Compact 3, 1gam6 coding, 1ap4 component testing, and 1can4 system testing, so don't save time in the early design review phase and the later joint test phase, otherwise the project risk will occur frequently and get out of control. Any creative activity is accompanied by boring and hard work, and programming is no exception. People usually expect the software project to converge faster towards the end of the project, but the closer the situation is to completion, the slower the convergence. The exposure of a risk problem, the progress deviation of a milestone, will eventually accumulate and cause the overall progress to deviate far away. Chronic schedule deviations are morale killers, and early problem reviews and continuous information synchronization can help get derailed projects back on track.

Case 2: multi-team joint solution implementation

Scene description

The department sets up a joint project of nearly 20 teams to implement the SCAR (project code) of the core line of business. The main goal of the project is to combine the capabilities provided by multiple platform systems into a complex solution to help the business enhance its capabilities. The cycle of the project is one year, and multiple platform R & D teams and more than a dozen business teams need to complete the R & D and business landing of the solution. In the initial stage of the project implementation, it is found that the platform development meets expectations, and several business teams do not promise a clear landing time, or the promised time lags behind the project expectations because of the impact of other projects of the team. The joint team adopted urgent communication and implemented some dual reporting mechanisms and indicator control methods to ensure the timely delivery of the project. The successful landing of this project on the business line has achieved very good results, as a successful case in multiple teams to do project management sharing.

key problem

How to ensure the consistency of multi-team goals?

How to follow up the project and find the schedule risk in time?

Solution

An important problem of multi-team collaboration is that each team has its own key project indicators, and the SCAR project is only one of them, or it may not be its key project, and the attention and resources invested by each team may not be sufficient. In this case, it is necessary to set up a horizontal joint virtual team, define the project goal at the manager level of multiple teams, make the goal become a part of the manager's own assessment KPI, and each team needs to select a member to participate in the joint project as an interface. The virtual team implements a dual reporting mechanism, in which team members not only report to their respective managers, but also need to report to the head of the horizontal joint team. When the team members' performance appraisal at the end of the year, the leader of the horizontal joint team will also give an evaluation. This mechanism can ensure that the project managers of each team support the project, and that cross-team members have sufficient input and friendly cooperation in the project.

Because there are many teams involved, the landing progress of multiple business teams is a black box for horizontal team leaders. Horizontal joint team leaders need to set appropriate indicators to monitor project progress and identify project risks. Key indicators include the following three categories:

Leading indicators (Leading Indicator): the indicators are established at the beginning of the project to clarify the capabilities of the SCAR system and the coverage of implementation in the business line at the end of the project. Through these indicators, project leaders can be guided to pay attention to the things that should be paid attention to in the black box.

Linear indicator (Linearity Indicator): in order to achieve the ideal progress target set by the goal, it can be understood as the quarterly and monthly KPI index of the project, such as the progress of system development, such as the implementation coverage of the business line. Taking the implementation coverage of business lines as an example, there may be 14 lines of business, 4 lines of business in the first quarter and 5 lines of business in each of the next two quarters. The linear goal is set to guide the progress of the project in stages, so as to avoid the overall uncontrollable project risk because the time span of the project is too long.

Trend indicator (Trend Indicator): predicts the future from trends based on time criteria and based on observations of the past. For example, the initial system of the project is not easy to use, the cost of business landing is high, and the early business implementation coverage index may lag behind the linear index set at the beginning. After a period of system optimization, the cost of business landing becomes lower, and the later business implementation coverage index may be faster than the linear index set at the beginning. Project leaders need periodic Review project trend indicators, timely coordination of resources, adjustment of project schedule and risk control.

Through the dual reporting mechanism of the virtual team, by setting the leading indicators and linear indicators of the project and periodic Review trend indicators, project leaders can better identify project risks and schedule resources to solve problems in multi-team collaborative projects.

Case 3: ToB customer acceptance project

Scene description

The team undertakes the development of a customer's platform and provides complete system summary design documents, user manuals and standard operation and maintenance process manuals to the customers when they need to be delivered. In the early stage of project delivery, the team conducted a spot check on some documents and found that some documents are lack of completeness, readability and maneuverability, so there is an urgent need for standardization and optimization. In order to ensure high-quality output to customers, the team fell into an urgent document optimization process, and many RD and PM went into overtime "firefighting". In the ToB project, each document represents the commitment and service awareness to the customer, represents the technical literacy of a team, and needs to be taken seriously.

key problem

At what stage should documentation be written? What characteristics should a good document have?

How do team managers and project leaders ensure document quality?

Solution

Summary design documents need to be produced and reviewed in the project design phase, not supplemented in the project delivery phase; interface design needs to be complete and reviewed before research and development; user manuals need to be complete before the implementation of customer training, with good readability and low cost of customer learning; operation and maintenance inspection and fault handling SOP manuals need to be completed before delivery to customer operation and maintenance, and implemented through drills.

A team should have certain executable documentation specifications, rather than taking it for granted that each team member gives full play to his or her talents, and the quality of delivery varies. The maintenance of each document also provides a project status monitoring and early warning mechanism. The document enables various plans and decisions to be communicated throughout the team, and it is also convenient to find the problems of the project in time.

The summary design document needs to clarify the background of the project, the explanation of the name, the functional overview, the performance index, the dependent software and hardware environment, the overall architecture of the system, the core business model of the system, the data relationship between the modules of the system, the functional overview of each module, and the interface description of each module relying on third-party services.

The HTTP Restful style interface design document needs to specify the resource-oriented HTTP URL design method, HTTP Method usage instructions, HTTP Status Code usage instructions, interface authentication methods, various parameters input and returned by the interface, and the clear meaning of the system error code returned by the interface.

The user's manual needs to be scene-oriented, with screenshots, and the user needs to clearly identify the risk of misuse. The operation and maintenance inspection and fault handling manual needs to be clear and executable.

The implementation effect of the document specification needs to have a quality control method, otherwise the document specification will become a decoration. The method commonly used by project leaders can be called "customs and monitor", and the quality control method commonly used by team managers is random inspection.

"Customs" means that we first set up many hurdles, and only after the document has passed the inspection can we enter the next R & D process. If the document fails to pass the review, it will be redone or discarded. Summary design documents and interface design documents should use this method.

"Monitor" means that we can mark the content of a document that does not meet the quality inspection. The document will not be intercepted at all levels in the process, and the whole process will become smooth. In this kind of detection, if the problem exceeds a certain amount, it needs to be revised immediately. For the coverage of the scene in the user manual and operation and maintenance inspection manual, we can use the "monitor" method to carry out multiple iterations according to the situation.

A random test is a random test. Because there are so many projects, different project leaders have differences in the strictness of document control, so for team managers, the cost of document-by-document inspection is very high, and it is only natural to change the frequency of inspection. If a manager is hands-on to his subordinates, it may lead to intervention and will waste more time on subordinates who are infallible. To make matters worse, his subordinates may become dependent-the boss will check everything anyway. The application of random test in management can not only increase the sense of responsibility of the project leader, but also save the manager time.

No matter which document quality check method mentioned above is to cultivate the team's awareness of document quality, because each poor quality document delivered to the customer may lead to the loss of customers and affect the team's word-of-mouth and product brand.

Send a message

The above is a review of the problems encountered in several typical project scenarios, and the implications of these cases are as follows:

Multi-role collaborative business projects: strictly abide by the software development process & early detection of problems and early resolution

Multi-team joint solution implementation: establishing a dual reporting mechanism & setting and targeting business indicators

ToB customer acceptance Project: cherish customers & attach importance to the quality of team document delivery

On how to elegantly solve the problem of project Delay and poor delivery quality is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.