Project development project management)

I hope you will discuss some ideas about project management.
the success or failure of a project is variable, both technical and management, there is also a relationship between our own and our customers, but as long as we do what we can control, at least half of the success of this project.
there must be some changes to the project, and the changes are usually frequent. How can we cope with such changes in the customer's needs. First, we should do a good job in the preliminary demand research and try our best to consider it for the user so as to maximize the functional quality. Both the "goal and scope" in the early stage of the Demand Survey and the "Function Specification" at the end of the Demand Survey should be signed and confirmed with the customer. This ensures that what we understand is what the customer wants, it also makes the project end-to-end and the Customer Acceptance time based on evidence. Based on my own project experience, since customers generally do not know much about computers and communicate with them in our industry, they do not understand, if you use documents that are difficult to understand, and there are a lot of documents, the customers are tired of reading them and it is not intuitive. If the customer can see that this is what they want, I personally think the best way is to build a system. The system should be developed in the real environment under the guidance of analysts during requirement analysis. Of course, development is only a functional simulation of the interface, there is no underlying Code implementation. This has three benefits: first, the customer intuitively sees what their system looks like and how it operates, and second, the development results can be reused, third, it can better stimulate customers' needs.

In the middle of the project, it is very common to have demand changes. At this time, we need to do a good job in the demand change management process. The requirement change table is easy to understand. The customer requires developers and designers to discuss the changes and submit them to the Project Manager. The project manager estimates the time of the change loss project, submit the change to the customer at a certain stage. Major changes should be submitted to the customer directly, and the customer should be informed of the impact of the change on the project, and kick the ball to the customer as much as possible, let the customer balance the progress, functions, and resources. The requirements are classified and rated. The key parts cannot be changed (such as the system architecture ). At the same time, it is best to complete the customer's signature confirmation. Of course, if this part can be written into the contract details, it seems that the domestic contract is basically committed during the order, and it will not be detailed, the problem is discovered only after the contract is signed. However, the contract can indicate the level of requirement change, the amount of money, etc. signing a contract is also a very high skill, we recommend that you sign the system boundary, function scope, and solution together with the contract so that the new functions proposed by the customer can be put on hold. Of course, this requires a high level of experience and skills from the Project Manager, rather than just learning.

The following describes the cause of failure in project development based on my project development experience:

I. In the demand research phase, we did not have enough detail. During the survey, it was almost a unit of half a day. We collected some reports and did not understand the user's needs at all.

2. We do not pay enough attention to the customer's existing system analysis and research. The system we developed is an existing system of the customer. They have been using it for many years and have formed their own habits. In addition, their old systems also have their advantages and are gradually improved in the use process. However, we completely ignore the existence of old systems during the development process.

Iii. signing a contract is also very important. I have already mentioned the specific content above.

4. There is no functional specification. This is the biggest mistake in our project, and the changes made by our customers make us passive. The Feature Specification reflects all the features required by the customer. We also developed the features in accordance with the Feature Specification. Subsequent customer changes can be compared with the "Feature Specification". The specific change is implemented according to our change process. Lessons learned: the functional specification as the final result of product requirements must be comprehensive: All requirements must be included. Developers and customers cannot make any assumptions. If any desired functional or non-functional requirement is not written into the software requirement specification, it cannot be part of the protocol and cannot appear in the product. And pay attention to the following points: integrity, correctness, feasibility, necessity, priority, non-ambiguity, verifyability, consistency, modifyability and trackability

5. The earlier the project developers invested too little, the longer the project cycle, the more unfavorable it is for us. There are mainly the following points:

1. The longer the time, the more customer needs and more changes, the greater our risk.

2. Political changes often occur in a long period, such as changes received by customers.

3. A long project cycle may lead to increased staff flow and reduced work efficiency.

Lessons learned: invest more manpower in the early stage and complete the work as soon as possible to reduce our risks.

6. project management personnel are critical to project success or failure. Especially for companies like ours, they have higher requirements for project managers and have high requirements on the overall quality of personnel in this position. Why? Let's start with the work done by our project manager, in our company, the project manager should undertake the preliminary research, demand analysis, architecture design, quality assurance, plan Arrangement Implementation and tracking, Master industry knowledge, personnel management, and technical support of the project. risk Prediction and database design. In a large software company, at least two persons with at least three years of professional experience are responsible for these jobs, a project manager and a software architecture designer. If the previous work of a project is a mistake, a strong development team will be useless. We are still a young team. We need such talents and companies to cultivate them. If we have a project and recruit people to take on such a job, we can imagine the risks. In addition, such personnel must have grown up from the actual project practice, not those with non-software project management experience or market personnel, it is not just from books or some training courses.

7. blindly pursuing fast development and time progress. Many of my companies want to finish the project as soon as possible. The same is true for our company, but I know that yonyou is not. Similar to pregnant women, there is no shortcut to the project. You must make one step at a time. Companies tend to omit some work to catch up with the schedule. The final result is several times later, saving the time to make up for it. What's more serious is that the previous work was done, it is described as a "Mouse zombie ". There is a golden triangle rule in the project, that is, time, functions, and resources. They are always connected and mutually exclusive. To balance them, we need to analyze and solve the problem based on the actual project situation. Developers do not want to spend too much time in a project. They also want to end the project earlier. Developers spend too much time in a project, so they become very annoyed and less efficient. The most serious risk is that they choose to leave to free themselves. So how can we solve this problem? My personal opinion is to use our actual capabilities to follow a normal progress. If a project has certain functions, time, and resources, if we have to finish it in May October, it would be the same as if we had to finish it in five months.

8. There is no system boundary. The so-called system boundary is the functional points of the project we are working on, and the specific degree to which these functional points will be implemented. These Uncertain tasks or problems are unclear to users. In the future, we will never finish our work. Users will constantly propose new requirements and new functions, which we cannot control.

9. I still do not pay enough attention to the preliminary research and design, including the database design. From the projects I have done in our company, I realized that we are always afraid of the customer's demands, I always do not dare to dig deeper into the customer's needs. I am afraid that our workload will increase. The consequence is that after the development, I will show the customer: "This is not what we need, what we want is this ". Very little time is invested in code and database design. These jobs are abstract and can be designed only after constant research and scrutiny. However, for the sake of time progress, we will soon come out, the consequence is the customer's small demand changes. Due to our poor design, the previous work was done in vain.

10. Consistency of customer opinions. We believe in leadership too much during our research. The real users of our projects are not leaders, and the majority of employees and leaders are only looking at data. Our research targets primarily end users, especially in large projects. We can say that there are many leaders who have their own ideas and opinions. who is right or wrong, in fact, there is no right or wrong. One thing we suffer is that these leaders did not come together when they put forward their opinions, and they did not have a meeting to study them. Whoever gives them their opinions should follow their suggestions, the consequence is that we do not know how much we do for repetitive work. This happens internally. Solution. The survey should also guide the real target of the survey, and cannot trust the customer's leadership too much.

11. Users must participate in the project at the beginning and end. Every time we create a function that can run, we need to communicate with users, this can avoid many risks and identify misunderstandings of requirements as soon as possible.