Почему мы не пишем ТЗ на 700 страниц
К нам приходят компании, которые уже через это прошли.
Недавний разговор. Клиент присылает очень подробное техническое задание, со скриншотами и названиями каждой настройки, которую будут менять — мы читаем и понимаем: ТЗ хорошее, люди старались, но если делать по нему, система никогда не заработает. Говорим об этом. В ответ: «Да, нам подрядчик два года внедрял по этому ТЗ. Хотим с ним судиться. Можете провести аудит и дать заключение?» Мы отказались.
Это не редкость. Это стандартный сценарий: предпроектное обследование, техническое задание, разработка, тестирование — и на выходе система, в которой невозможно работать. Бюджет потрачен, команда устала, подрядчик ушёл.
Проблема не в людях — проблема в подходе. Когда вы пытаетесь описать всё заранее, вы неизбежно ошибаетесь. Задачи меняются, пока пишется ТЗ. Решения устаревают, пока идёт разработка. Ошибки копятся — и всплывают разом, когда исправлять уже поздно.
Мы работаем по-другому. Короткими итерациями — работающий результат. Ошибки ловятся сразу, а не через два года. Это не быстрее и не дешевле. Но это работает.