March 10, 2015 at 18:00Customers and apples: a few words about collecting requirements
“But I wanted a green big sour apple,” I moaned, holding in my hands a small apple with a red side. “You said that I bought an apple, I bought an apple,” her husband snapped sternly .
At the beginning of development, customers are always satisfied, they become dissatisfied at the end when their expectations do not coincide with what is developed. It seems that the customer and the development manager spoke about one thing, they seemed to use smart words like “plan” and “risks”, and the client was not enthusiastic about 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 very general, sometimes very detailed and specific. Often representations contain both 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 says that he wants a tool.
The development manager, having his own context and experience, looks at this desire through the stereotypes of usability, the benefits of the development company and the project budget. And it forms its initial ideas about the tool, fixes them and presents it to the customer.
The customer sees that in general terms the presented 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 by the general list and fit well into 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 finalizes the final details of various components of the customer’s tool, the customer notes attention to details and deadlines, he is satisfied with the manager’s work and is looking forward to quickly putting the tool into operation and, as a result, lightning-fast and high-quality solution to his business task, the manager is looking forward to a hassle-free delivery project to such a loyal client, profit for the executing company and a bonus.
But at the first presentation of the customer’s result, disappointment awaits - the tool not only does not solve the problem, but also does not fit into the existing business processes of the customer company. “But you didn’t talk about such restrictions, you signed a statement of work, where there’s no word about it!” - The manager’s chagrin is growing, he already considers the client an inattentive layman. “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 during the first discussion of the tool, then both the manager and the customer did not agree and did not agree. The context stored by the customer has not become the context of a tool development project. The manager made representations 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 outlined by the client. So it turned out the very apple from my example, understandable to everyone, but not guaranteeing the coincidence of tastes, addictions and stereotypes.
From my experience this can only be avoided by talking. To speak with the client in detail about the client and his business, out loud and taking notes, drawing sketches and diagrams.
Talk about tasks and users, not specific system functions.
- I want an online store.
- Yes, we’ll do 100 thousand rubles.
This dialogue is a typical, unfortunately, example of communication with a client. Yes, to find out what the store will sell, who its customers are and how they choose and purchase goods, at the first meeting with the customer is expensive. Moreover, the sale may not take place, this money will simply fly into the pipe. But it’s more expensive to remake the instrument, in this case there are already obligations under the contract and the client is no longer satisfied with the development company, and this image loss is significant for the service company.
Avoid the terms.
- I have a business card site integrated with a billing system, please.
- This is not a business card, this is a corporate site.
Having clarified the tasks, simulated user behavior and clarified the basic functions of the system, the development manager imagines how and what he will develop. It remains to convey this to the client in everyday language, avoiding terms incomprehensible to the client, so that the client checks to see if the presented system fits into his expectations and points out points that were left unattended in time. And if he gets bogged down in terms and in his ideas about these terms, agreement will not work. After all, everyone understands even the “apple” in their own way, and here is “stress testing” and “agile”, sheer speculation and expectations.
Pursue business goals.
- Do not teach me how to sell toilets, here draw a button to buy and put 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. It is from the list of tasks of the tool from the point of view of business that the context will be visible, as well as the expectations of the client. And if the client insists on discussing the fields and buttons, discuss them too, but after fixing specific tasks of this part of the tool.
Find out and ask again.
The more often you say the obvious, finalize and double-check, the more you learn about the expectations of the client. Even if you, as a development manager, the solution seems obvious, tell the client about this solution, write it in the general model and make sure that this action did not create a black hole by time or budget. The client, although tired of such a dialogue, will be grateful to receive a tool working in his business that solves the problem, and not the decoratively spent money.
Of course, this is primitive. Undoubtedly, it 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, which is the basis of the tool necessary for the customer. But no one will relieve the manager of responsibility for the terms of the project, its budget, commissioning. And the responsibility for customer satisfaction with the company will also remain on the shoulders of the manager. That is why we must not forget about these seemingly banal things.
“A green sour apple (varieties of granny smith or seed) weighing 350-450 grams,” I wrote on 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 is developed. It seems that the customer and the development manager spoke about one thing, they seemed to use smart words like “plan” and “risks”, and the client was not enthusiastic about 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 very general, sometimes very detailed and specific. Often representations contain both 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 says that he wants a tool.
The development manager, having his own context and experience, looks at this desire through the stereotypes of usability, the benefits of the development company and the project budget. And it forms its initial ideas about the tool, fixes them and presents it to the customer.
The customer sees that in general terms the presented 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 by the general list and fit well into 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 finalizes the final details of various components of the customer’s tool, the customer notes attention to details and deadlines, he is satisfied with the manager’s work and is looking forward to quickly putting the tool into operation and, as a result, lightning-fast and high-quality solution to his business task, the manager is looking forward to a hassle-free delivery project to such a loyal client, profit for the executing company and a bonus.
But at the first presentation of the customer’s result, disappointment awaits - the tool not only does not solve the problem, but also does not fit into the existing business processes of the customer company. “But you didn’t talk about such restrictions, you signed a statement of work, where there’s no word about it!” - The manager’s chagrin is growing, he already considers the client an inattentive layman. “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 during the first discussion of the tool, then both the manager and the customer did not agree and did not agree. The context stored by the customer has not become the context of a tool development project. The manager made representations 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 outlined by the client. So it turned out the very apple from my example, understandable to everyone, but not guaranteeing the coincidence of tastes, addictions and stereotypes.
From my experience this can only be avoided by talking. To speak with the client in detail about the client and his business, out loud and taking notes, drawing sketches and diagrams.
Talk about tasks and users, not specific system functions.
- I want an online store.
- Yes, we’ll do 100 thousand rubles.
This dialogue is a typical, unfortunately, example of communication with a client. Yes, to find out what the store will sell, who its customers are and how they choose and purchase goods, at the first meeting with the customer is expensive. Moreover, the sale may not take place, this money will simply fly into the pipe. But it’s more expensive to remake the instrument, in this case there are already obligations under the contract and the client is no longer satisfied with the development company, and this image loss is significant for the service company.
Avoid the terms.
- I have a business card site integrated with a billing system, please.
- This is not a business card, this is a corporate site.
Having clarified the tasks, simulated user behavior and clarified the basic functions of the system, the development manager imagines how and what he will develop. It remains to convey this to the client in everyday language, avoiding terms incomprehensible to the client, so that the client checks to see if the presented system fits into his expectations and points out points that were left unattended in time. And if he gets bogged down in terms and in his ideas about these terms, agreement will not work. After all, everyone understands even the “apple” in their own way, and here is “stress testing” and “agile”, sheer speculation and expectations.
Pursue business goals.
- Do not teach me how to sell toilets, here draw a button to buy and put 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. It is from the list of tasks of the tool from the point of view of business that the context will be visible, as well as the expectations of the client. And if the client insists on discussing the fields and buttons, discuss them too, but after fixing specific tasks of this part of the tool.
Find out and ask again.
The more often you say the obvious, finalize and double-check, the more you learn about the expectations of the client. Even if you, as a development manager, the solution seems obvious, tell the client about this solution, write it in the general model and make sure that this action did not create a black hole by time or budget. The client, although tired of such a dialogue, will be grateful to receive a tool working in his business that solves the problem, and not the decoratively spent money.
Of course, this is primitive. Undoubtedly, it 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, which is the basis of the tool necessary for the customer. But no one will relieve the manager of responsibility for the terms of the project, its budget, commissioning. And the responsibility for customer satisfaction with the company will also remain on the shoulders of the manager. That is why we must not forget about these seemingly banal things.
“A green sour apple (varieties of granny smith or seed) weighing 350-450 grams,” I wrote on the shopping list. Then she thought and added: “Without a leaf, but with a tail. The color of the tail does not matter. ”