How to start the project: how to deal with the customer's needs (transferred from the nine secrets of West Joe)

Original article address:Http://blog.xiqiao.info/2009/04/17/277

 

In the initial phase of the project, the main task the project manager has done is to collect customer requirements. This is a very headache for the project manager. The cooperation has just begun, errors in demand problems can lead to endless future troubles.

Three customer types:

• 1 is indeed very professional. Provides basic available documents, standards, and valuable questions and concerns. Can answer your questions quickly
• 2. Think you are very professional. The provided documents are basically useless. There is no way to provide specifications and standards. I like to point a finger or pick up a fault. I will only ask you silly questions. You cannot answer your questions.
• 3. I don't understand anything. No documentation. I can provide you with several reference examples (open several websites and tell you that I want to do the same thing as them .) You can only wait for 100 questions...

Four cooperation methods:

• 1. The founder directly approached you:There is a lot of room for negotiation on the exchange results, and the demands are not repeated, so the details will not be excessively pursued. It is easier to unify your ideas and execute more efficiently. You can have a greater impact on projects and products. However, Party A is often too anxious.
• 2. The project representative will contact you:This is an ideal situation. Party A has a product manager or IT manager who can serve as a representative to summarize all Party A's requirements and standards and communicate with you. Party A has worked with the outsourcer to understand the dangerous links, can assume the role of translation and bridge to help you block and persuade inappropriate demands. You can take responsibility in a centralized manner and actively avoid the risk of project failure with you. Very luky!
• 3. Contact your professional department:A senior engineer in the IT or technical department is responsible for communicating with you. Technical cooperation will be smooth, but they cannot help you block the troubles from the market or content department when it comes to products and needs. After the cooperation starts, it is very likely that there will be technical differences.ProgramYou may be challenged by other departments and upper layers if the product side is ignored.
• 4. Contact the marketing department (content department) with you:It is recommended that you first burn incense and prepare the worst plan. The differences between professional and thinking models will lead to totally different issues of concern to you. When you first meet their concerns, remember to set aside a lot of time to solve problems that are invisible but actually very important to them. In addition, you need to do more things, write more documents, take the initiative to contact the professional departments, and strive to communicate with the Decision-Making layer.

If you are facing 3rd and 4th situations,

• First, familiarize yourself with Party A's organizational unit. For exampleContent-Type, media, channel, and publicity projectsDevelopment:

• Requirement and Marketing Department communication

• Function and content department Communication

• Communicate with the Sales Department for soft and soft ad spaces or special topics (if it is a revision, the ad space contract may be signed half a year in advance and must be well coordinated with the sales team)

• Communicate with it, network management, and data statistics departments on technologies, systems, security, and statistical issues

• Certain issues need to be communicated with the Assistant to the President and administrative departments.

• Some special content needs to be communicated with originality, artist, and copywriting departments

• If you find that the personnel from these departments are not involved, contact them in advance.

• Skip the preceding steps in 1st and 2nd cases.

Step 8:

• Step 1: Hear what the customer wants.

And the estimated construction period and budget (don't be shy about these two issues, this is the most important element in the success or failure of the project ).

• Step 2: ask a question.

1. What is the purpose of the project. (Brand, channel, traffic, advertising fee, number of users, Vc, and other business models)

2. What are the advantages and resources of Party. (Money, content resources, human resources, advantages of traditional industries)

3. provide visual reference and reference objects as much as possible. (Is there any solution on the application. Which site is preferred on the interface. Is there any reference object for Interaction)

4. Details of other projects. For example, (what is the upper and lower limits of the construction period? Will it need to be integrated with the existing system or data migration? Will it require the cooperation of Party A's engineers? Are there any development platform restrictions? YesCodeNorms and standards? What development documents and source code are ultimately required)

• Step 3: reach consensus.

It is very important to reach consensus with Party A to ensure that they understand the same thing. In this step, you need to outline and draw a sketch or frame chart based on your knowledge. If you have a reference object, which part of the annotation will be more like XX. Then ask Party A to confirm that this framework is what they want.

• Step 4: Give the project timeline.

At this stage, your project manager needs to organize all team members to sit down and discuss, and divide functional modules first, then, the feasibility, difficulty, time spent, bug rate, and test time of each function module are discussed. Next, we will discuss the time required to build and integrate one system at a time.

After the project manager has a thorough understanding of the project time and feasibility, he can draw a timeline for the project. Including parallel conditions, milestone nodes, test periods, and buffer periods (how to draw a project timeline, Gantt chart, I will write a special article later ).

The timeline should be realistic and a sufficient buffer period should be reserved (engineer estimated * 2 * 110% ).

• Step 5: Demand subtraction.

In most cases, the timeline performance exceeds the customer's expectation.

If the customer has no requirements for the construction period, remind the customer to consider the project feasibility risks, market waiting costs, or the waste caused by market or strategic changes.

Han Lei has a blog titled "big brother or underwear" that vividly describes this issue.

Therefore, we should try our best to reduce the demand with Party. Split the overall requirement into 2 ~ Phase 3: implement only the most basic and necessary requirements for development.

Then the formal development agreement is signed. Do not forget the cost of computing Requirement documents and product solutions.

• Step 6: write detailed requirement documents.
• Framework DiagramDownload the template of xiqiao. Visualizes the framework, layout, details, and interaction of the product.
• FlowchartDownload the template of xiqiao. Identify the logical relationship of the product.
• Functional requirements documentDownload the template of xiqiao. Lists functional, application, and interaction details, separates basic components, and serves as a basic document for Development Division and system and data structure.

• Step 7: Discuss demand documents

Call the persons in charge of all relevant departments of Party A to hold the meeting and discuss the requirement documents.

Before reading your requirement documents, most people of Party A may not have a visual or concrete understanding of the product. I have never paid attention to the details and logical relationships. Therefore, the product manager needs to explain the document from a global perspective and logic clue.

What is more likely to happen is that no one keeps reading or carefully reading the documents you have written.

Therefore, this meeting is a matter of patience and physical strength. The author of the document needs to point out to various departments where they need attention and decisions, listen to their suggestions, and classify any change requirements. Appease your mood. Solve the problem. Control demand changes.

• Step 8: draft the requirement document

Create Table documents by function (department. Write down all divergent opinions and changed opinions during the meeting negotiation one by one. CC to all relevant owners. And asked them to correct their differences and confirm the changes.

Comments in this email document may be raised at all meetings and will not be included in the requirement document. Of course, you can provide feedback in writing.

Modify the requirement document based on the confirmed feedback. Wait until the requirement document is finalized.

The negotiation discussion and document modification may go through 2 ~ Three rounds. Therefore, the project manager should remind the customer in advance of the timeline milestones of "collecting requirements and finalizing documents. If this phase takes too long, the entire project progress will be seriously delayed. Require the customer to make suggestions and modifications with caution as much as possible.

Three weapons:

• Demand questionnaire:

There are many omissions in communication between professional and non-professional customers. The points they cannot see are often the most critical points, it may also be a point that customers intentionally circumvent.

At this time, a requirement questionnaire is very effective. The customer must answer important questions in writing one by one.

• You can provide multiple option answers and additional areas for some questions.
• Some problems require a definite attitude, yes or no.
• Do not ask the customer to write a large paragraph of declarative text. The demand questionnaire is concise, targeted, and important,
• Do not waste the customer's time, and do not throw the writing workload to the customer.

• Written confirmation:

Written confirmation includes, on the one hand, that all discussions, suggestions, and changes should be prepared in writing for future reference. These verbal expressions mentioned at the telephone and Conference have no effect. From the very beginning, you should declare that it is even necessary to write it in the contract.

On the other hand, you should try to provide written visualization for Party A to confirm. It is difficult for Party A to complete or provide documents suitable for engineering use. Therefore, do not be lazy in the demand documents at the initial stage of the project.

• Email CC:

Email CC is a clear method of responsibility. The recipient may not read your email, but it means you have told me. Try to copy important emails to the strategy layer to avoid major problems.

Conclusion:

It seems that gathering and determining requirements is really a time-consuming project.

In fact, in the ideal project time allocation, 1/3 of the time is used to determine all requirements and development documents. 1/2 of the time is used for testing, solving bugs, security testing, and stress testing. Only 1/6 of developers are actually used. Of course, the development of Web projects certainly cannot meet this ideal situation.

However, we can also see the importance and workload of the demand stage. This stage saves one or only one point of effort and may require a lot of effort to make up for it later in the project.