Project management salon Eighth Meeting Minutes

Project management salon Eighth Meeting Minutes

This salon is still a summary of NSEC's agile experience. This time, we still talked about customers and needs. Because the customer and the development team are not in the same region, the customer is not involved in the development of the project, and all communication is conducted by the Project Manager. From the perspective of developers, the biggest problem with demand changes is that developers cannot determine whether it is really useful to customers. First of all, the customer has a lot of ideas, and the PM cannot communicate with the customer face to face due to the distance. Therefore, the customer can only beat his head and guess the riddle. As a result, developers are not satisfied with the sense of accomplishment, so they naturally feel better. The question is: what should developers do?

In the face of this situation, we have discussed that we should fully trust PM first, but PM also has the responsibility to fully communicate with the customer. At this time, the "primitive method" that we have been emphasizing will play a great role. There are many prototype tools, such as a series of simple html pages or a ppt demonstration. The advantage of the former is that a complete process can be quickly demonstrated, and the latter can demonstrate some user interface effects at the same time. In short, prototype tools are the kind of things that can be quickly built and quickly discarded. It is very suitable for customers with unstable or even unformed requirements.

In fact, NSEC's demand problem is not rooted in customers, nor PM, but, like most other projects, it lacks a role, "Business Analyst", or BA for short. In many projects, BA is held by PM or business personnel, but they either have multiple roles or are not trained in specialized business analysis and cannot fully guide the customer's needs, as a result, the demand is unclear and unstable. Quote a statement from a salon member: the programmer does not oppose changes, but the objection is a waste!

The role of BA is very important. In agile pairing, BA pairing objects are customer representatives. His job is to guide customers and make their needs clearer and more stable. The prototype method is a good method for guiding requirements. As we have always stressed, "customers do not know what they want, but do not know what they do ", the role of the prototype method is to allow customers to constantly reject their own ideas and ultimately form what they want. This is what the project team dreamed of as "stable. In fact, there are far more BA tools, and "syntax analysis" is also a tool for BA. The statements are divided into nouns, verbs, adjectives, subjects, predicates, and objects based on the customer's statements. Based on the characteristics of each word, we can sort out a series of targeted problems. An experienced BA will ask all the customer's requirements as long as the customer keeps talking. The specific method can be discussed in detail in a later Salon.

Another problem with NSEC is that the customer occasionally asks the project team to release results from time to time. In response to this situation, we feel that the automated construction and The UAT environment discussed last time are very useful. The root cause of this problem is the instability of customer requirements. Of course, it is also important to regularly publish results and make the customer feel the changes in progress.

"No Acceptance Criteria Document" is another NSEC issue. From our perspective, this is a common problem for almost all projects in China. In theory, we will conduct a survey on the customer's requirements after winning the bidding, and then take the form of the requirement specification as an appendix to the contract, and use this as the customer acceptance criteria. In fact, there are almost no projects that can achieve this degree. Even if this is done, the requirements in the appendix of this contract will be constantly changed during the development process, and eventually become completely unrecognizable. Experienced people will certainly come up with a "Change Control" approach, but in the actual project process, how many customers are willing to sign each change request? How many customer representatives have left the change demand because they have to sign? The answer is "few" or even "no ". Many projects are caused by restrictions on the customer's change requirements, or frequent unpleasant changes during the change request process. As a result, the customer relationship deteriorates and the final project fails. This is also the biggest difference between a "traditional" project and an "agile" project.

From an agile perspective, the project team fully accepts the impact of changes, but all changes cannot affect the ongoing iteration process, all changes take effect in the next iteration as soon as possible. But what if there is an urgent need for change? In fact, there is no "urgent" demand change, because the implementation of all requirements requires time and demand is a future thing, the project team must clearly distinguish "demand" from "BUG", and cannot solve the "demand change" by solving the BUG. (this is also a common mistake of most project teams, if the task has no priority, the result is frequent overtime ). For a demand change, unless it can immediately invalidate a task in the current iteration, we need to change the iteration schedule in real time, otherwise this iteration will not be affected.

The absence of Acceptance Criteria documentation is a problem, but "relying on customers for testing" is another and more serious problem. Because the customer mentioned previously requested the release of the project from time to time, the project team was very busy at the time of release. In addition, the project team was not fully tested at ordinary times, therefore, the project team hopes that the customer can extract manpower to perform the acceptance test. In fact, the customer will hardly perform any serious tests. Some participants thought that "relying on customers for testing" was a failure of the project.