7 Grocery technicians that the developer should pay attention to

When we order a costume in a studio or interior design, we are not asked to come with ready-made measurements, chosen style or color of the ceiling. Professional designers and designers ask questions and offer solutions based on our goals.

However, from software development customers, we often expect to receive a ready-made specification of requirements.

A little better is the case in product development, especially in startups, where the generation of requirements is evenly distributed throughout the entire life cycle of work on the product. Thanks to the principles of Lean StartUp : build -> measure -> study, product teams work in shorter cycles. At the entrance of each iteration - a new portion of the requirements for the "experiment", in the formulation of which the entire team is often involved.
')
In custom development, I observe 3 types of problems associated with the expectation of ready-made requirements from the client:

1. “Business” does not know how to formulate good requirements, because it does not understand the development process and technological capabilities. The specification contains the customer's idea of ​​solving the problem, which is difficult to get to the bottom of the document.
   
   
2. “Business” does not have enough time to work out the requirements. Some of the options for using the system, not thought out in advance, are dropped during the development. The fewer practitioners who support the iterative process (CI, automated testing, restriction on the number of features in the work), the more difficult it is to make changes to the requirements.
   
   
3. “Business” and “development” speak different languages. As a result - a false understanding of the requirements, not clarified assumptions, resulting from them 'surprises' at the time of the demonstration. A non-existent system is difficult to describe on paper. This leads to problems that can be summarized by the words of the customer: “I don’t know exactly what I want, but I know exactly what I don’t want”.

Obviously, both the formulation of problems and the search for technical solutions will be easier and more effective if both parties, business and development, are involved in this process.

How to help a customer who is burning with the idea of ​​a product - to formulate it clearly, in the language of business and problems. How to avoid imposing solutions, excessive and premature specification of requirements? How to reduce the time for understanding the market, users, values ​​of requirements and criteria for the success of their implementation?

Below is an overview of product techniques that can help.

1. User Personas This tool was borrowed by developers from an interactive design for maximum focus on user problems and tasks. Person Description helps the development team understand the needs of key user groups, formulate and implement requirements based on their demographic data, lifestyle and other common characteristics.
   
   
2. Impact mapping This is a strategic planning tool that helps build a vision and prevents its loss in the “feature soup” in the course of development. Influence map contains business objectives for the next iteration and helps the team make decisions according to them. It also protects against misunderstanding and false assumptions about functionality, helps generate alternative implementation ideas that do not require serious investment in development.
   
   
3. User Stories The format for describing requirements in the form of User Stories is convenient for prioritizing, storing and “inviting” to a more detailed business and development dialogue. Such a dialogue should happen on the principle of JIT (“just in time”), that is, at the moment when the decision on the development of functionality has to be made. This allows you not to invest a lot of time in the detailed elaboration of requirements that may not have to be implemented. This format uses the language of the business, contains information about the Person and Business Value of the requirement in order to maintain the focus of developers on the vision and objectives of the product / release / iteration.
   
   
4. User Story Mapping Approach to get a high-level requirements model that describes the types of users and scenarios of their interaction with the product. Creating a user story map can be one of the brainstorming types before starting product development. At the same time, this tool can be used for planning a release and choosing the functionality that will be included in it.
   
   
5. Kano Weighting A “weighting” requirements technique that uses a classification of user preferences based on 5 satisfaction criteria. It helps to answer the question - what is the minimum value of the product delivery volume (MVP) and choose the functionality to be implemented in the next iteration.
   
   
6. User Story Hamburger A requirements decomposition tool that allows you to visually discuss technical implementation details and choose the best path from the point of view of beauty / complexity / cost. It is useful for product owners and developers who have difficulty in separating complex stories into simpler ones in order to speed up delivery and receive feedback. It is also useful for explicitly discussing “sufficiently great” solutions, both from the point of view of business people and from the point of view of developers.
   
   
7. Specification by Example A tool for organizing acceptance testing that affects the process of formulating and managing requirements. It allows you to improve the interaction between business users and developers, improve the quality of products, reduce the processing of features and “idle” development based on false assumptions.

Detailed information about each technique you will find on the links, I just wanted to draw attention to their existence. Questions of practical application of these tools will be glad to highlight in separate articles or in person.