Guide to "no pitfall" for software projects

How deep is a trap?

2. Who is creating a trap?

3. How to Avoid pitfalls?

"No one can change the status quo. There are only countlessProgram." This is not an exaggeration. If a software project fails, it is a pitfall, and the participants are just a pitfall. Just like meeting the national team on the World of Warcraft battlefield, you cannot win or even get out.

How deep is a trap?

When we enter a project, we can constantly observe whether our project is a pitfall. Pitfall projects often have some "bad smell". The following are some of my understandings. These "bad smell" is a clear sign of poor project Health:

• The code specification is similar to the waste paper,CodeLow QualityEvery project has code specifications, but strict implementation is another matter. There are too many projects that use coding standards as their forms. No one cares about letting developers write "programs that can be understood by people". Comments and naming have become what developers do. There is always only a development task in the project, but the unit test time and code review time are hardly found. Projects under high pressure appear to be so shanzhai. When we are still complaining about our low salary, let's see if our program can be called oop.
• Lack of documentation or low document qualityThe preliminary documents are very important, including the API User Manual of the framework, the requirement or design documents, the specifications of various established processes, templates of different types and checklists, etc, A project is a very important resource. In some projects, such documents are written by non-software industry personnel, or they do not plan to waste time on documents in the early stage. This leads to the lack of relevant documents or document quality being low. During the software building process, developers and teams have to struggle for the product of this "Surface Engineering. It may even be returned to the preliminary preparation to complete the required documents. Some documents can be supplemented later, but some documents must be prepared in the early stage to keep the team at risk reduction, reduce the probability of defects attracting and improve the coding quality. If such documents are not completed in the early stage, so it will be like not reviewing before the exam, self-harm.
• Endless changes in demand will never catch up with the progressThis is the most common and terrible, because we cannot do it anyway. The customer may think that changing a program is just as easy as changing an Excel file, and may even use all the rights and resources available to implement the change. Well, I admit that I have met many such customers. After I have explained the cost of the change to the customer and provided an alternative solution, I can only wait for the customer's choice, but it is helpless.
• Work overtime alone to cope with lags behindIt's not terrible to lag behind. What's terrible is that you only need to work overtime to catch up with the progress. This is the key to the problem. After a long period of work, you still cannot catch up with the progress. This only means that the project has a deeper level of problems, which cannot be solved simply by work. Pay attention to projects that work overtime for a long time. They often have a lot of problems in management. When you find these problems, do not make similar mistakes when you become a PM.
• No communication skillsIf you are in a project called "day-to-day", you 'd better worry about it. Communication is very important in projects, but in some projects, leaders are too busy to find their jobs, and no one can return the emails they send. If they encounter problems, they are responsible for themselves. There are also some benefits in such projects, such as training your self-learning ability and training your will and root. However, these are also my self-ridicule. Inefficient communication will lead to unnecessary rework, which is what I hate. One of my most annoying experiences is that party a wants to make a change and no one will inform me after a week, my team completed several originally planned needs and entered the testing phase during the week, but these requirements were all cut off. Originally, only Party A informed that the development progress could be adjusted to develop other modules, but it eventually evolved into a waste of resources. It can be seen how important communication is.
• No one cares about QualityBecause software construction is in a professional field and customers do not have knowledge in the relevant fields, this information asymmetry has contributed to the low quality of software. The software we develop can be "low-grade and high-quality", but not "high-grade and low-quality. However, too many projects do not focus on coding quality, which is related to the complexity of software building and the ethos of the entire industry. However, whatever the reason, improving the code quality should still serve as the team's effort. The team should reward programmers who write high-quality code. If your team is rewarded with "bug killer" (modifying hundreds of bugs every day), and the programmers who have detected very low defects are left out, your PM is technical-insensitive. At least I personally think that any PM with a technical background should reward programmers who are maintaining professional ethics, taking requirements seriously, and ensuring code quality. They have paid more for the project, more exception handling, more test debugging, more checks, and more refactoring, although their progress is not fast, but they have very few obvious defects. Every developer will make a trade-off on quality and progress, and I admire those who choose quality programmers because they are the ones who really take development as a career. Here, I would like to pay tribute to all programmers who strive to improve the code quality!
• No one pays for the defectNo one is responsible for their own results. The requirement outputs a low-quality document, and the design is not fully iterated. How can developers write it easily? tests can be tested at will. No one pays for the defects in their own results, except for the project manager, he takes sole responsibility for the project. When all the project team members are mixing up, they are digging holes for themselves. The accumulation of such defects will be like the accumulation of radioactive elements in the food chain, and projects will crash in the morning and evening.
• High resignation RateThis is the most obvious "foul smell", which indicates that our peers are intolerable here. Its negative effects are not only reflected in the reduction of available resources, but also in the huge impact on member morale. If it is not improved in time, this will be a very vicious cycle. When you add resources to a project that is lagging behind, the progress will only lag further, rather than leaving the company, new resources must be added. from recruitment to training, the resources will fluctuate with the team and reduce the productivity of the current team. It is difficult for a team that is frequently in the formation stage to require cohesion. Team issues will be highlighted, especially in communication. when the project is busy, it is rare to take care of new people. The time spent on training new people and communicating with them is likely to be worth the candle.
• Bad mood in the teamDifferent teams started to get together and become hostile to each other. For example, the development team thought that the design team was an idiot engaged in business and did not understand programming. The test team thought that the developers were spam, when a bug is submitted, it cannot be closed. PM starts to complain that its members do not cooperate. Members start to complain that PM is purely managerial and not qualified to direct the experts to do things. And so on, such resentment will accumulate in the team and take a fuse as an opportunity to erupt. Face the reality, at least, I am far from as noble as I think. I admit that I would once say to other programmers, "You see the code they wrote in XX. In the past, I also spoke about other people's code. This is wrong and I am sorry for this. Now, if necessary, I will say that the Code is defective, but it will never be said that its code is not good. I hope we can respect each other. For a technician, if he does not respect his achievements, he or she does not respect him. Therefore, I suggest that PM use "defects" in management ", use less "NO" or "no ". However, there are always some people in the project who despise others' achievements to demonstrate their own strength. There are few. At least I have met a few people. I have met a few people. Let's make their words a motivation for your learning. I was once ridiculed that the UI was too ugly, and then I learned SL and flex. I was despised by people and started to read CLR via C #. my friends have been ridiculed for database design, and now they have begun to buy books for further study. In the team, we can't control others' mouths, but we can control ourselves. Speaking less and listening more, a blockbuster, is the best strategy. Do not be influenced by emotions, so keep yourself calm.
• Post-evaluation without project or stageIf you do not post-review the project stage, no one cares about what you actually did. All of you are not evaluating the progress. This also means that you cannot get the attention of the leaders by doing your job well. In the end, only the programmers with the longest overtime hours are recognized by the leaders. A strong team member with good reputation can only leave legends between the Team and the customer.

2. Who is creating a trap?

Software projects involve a large number of people, and most of the pitfalls are within the project implementation team. The reasons are also multidimensional, but the four dimensions of the project-time, scope, cost, and quality. Most of the time, the customer does not have the implementation experience of software projects, and the implementation team will do more or less in these four dimensions to cater to the customer's wishes.Article. Resources, insufficient time, and light-weight functions often become an opportunity for creating pitfalls. Therefore, there is no need to doubt that we often build ourselves. It is hard to understand that the person who actually dug the big hole is also the person who finally filled the hole. It is easy for a person to be influenced by external firms, just like "a lot of the same fake, it's really the same as a fake". Most people don't want to stand alone in a new environment. But some old programmers also said to me: "When someone else does something wrong, you should not follow it !" Therefore, I think work is a task, and we do not need to integrate much interest into it, nor need to make too much effort, but we need to take the results of our work seriously. As the saying goes: "How much is it, how much is it !" If some teams are conscious and responsible for their work, we can at least make fewer pitfalls for ourselves.

3. How to Avoid pitfalls?

(1) Clear blind spots

The following points are my summary of some mistakes in software projects:

• Write a usable program!First, we should know what we are doing. The deliverables produced by a mature team should include software programming products and related documents, some other non-formal results (training) have been learned from the project implementation process ). Here, we must clearly understand that we are developing a programming product, rather than our individual technical practices or university design. For programming products, we must realize that they are product-level, must ensure quality, must improve user experience, and must consider many features or dimensions of the system. This process is far more complex than writing a program. The design needs to be continuously iterated; developers need to comply with stringent specifications, write a large number of comments and handle a large number of exceptions; testers need to continuously perform various repeated tests, but it is such a global specification that the unremitting efforts of all teams ensure that our programming products can be called products. Therefore, we must make it clear that what we want to accomplish is a product, not a graduation design. It is not a technical practice of a person, but the best result that the entire team is devoted. We can easily implement certain customer needs, but some things behind the requirements need to be taken seriously, such as security and performance. Anyone who implements the function will write it, and writing high-quality programs is the real art.
• Start encoding as soon as possible!Software components are a well-designed process, and their preliminary preparation is very important. The cost of fixing defects in the future is much higher than that in the early stage. Therefore, before the project is executed, it is necessary to implement the regulations in the early stage. Each defect found in the early stage will save a lot of cost for the later stage.
• How have requirements changed!There is no constant demand.
• Recruit people when the progress lags behind!This is a typical misunderstanding. The Mythical man-month has clearly stated that injecting resources into a project with poor progress only causes the progress to lag further. Although this book has become a must-read task of PM, its idea has been widely recognized by the industry, there are still many managers who simply think that injecting resources can solve the problem. For these people, we can only let practice test the truth.
• Software Quality Assurance is a test task!This is an escape statement. If you compare the code quality to losing weight, the test is undoubtedly a scale, and developers must complete the weight loss work. Therefore, do not expect code quality to be tested. Even for large-scale user tests, the error detection rate is less than five. What really bears the burden on code quality is code review.
• Programmer, have you written such code in 8 hours?It is impossible for developers to spend all their time coding. Developers need to read documents in advance, communicate with relevant stakeholders, and spend time searching for resources. In addition, you may need to write documents, attend meetings, train, and handle personal affairs. These times will relentlessly take away the encoding time. Programmers spend about 20% of their time or even more on coding-related things (not counted as work or chatting with qq), so do not mistakenly think that every programmer can write 8 hours a day.
• It's really efficient to write so many lines of code today!The code is not sweeping the floor, which is larger than the scanned area. You cannot simply use the number of lines to evaluate the workload of developers. The criteria for evaluation should be based on the complexity of the module, the number of defects and the ratio of available code at the end of delivery (practices show that we have scrapped a lot of useless code ).
• He modified more than 100 bugs today, and we have to praise him in the group!In my opinion, such a leader is not followed, and this is quite speechless. Before submitting a test, a good developer feels that he or she will conduct code inspection and debugging, or even use a unit test tool. Therefore, the number of defects in the Code is small. Such programmers are worthy of praise. The person who changed his 100 or more bugs on that day should think about where the process is wrong and need to be improved.
• you can design it and shut up development! there are many such examples. There is a reasonable reason for this practice-to ensure the conceptual integrity of the Project architecture. It is explained that, if the designer is separated from the developer, the conceptual integrity of the architecture can be unified, because the number of designers is less than the number of developers, it is easier to unify understanding. By default, the project team thinks that the technical strength of the design group is significantly higher than that of the Development Group. They often choose good designers from the development team to the design group, but there will also be eye-catching. First, hard-handed personnel were not promoted. At this time, most of them were hard-handed and dissatisfied with the design. They questioned the team's management and tried to communicate with each other. If the problem is handled well, it may be hard-handed. If there is no way to communicate with each other, it may be filled with complaints and dissatisfaction, and the deterioration of interpersonal relationships. Some tough ones may choose to reject unreasonable designs or, more importantly, resign. Another kind of situation is that the pick-up cannot do the design. This is often to let him exercise, rather than switching (Peter's principle-everyone will be promoted to a position he is not suitable ). This is so depressing that the designers will have a long-running dark battle with several developers. Among them, it is not just personal complaints, or even the morale of the member groups, and ultimately facilitates the restructuring of the group. I think it is necessary to include developers in design activities. There are three reasons for reference: first, developers are quite familiar with implementation and often find deficiencies in design. Second, developers can feel their sense of identity by authorizing them to participate in design, improve their desire to participate in the project and their sense of responsibility; third, let the development participate in the design, the design staff can be reserved, as needed as an alternative resource.
• The customer (LEAD) says it must be done, and I cannot help it!This is "the leader's words: the working people are disconnected !" This is a typical overtime excuse. The software build process is like farming. You only process a small part of it each time, and add 1.1 points to the entire system to make the system grow at 1.1 points ". This also implies that work should be performed step by step. Just like the spring Harvest and autumn harvest, each link has a strong logic. Therefore, we must learn to say "no" to unreasonable requirements ". This does not mean to reject the customer's needs, but to inform the customer of the situation and propose appropriate alternatives for reference. For example, the project can be completed on time by reducing the scope. PM needs to inform the customer of the situation and provide several feasible solutions to facilitate the healthy development of the project.
• I'm the leader!The arrangement of work progress cannot be a unilateral decision of the leader, but should be based on the opinions of the person who understands the work.
• After the system is launched, the project is over!Only when deliverables are successfully handed over, the corresponding finishing work of the project will be completed, and the lessons learned document of the project will be summarized and summarized.

(2) Suggestions

• make preparations , if appropriate preparation activities are carried out carefully before building the project, the project will work well. Adequate preparation prevents us from making a wrong product. The quality of the preliminary work will lay the foundation for the success and failure of the project. Even when we enter the build phase, if we find that the preliminary work is not doing well, there is no reason to return it. Preliminary preparation and core goals are to reduce risks-a good project planner can clear the major risks as early as possible so that most of the project's work can be carried out smoothly. Currently, poor demand analysis and project planning are the most influential risks in the future. Therefore, preparation tends to focus on improving demand analysis and project planning.
• do it in advance, you must first sharpen the tool to improve production efficiency by using the software armed team, such as version control, Error Tracking, Information Release, automatic release, CASE tool, debugging tool, and test tool, document management and code generation tools.
• analysis project type, finding a balance between management and construction commercial systems, mission-critical systems, and life-critical systems have different control granularities throughout the project phase. It is necessary to determine the degree of rigor of management based on the specific project type to avoid "excessive control" or "insufficient control ".
• requirements must be frozen requirements must be frozen. If requirements cannot be frozen, so it's useless for anyone to come. A strong team cannot complete an endless task.
• the change must follow the process to respond to the Change correctly. The change is not terrible, what's terrible is a runaway change. The following suggestions may help readers:

handle demand changes during build

1. check the requirement and evaluate the quality. If the requirement is not good enough, stop it and try again.
2. make sure everyone knows the price of the change: it is not as easy as making a few changes in Excel to let customers know what they want. "progress" and "cost" are your most powerful weapons.
3. set up a change control program: a fixed change control program that lets you know when to handle changes, let customers know that you will handle their proposal.
4. use a development method that can adapt to changes: iteration and increment.
5. discard this project: If none of the above proposals works and demand changes are extremely frequent, evaluate your project, consider giving up on it. Continue on, and you will only get deeper and deeper.
6. pay attention to the commercial case of the Project: cost-effective, and there is no need to meet the demand that exceeds the project cost.

• About overtimeIt is normal to work overtime for it, but overtime is meaningful and should not work overtime for a long time. You must rush to work on the Key Path, rather than doing something that cannot speed up the overall progress. In addition, adjustments should be arranged instead of overtime. The main reason is that I am not in favor of working overtime-fatigue is more attractive. Working overtime will undoubtedly make people tired. Everyone wants to finish their work as soon as possible and then go home to rest. In the case of long-term fatigue, the staff's work efficiency will decrease, morale will be low, and the abnormal resignation rate will increase. The most important thing is that the tired team is hard to ensure the quality of software, the defects are noticeable and will undoubtedly be paid in the future. The total cost and cycle of a project multiply with the increase in the number of defects that are noticeable, and the later the project is discovered, the more serious the project is.
• Complete version control and configuration managementVersion Control and configuration management are necessary. Even small projects cannot be ignored and must be taken seriously. Once the version is chaotic, it may affect the construction activities more or less. Therefore, do not be lazy and manage each baseline.
• Benefits of authorizationThere are many benefits of authorization, including: 1. reduce the workload of managers; 2. consciously exercise and cultivate reserve talents; 3. Increase the personnel's participation in projects to increase morale.
• Optimistic management and pessimistic ManagementOptimism and pessimism depend entirely on people's personalities. Generally, they tend to be optimistic. We should be clear about the advantages and disadvantages of these two personalities in projects. I personally tend to be pessimistic, probably because of my own personality, but pessimistic management will at least not lead to mistakes. The advantage of optimistic management is that it is easy to create an atmosphere and is good at describing a bright future for customers or leaders. This style is very comfortable in the early stage, but it may be difficult in the later stage. Optimistic management is prone to insufficient risk estimates, insufficient buffer time, and insufficient preventive measures. The performance is that when you plan the progress, you always think that today's problem can be solved today, and the bugs that have been fixed will not appear again. The user requirement is the last change, so on, such optimistic ideas will blind managers and fail to cope with risks. The result is that no matter how long they work, they will not be able to catch up with the progress, because the schedule is designed to be the most smooth, it is not a real scenario. The advantage of pessimistic management is that it prepares for potential risks. However, there is a major defect in pessimistic management, that is, "excessive control", which can be compared to "suspicious heart disease" (both careful and ill-intentioned ). The performance is as follows: according to the previous measures, if a problem is found to be missing, the pessimistic manager will add new safeguard measures based on the previous measures, and then discover that a problem is missing, then, we will continue to add safeguard measures. At first glance, there is no problem, because it is constantly improving the process, but the problem is that the growth rate of safeguard measures is too astonishing, and it is not a "suspicious heart disease" at all, pessimistic managers can easily put too much control in a very small place, resulting in a waste of people and days, and ignore the more important issues that should be concerned. Regardless of personality management, it is always good to know your weaknesses.
• Effective communication, do not play the ballSoftware Projects Require communication because of their complexity and a large number of stakeholders. Communication problems are shared by all large projects. In most teams, communication is often not considered a problem. However, I still want to ask readers to take communication seriously, such as emails. The email can be replied slowly, but please reply to the email. When I work in a team that even sends an email and no one replies, I feel helpless and indifferent except that the problem cannot be solved.
• Customers are our friendsTaking your customers as friends is one of our important resources. More potential customers are often hidden behind each customer. We must be clear that customers, as non-professionals, may not understand our work. It is inevitable that there will be friction during project implementation. However, none of these can be an excuse for us to anger customers or deliberately put water in our work. We must maintain the relationship with our customers even if the project can be completed successfully.
• Do not design ahead, do not project Gold PlatingAdvanced design and gold-plated projects are not desirable because they are a waste of resources. Meeting anything other than your needs will not be of any benefit to your project, but it may be flawed.
• Lessons learnedLessons learned at the stage must be summarized, and nothing is more valuable than these gains. This document is the assets of the Organization and serves as a reference and basis for similar projects in the future, and plays a more important role in the continuous optimization.
• Don't put meetings and documents on the team's feet"When the ship is about to sink, what we need is a command-issuing leader, not a meeting ." The core issue of software projects is to reduce complexity. The more complex the project is, the more communication is required. But don't let the meeting drag us down. If there is no need to open as few or as few meetings as possible, it is necessary to hold regular meetings and small meetings. Each meeting can be attended by several stakeholders, and there is no need to expand to full participation. Lengthy discussions should be terminated at the right time. After all, decisions can only be made in the conference room, and problems must be solved. So I think we should streamline those lengthy meetings. In addition, always remember that what the customer ultimately needs is a software product that can run well, rather than a gorgeous document. Therefore, the document should be just right. If there is no complete system for writing beautiful documents, it is just a pile of waste paper. Don't lose the watermelon and pick up sesame seeds. The software that can work normally is our focus.
• Check your table.Just as aircraft engineers use checklists when inspecting airplanes, software projects can also use a large number of checklists. The checklist can help check document quality, reduce the number of defects, and improve project management. A good checklist is a good assistant in your work.
• Controlled in a small scope, out of control in a large scopePay attention to the granularity of control. Depending on the project scale and personnel composition, different control granularities should be adopted. The controllable scope of evaluation does not mean the wider the control, the better the control, or the out-of-control. It is feasible to authorize others to manage places with no care. Even if it is controlled in a small scope, it is better to get out of control in a large scope. No one knows where a runaway project will go.

1. Check the requirement and evaluate the quality: if the requirement is not good enough, stop it and try again.
2. Make sure that everyone knows the price of demand change: it is not as easy as making a few changes in Excel to let the customer know the demand, "progress" and "cost" are your most powerful weapons.
3. Set up a change control procedure: a fixed change control procedure will let you know when to handle the change and let the customer know that you will handle their proposal.
4. Use the development method that can adapt to changes: iteration and increment.
5. Abandon this project: If none of the above proposals works and demand changes are extremely frequent, evaluate your project and consider giving up it. If you continue, you will only get deeper and deeper.
6. Pay attention to the business case of the Project: cost-effectiveness, and there is no need to meet the needs that exceed the project cost.