The need for something.

The need for something.

---testing Department Zhang Shusen

With regard to demand, we often have such distress: 1. The user needs too much, it is almost impossible to complete the contract date; 2. The team members of the needs of the understanding of inconsistent, not in place, the products do not match the needs of users; 3. User requirements have been changing. 。。。。 I would like to talk about my own views on such issues

Speaking of demand, the mind will always flash in the picture, it in an image but exaggerated way to describe the demand in the transmission of the distortion. I do not know whether someone has deliberately calculated because the need to understand the cost of a mistake, I think it must be not low. And this "situation" is not uncommon! In the spirit of "do anything, never repeat twice without realizing or questioning this is actually a problem" principle, I have done a little research on demand management. Now will be a recent experience to the paper, hope to do his mountain stone.

From the beginning of demand acquisition, the process of requirements management throughout the project cycle, for easy reading, I have my own harvest and views in accordance with the project stage to explore.

Demand Research Phase :

How to do demand research? How to communicate with customers?

The problem seems very simple. If I ask some of my colleagues who have done demand research with customers, I think most of them will answer: talk to the customer about what they want, then let the designer do a axure, and finally take (and possibly the blueprint) with the customer to confirm it.

Is it really that simple?

If you ask: "When the customer expresses the demand, will you tell the customer something they didn't think about (especially when the development time is tight)?" Or are you going to ask me some sharp questions? "I think most of the answer is:" This time we mainly listen to the customer to make clear. Time is too tight, the customer did not mention do not take the initiative to dig the hole. "Ask again why?" I think most of the answers will be: "This is obvious, and the predecessors have done so." ”

Is this "taking for granted" behavior really right? Or does not mention the problem can reduce the project risk? Can we ensure that the customer does not mention new ideas during the development process (perhaps we have thought about this in the research phase but didn't mention it)? Can we deliver the project as scheduled without mentioning the problem?

In my opinion, when discussing the need, we should go as far as possible, raise some sharp questions, and let the difficulties appear in advance.

Reason:

1. In-depth communication can explore the hidden needs, confirm the customer's true intentions, which helps us to set the right direction;
2. In-depth communication, even if it leads to increased functionality, but we can choose to do or not to do, if the customer wants to do, then we can prioritize, apply more work
3. The sooner you ask the question, the lower the cost of the correction.

Requirements Analysis Phase:

Why do you need to do a demand analysis?

Some people say it is to clarify the client's intentions, some people say it is to assess technical difficulties and project risk, but also some people say it is to arrange tasks to estimate the workload ... These are all right, but I think it is more important that the project leader should be able to work through this period of time to be confident.

Professor Guo often says that the project is not training ground. If you want to do a good job, you have to be confident before you do it. As a painter before the painting of bamboo, the heart of the image of the bamboo, the painter did, but the heart is thinking of things, transcripts to the paper just, of course, can be done at ease. If the project member knows how to do it before the project starts, it's hard for the project to succeed if it knows how to do it best. On the other hand, the project is a bit of a gamble and a miracle, isn't it?

How to be confident

Want to do before the start of the project is confident, experience, knowledge and skills, thinking is indispensable. Experience allows us to replicate past successes, or to avoid repeating them. Knowledge and skills allow us to understand the project more and more widely, can extrapolate comprehend by analogy, but also can find the potential problems of project difficulties. Thinking, refers to the customer needs of the understanding process, the idea of solving problems.

The core of a project is nothing more than what to do, how to do and resources of these three aspects, if these aspects are clear, are in the grasp, then we have generally achieved a confident. If you're still unsure, well, then let's go around the three centers and try asking ourselves six questions, and think about them and answer them.

One of the biggest headaches for project managers at this stage is the need for too much, too complex logic, and tight project time. I've seen some of the project's WBS, and I've found that no matter how complex the functional logic, the workload can be magically compressed in the contract completion date---Actually, these projects did not follow the WBS to check the progress of the project, of course, most of the last delay.

I think we must improve on this point. Provides a requirement analysis artifact---carnot model

Requirements Analysis Artifact Carnot model.

Any Internet product, even the simplest activity page, will involve a lot of requirements, each demand will lead to related functional logic, demand more, especially a lot of cross-covering requirements, product logic will become very complex. And the Carnot model can help you.

The Carnot model, also known as the Kano model, was proposed by the Japanese master of Quality control No Jizho (Noriaki Kano) in 1984. The core of the Carnot model is to divide the product quality into four parts:

A No difference quality (indifference): whether provided or not to provide this quality, customer satisfaction will not change, in other words, this quality users do not care at all, this quality is the product design needs to avoid.

B charm Quality (attractive): Users can not imagine the quality, if not provide this quality, will not reduce user satisfaction, once the charm of the quality, customer satisfaction will be greatly improved.

C One-dimensional quality (one-dimensional): one-dimensional quality is also known as linear quality, if the quality of good, high customer satisfaction, on the contrary, poor quality customers will give negative evaluation.

D Required Quality (must-be): This is the basic requirements of the product, regardless of the necessary quality of how to improve, the customer will have a satisfaction limit, but do not provide this demand, user satisfaction will be greatly reduced.

E Reverse Quality (Reverse): The user does not have this demand, after the provision of user satisfaction will decline.

Using Carnot model to differentiate product demand

Above simple to say a few quality, we do product design, we should try to avoid the quality of non-difference, reverse quality, at least do the necessary quality, one-dimensional quality, and strive to do charm quality.

A try to avoid: no difference quality, reverse quality

B at least do: necessary quality, one-dimensional quality

C try to do well: charm quality

When analyzing the demand point of the product, all the identified needs are analyzed according to: Like, should be so, indifferent, can endure, do not like, to assess. Then, according to the following table, what types of requirements are required.

			This feature is not available
			Like	That should be true	Doesn't matter		Can endure		Don't like
Provide this feature	Like		/	B	B		B		C
	That should be true		E	A	A		A		D
	Doesn't matter		E	A	A		A		D
	Can endure		E	A	A		A		D
	Don't like		E	E	E		E		/
A No difference quality		b Charm Quality		C One-dimensional quality		D Required Quality		E Reverse Quality

Demand communication

The same project team, members of the project is inconsistent understanding of the common, if the needs of the understanding is not deep, to make the wrong function is "taken for granted." Provide an idea as follows:

The project leader should explain to the team members:

1. Why do you want to do this project? Who offered to do the project?
2. Elevator speech, if only 30 seconds to describe the project, what should be said?
3. To create a negative list, we need to know what the project should do, and what we shouldn't do.
4. If you want to advertise our project, how should we advertise?
5. Who are our peers or competitors?
6. What are the solutions (technology architecture and blueprints)? Drawing blueprints helps ensure that you are focused on the same thing.
7. What is the risk? Find the problems that keep us awake at night, discuss and find ways to avoid them, and effectively reduce the impact of related problems.
8. Project cycle? What resources are needed?
9. What are we going to abandon? Projects can be regulated by leverage such as time, scope, budget and quality, so what is the most important and least important thing in this project?

Focus on the elevator lecture-excellent elevator talk is good for the project.

(1) It can bring a clear mind.

No need to be exhaustive, lift speeches force the team to answer only what the product is, and for whom it is the most acute of these questions.

(2) It can force the team to consider the problem from the customer's point of view.

By focusing on the efficacy and rationale of the product, the team understands the beauty of the product and why the customer first buys its product.

(3) It can be directly to the point.

Lift speeches are like a laser beam that penetrates and goes directly to the heart of the project. This can help prioritize and capture critical requirements more efficiently.

Now look at a template that will help you with your speech:

For "Software users" They "need to track the type of work done on the building site." and "cswp*" is a "Safe work permit System" It is able to "create, track, and audit secure work licenses" Not used in "existing paper systems" Our products are "web-based and accessible from anywhere"

*CSWP: Construction Safety Work permit

There's more than one way to talk in an elevator, I like the way that Jay Geoffrey Moore's book, Crossing The Chasm, refers to the above few words.

• Target customers -explain who the project is for or who will benefit from its application.
• Requirements or Opportunities -Specify the issues or requirements that the customer must address.
• Product Name -give the project a name and give it vitality. Names are important because they can convey intentions.
• Product Categories -explain what a product or service is or can do.
• Main Advantages --explain the core competitiveness of products
• The main competitive product -explaining why we are not using other ready-made products.
• The main difference --differentiate and explain how our products are different, and what the advantages are compared to competing products.

Project launch

Before the project starts, each of our project members should ask themselves the following questions:

1. What am I good at?
2. How do I do it?
3. What do I value?
4. What do you expect me to deliver?

The need for something.