Ten misunderstandings in software project management

With the continuous improvement of computer hardware, the scale and complexity of computer software also increases. Computer software development has moved from the era of "personal heroes" to the Age of team, and management of computer software projects has also moved from "Workshop-style" management to "software-driven" management. This requires software developers, especially software project management personnel, to have a deeper understanding of and grasp the theoretical methods of modern software engineering and to complete the transformation of ideas and concepts. I have analyzed 10 misunderstandings that may easily fall into the ideological concepts of modern project management, hoping to inspire others to think about and discuss them.

 

Misunderstanding 1:In the demand analysis phase of the project, the developer and the customer can reach an agreement on the basic outlines of various issues. The specific details can be filled in later.No matter how detailed at the beginning, modifications to requirements in the future are almost inevitable. Analysis: This is a very dangerous idea. In fact, the main cause of failure in many software projects is that the problem is not described in detail in the demand phase, resulting in a later budget exceeding or time schedule failing to meet the requirements. The correct method is: in the project requirement analysis stage, both parties must thoroughly discuss the project's application background, functional requirements, performance requirements, operation interface requirements, interface requirements with other software, and evaluation criteria for the project. In addition, after the demand analysis, both parties should establish channels for direct contact to communicate with each other as early as possible.

 

Misunderstanding 2:The needs of software projects can be constantly changed and these changes can be easily implemented.Analysis: indeed, it is difficult for the customer to fully and accurately describe all problems in the demand analysis stage for various reasons. As development progresses, there are often some changes in requirements. Modern software engineering theory also uses the flexibility of software to adapt to this situation in various ways. However, this does not mean that "the needs of software projects can be constantly changed and these changes can be easily implemented ". Practice shows that as the development progresses, the cost of changing software requirements increases exponentially. It is assumed that the demand change at the demand analysis level will cost twice; in the system design and coding phase, the cost will be 1.5-6 times; it costs 10-20 times in the system test phase; it may even cost 60-times after the software version is released. It can be seen that changes to software requirements should be proposed as early as possible during the project development process. In this way, it may cost less and is easy to implement.

 

Misunderstanding 3:SoftwareProgramMainlyCodeTherefore, the coding stage is the most important stage of the entire software project. It should be given a lot of time and focus on the main resources.. Analysis: compared with the past, due to the increase of software scale and complexity, and the emergence of semi-automatic software code development platform, the center of modern software project management has been transferred-not focusing on the coding stage, it focuses on the overall/Detailed design stage of the system. Generally, the rational allocation ratio of various resources in modern software project management is: 3% in project demonstration and risk assessment, 8% in project requirement analysis, and 45% in system overall/detailed design, code stage 10%, system test stage 34%.

 

Misunderstanding 4:To facilitate code maintenance and modification, you should write the pseudo code of all programs in the detailed design phase of the system.Analysis: Generally, the maximum effect of a pseudo code is on the program.AlgorithmThe process is described to help people gain a deep understanding of the functions and implementation process of the program. It can be seen that, to a certain extent, the pseudo code is indeed conducive to the maintenance and modification of the program code. However, we know that to ensure the one-to-one correspondence between the project document and the program code, we also need to maintain the project document while maintaining the program code. The pseudo code is very similar to the program code. If the pseudo code is maintained, it is equivalent to twice the program code maintenance. The workload is huge. Therefore, the practical method should be to implement a program flow chart for the general program documentation. For those involving more complex algorithms, the pseudo code is required.

 

Misunderstanding 5:Since a dedicated tester is set up in the project staffing, all the internal testing work of the software should be completed by the tester.Analysis: software program testing can be divided into two methods: "white box" and "black box. Because the "white box" method has various requirements on the quality of testers, the "black box" method is always the best choice for testers during program testing ". They often work in the "black box" Test of the program first; if the test fails, they have to consider the "white box" Test of the program code. Obviously, this "escape" intentionally or unintentionally to the "white box method poses a threat to the software's reliability and stability. How can this problem be solved? On the one hand, we need to improve the requirements for testers, and on the other hand, we also need programmers to complete some "white box" tests (in fact, programmers are often the best candidates for "white box" tests ).

 

Misunderstanding 6:Software project management is only related to the relevant technical departments and has nothing to do with other departments of the company.Analysis: In today's increasingly fierce competition, software projects are large, complex, and time-consuming. To improve the company's software project management level, it is necessary to improve the company's overall awareness of participation, the company's various departments need to work together. For example, the accounting department is required to assist in project budget, financial management and cost control; the research department (Technical Committee) is required to assign experts to assist in various risk assessment and provide technical guidance; the Logistics Department is required to provide various support.

 

Misunderstanding 7:When the development progress lags behind, you can hire more programmers to join the development team and add human resources to catch up with the progress.Analysis: in the era of team development, developers should carefully consider this practice based on the current software project management level. If the new programmer has a certain understanding of the application industry of the current software project, and can quickly adapt to the developer's project management method, software development style, and team collaboration atmosphere; therefore, it is helpful to add new users. Otherwise, you may be "willing to do bad things ". Despite its high personal abilities, the development team had to assign people to train the project-related technical/business personnel in order to work with everyone, what's more important (and the most difficult) is to guide them into the team. This may take a lot of time and effort from the development team, making the project progress slower.

 

Misunderstanding 8:The technical backbone should be the project manager of the project. The project manager must have the highest salary among all project members.Analysis: In the "software Workshop" era, this is a widely used and effective method. In the "software factory" era, this method has brought about various problems, sometimes the project fails. The main reason is that, with the refined division of labor in modern software development, the requirements for project managers have also undergone fundamental changes-the most important thing is not the mastery of a certain professional technology, it is its ability to organize, lead, and coordinate development teams (of course, both of them can be the best ). As for the salary of the Project Manager, this has a lot to do with the pay-as-you-go system. In general, the Project Manager executes the compensation system of management personnel, while others execute the compensation system of technical personnel. The Project Manager's salary is relatively high among the project members, but not necessarily the highest. Sometimes, to motivate technicians, the technical backbone in the project gets a higher reward than the project manager.

 

Misunderstanding 9:Only the project manager and department director are concerned about the overall progress of the project, and the programmer only cares about the development progress.Analysis: This is a "bureaucratic" idea. In fact, as a member of the team, a programmer is not only engaged in a job, but more importantly, participating in the creation of a "work. While appreciating the hard work, it is more important for programmers to enjoy the pleasure of creation. The project manager should not ignore the programmer's pursuit of "sense of accomplishment", but should explain to everyone how the final "work" will be wonderful and exciting, and set up a series of milestones on the way to the final goal. Whenever the project moves toward a milestone, the project manager should notify every member of the project. In fact, this not only allows all project members to enjoy the joy of a phase victory, but also inspires greater enthusiasm for work and improves work efficiency.

 

misunderstanding 10: to ensure that the project continues, raise the salary for retaining core programmers. analysis: salary increase is a common method used by many enterprises to retain programmers. This offer may take effect temporarily, but it is often because people have stayed, but the side effects have also come. People with salary increases may not see much work, but those without salary increases may start to neglect. In fact, too many projects rely on the programmer's personal technology as a "bad habit" in the "Workshop" era ". Since the flow of people in the IT industry is uncontrollable, project execution should pay more attention to the strength of the group, and the overall technical level and core technical capabilities of the company should be considered. Such as the company's own expert knowledge base, class/function library, third-party control library, and a development platform with independent copyrights. In addition, in fact, the reason why programmers give up their intentions is largely not salary, but lack of encouragement and respect. This requires the project manager to use the "old soil" method, find the right time to do ideological work for programmers, describe the bright future of the project, and let them feel concerned and respect. In short, we should begin to ensure the smooth development of the project from multiple aspects, rather than simply raising the salary.