fbpx

Без ТЗ — результат ХЗ!

17 февраля 2017

  • Автор: Мэри Ротарь

  • Сложность: норм

  • Время: 4 мин

Как-то раз мой хороший товарищ Иннокентий, на сегодняшний день весьма успешный PM и отличный специалист, спросил: «Как ты думаешь, с какой фразы начинается дорога в ад?». Я недоумевая поднял бровь. «С фразы: А давайте работать без ТЗ», — ответил он и рассказал мне весьма поучительную историю.

Как Кеша сайт делал

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

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

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

Проблемы начались почти разу: сперва, разработчики вернулись через 2 недели после вышеупомянутого собрания и принесли не то. Мой товарищ так им и сказал, после чего ребята обиженно ушли переделывать. Позднее, когда они пришли с более подходящим вариантом Иннокентия ждал новый сюрприз. В процессе демонстрации продукта коллегам он выяснил, что те представляли корпоративный сайт совершенно иначе. По их мнению всё нужно было срочно переделать.  Вот с этого момента начался Кешин персональный ад. Сперва он день ото дня ругался с коллегами, объясняя, что сайт-визитка не предполагает возможности прямой продажи продуктов через интернет и решает совсем другие задачи.

Без ТЗ — результат ХЗ! 0

Когда стало понятно, что продукт надо сдать в сентябре, а на дворе уже август и решения всё нет, к разбирательствам присоединились ТОП-менеджеры и разговаривать они стали исключительно на повышенных тонах.  Руководство ограничивалось рыками: «Это так не работает, а как нужно — мы не знаем, решите проблему!»

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

Банальный, но важный документ

Работа без ТЗ — это путь в ад. По дороге теряются деньги, время, нервы, терпение, умирают проекты и ломаются жизни. Это не только Кешино мнение.  Все очень логично — ТЗ — это не просто документ — это инструмент, который решает ряд конкретных задач. Чтобы поменять колесо в машине, вам нужен домкрат, чтобы разработать эффективный IT-проект , вам нужно ТЗ. Зачем? Вот только часть причин:

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

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

  • Мы хотим копию продукта конкурентов — зачем нам ТЗ?
  • Наш проект — это коммерческая тайна и мы никому о нем не расскажем.
  • Мы ещё не знаем, чего хотим в итоге и хотим рассмотреть разные варианты.

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

Плюсы работы без ТЗ

Есть ли какие-то плюсы от работы без ТЗ? Только в том случае, если у вас извращённое чувство прекрасного:

  • У вас есть свобода принятия решений — за которую потом придётся дорого платить.
  • Отсутствием ТЗ можно обосновать повышенную неопределённость и заложить бюджет на всякие «сюрпризы», если конечно вам дадут это сделать, однако после начала работы думать об этом будет уже поздно.
  • Формирование и проверка ТЗ требуют вложения времени и сил до начала основной работы. Отсутствие ТЗ позволяет эти усилия перенести на более поздний срок, правда в этом случае часть уже сделанной работы придётся переделывать.
  • Вы всегда можете «переиграть» в свою пользу плохо проговорённые  моменты. Особенно, если вы мастер скорее слова, чем дела.

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

Мэри Ротарь

CEO и Co-Founder в IAMPM 10 лет опыта в маркетинге и управлении продуктами. Вывела на рынок более 50-ти проектов в роли консультанта, работала как Product Manager в SaaS, Gaming и EdTech нишах. Вырастила лабораторию Нетехнического IT-образования IAMPM из хобби в международный бизнес.