Как-то раз мой хороший товарищ Иннокентий, на сегодняшний день весьма успешный PM и отличный специалист, спросил: «Как ты думаешь, с какой фразы начинается дорога в ад?». Я недоумевая поднял бровь. «С фразы: А давайте работать без ТЗ», — ответил он и рассказал мне весьма поучительную историю.
Как Кеша сайт делал
Лет пять назад он работал маркетинг менеджером в одной средних размеров конторе. Занимался, как водится, всем: придумывал наружную рекламу и видео-ролики, строчил тексты, отвечал за мерчендайзинг на торговых точках, в общем, был и жнец и на дуде игрец. Никто уже не помнит как именно прогресс добрался до этой компании, но в один прекрасный день руководство решило, что их фирме срочно необходим веб-сайт. Руководить проектом разработки, назначили как раз моего приятеля.
С компанией подрядчиком определялись не долго. С лёгкой руки директора была выбрана студия мужа подруги жены — «мировые ребята, Люся всегда о них хорошо отзывалась». После первой же встречи было решено, что задача стоит совершенно простая — запилить сайт-визитку. Ребята уже 1000 раз такое делали и были полностью уверены, что справятся быстро и без проблем. На попытку Антона что-то сказать о планировании проекта разработчики только улыбнулись: «Да чего тут думать? Тут делать нужно». «И как можно скорее — вон у конкурентов уже месяц как сайт есть», — поддержал ребят глава отдела продаж, — «ты думаешь мне просто на встречи ходить позориться? Все и так думают, что мы отсталые». В конце собрания было решено, что сайт должен быть готов через полтора месяца и не минутой позже.
«Когда я умру, и за мной явятся черти», — говорил мне Кеша, — «они тоже скажут, что задача совсем простая. С каждым новым шагом они будут рассказывать мне о том, что вспомнили о какой-то пустяковой функции, которая изначально подразумевалась и была всем и так очевидна…»
Проблемы начались почти разу: сперва, разработчики вернулись через 2 недели после вышеупомянутого собрания и принесли не то. Мой товарищ так им и сказал, после чего ребята обиженно ушли переделывать. Позднее, когда они пришли с более подходящим вариантом Иннокентия ждал новый сюрприз. В процессе демонстрации продукта коллегам он выяснил, что те представляли корпоративный сайт совершенно иначе. По их мнению всё нужно было срочно переделать. Вот с этого момента начался Кешин персональный ад. Сперва он день ото дня ругался с коллегами, объясняя, что сайт-визитка не предполагает возможности прямой продажи продуктов через интернет и решает совсем другие задачи.
Когда стало понятно, что продукт надо сдать в сентябре, а на дворе уже август и решения всё нет, к разбирательствам присоединились ТОП-менеджеры и разговаривать они стали исключительно на повышенных тонах. Руководство ограничивалось рыками: «Это так не работает, а как нужно — мы не знаем, решите проблему!»
В результате работа, которая должна была занять два месяца растянулась почти на пол года, бюджет проекта вырос в два раза, а Кеша в конечном итоге уволился из компании и начал свою карьеру в IT.
Банальный, но важный документ
Работа без ТЗ — это путь в ад. По дороге теряются деньги, время, нервы, терпение, умирают проекты и ломаются жизни. Это не только Кешино мнение. Все очень логично — ТЗ — это не просто документ — это инструмент, который решает ряд конкретных задач. Чтобы поменять колесо в машине, вам нужен домкрат, чтобы разработать эффективный IT-проект , вам нужно ТЗ. Зачем? Вот только часть причин:
- ТЗ аккумулирует в себе принятые идеи. Именно этот документ фиксирует решения с которыми согласны все ответственные лица данного проекта. Если вы не хотите ссориться с коллегами как Кеша — ТЗ ваш путь к успеху.
- ТЗ — это библия как для разработчика, так и для заказчика. Оно даёт возможность выяснить, соответствует ли конечный продукт заявленным критериям и узнать кто прав, а кто виноват в неоднозначных ситуациях.
- Давайте не забывать о том, что ТЗ — это юридический документ. Чаще всего оно является приложением к договору на разработку.
Самая главная функция технического задания в том, что оно описывает, как должен выглядеть и работать качественный продукт. Не сложно догадаться, что если в конце концов вы хотите получить именно такой результат — не стоит пренебрегать ТЗ. С вами могут спорить и говорить, что:
- Мы хотим копию продукта конкурентов — зачем нам ТЗ?
- Наш проект — это коммерческая тайна и мы никому о нем не расскажем.
- Мы ещё не знаем, чего хотим в итоге и хотим рассмотреть разные варианты.
Ну или уж совсем перлы вроде «в вдруг у нас/вас поменяется концепция?» или «мы сначала хотим понять сколько наш/ваш проект будет стоить». К сожалению, подобный бред, иногда, можно услышать не только от клиентов, но и от разработчиков, так как качественная оценка проекта — затратная статья для аутсорсинговой компании и разработка подробного ТЗ может не окупиться, если клиент отменит заказ. Заказчик может вообще не заплатить за такую работу, так как в наших реалиях до сих пор принято считать конечным продуктом исключительно готовый сайт или приложение, а ТЗ — это так, каракули.
Что такое техническое задание в IT-разработке
Давайте представим, что техническое задание (ТЗ) в IT — это ваша кулинарная книга для приготовления идеального программного «блюда». Не просто список ингредиентов, а полная рецептура успеха. Только вместо томатов и базилика здесь функционал и интерфейсы.
Что мы варим? ТЗ определяет, что именно должен делать ваш IT-проект. Это как указать, будем ли мы готовить спагетти болоньезе или веганский бургер – детали имеют значение.
Рецепт успеха. В ТЗ описывается каждый шаг разработки, чтобы избежать «пересола». Это ваша дорожная карта от замысла до реализации, где каждый поворот прописан.
Для кого готовим? ТЗ помогает всей команде готовить «на одной кухне». Заказчик уверен, что получит то, что заказывал, а разработчики точно знают, какие «блюда» нужно приготовить.
Инструкция по применению. ТЗ — это не просто план, это инструкция для всех участников проекта. Как в рецепте, где указаны время приготовления и температура, ТЗ регламентирует сроки и технические аспекты.
Путь к мастерству. Создание ТЗ — это не прогулка по супермаркету. Это скрупулезный процесс, включающий обсуждение, анализ и документирование.
Зачем всё это? Без ТЗ легко заблудиться в лесу IT-разработки. Оно помогает избежать недоразумений, сокращает риски, защищает интересы всех сторон и обеспечивает точное планирование.
Вот и всё! Теперь, когда вы знаете, что такое ТЗ, вы готовы создавать IT-проекты, которые будут «вкусными» и удачными. И помните, что хороший рецепт — это половина успеха в приготовлении шедевра.
Функции ТЗ в IT-разработке
Техническое задание в IT-разработке выполняет несколько ключевых функций:
- Уточнение и фиксация требований. ТЗ точно определяет требования к проекту, включая функциональные и нефункциональные аспекты, обеспечивая ясность и понимание целей проекта.
- Коммуникация между участниками проекта. ТЗ служит основой для общения и согласования между всеми заинтересованными сторонами, включая заказчиков, разработчиков и управляющих проектом.
- Планирование и управление проектом. ТЗ помогает в создании плана проекта, определении сроков, ресурсов и этапов разработки.
- Оценка и контроль качества. ТЗ предоставляет критерии, по которым можно оценивать прогресс и качество продукта на разных этапах его разработки.
- Юридическая защита. Как документ, ТЗ может использоваться в юридических целях для защиты прав и обязательств всех сторон, участвующих в проекте.
- Гибкость и адаптация. ТЗ позволяет адекватно реагировать на изменения в проекте, обеспечивая возможность корректировки целей и требований в процессе разработки.
Каждая из этих функций ТЗ в IT-разработке имеет ключевое значение для успеха проекта. Оно обеспечивает четкую ориентацию, предотвращает недопонимания и конфликты, способствует эффективному планированию и управлению, обеспечивает высокое качество разработки и служит защитой интересов всех участников. В итоге, хорошо составленное ТЗ значительно повышает вероятность своевременного и успешного завершения IT-проекта, минимизируя риски и потенциальные затраты.
ТЗ — не просто документ, а критически важный инструмент в арсенале каждой команды разработчиков, гарантирующий четкость, качество и эффективность работы над проектом.
Что главное в техническом задании
«Всё важно, но что-то важнее!» — так можно охарактеризовать главные аспекты в техническом задании. Вот на что стоит обратить особое внимание:
- Если ТЗ написано на языке древних шумеров, никто не поймет, что от него хотят. Ясность и простота формулировок — ваш лучший друг.
- Полное описание функционала. Это как «полный список ингредиентов» для вашего проекта. Не забудьте про «приправы» —- мелкие, но важные детали.
- Согласованность с заказчиком. ТЗ не должно быть односторонним. Это диалог, а не монолог. Убедитесь, что заказчик кивает головой, а не царапает её в недоумении.
- Мир не стоит на месте, и ТЗ тоже. Готовность к изменениям — это не слабость, а знак умения адаптироваться.
- Помните, ТЗ — это не просто план, но и документ. Хорошо, если он защитит вас, если что-то пойдет не так.
- Тестовые сценарии и критерии приемки. Это ваш контрольный список перед «сдачей блюда». Убедитесь, что всё приготовлено правильно.
Так что, когда будете писать ТЗ, помните: оно должно быть четким, полным, согласованным, гибким, защищенным и проверенным. Это как рецепт успеха, только в IT.
Что должно быть в техническом задании в IT-разработке
Подумаем о техническом задании как о рецепте для шеф-повара: что должно быть в этом «кулинарном шедевре»?
- Описание проекта. Первый кусочек — вкусное вступление. Здесь мы говорим о целях и задачах проекта.
- Требования к функционалу. Это как список ингредиентов. Что должно получиться в итоге? Электронная коммерция? Интерактивное приложение? Всё указываем!
- Интерфейс и дизайн. Это о том, как будет выглядеть наш «кулинарный шедевр». Прототипы, макеты, описание пользовательского интерфейса.
- Нефункциональные требования. «Приправы» типа безопасности, скорости работы, совместимости.
- Критерии приема работы. Как мы поймем, что блюдо готово? Тесты, критерии успешности проекта.
- Бюджет и сроки. «Сколько соли?» — вопрос не только о специях, но и о ресурсах и времени.
Подходите к составлению ТЗ творчески, но систематически. И помните, хороший рецепт — это полдела на пути к вкусному IT-проекту!
Что нужно менеджеру, чтобы правильно работать с техническим заданием
Вот несколько советов, которые помогут проектному менеджеру эффективно работать с техническим заданием:
- Изучите основы. Понимание базовых IT-концепций и терминологии упростит взаимодействие с командой разработчиков.
- Общение с разработчиками. Научитесь говорить с разработчиками на их языке, чтобы лучше понимать их нужды и ожидания.
- Анализ требований. Развивайте навыки анализа и оценки требований проекта.
- Внимание к деталям. Особое внимание уделяйте деталям ТЗ, чтобы избежать недоразумений.
- Гибкость и адаптивность. Будьте готовы к изменениям в ТЗ и умейте быстро на них реагировать.
- Юридические аспекты. Понимайте юридическую сторону ТЗ, чтобы защитить интересы вашей компании.
- Управление ресурсами и сроками. Развивайте навыки планирования и управления ресурсами.
Курс TechMind от IAMPM может значительно помочь в этом. Он предоставит вам знания о том, как выбирать архитектуру, фреймворк и команду для проекта, анализировать требования, создавать прототипы продукта, работать с API-документацией и Git, а также понимать процессы в различных типах разработки. Освоение этих навыков облегчит вам взаимодействие с техническими командами и поможет эффективно управлять проектами IT-разработки.
Плюсы работы без ТЗ
Есть ли какие-то плюсы от работы без ТЗ? Только в том случае, если у вас извращённое чувство прекрасного:
- У вас есть свобода принятия решений — за которую потом придётся дорого платить.
- Отсутствием ТЗ можно обосновать повышенную неопределённость и заложить бюджет на всякие «сюрпризы», если конечно вам дадут это сделать, однако после начала работы думать об этом будет уже поздно.
- Формирование и проверка ТЗ требуют вложения времени и сил до начала основной работы. Отсутствие ТЗ позволяет эти усилия перенести на более поздний срок, правда в этом случае часть уже сделанной работы придётся переделывать.
- Вы всегда можете «переиграть» в свою пользу плохо проговорённые моменты. Особенно, если вы мастер скорее слова, чем дела.
Перечисленные «плюсы» — это шутка, сродни вредным советам Григория Остера. Я настойчиво рекомендую не проверять их на себе и своих проектах. Результат может быть плачевным — доказано Иннокентием. Именно поэтому я решил выпустить целый цикл статей про техническое задание и то, как правильно его разрабатывать. Не будь как Кеша — пиши ТЗ!
Заключение
Техническое задание — это не просто формальность, а ключевой инструмент в управлении IT-проектами. Оно помогает всем участникам проекта оставаться на одной волне, минимизирует риски и недопонимания, и является основой для успешной реализации проекта. Изучение основ IT, взаимодействие с разработчиками, внимание к деталям, гибкость и правильное управление ресурсами – вот составляющие успешного управления ТЗ. Курсы, такие как TechMind от IAMPM, могут значительно облегчить этот процесс, предоставляя необходимые знания и навыки для эффективного управления IT-проектами.