The technical task: why the wording “Make as here” does not work?

I think this article will be relevant for many IT domestic non-software companies of large and medium size with "pocket" IT, not focused on the release of "boxed" products, most of the situations described below are typical for companies where IT is an "application" to the core business. The article does not in any way claim to be the ultimate truth and does not give any “special” recommendations on who should do what, but only illustrates possible options for the development of possible participants in the situation “how to make it so as not to ruin the system” with an emphasis on TK and on the relationship in the team. For many, the situation may be more than obvious, and for some it will open its eyes, so perhaps it will be useful to someone, as well as bring a little humor to life.

Consider a typical example from the life of ordinary programmers in such a company: a large system X is being developed, in which there are many complex and interesting (and sometimes not very interesting) - and the business is quite successful, and there are programmers, and managers / analysts - as a connecting link between business and programmers. Everything seems to be smooth, debugged, works. And a lot of code, and bugs. And you will not find actual documentation often in the afternoon with fire ... In general, everything is “like everyone else”. You can live.



')
Let us imagine a situation: there is a manager (analyst) Masha, based on the needs of the customer, Ivan Ivanovich (AI), who built a certain technical task (TK) for the programmer Vasya, which says something like "Take functionality from point A of system X and repeat it in place B (of system Y) ". In other words - “Make as here”, without a detailed description of all the technical details of the implementation.

This situation carries enormous risks.

First, programmer Vasya can misunderstand the TK and, in the absence of Vasya’s habit of asking questions, as well as constant monitoring from Masha or his immediate superior, Petit, make complete garbage. If Vasya is a typical programmer, it can happen with a certain degree of probability.



Secondly: in the event that Masha / Petya is still “keeping abreast”, and Vasya still misunderstands the TK, he has a number of questions for Masha and Pete. In the best case, Masha, Petya and Vasya will somehow somehow somehow agree and eventually spend an unmeasured amount of nerves, break ten copies, eat a pound of salt and get a dule from the AI ​​for disrupting the deadlines, all the same by means of Vasin who worked to calluses brains implement a functional that is more or less or even fully compliant with customer requirements.

There will be an obvious and short-lived happiness for all. Vasya will play his favorite Counter Strike, Masha will make a career, Petya will be completely and completely left to communicate with his family and a trip to Turkey, and the AI ​​as a real capitalist will count profits. Exactly until the implemented functionality does not need to be significantly changed / redone. And then comes the new round of proceedings in the undocumented code, ill-conceived architecture, attempts to redo everything. In general, the ordinary labor process of these workaholic from IT. The months and years spent on this are not considered by anyone except, perhaps, the wives of programmers.



Third: if for some reason Vasya “rested” (for example, he had a personal conflict with Masha or Petya on the basis of psychoemotional stress caused by general overwork and affect from what he saw or simply earning money for a mortgage) companies are not very good, or Masha (or Petya or Vasya - it doesn’t matter) pursue any personal goals (for example, putting Masha into the leading analysts, whom she achieves by all available means, including very unethical ones), or else either c us - in this case, things can turn bad: for Masha / Washi / Petit, and for the customer / system as a whole. Copies will be broken even more, about the nerves, reputation and general attitude, I do not even say; and the salt will not be eaten any more pood, but the whole KAMAZ. About the timing of the task at all out of the question. And this is on condition that no one leaves, spitting on all this (or it will not “go away”) and the task / project will not be ruined at all.



The situation is potentially not beneficial to anyone: neither Vasya, nor Masha, nor Pete, nor AI and his business as a whole. But, nevertheless, this happens quite often and everywhere.

Question: what to do to avoid this situation?



AI: Work on development. To think not only by categories of business (“my business needs to earn money on this — and I will give money for it, but not on everything else”), but also on categories of development. As an option - do not save and get yourself a good CEO who can work together with everyone, correctly distribute tasks and priorities and build a working process. As an option - to make CEO Petya, “having grown him up”. No matter, it all depends on the specific situation and the availability of time and resources. In general, the key word here is “good.”

Masha: Work on development. And not only your own. Despite all the desire to make a career, still describe in detail all the technical details of the upcoming TK. A manager / analyst who does not understand (or does not want to understand) all the technical intricacies - a priori is not a good manager / analyst; here, most likely just the desire to make a career, and nothing more.

Pete: Work on development. Improve system architecture. Understand what Vasya is doing. Do not allow bad goat procreation - neither Vasya, nor Masha, nor even AI. Understand what the AI ​​wants and what Masha wants. Sometimes these are different things. :) Highlight Vasya one day a week, which he will spend on improving interfaces, code optimization, mowing bugs, etc. And while not listening to either Masha or AI, if they are trying to “take away” the programmer at a specified time from him.

Vasya: Work on development. Not only engage in tasks that the direct superiors put at work: study (or even write) some interesting framework, create an interesting website or service, or blog. To keep abreast of current trends in IT and not get hung up. Get out of the comfort zone. And sometimes to think not as a programmer, but as a manager, analyst, Petya, Masha, AI and Bald Devil himself combined. Ask questions, including yourself. If the roof does not go.



And then, perhaps, Vasya, Petit, Masha and AI will end up with a good and high-quality product.