When you create complex software, a long production chain is inevitably built, as well as the gap between those who program this software and those who ultimately use it. This is especially felt when people involved in the development do not use the product they create. In our case, this chain is also lengthened due to the fact that the final product is received not even by our direct customers, but by their customers.
The larger the chain of production, the more problems there are, and the more disconnected from the end user the product is. When a programmer developing a product cannot put themselves in the user’s place, we may experience two problems:
- The programmers don’t have a full understanding of the value of what is being developed. They, as a rule, are more focused on what they do and what they know than on why this is done.
- The programmers don’t have a full understanding of how this product will be used.
In our practice, there were many examples of what such a gap may lead to.
We do not have analysts in the company, their work is mainly done by product owners, and inevitably it turns out that some things should be done by programmers. Once, a customer came to us and asked for the new feature that allows getting screenshots from archived videos. For this to work, we need to make timestamps for the video file.
Without detailed explanations, the task to develop this feature went to the programmer. We handed the resulting feature to the customer, and it turned out that they did not understand how to use it. The programmer wrote a code in which you need to refer to the segment number, after which a screenshot is issued from the very beginning of this segment. The programmer proceeded primarily from the fact that this code was easier and faster to write, and not from how usable and understandable it would be.
Cutting the Distance
Of course, we fixed the problem and made the feature more convenient and usable, but the question arose: how could we avoid this situation in the first place? We could hire analysts, but we don’t have such a level of bureaucracy and not such a number of tasks that would constantly need their involvement. Therefore, the gap between the developer and the user needs to be reduced differently.
There are many approaches to how to get rid of this gap, while not removing the reason why it initially occurs: with the growth of projects the growth of bureaucracy is inevitable. This is not something to struggle with – it is just a fact that we accept. No project can exist without bureaucracy.
In the end, we came to this conclusion: if a programmer first wrote a short, simple manual on how to use this code, he would immediately understand how inconvenient and non-client oriented his idea was. All his decisions were logical and understandable from the point of view of development, but not from the point of view of the customer. This is what Read Me Driven Development is all about – starting from the end, taking the place of the customer even before the development started.
You need to understand that we are not talking about some kind of “Terms of Reference” document, which goes through dozens of approvals. The “Terms of Reference” is a document that describes what to do, and good technical specifications in terms of complexity are comparable to the code itself. Read Me document should not be about how to write the code; it is about how the customer will use the product. The Read Me file, unlike complex technical documentation, removes unnecessary details and leaves only the most important things. It becomes clear whether this solution needs to be developed or not, how it will solve the customer’s problem and how understandable it will be.
The RDD approach is difficult to apply for products that have a graphic interface. It is much easier when dealing with a text interface and API. This is exactly our case – we work with the API, config and admin panel. When we make a ticket, we work out the API itself by writing it in advance, after which we compile the config file. We describe the scenarios that processes can follow, and on the move, we can begin to rethink our idea of what and how should work.
Start From the End
When developing frontend and backend, the question often arises – what do we do first? Now we are moving on to the approach when the first thing we do is the design of the feature, and only after that, the backend is written – thus, in fact, we start from the end. Previously we moved from the backend to the frontend, and in the end, we often had to redo a lot.
When we start moving from the result to the beginning, we switch our attention to what’s more important. If the “Terms of Reference” concentrates on the details and distracts from the result, a simple Read Me file concentrates on the result and distracts from the details. In the end, we get significant time saving and a satisfied customer who has been heard and understood.
submitted by /u/flussonic
[link] [comments]