Почему так важно составить ТЗ перед созданием сайта

Назад
04
Окт 2019

 

За последний год мы в Webcase отдали заказчикам 80 простых и сложных проектов, из них 5 были без ТЗ. И это были самые долгие, самые вымученные проекты, вне зависимости от функционала. Каждый из этих проектов вылился в 30-40 дополнительных рабочих часов для наших разработчиков, 15-20% сверх оговоренной стоимости для клиента, и 1000+ седых волос для наших проджект-менеджеров. 

Теперь мы руководствуемся законом Мерфи: “Если вас могут понять неправильно, вас обязательно поймут неправильно”, и работаем только по ТЗ. В этой статье мы рассказываем, почему это так важно, и почему без ТЗ результат точно ХЗ.

 

Что такое ТЗ и зачем оно нужно

Техническое задание на разработку  — это согласованный заказчиком и исполнителем документ, который полностью описывает все требования к будущему сайту, порталу, сервису, CRM- или ERP-системе. Чем четче указаны все требования и пожелания, тем лучше обе стороны друг друга понимают, и тем выше шанс, что они останутся довольны результатом. Согласованное ТЗ дает больше вероятности, что заказчик получит то, что ожидал, а команда исполнителей не будет за день до дедлайна переделывать половину функционала, обложившись чашками кофе.

 

 

Польза наличия ТЗ на разработку сайта для клиента:

  • Понять, за что он платит деньги, какой сайт получит в итоге. Еще до начала разработки можно увидеть структуру, понять, как элементы будут взаимосвязаны между собой. И если что-то не устраивает, изменения можно внести в ТЗ до начала разработки.
  • Убедиться в том, что исполнитель имеет нужный опыт и навыки. Техзадание пишет проджект-менеджер или тимлид, и если оно понятное и четкое – значит команда точно знает, как выполнить проект. Если там каша из терминов и непонятных набросков, значит нужно бежать от таких исполнителей без оглядки. 
  • Сверить готовую работу с ТЗ. Если в переданном сайте есть очевидные несоответствия документу, разработчики обязаны переделать их бесплатно, а если они отказываются, техзадание – основание для обращения в суд.
  • Узнать более-менее реальную стоимость разработки сложного функционала. Невозможно посчитать, сколько будет стоить сайт или приложение со сложной архитектурой, пока не разложить его на элементы и функции. Именно для этого и составляется техническое задание.

Зачем ТЗ исполнителю:

  • Точно понять, что хочет увидеть заказчик. Перед составлением ТЗ на разработку сайта наш проджект-менеджер задает клиенту множество вопросов, показывает готовые примеры, предлагает решения. Каждый выбор, описание каждой функции и элемента записывают в единый документ, который и превращается в ТЗ. Если оно проходит согласование у клиента – значит мы поняли его правильно. 
  • Застраховаться от внезапных изменений. За несколько лет работы мы сталкивались с ситуациями, когда клиент посередине процесса разработки хотел изменить задачу, и как правило все начиналось с “а можно добавить еще одну маленькую фичу”, а заканчивалось на “а давайте из лендинга сделаем второй Amazon”. Именно в таких случаях очень выручает ТЗ, ведь все работы производятся только в соответствии с ним. 
  • Доказать экспертность. Грамотно составленное ТЗ может переубедить даже сильно сомневающегося заказчика. Часто именно на этапе составления ТЗ наши потенциальные клиенты превращались в действительных – когда заплатили отдельно за составление ТЗ и увидели, что мы полностью понимаем их потребности.
  • Упростить и ускорить работу над проектом. Вся команда, которая работает над сайтом или приложением, опирается на ТЗ, как на Библию. В хорошо составленном ТЗ тщательно описана структура, все элементы и функции на каждой странице. Остается только писать код и придумывать дизайн, а не вести бесконечные переговоры с клиентом через проджекта или аккаунта.

 

От теории к практике: как составить ТЗ на разработку сайта

“Разработать сайт про котиков” – это уже техзадание. Но оно максимально нечеткое и явно приведет к путанице. На основе этого ТЗ разработчик может сделать одностраничник для питомника, а клиент хотел большой и красивый информационный портал про породы котов, с блогом, форумом и сложными эффектами на каждой странице. 

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

  • Базовая информация о проекте и целевой аудитории, цели и задачи.
  • Глоссарий терминов, с которыми клиент может быть не знаком.
  • Подробные технические требования к функционалу и верстке.
  • Стек используемых технологий для осуществления проекта и перечень требований к хостингу.
  • Четкая структура сайта, со всеми подстраницами и взаимосвязями:
  • Разработка непосредственно структуры;
  • Выделение “ролей” пользователей в системе и определение их прав доступов;
  • Описание функциональных возможностей проекта;
  • Перечень системных сообщений и события, при которых они отправляются;
  • Список возможностей администратора.
  • Описания всех страниц и элементов на них.
  • Сценарии взаимодействия с нестандартным интерфейсом (опционально).
  • Оговоренный список контента, который заносит на сайт разработчик.
  • Требования к дизайну (опционально)

 

Кто и как составляет ТЗ

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

  • Каждая задача, описанная в ТЗ, должна быть граничной – то есть, должно быть понятно, где закончился конкретный пункт и начался следующий. В документе нет места абстрактным фразам типа “продумать удобную навигацию”. Это очень субъективно – кому-то будет удобно, кому-то совсем неудобно, но определить, выполнен ли этот пункт в соответствии с ТЗ, невозможно. 
  • Если мы разрабатываем несложный сайт, и для ТЗ описываем какой-то функциональный модуль, мы анализируем сайты с похожим функционалом или поднимаем уже выполненные подобные проекты. Прикладываем ссылки на страницы с нужным интерфейсом и функциями, даем описание в ТЗ, что именно будем делать и как видоизменим данный пример.

 

 

Что это стоит для клиента: реальные цифры

Мы в Webcase занимаемся двумя направлениями в разработке: создаем относительно простые вебсайты, и занимаемся сложными, высоконагруженными системами, крупными порталами, CRM-системами и SaaS-решениями. В зависимости от типа проекта меняется и ТЗ, его объем и сроки написания, хотя в целом, структура остается прежней. 

  • Простые корпоративные сайты и лендинги

В этом случае написание ТЗ занимает у нас 2-4 часа, так как основные блоки и функционал повторяются из проекта в проект, с небольшими изменениями – и каждый нюанс мы тщательно описываем в техзадании. Обычно объем такого ТЗ – несколько страниц.

  • Сложные, крупные проекты

Для высоконагруженных сайтов и сложных систем с множеством взаимосвязей создание технического задания занимает около 5 полноценных рабочих дней – то есть, около 40 часов рабочего времени. Объем такого ТЗ может быть 80-100 страниц и более, так как здесь очень подробно продумывается и описывается структура, весь функционал, логика проекта и т.п. Кроме того, крупные проекты делятся на итерации – и под каждую итерацию готовится отдельное ТЗ, так как один функционал тянет за собой появление другого в следующей итерации, и т.д.

Сколько стоит составление ТЗ –  в любом случае зависит от количества человеко-часов, потраченных на его обдумывание и написание, но поверьте – это точно не тот этап, на котором можно сэкономить и закончить побыстрее. 

В нашей практике бывали ситуации, когда заказчик приходил со своим ТЗ – но обычно это был просто перечень “хотелок”, без деталей и точного описания функционала сайта. В этом случае мы все равно дописываем документ, чтобы быть с клиентом на одной волне, так как одна и та же фраза может трактоваться клиентом, проджект-менеджером и разработчиком абсолютно по-разному.

 

 

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

 

А что, если все-таки без ТЗ?

Работа без ТЗ – это кровь, пот и слезы каждого участника процесса. Отсутствие технического задания или не достаточно четкий документ — это выход за рамки дедлайна, долгие дискуссии с заказчиком и много, много нервов. Когда все написано и проработано, это минимизирует возможность овертаймов и недопониманий – хотя по опыту, учесть абсолютно все невозможно, все равно по ходу проекта появляются мелкие замечания и доработки.

 

 

Слова красивые, а ситуация страшная. Приведем пример работы без ТЗ, из нашей практики. 

Мы разрабатывали CRM-систему для небольшой компании, где клиентов около 5000, работников всего 4. Нам нужно было оптимизировать работу сотрудников так, чтобы формирование клиентов и обработка их заявок происходила в пару кликов, а в конце дня/месяца/года формировались отчеты по количествам продаж. Клиент, далекий от сферы IT, вкратце рассказал о своих пожеланиях, сказал, что никакие документы ему не нужны, ведь мы «и так хорошо понимаем друг друга». Однако за неделю до сдачи проекта нам пришлось переделать практически всю архитектуру проекта из-за “небольших нюансов”, которые были очевидны заказчику, но он их не озвучил, так как подумал, что мы поняли, что имеется в виду. Это вылилось в 50 часов дополнительной разработки, которые не были заложены в смету. Клиент переплатил 15% от изначально оговоренной стоимости, потому что предпочел сэкономить на подготовительном этапе и подготовке ТЗ. 

 

 

При внесении одного изменения, казалось бы мелкого, на пару часов, после тратится около 20 часов на тестирование и столько же на фикс багов — и вот уже 2 часа превращаются в 40. Нужно понимать, что проект — это целостный организм, и при изменении одного значения, нужно проверять и переделывать работу десятков других. Все эти этапы сильно упростятся, если первым делом написать ТЗ, и только потом браться за разработку. 

 

 

В поисках идеального ТЗ

Клиенту совершенно не обязательно проводить подготовительную работу и гуглить, как правильно написать ТЗ для разработчика, скачивать шаблоны и т.п. Это наша работа, и мы настаиваем на создании технического задания для любого проекта, даже если там работы “на пару часов”. 

На практике идеального ТЗ не бывает, все равно возникают доработки и нюансы, которые не были учтены. Но наличие грамотного ТЗ дает возможность уменьшить количество таких недоработок, что значит –  сохранить ваши средства, а это 15-20% от эстимейта и во временном, и в денежном выражении. 

Грамотное и полное ТЗ — первая ступенька к успешному проекту. Это фундамент, на котором все держится. Если вы хотите, чтобы ваш проект был выполнен в срок, не опускайте этап подготовки ТЗ – наоборот, закажите его у надежных специалистов, и получите точную оценку и готовый, полный документ, на который можно опереться.

 

Техническое задание экономит стоимость разработки!

Все стартапы начинаются с ТЗ

Подробнее

Спасибо за ваш интерес!

Мы с вами свяжемся в ближайшее время