Техническое задание не спасет проект, если никто не понял задачу бизнеса

Я люблю хорошее техническое задание. Оно снимает лишние догадки, помогает договориться о границах работы и потом честно принять результат. Но есть момент, который часто забывают: техническое задание не отвечает на вопрос, правильно ли команда поняла саму задачу бизнеса.

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

Поэтому перед ТЗ я стараюсь вернуть разговор на шаг назад: что в работе компании сейчас происходит, кто от этого страдает, какое решение должен получить руководитель или клиент и по каким признакам мы поймем, что стало лучше.

ТЗ фиксирует решение, а не находит проблему

В документ обычно попадает уже выбранный путь: «сделать личный кабинет», «внедрить CRM», «собрать дашборд», «добавить мобильное приложение». Эти формулировки выглядят как задачи, но часто это лишь предполагаемые ответы.

Допустим, руководитель говорит: «Нам нужен отчет по продажам в реальном времени». Легко сразу обсуждать графики и права доступа. Но полезнее спросить: какое решение он не может принять сегодня? Данные приходят поздно? Цифрам не доверяют? Менеджеры по-разному называют одну и ту же стадию сделки? Причины могут быть разными, а значит и решение тоже.

Если данные не сходятся между отделами, новый красивый отчет даст только более быстрый доступ к спору. Если сотрудники не обновляют статусы, можно бесконечно улучшать интерфейс, но проблема останется в правилах работы и ответственности.

Где проект обычно сворачивает не туда

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

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

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

Сначала посмотреть на обычный день

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

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

Полезно отдельно разобрать три вещи:

• какое событие запускает процесс и кто за него отвечает;
• где появляется ручная передача, ожидание или повторный ввод данных;
• каким результатом процесс должен закончиться для клиента и для бизнеса.

Эта простая карта часто меняет будущий документ сильнее, чем десяток совещаний про стек технологий.

Типовой пример: автоматизировали согласование, а тормозил выбор

Представим составную для многих компаний ситуацию. Команда жалуется, что договор долго согласуется, и просит систему маршрутов. На первый взгляд все очевидно: настроить этапы, уведомления и напоминания.

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

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

Как отделить факт от предположения

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

Я стараюсь прямо помечать такие места. «Считаем, что клиенту важен этот статус», «полагаем, что согласование задерживается здесь», «ожидаем, что отдел готов работать по одному справочнику». Рядом полезно записать, как именно это проверить: посмотреть несколько реальных операций, поговорить с конкретной ролью, сравнить данные из двух источников.

Эта привычка делает обсуждение спокойнее. Команде не нужно изображать уверенность там, где ее пока нет. Собственник видит, какие решения уже обоснованы, а какие требуют короткого исследования до вложений в разработку.

Особенно важно проверять не средний случай, а неудобные края процесса: отмену заказа, возврат, смену ответственного, нестандартную цену, отсутствие данных. Именно там обычно живут ручные обходы, которые потом неожиданно становятся «обязательной функцией».

Не просите ТЗ заменить решение собственника

Бывает, что документ пытаются использовать как способ отложить неприятный выбор. Например: кому принадлежат данные, какой отдел отвечает за качество справочника, можно ли отказаться от старого исключения, кто имеет право менять условия сделки. Разработчик не может принять такие решения за бизнес, даже если его попросить описать все максимально подробно.

В хорошем старте проекта это видно сразу: технические вопросы идут рядом с управленческими. Команда может предложить варианты и показать последствия, но приоритеты, правила и допустимые компромиссы должен подтвердить тот, кто отвечает за результат бизнеса.

Тогда ТЗ перестает быть попыткой переложить ответственность в документ. Оно становится общей фиксацией уже принятого решения — и это гораздо надежнее.

Что должно появиться до подробного ТЗ

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

1. Кто и какое решение должен принимать быстрее или точнее. Не «кто будет пользоваться системой», а какое действие изменится.
2. Какая цена текущей проблемы. Это может быть ожидание клиента, переделка, потерянная заявка, лишняя ручная операция или риск ошибки.
3. Какие данные являются источником правды. Если их несколько и они расходятся, это отдельная задача.
4. Что изменится в процессе вместе с системой. Новый инструмент редко работает сам по себе.
5. Как выглядит первый полезный результат. Не идеальная платформа через год, а конкретный работающий шаг.

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

Техническое задание все равно нужно

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

Он нужен команде, чтобы не додумывать требования по дороге. Он нужен собственнику, чтобы видеть границы вложений. Он нужен обеим сторонам, чтобы изменения не превращались в спор о том, «что имелось в виду».

Но ТЗ — это карта выбранного маршрута. Прежде чем аккуратно рисовать карту, стоит проверить, туда ли вообще идет компания. Для этого полезно посмотреть на реальную работу бизнес-процесса, а не только на желаемую схему. А если нужна рамка, в которой соединяются задача, продукт и технология, она начинается с разбора системы целиком.

Хорошее ТЗ не спасает неверную идею. Зато оно отлично помогает довести до результата ту задачу, которую действительно поняли.