👷‍♂️ Во многих компаниях роль инженера в эксплуатации АСУ ТП деградировала до уровня обслуживания. На инженерные позиции нанимают техников и слесарей, способных только заполнять обходные листы и выполнять несложный модульный ремонт. Последствие такой опрометчивости — по любой серьезной задаче приходится бежать к настоящим инженерам, например из какого-нибудь системного интегратора.

✍️ И ко мне тоже обращались. И определенное количество проектов я успел сделать как фрилансер. И каждый раз сталкивался с одной и той же проблемой — формирование технического задания. Обычно если внутри компании нет специалиста, способного решить задачу, то и грамотное ТЗ никто составить не в состоянии. Это моя принципиальная позиция, которую я считаю невероятно важной: «Чем менее глубоко человек погружен в техническую реализацию задачи, тем менее качественной будет его постановка». Сколько бы оператор ни тыкал в кнопки, систему управления он не разработает — он не знает, что "под капотом".

🔍 Если заказчик понимает, что не обладает экспертизой — грамотным решением будет позвать эксперта со стороны. Организовать прослойку между собой и конечным исполнителем. В нормальных IT-компаниях такой прослойкой часто выступает аналитик. Он сможет принять грамотные проектные решения, так как достаточно глубоко погружен как в предметную область, так и в технические детали реализации. Многое из того, что напишет эксперт может быть непонятно и это нормально, ведь ценность аналитика напрямую зависит от его автономии в принятии решений. Делегирование — это всегда про доверие и готовность пожертвовать частью контроля над ситуацией. Именно это отличает грамотного управленца от очередного эффективного менеджера.

🐌 Но не всегда решения принимаются оптимально, и тут есть как минимум два способа сесть в лужу. Первый способ — это микроменеджмент. Заставить эксперта со стороны объяснять каждый свой шаг, обложить регламентами, ограничить автономию в принятии решений. Процесс превращается в бесконечную череду согласований, когда вместо принятия верного решения начинают размусоливать альтернативы. И вместо «отдали на сторону и быстро получили качественные требования» появляется «провели серию совещаний, обсудили альтернативы...». В конечном счете процесс затягивается, а качество решений значительно снижается. Ведь дефицит экспертизы никуда не пропадает — глупо выбирать из альтернатив, которые ты не можешь понять. Это особенно заметно, когда таких решений у руководителя несколько десятков в день.

🧨 Второй способ — работать без ТЗ или заставить исполнителя писать ТЗ самому себе, признаюсь, я и сам так делал. Это удобная модель: ответственность формально есть, требования тоже, в такой модели хорошо все, кроме конечного результата. Так работают рыночные отношения — чем менее качественный продукт будет формально подходить под ТЗ, тем больше денег можно заработать на поддержке и доработках. Никто не производит вечные лампочки. Иногда это превращается в откровенный сюр, когда на любую просьбу о доработке есть универсальный ответ: "изначальная архитектура этого не предполагала, нужно начинать с нуля".

📌 Хороший способ все это понять — дождаться, когда команда распадется, а на руках останется забагованный прототип. Обычно это очень дорогая ошибка, и повод перестроить процессы в компании, чтобы не допустить повторения. И только качество процессов определит, будет ли в очередном проекте что-то новое кроме названия.