Как-то раз мой хороший товарищ Иннокентий, на сегодняшний день весьма успешный PM и отличный специалист, спросил: «Как ты думаешь, с какой фразы начинается дорога в ад?». Я недоумевая поднял бровь. «С фразы: А давайте работать без ТЗ», — ответил он и рассказал мне весьма поучительную историю.
Как Кеша сайт делал
Лет пять назад он работал маркетинг менеджером в одной средних размеров конторе. Занимался, как водится, всем: придумывал наружную рекламу и видео-ролики, строчил тексты, отвечал за мерчендайзинг на торговых точках, в общем, был и жнец и на дуде игрец. Никто уже не помнит как именно прогресс добрался до этой компании, но в один прекрасный день руководство решило, что их фирме срочно необходим веб-сайт. Руководить проектом разработки, назначили как раз моего приятеля.
С компанией подрядчиком определялись не долго. С лёгкой руки директора была выбрана студия мужа подруги жены — «мировые ребята, Люся всегда о них хорошо отзывалась». После первой же встречи было решено, что задача стоит совершенно простая — запилить сайт-визитку. Ребята уже 1000 раз такое делали и были полностью уверены, что справятся быстро и без проблем. На попытку Антона что-то сказать о планировании проекта разработчики только улыбнулись: «Да чего тут думать? Тут делать нужно». «И как можно скорее — вон у конкурентов уже месяц как сайт есть», — поддержал ребят глава отдела продаж, — «ты думаешь мне просто на встречи ходить позориться? Все и так думают, что мы отсталые». В конце собрания было решено, что сайт должен быть готов через полтора месяца и не минутой позже.
«Когда я умру, и за мной явятся черти», — говорил мне Кеша, — «они тоже скажут, что задача совсем простая. С каждым новым шагом они будут рассказывать мне о том, что вспомнили о какой-то пустяковой функции, которая изначально подразумевалась и была всем и так очевидна…»
Проблемы начались почти разу: сперва, разработчики вернулись через 2 недели после вышеупомянутого собрания и принесли не то. Мой товарищ так им и сказал, после чего ребята обиженно ушли переделывать. Позднее, когда они пришли с более подходящим вариантом Иннокентия ждал новый сюрприз. В процессе демонстрации продукта коллегам он выяснил, что те представляли корпоративный сайт совершенно иначе. По их мнению всё нужно было срочно переделать. Вот с этого момента начался Кешин персональный ад. Сперва он день ото дня ругался с коллегами, объясняя, что сайт-визитка не предполагает возможности прямой продажи продуктов через интернет и решает совсем другие задачи.

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