На поверхности этот пост — про ТЗ. Про то, почему интегратору вредно бездумно исполнять «подключите телеграм», «добавьте поле», «настройте воронку». Но по сути он вскрывает не проблему ТЗ как документа. Он вскрывает типичные управленческие поломки, из-за которых бизнес начинает лечить симптомы вместо причин. И это гораздо важнее.

Первая проблема — подмена анализа заказом на инструмент.

Это очень узнаваемая управленческая логика: не разбираться, почему теряются заявки, где ломается процесс, кто за что отвечает и на каком этапе исчезает контроль, а сразу заказать решение в терминах инструмента. Подключить чат, настроить согласование, добавить поле, внедрить AI. То есть компания говорит не «у нас сбой в управлении продажами», а «нам нужен телеграм в Битрикс24».

Так удобнее. Инструмент обсуждать проще, чем собственную управленческую несостоятельность.

Вторая проблема — желание купить решение без диагноза.

Это вообще одна из самых дорогих управленческих привычек. Руководитель хочет сразу перейти к действию, минуя неприятный этап: признать, что система устроена плохо, процессы не прозрачны, роли пересекаются, деньги теряются, а картина происходящего у компании фрагментарная.

Появляется иллюзия: сейчас мы «докрутим» один элемент — и всё заработает.

Но если причина не в отсутствии поля, не в чате и не в воронке, то компания просто автоматизирует собственный бардак.

Третья проблема — локальная оптимизация вместо системного решения.

Это особенно хорошо видно в примерах автора. Можно идеально выполнить ТЗ. Красиво, по пунктам, с актом и бантиком. Но это будет улучшение маленького куска системы, а не бизнеса в целом.

И вот тут начинается классическая управленческая ловушка: руководству кажется, что работа сделана, деньги потрачены не зря, цифровизация идёт. А результат не меняется. Потому что улучшили локальный элемент, а ограничение системы осталось на месте.

Четвёртая проблема — перекладывание мышления на исполнителя или отказ от мышления вообще.

Это очень характерно для незрелого управления. С одной стороны, бизнес хочет, чтобы подрядчик «просто сделал по ТЗ» и не задавал неудобных вопросов. С другой — потом от него же ждут, что он каким-то образом поймёт реальную проблему и спасёт ситуацию.

То есть ответственность за решение как будто передали, а ответственность за постановку задачи — нет. В итоге исполнитель либо превращается в «человека-кнопку», либо вынужден заниматься диагностикой там, где заказчик хотел купить только руки.

Пятая проблема — страх смотреть на реальные причины.

Именно поэтому так популярны псевдорешения. Признать, что у вас не телеграм не подключён, а неуправляемы продажи, — тяжело. Признать, что дело не в отсутствии согласования, а в хаосе полномочий и зависших решениях, — ещё тяжелее.

Намного приятнее сформулировать проблему технически. Тогда она выглядит локальной, безопасной и как будто легко устранимой.

В этом смысле пост вообще не про интегратора. Он про то, как бизнесы пытаются спрятаться от собственных управленческих проблем за языком внедрения.

Именно поэтому фраза «я не люблю работать по ТЗ» в этом тексте на самом деле означает совсем не то, что кажется. Не «я не люблю порядок», а «я не хочу автоматизировать чужие заблуждения».

И вот это, пожалуй, самая сильная мысль.

Хорошее ТЗ не вредно. Вредно ТЗ, которое появляется вместо управленческого мышления. Когда диагноз ещё не поставлен, а рецепт уже выписан.

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