It so happened that lately I have been working a lot with requirements for the product from an “internal customer”, including from colleagues from various departments and technical teams (within the company). And people constantly come to me so that our team implements certain features, altered something, added, removed.
In this article I want to tell you how to work with all this incoming chaos.
The article is written based on the practice of work, and does not intend to cover the whole topic of project management, requirements, teams, quality of the subsequent implementation of requirements by developers, the topic of analysis of implementation results, etc.
And it covers only a small narrow part between the "Wishlist" and the "Implementation", which is about the requirements themselves: arbitrary Wishlocks / Requirements / Wishes / Problems, etc., fly in with us, and we work with them and at the output we get what suitable for development.Clarification of the real problem
When someone comes up with a problem, demand, idea of a new feature, etc. it does not always bring us this in a finished form, suitable for implementation. As a rule, this or some kind of “cosmos” is something very big, out of place, unrealistic, requiring to be completely redone to solve a small problem, the relevance of which is unknown. Or simply “raw”, incomprehensible, non-specific requirement.
For example, a person suggests adding a new feature. And do it this way, offering some kind of technical implementation. At the same time, not knowing how things are arranged and how they can be realized. Obviously, you can not just take as there are such requirements and implement. If they did, the world would have long since plunged into the chaos and darkness of the nether world.
In order to move the chaos and darkness of the underworld a bit away, we need to understand what is behind these ideas and suggestions. What task did the person who came to you really want to solve, what problem to close?
It is not always clear and immediately obvious. Often it is necessary to wade, asking the same questions many times. Or different questions. Until it finally becomes clear what is wrong in essence, in substance, and how, in the understanding of a person, it should be “so.” And this understanding, as a rule, is very different from the original formulation of the task / problem. But without receiving it, it is impossible to proceed to the next steps and satisfy the need.
Understand that a person
really needs is a whole art to which whole parables are devoted (for example, “Vladimir Tarasov - Approaching a deer”), books (for example, “Rob Fitzpatrick - Ask for mom”) and practical efforts (for example, on the developer).
Old bike about the buyer of the drill
A man comes to the store and buys a drill there. But in fact, he doesn’t need a drill, he needs a hole in the wall that he wants to drill. Therefore, he buys a drill.
But that's not all. The hole is not needed by itself. It is necessary to hang a big beautiful picture in a heavy frame. And this hero wants to hang a picture in order to please his mother-in-law, who has long asked him to hang a picture, but he still did not do it.
It seems to us that we have already found the root problem. But no.
In fact, there will be a football match in a day, which our hero really wants to see. And so that the mother-in-law had no reason to interfere with him, he organized for himself a reason to have the right to watch football - did what he had been asked for long ago - hung the picture.
That is, buying a drill, he actually wanted to quietly watch football.
Here it should be noted that the situation when someone comes up with strange, incomprehensible, crookedly formulated or, from your point of view, incorrect requirements is
normal . For people in general, it is natural that they want something, but they cannot always formulate exactly and correctly what they want. People, as a rule, such - it is natural. That is, the point is not that someone is wrong, but how you can work with such a situation.
At this particular moment, working with an internal customer is not very different from working with an external one.
Requirements for features that already exist
Bike about spy.
Somehow they sent a spy to one city to find out where the ammunition factory is located. They gave information to help that there is a church in the city, and if you walk straight up and to the left from it, then there will be a plant somewhere in that side.
Here comes the spy in the city. Meets grandmother and asks:
- say, and how to get to the church?
- and here you see cartridge plant? From him, go straight and then to the right. There will be a church.
The simplest case when it turns out that what we want is what we already have. Perhaps not quite in the form in which the person expected, imagined, imagined. Simply, either the person does not know what it is, or does not know how to use it, or he has incorrect information about how it works. Or you just need to tweak / enable something to get what you need.
When everything is so simple, it remains only to give a person instructions on how to get the result he needs using the available opportunities.
Is done.
Recurring requirements
It often happens that the requirements are similar, differ only in the nuances of the (potential) setting, or about the same, but in slightly different words. Such requirements can be combined to understand how much and in which places flexibility is needed (or will be needed in the future), and where it is not needed. What are the main functions? Once to make one system or piece of functionality that will satisfy all these needs at once. Perhaps with different settings or variations, but it will not be necessary for each need to do the same thing separately several times.
Example:
Representatives of several different departments come to you (as a rule independently of each other and at different times) and say that one needs to send reports to clients from the list, and another to notifications to a certain circle of addresses that some technical systems are not work. The third one comes and wants the client to send a letter with the results of the processing of client data.
Here it is obvious that in all cases a system for sending letters is needed, and the tasks for sending come from different places under different circumstances.
Accordingly, a certain unified system of sending letters appears. To which tasks can come from different systems. And if all of the above events (with which those who wish to send letters came to us) occur within the same system, then even better: it means that the system can be made more uniform and simpler.
If we do not work with the incoming requirements in this way, and they come in raw form immediately to the development - then after some time we will find our system with several different senders of letters, each of which works according to its own logic, has its own specific implementation, settings, functions. In order to change a small piece of logic in all three, or add a function from another to one of these senders, you need to either copy-paste the code, or rewrite quite a large part and refactor after implementation and operation. Although, in principle, one could understand in advance that this will be the case.
Conflicting requirements
It happens that some specific two or more requirements contradict each other. Sometimes “completely”, which can not be combined. Sometimes you can still provide “different modes”, in each of which one requirement is satisfied, and the other is not available. Or solve some of the problems in another way - then the contradiction will disappear.
To move towards a solution, you need to start unwinding the “why / why” chain. For each of the requirements (as described in the first part of the article). That is, we must understand as deeply as possible, from which precisely such demands have arisen, and that people who come with these requirements want “in fact”.
Then we have the opportunity to either find other solutions to these “real problems”, or to understand how these conflicting requirements can be combined.
For example, if one requirement is in fact necessary only in some specific narrow conditions, and the other in other specific narrow conditions. Then it turns out that they do not intersect. Or that task, for the solution of which a certain demand was invented, can be solved in a completely different way, perhaps even more simple and effective. And then one of the requirements disappears (or becomes completely different - which is in no way connected with the second), and the second remains. And there is no contradiction.
Or understand: these requirements can not be combined, and you need to choose some one. But, fortunately, it is still quite rare.
All this is possible because almost every problem can be solved in several ways. And if we are going from higher and higher technical terms to higher and higher in the understanding of what the task is in principle, then there are more and more solutions. Including non-technical solutions (settings, process, organizational, etc.). And the wider the choice of options, the easier it is to choose two options for solving two problems that do not interfere with each other, and even, perhaps, help if they succeed.
Boiler requirements
The idea is that initially all disparate demands from all sources should merge into some kind of single heap, into some kind of single boiler. After that, they can be disassembled from there, analyzed for the above described options - “repeated” or “contradictory”, in order to produce at the output already prepared: non-repeating and consistent requirements that can be “taken and done” in the correct order.
That is, the idea is to look at the whole picture. For everything that is now and that they want to add, change. And based on this whole picture, it is already up to decide what to do, how and when.
In such a context, all incoming requirements are the raw materials in order to get ready for development tasks at the output. Moreover, the tasks at the exit will not always coincide one-to-one with some incoming need. One task can satisfy several needs at once or close a whole class of requirements. Or be just part of some big story.
Total
This is how the incoming chaos turns into a beautiful, useful, and understandable for developers set of tasks and functions of your system, which pleases your colleagues.