Terms of Reference: why the wording “Make it Like Here” doesn’t work?

    I think this article will be relevant for many IT domestic non-software large and medium sized companies with "pocket" IT, not oriented to the production of "boxed" products, the situations described below are most typical for companies where IT is an "application" to the main business. The article in no way claims to be the ultimate truth and does not give any “special” recommendations to whom it is necessary to do, but only illustrates the possible options for the development of possible participants in the situation of “how to avoid ruining the system” with an emphasis on compiling TK and relations in the team. For many, the situation may be more than obvious, and for some it will open their eyes, so it may be useful to someone, and also bring a little humor to life.

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

    And imagine a situation: there is a manager (analyst) Masha, based on the needs of the customer, Ivan Ivanich (AI) who built some kind of technical task (TOR) for the programmer Vasya, which says something like “Take the functional from place A of system X and repeat it at location B (system Y). ” In other words, “Make it like this,” without a detailed description of all the technical details of the implementation.

    This situation carries enormous risks.

    First: the programmer Vasya may misunderstand TK and, in the absence of Vasya’s habit of asking questions, as well as constant monitoring by Masha or Petya’s immediate boss, make complete garbage. If Vasya is a typical programmer, this can happen with a certain degree of probability.

    Second: in case Masha / Petya nevertheless "keeps abreast", and the lack of understanding of TK Vasya still raises a number of questions for Masha and Petya. In the best case, Masha, Petya, and Vasya eventually somehow agree, and as a result, having spent an immense amount of nerves, breaking a dozen copies, eating a pound of salt and receiving a dule from the AI ​​for the failure to meet the deadlines, all the same, through Vasins strained to corns brains implement functionality that more or less or even fully meets the requirements of the customer.

    There will come an obvious and short-lived happiness for everyone. Vasya will play his beloved Counter Strike, Masha will pursue a career, Petya will completely devote herself to socializing with her family and a trip to Turkey, and AI, as a real capitalist, will take profits. Exactly until the implemented functionality does not need to be significantly changed / redone. And then there comes a new round of proceedings in undocumented code, ill-conceived architecture, attempts to redo everything. In general, the ordinary workflow of real IT workers. Months and years spent on this, no one considers, except, perhaps, the wives of programmers.

    Third: if Vasya “rested” for some reason (for example, he had a personal conflict with Masha or Petya on the basis of psychoemotional stress caused by general overwork and the state of affect from the seen code, or simply by making emergency money for a mortgage), or the company’s situation is not very good, or Masha (or Petya, or Vasya - it doesn’t matter) pursue any personal goals (for example, promoting Masha to leading analytics, which she achieves by all available means, including very unethical ones), or by some other either reason us - in this case, things can turn bad: for Masha / Washi / Petit, and for the customer / system as a whole. The copies will be broken even more, about the nerves, reputation and general attitude, I do not even speak; and salt will no longer be eaten by a pud, but by a whole KAMAZ. About the timing of the task is generally out of the question. And this provided

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

    Question: what to do in order not to fall into such a situation?

    AI: Work for development. Thinking not only in terms of business (“my business needs to earn on this - and I will give money for this, but not for everything else”), but also in terms of development. As an option, don’t save money and make yourself a good CEO who can work with everyone, correctly distribute tasks and priorities and build a workflow. As an option - make CEO Petya, “growing” him. 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 pursue a career, still describe in detail all the technical details of the upcoming TK. Manager / analyst who does not understand (or does not want to understand) all the technical details - a priori there is no good manager / analyst; here, most likely just a desire to make a career, and nothing more.

    Pete: Work for development. Improve system architecture. Delve into what Vasya is doing. Do not allow govnokod to producebad - neither Vasya, nor Masha, nor even AI. To delve into what the AI ​​wants and what Masha wants. Sometimes these are different things. :) Allocate Vasya one day a week, which he will spend on improving interfaces, optimizing code, mowing bugs, etc. And at the same time, do not listen to either Masha or the AI, if they try to “take” the programmer from him at the indicated time.

    Vasya: Work for development. To deal not only with the tasks that the immediate boss sets at work: to study (or even write) some interesting framework, create an interesting site or service, and maintain a blog. Keep abreast of current trends in IT and do not go in cycles. Get out of the comfort zone. And sometimes thinking not as a programmer, but as a manager, analyst, Petya, Masha, AI, and Bald Damn together. Ask questions, including to 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.

    Also popular now: