Why we never make TK. And what in return?

There are different development methodologies. Everyone chooses for himself the approach that best suits the development company. As a basis for our own methodology, we use extreme programming (XP). Of course, we made our own changes to it, but today I would like to tell more about this.



Any project begins with a technical task. So it was before, but for many it remains an axiom to this day. This is not bad, but we have almost completely abandoned TK. Now it reduces us to a tremendous amount of time, which was wasted earlier almost in vain.

User must make TK

The most inefficient way to build TK is to communicate with users. But how can you argue, because the programs are written for users! Yes, programs are written for users, but not by users. Imagine a certain worker who tightens the screws on the conveyor every day. You ask him what you need to do to make it convenient for him to tighten the screws? He will say that it is desirable to make an auto-adjusting key that does not need to be set to the desired position in order to get them on the nut. You need a key that turns the screws on its own, you need a comfortable chair so as not to stand near the conveyor and so on. You scrupulously write down all the wishes and make them in the TK. After all, you solve the real problems of the user! You go to the second worker, and he tells you that it would be nice to have a tap with water and a refrigerator with sandwiches near the workplace, so that you can have a snack while working. Third, and so happy with everything, well, that only muzonchik needed, tedious work after all.
')
So, we recorded all the wishes of the workers. Now the question is, what is the effectiveness of solving the pressing problems of users from the point of view of the company? I think that it fluctuates around zero. It is like repainting all the buttons in blue. Like and did something, but to sense from this ...

To whom should I go for TK?

To the one who builds the processes. These may be department heads and department heads, planning departments, and so on.

The worker knows only his own process, and he is forced upon him from above. The chief knows the processes of all the employees in subordination and the processes of interaction with other departments. This is what is important. To begin with, it is worth trying not to try to insert business processes under the program’s capabilities, but to implement them in code. Then the program will make sense and will be used. Otherwise, everyone will be sent to the drawer in a month, or maybe earlier. As it seems to me, Google Wave was not accepted by users just because it did not solve the problem, but focused on the process. The process as a thing in itself, in isolation from reality, is of little interest.

Again, do not try to squeeze the maximum out of these people. Stand in place of a simple department head. In addition to maintaining a fragile order in the chaos of fluctuations of the streams of consciousness, actions and decisions of subordinates, he also needs to be involved in drafting a document, which for him is not something third-rate, it is generally far beyond the horizon of execution cases. And the questions that you will ask them for them are equivalent to questions like: “Tell me in detail about the process of picking your nose”. You can talk, but these conversations do not bring money at the moment.

What to do if the business process is not formalized?

Then you have to create it yourself. Yes, it is the developer who needs to offer the business process to the customer. To do this, you will have to spend time studying the methodologies of the client, to penetrate into his problems, to identify the key points of automation. Proposals must be received at all stages of development, and not only at the time of formalization of certain general requirements. Each developer, without exception, must know why he is doing something, what is the reason, what business process is embodied in the code.

The most ideal customer, in my opinion, is the one who trusts you not just automating your own processes, but also reorganizing them to achieve the greatest effect from automation. It sounds paradoxical, but the most successful examples of automation are obtained where TK is minimal. It's like that treasured “Make Beautiful” button.

Eloquent Prototype

Nothing stimulates the formalization of customer requirements better than a prototype. He clearly shows him all the charms and shortcomings of the internal organization of the production process. I have written enough about prototypes without me, so I will not dwell on this.

But how without TK?

We replaced the TK with some problem cards. This is a summary of the tasks for the solution, written in freestyle. Solved the problem = fulfilled the agreement. It's simple.

At the time of development, we become like a department of the customer’s company, which in parallel works for a single result. Teamwork on tasks encourages the customer to think about the ordering of thoughts regarding the formalization of a brief TK, but at the same time it does not interfere much with the daily work of doing business. It turns out such an unobtrusive development.

Summing up

Of course, this is not a silver bullet and not a panacea for all ills. Everyone must choose their own path in business development and look for the best solutions for the current market situation.

Good luck with your business!