Как согласовать ТЗ на разработку сайта и не поседеть
Техническое задание (ТЗ) – это некий симбиоз ожиданий заказчика и возможностей исполнителя, который позволяет получить качественный и полезный продукт на выходе. Что может быть проще! Однако любой, кто хоть раз сталкивался с разработкой сайта, ощутил на себе всю боль каждого из этапов упаковки и согласования всех нюансов технического задания. Как организовать процесс формирования ТЗ, чтобы узнать, чего хочет заказчик/что будет делать исполнитель и желательно не потратить на это уйму времени? Рассмотрим два наиболее популярных сценария работы и поделимся нашим практическим опытом.
Сценарий №1
Большинство веб-студий просят клиентов предоставить ТЗ для всего сайта сразу, с учетом всех «подводных камней» и нюансов конкретного бизнеса. Если, получив такой документ, исполнитель не задаёт лишних вопросов, сразу называет сумму и конкретные сроки, на первый взгляд, он может показаться идеальным вариантом, и первое, что хочется сделать, – заключить сделку и скинуть эту «гору» с плеч. В итоге при сдаче проекта заказчик с ужасом понимает, что проект по какой-то неведомой причине не соответствует заявленному ТЗ. И на выходе исполнитель получает море негатива, а клиент – выброшенные деньги и время на ветер и необходимость начинать всё заново. Почему так происходит? Всё дело в трактовке ТЗ. В сфере web-разработки есть своя терминология, свои понятия и стандарты, которые зачастую отличаются от представлений клиента. Получается, что заказчик пишет на своем языке, а исполнитель читает на своём. В результате такого сломанного телефона и получается продукт, отличный от того, что планировал получить клиент.
Сценарий №2
Разберем другую ситуацию – вы подготовили ТЗ, а исполнитель забрасывает вас вопросами, просит уточнить формулировку или трактовать описание как-то иначе.
Схема работы выглядеть примерно так:
- Вы пишете ТЗ;
- Передаете исполнителю;
- Он задаёт вопросы, вносит правки и предложения;
- Вы вносите правки в ТЗ;
- Согласуете правки внутри своей компании;
- Опять несете ТЗ исполнителю.
Казалось бы, это – верный вариант. И опять промах. Цикл может повторяться неоднократно. Сам процесс может длиться годами, и в вашем ТЗ появятся пункты типа «Нельзя сушить кота в микроволновке». Почему? Все просто – что одним людям кажется очевидным, другим – совершенно непонятно.
И вот, настал тот момент – вы готовы ко всему, ваше ТЗ безупречно, хоть в нем страниц и больше, чем во всех томах «Войны и мира». И, вроде бы, пора стартовать разработку! Но выясняется, что пока вы так усердно «вылизывали» это ТЗ, ваши конкуренты уже колонизировали Марс, а весь функционал в ТЗ устарел.
Поэтому мы на основе многолетнего опыта отказались работать по схеме – «что было в ТЗ, то и получили». Мы всегда стараемся придерживаться золотой середины:
- Отказ от общего ТЗ на весь проект
Всеобъемлющее ТЗ на разработку всего сайта мы никогда не запрашиваем. - Запрос ТЗ на отдельные нестандартные задачи
Иногда возникает потребность в отдельном ТЗ, например, для разработки дизайн-макетов или для какого-то конкретного функционала. Этот документ не требует детального описания задачи, но в нем прописываются основные нюансы и нестандартные вещи. - Обсуждение стандартных задач в устном формате
Когда речь идет о более стандартных вещах или незначительных отклонениях от стандарта, мы проговариваем всё устно и фиксируем договоренности в протоколе, который заказчик подтверждает со своей стороны. - Разработка прототипов для уникального функционала
При разработке уникального функционала для сайта, мы – на основе запрошенного у клиента ТЗ – готовим прототипы для всех страниц, связанных с этим функционалом. Прототип – это некая гарантия того, что обе стороны друг друга поняли. Помимо этого, в ходе создания могут возникнуть новые идеи, которые можно сразу отразить в прототипе.
Современный онлайн-рынок не терпит промедлений. Нужно действовать быстро и эффективно во всем. Поэтому не теряйте драгоценное время. Конкуренты не дремлют!
