[Простые ответы] Что должно быть в техническом задании на разработку сайта?
«Что должно быть в техническом задании на разработку сайта? Толстые документы выглядят солидно и (в теории) прикрывают в случае конфликтов, но клиент их не читает. В коротких можно что-то не учесть и «попасть» на разработке. Что из себя представляет сбалансированное ТЗ? О чём писать нужно, а о чём — нет?»
Дмитрий Боренко
Задайте свой вопрос экспертам!
Мнение редактора проекта «Простые ответы»
Ожидая ответ на ваш вопрос, я ждал ссылок на файлы с техническими заданиями. Видимо, говорить о стандартах веб-разработки рынку ещё рановато.
Главное, что я вынес для себя из ответов экспертов — описывайте в ТЗ то, что прикроет вас даже в Конституционном суде, но чтобы это было описано словами, которые судьи поймут. Разбивайте работу на этапы, чтобы в конце каждого этапа клиент получал и утверждал документ, понятный для него на данном этапе работ. Обучайте клиента, чтобы улучшить взаимопонимание и прояснить ожидания о будущем проекте. Не детализируйте ТЗ сверх меры, а мера зависит от вашего типового клиента.
Ответы (шорт-лист)
Ответы (шорт-лист)
Максим Выдрин
Компания: X-CartДолжность: CEO
При выявлении требований заказчика всегда надо отталкиваться от того, что как бы вы не детализировали изменения, у клиента в любом случае возникнут дополнительные требования. Это нормальный итерационный процесс, который начинается уже на фазе первичной сдачи проекта.
Я рекомендую всегда закладывать запас в оценку на реализацию таких дополнительных требований, и при появлении таковых — реализовывать с указанием на факт бесплатности изменения. Впоследствии, клиент чаще всего адекватно реагирует на то, что очередные «хотелки» могут быть реализованы уже только в случае дополнительной оплаты.
Исходя из этого принципа мы детализируем только бизнес-требования (которые понятны клиенту), а не технические детали. А любые двусмысленности оцениваем на трудозатратность. Если оценка такой двусмысленности малая, то ее уточнение и детализация будет стоить дороже самой реализации. Если же влечет за собой цепочку изменений в логике или архитектуре — то обязательно детализируем.
Алексей Соколов
Компания: UplabДолжность: Ведущий менеджер проектов
Всегда нужно понимать, что техническое задание — это в первую очередь документ, на котором две стороны (Заказчик и Исполнитель) ставят подписи и печати, то есть его содержание подлежит выполнению в полном объёме.
Наша компания использует разработанные шаблоны ТЗ с описанием специальных терминов и перечнем технических нюансов выпускаемого продукта: основные требования к структуре верстки страниц, к системе администрирования (90% наших проектов разрабатываются на CMS 1С Bitrix).
Ключевым разделом ТЗ является описание структуры сайта и его функционала, потому что изменения в данной области могут привести к перерасходам по ресурсам и срокам. Не менее важно описание применяемых при разработке технологий: эффектов вёрстки, к примеру. Т.к. их изменения Заказчик может требовать постоянно, просто выбирая понравившийся.
Для представления полной картины перед финальным утверждением ТЗ с клиентом утверждается динамический прототип сайта, который отображает функционал сайта и совпадает с ТЗ.
Начнём с того, что такое ТЗ. Один считает это общим описанием сайта — цели/задачи, требования, структура, основные возможности, — которое делает обычная веб-студия. Другой полагает, что это требования/видение заказчика.
Я считаю ТЗ результатом проектирования (одним из), который ставит программистам задачу и описывает в идеале: структуру и информационную архитектуру, бизнес-процессы и интеграцию с другими системами, функционал, требования к вёрстке и программированию, эскизы или уже готовый дизайн, требования к управлению. Естественно, состав зависит от проекта.
Бывает, что программисты получают вводные и пишут ТЗ сами, но тут есть проблема: пишут они на своём языке, не для клиента, который в результате ничего не понимает и Будда знает что подписывает. А дальше вы понимаете…
Таким образом, дело не в толщине документа, а в глубине проработки и понятности. Бизнес-процесс можно расписать на две страницы корявым языком с кучей терминов, а можно простой наглядной схемой, «по-человечески».
Константин Доценко
Компания: TRINET.DevelopmentДолжность: Генеральный директор
Дмитрий, по нашему мнению, в техническом задании нужно писать обо всем, даже если клиент не осиливает весь документ. Важно не изливать поток мыслей, а структурировать материал для упрощения понимания. В нашей практике ТЗ делится на несколько частей:
Прототип проекта. Поскольку это визуальные картинки, связанные между собой, клиенту достаточно просмотреть их и понять, что именно ему предлагается. Описание функционала. Дается человеческим и доступным заказчику языком. Как правило, он эту часть вполне осиливает :) Описание требований к дизайну, верстке, хостингу и тп. Если у клиента есть четкие пожелания (чтобы была адаптивная верстка, чтобы работало в старых браузерах, чтобы была мобильная версия), он дает комментарии. Описание структуры данных. Да, эту часть редко кто-то читает :) Она тяжела для понимания, но важна в случае конфликтов. Зачастую, у крупных клиентов есть своя IT-служба, либо консультант, которые могут дать более детальное заключение по предоставленному ТЗ.
Задать свой вопрос
все вопросы
подписаться на уведомления о новых материалах
Полный текст статьи читайте на CMS Magazine
