Clients and apples: a couple of words about collecting requirements
“But I wanted a green big sour apple,” I groaned, holding a little apple with a red side in my hands. "You told me to buy an apple, I bought an apple," the husband sternly snapped .
At the beginning of development, customers are always satisfied, they become dissatisfied at the end, when their expectations do not coincide with what has been developed. It seems that the customer and the development manager were talking about one thing, they seemed to use clever words like “plan” and “risks”, and not the client was delighted with the finished product. How so?
Conceiving a tool for solving his business problem, the client, as a rule, is already endowed with some ideas about this tool, sometimes quite general, sometimes very detailed and concrete. Often, submissions contain the experience of this client, and the competitor, and knowledge about consumers and their behavior. The client, working with his business task and its context, forms his expectations from the tool, and then goes to a professional to develop this tool. Comes and tells you what the tool wants.
')
The development manager, having his own context and experience, looks at this desire through stereotypes of usability, the benefits of the company-developer and the project budget. And it forms its initial ideas about the instrument, fixes them and presents them to the customer.
The customer sees that, in general terms, the presented person satisfies him, but, he checks this in the context of his knowledge. If he sees discrepancies, he asks questions, but worse, if the requirements are fixed in a general list and fit well with the context. Then the customer is satisfied with the start of development, tasks are set, work is in full swing.
In the course of development, the manager completes the final details of various components of the customer’s tool, the customer notes attention to details and deadlines, he is satisfied with the work with the manager and looks forward to quickly launching the tool into operation and, as a result, a lightning-fast and high-quality solution of its business problem, the manager looks forward to smooth project to such a loyal client, the profit for the executing company and the premium.
But at the first presentation of the result, the customer is disappointed - the tool not only does not solve the problem, but does not fit into the existing business processes of the customer company. “But you didn’t talk about such restrictions, you signed a TK, where not a word about it!” - the manager’s annoyance grows, he already considers the client to be an inattentive profane. “And you did not ask about these subtleties and nuances” - the client is no longer satisfied with the development and developers.
And the problem arose when the instrument was first discussed, then the manager and the customer did not agree and did not agree. The context stored by the customer did not become the context of the tool development project. The manager has made ideas about the functions of the tool, but did not check whether his ideas about the stages of solving the client’s business problem coincide with those that the client has outlined. So it turned out the very apple from my example, understandable to everyone, but not guaranteeing the coincidence of tastes, preferences and stereotypes.
From my experience this can be avoided only in one way - to speak. Speak in detail with the client, about the client and his business, aloud and writing down, drawing sketches and diagrams.
Talk about tasks and users, not specific system functions.
- I want an online store.
- Yes, we will make 100 thousand rubles.
This dialogue is a typical, unfortunately, example of communication with a client. Yes, it’s expensive to find out what the store will sell, who its customers are and how exactly they choose and purchase the product. Moreover, the sale may not take place, the money just fly into the tube. But it is more expensive to rework the tool, in this case there are already obligations on the contract and the client is no longer satisfied with the development company, and this image loss is significant for the company providing services.
Avoid the terms.
- I have a business card website integrated with the billing system, please.
- This is not a business card, this is a corporate site.
Having clarified the tasks, having modeled the users behavior and clarified the basic functions of the system, the development manager imagines how and what he will develop. It remains to bring this to the client in everyday language, avoiding incomprehensible terms to the client, so that the client checks whether the presented system fits into his expectations and points out the moments that were ignored. And if he gets bogged down in terms and his ideas about these terms, there will be no agreement. After all, even the “apple” everyone understands in his own way, and here “load testing” and “agile” are solid guesses and expectations.
Chase the business goals.
- Do not teach me to sell toilet bowls, draw a button here and draw a banner here.
Even if the client is ready to talk about the system, about specific fields and elements, do not depart from the goals and objectives in the context of business for each part of the tool. From the task list of the tool from the business point of view, the context as well as the client's expectations will be visible. And if the client insists on discussing the fields and buttons, discuss them, but after fixing specific tasks of this part of the tool.
Give and ask again.
The more often you pronounce the obvious, finish and recheck, the more you will learn about the expectations of the client. Even if the decision seems obvious to you, as a development manager, tell the client about this decision, enter it into the general model and check that this action did not create a black hole in terms of time or budget. The client, although he gets tired of such a dialogue, will be grateful to get a tool working in his business that solves the problem, and not decorative money spent.
Of course, this is primitive. Undoubtedly, will not save from all inaccuracies. Yes, the business analyst can specify the requirements, and the system analyst will put them on the requirements of the software product that is the basis of the tool the customer needs. But no one will remove from the manager responsibility for the timing of the project, its budget, commissioning. And the responsibility for customer satisfaction with the company will also remain on the manager’s shoulders. That is why we must not forget about these seemingly banal things.
"Sour green apple (varieties of granny smith or semerenko) weighing 350-450 grams," I wrote in the shopping list. Then she thought and added: “Without a leaf, but with a tail. The color of the tail does not matter. "
At the beginning of development, customers are always satisfied, they become dissatisfied at the end, when their expectations do not coincide with what has been developed. It seems that the customer and the development manager were talking about one thing, they seemed to use clever words like “plan” and “risks”, and not the client was delighted with the finished product. How so?
Conceiving a tool for solving his business problem, the client, as a rule, is already endowed with some ideas about this tool, sometimes quite general, sometimes very detailed and concrete. Often, submissions contain the experience of this client, and the competitor, and knowledge about consumers and their behavior. The client, working with his business task and its context, forms his expectations from the tool, and then goes to a professional to develop this tool. Comes and tells you what the tool wants.
')
The development manager, having his own context and experience, looks at this desire through stereotypes of usability, the benefits of the company-developer and the project budget. And it forms its initial ideas about the instrument, fixes them and presents them to the customer.
The customer sees that, in general terms, the presented person satisfies him, but, he checks this in the context of his knowledge. If he sees discrepancies, he asks questions, but worse, if the requirements are fixed in a general list and fit well with the context. Then the customer is satisfied with the start of development, tasks are set, work is in full swing.
In the course of development, the manager completes the final details of various components of the customer’s tool, the customer notes attention to details and deadlines, he is satisfied with the work with the manager and looks forward to quickly launching the tool into operation and, as a result, a lightning-fast and high-quality solution of its business problem, the manager looks forward to smooth project to such a loyal client, the profit for the executing company and the premium.
But at the first presentation of the result, the customer is disappointed - the tool not only does not solve the problem, but does not fit into the existing business processes of the customer company. “But you didn’t talk about such restrictions, you signed a TK, where not a word about it!” - the manager’s annoyance grows, he already considers the client to be an inattentive profane. “And you did not ask about these subtleties and nuances” - the client is no longer satisfied with the development and developers.
And the problem arose when the instrument was first discussed, then the manager and the customer did not agree and did not agree. The context stored by the customer did not become the context of the tool development project. The manager has made ideas about the functions of the tool, but did not check whether his ideas about the stages of solving the client’s business problem coincide with those that the client has outlined. So it turned out the very apple from my example, understandable to everyone, but not guaranteeing the coincidence of tastes, preferences and stereotypes.
From my experience this can be avoided only in one way - to speak. Speak in detail with the client, about the client and his business, aloud and writing down, drawing sketches and diagrams.
Talk about tasks and users, not specific system functions.
- I want an online store.
- Yes, we will make 100 thousand rubles.
This dialogue is a typical, unfortunately, example of communication with a client. Yes, it’s expensive to find out what the store will sell, who its customers are and how exactly they choose and purchase the product. Moreover, the sale may not take place, the money just fly into the tube. But it is more expensive to rework the tool, in this case there are already obligations on the contract and the client is no longer satisfied with the development company, and this image loss is significant for the company providing services.
Avoid the terms.
- I have a business card website integrated with the billing system, please.
- This is not a business card, this is a corporate site.
Having clarified the tasks, having modeled the users behavior and clarified the basic functions of the system, the development manager imagines how and what he will develop. It remains to bring this to the client in everyday language, avoiding incomprehensible terms to the client, so that the client checks whether the presented system fits into his expectations and points out the moments that were ignored. And if he gets bogged down in terms and his ideas about these terms, there will be no agreement. After all, even the “apple” everyone understands in his own way, and here “load testing” and “agile” are solid guesses and expectations.
Chase the business goals.
- Do not teach me to sell toilet bowls, draw a button here and draw a banner here.
Even if the client is ready to talk about the system, about specific fields and elements, do not depart from the goals and objectives in the context of business for each part of the tool. From the task list of the tool from the business point of view, the context as well as the client's expectations will be visible. And if the client insists on discussing the fields and buttons, discuss them, but after fixing specific tasks of this part of the tool.
Give and ask again.
The more often you pronounce the obvious, finish and recheck, the more you will learn about the expectations of the client. Even if the decision seems obvious to you, as a development manager, tell the client about this decision, enter it into the general model and check that this action did not create a black hole in terms of time or budget. The client, although he gets tired of such a dialogue, will be grateful to get a tool working in his business that solves the problem, and not decorative money spent.
Of course, this is primitive. Undoubtedly, will not save from all inaccuracies. Yes, the business analyst can specify the requirements, and the system analyst will put them on the requirements of the software product that is the basis of the tool the customer needs. But no one will remove from the manager responsibility for the timing of the project, its budget, commissioning. And the responsibility for customer satisfaction with the company will also remain on the manager’s shoulders. That is why we must not forget about these seemingly banal things.
"Sour green apple (varieties of granny smith or semerenko) weighing 350-450 grams," I wrote in the shopping list. Then she thought and added: “Without a leaf, but with a tail. The color of the tail does not matter. "
Source: https://habr.com/ru/post/286536/
All Articles