Читайте лонгрид про подготовку технического задания: как написать его правильно, какие бывают ошибки, как их избежать?
В разработке качественного ТЗ заинтересованы и заказчик, и исполнитель. Корректное техническое задание поможет избавить друг друга от лишней головной боли и точно определить, что и как должно быть сделано в проекте. Узнаём у экспертов, какие ошибки допускают при составлении техзадания и как сделать так, чтобы оно было понятно всем сторонам.
Прежде всего надо определиться с отношением к техническому заданию как таковому. Либо это «священная корова», документ, в рамках которого действует исполнитель и сверяется результат его работы, либо это общее видение проекта, задающее его рамки.
В первом случае ТЗ — больше юридический документ, который должен быть подписан, прикреплен к договору, и при любых спорах именно он будет иметь приоритетное значение. Причем любые изменения в ТЗ должны быть также зафиксированы документально с подписью и печатью — иначе вы ни о чем не договаривались и не важно, сколько времени потратили на работу.
Этот формальный подход вынуждает разработчика быть очень внимательным к ТЗ при чтении и оценке проекта, а заказчика — подключать технического специалиста, консультанта или аналитика для написания этого документа. Важно то, что человек от бизнеса, сисадмин, менеджер или интернет-маркетолог не напишет ТЗ на разработку сайта в таком формализованном виде, потому что оно должно содержать технические детали реализации.
Речь не идет о конкретных архитектурных решениях — как именно мы будем хранить данные. В ТЗ должны быть отражены вопросы такого плана: удаление или архивирование сущностей (пользователей, данных), логирование, статистика, администрирование контента и фильтры, сортировки по этому контенту в административном разделе. Использование коробочных систем, например 1С-Битрикс, много таких вопросов снимает. Но при кастомной разработке ничто не может «подразумеваться по умолчанию». Для разработчика не существует того, что не описано в ТЗ и договоре. Хорошо, если при вышеупомянутой оценке разработчик обратил внимание на отсутствие ряда функциональностей и в смету включил. Но на этапе тендера такие правильные детали могут сделать коммерческое предложение неконкурентным, а представитель заказчика, проводящий тендер, не всегда готов улавливать такие тонкости – у него иные критерии на этапе выбора подрядчика: цена, опыт в схожих проектах и тематике. А внимательность и техническая компетенция при оценке проекта будут далеко не первым критерием при оценке.
Получается палка о двух концах. Либо мы профессионалы и еще на этапе оценки помогаем заказчику с ТЗ, либо мы выбираем другой подход – с рамками и рисками.
В этом случае нам ТЗ важно для определения ожиданий со стороны бизнеса. Мы доносим до заказчика, что его ТЗ не техническое, а функциональное. Важно то, что оно определяет и что нужно получить на выходе, а не как это должно быть сделано. Как проект будет сделан, определится и на этапе проектирования и дизайна (которого в этот момент нет), и на этапе архитектурного проектирования и консультирования в начале разработки. А сейчас, на старте проекта, мы оцениваем функциональность в привязке к выбранной технологической платформе и в зависимости от сложности проекта закладываем вот такой люфт бюджета на риски. Этот задел позволит нам гибко реагировать на пожелания заказчика и отвязаться от ТЗ как от той самой «священной коровы».
Есть и третий вариант: когда ТЗ пишет исполнитель уже после подписания договора, в рамках обозначенной работы за фиксированную сумму, а после написания уже делает смету на проект. С этим ТЗ заказчик может уйти и в другую компанию. Но на практике крайне редко на такое соглашается заказчик – риск смены подрядчика никому не нравится и создается ощущение, что написание ТЗ слишком отложит старт проекта, на который уже есть четкие требования по срокам, обусловленные бизнесом либо финансовой отчетностью за выделенный на проект бюджет.
Примеры ошибок в ТЗ из нашей практики:
- Не учтено логирование при большом количестве контент-менеджеров: невозможно найти, кто внес то или иное изменение. Здесь же обратный случай: не продуманы группы пользователей и их права, со стороны клиента все ходят в админку под одним логином администратора (и люди, отвечающие за добавление новостей, и seo-специалисты, и бухгалтеры).
- Не продумано удаление и архивирование элементов и разделов: если на элементы завязана какая-то статистика или заказы и это где-то демонстрируется, надо продумать, оставляем ли мы архив и как мы решаем, что показывается. Это важно и для поискового индекса.
- Не описан механизм нетиповой интеграции с 1С (endpoint, принципы, пр.) – согласование и выстраивание этой интеграции потребует плотных коммуникаций разработчиков и 1с-специалистов, времени и плотного контроля заказчика.
- Нет выгрузки товарного каталога и описания хранимых данных в 1С по товарам – все они в итоге отдают одно свойство «характеристики», а в ТЗ предусмотрена фильтрация.
- Не описана созависимость фильтров.
- Упущены сортировки как таковые.
- Административный раздел не описан полностью.
- В административном разделе не описаны фильтры по заказам по дате, номеру, телефону, вообще какие-либо фильтры, которые будут необходимы администратору.
- Управление мета-тегами забывают всегда: про то, откуда у страницы берется title – нигде не зафиксировано. Здесь же можно отметить весь пул SEO чек-листа (ЧПУ, 404, хлебные крошки, robots, коды счетчиков, редиректы и т.п.).
- Не прописаны обязательные по законодательству ссылки в футере (например, СОУТ или «Политика конфиденциальности»).
- Не описаны почтовые уведомления, которые вообще должны быть (о заказе, регистрации, отправленной форме и т.д.).
- Не описано управление промо-баннерами. Описано все, но про сквозные картинки в дизайне и про слайдер – забыли.
- Не продумана и, соответственно, не описана работа с заказами, оплатой и доставкой. Какие будут возможности оплатить заказ? Будет ли работа с юридическими лицами, можно ли им дать возможность сразу выставлять счет или работаем только через менеджера? Какие службы доставки используются, какие данные по заказу и товару нужны для расчета стоимости и сроков доставки? Какие статусы заказов, на каких этапах происходит оповещение пользователя о смене статуса и по каким каналам?
- Клиент при написании ТЗ не продумал структуру контента, не определил разделы и подразделы. Необходимость вложенного меню с подуровнями может выясниться уже после завершения программирования при внесении контента.
Пишите и читайте ТЗ внимательно. Помните: любые неоплачиваемые доработки проекта вне ТЗ и договора съедают вашу маржинальность.