I hope you will discuss some ideas about project management.

The success or failure of a project is variable, both technical, management, and related. There are both our own and our customers, but as long as we do what we can control, at least half of the project is successful.

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, and there is no underlyingCode. 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 for the moment. Of course, this requires a high level of experience and skills from the Project Manager, rather than just learning.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.

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

II, The Feature Specification reflects all the features required by the customer. We also developed the features in accordance with the Feature Specification. Later StageThe customer's changes can be compared with the "Feature Specification", and the specific changes are implemented according to our change process. Lessons learned: The specification must be comprehensive as the final outcome of product requirements: All requirements must be included. Developers and customers cannot do anything What are the 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 And cannot appear in the product. And pay attention to the following points: integrity, correctness, Feasibility, necessity, priority, no ambiguity, Verifiable, consistent, modifyable, and Trackable

3. The earlier the project developers invested too little, the longer the project cycle. There are mainly the following points:

1The longer the time, the more customer needs and more changes, the more risk we have.

2In a long period, there are often political changes, such as changes received by customers.

3The project cycle is too long, which may lead to the expansion of staff flow and the reduction of work efficiency.

 

ThuProject management personnel are the key personnel for project success or failure. Why, the project manager shall undertake the preliminary research, demand analysis, architecture design, quality assurance, plan Arrangement Implementation and tracking, Master industry knowledge, personnel management, technical support, and risk prediction of the project. and database design.If the previous work of a project is a mistake, a strong development team will be useless.

5. 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 requires a certain degree of functionality, time, and resources10If the task is completed in a month5Completed in a month, and pregnant with a pregnant woman5The consequence of giving birth to a child in a month is similar.

Sat.The system boundary is not determined. 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 are to 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.

7. I still do not pay enough attention to the preliminary research and design, including the database design. I realized in the project 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.

8Consistency 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. Solution. The survey should also guide the real target of the survey, and cannot trust the customer's leadership too much.

9, User participation, users need to be involved all the time at the beginning and end of the project. Every time we make 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.