Разработка технического задания

Подробно

Составление технического задания в Кодовой студии начинается с интервью: выясняем, какую задачу решает продукт, кто им будет пользоваться и по каким признакам заказчик поймет, что проект удался. Потом переводим ответы в документ, по которому дизайнер рисует экраны, разработчик оценивает часы, а тестировщик пишет проверки. Делаем ТЗ на сайты, мобильные приложения, личные кабинеты и внутренние системы компаний. Документ остается у вас: с ним можно идти к нам в разработку или к любому другому подрядчику.

ТЗ для сайта

Техническое задание работает как договоренность между заказчиком и исполнителем. Документ фиксирует, что должно получиться на выходе: какие страницы и функции есть в продукте, как они себя ведут, с какими сервисами связаны и какие технические требования к ним предъявляются. О структуре документа и его юридическом статусе мы подробно писали в статье что такое ТЗ.

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

Без технического задания проект обычно идет по одному сценарию. На старте все договорились устно, в середине выяснилось, что каждый представлял готовый продукт по-своему, а в конце начинаются доработки за отдельные деньги. Разработка технического задания обходится дешевле, чем переделка готовых экранов и кода.

Кто пишет ТЗ? Чаще всего исполнитель: аналитик студии вместе с менеджером проекта и техническим лидом. Заказчик дает вводные, отвечает на вопросы и согласует итоговый документ. Поставить задачу "сделайте нам сайт" может любой, а превратить ее в список проверяемых требований без опыта в разработке трудно.

Бриф на разработку сайта

Бриф и ТЗ часто путают. Бриф (короткая анкета заказчика) собирает исходные данные: информация о компании, цели проекта, целевая аудитория, примеры сайтов, которые нравятся и не нравятся, бюджет и желаемый срок запуска. Его заполняет заказчик сам или вместе с менеджером проекта на созвоне.

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

В брифе мы просим указать:

• чем занимается компания и что продает;
• кто покупатели и откуда они приходят;
• какое действие посетитель должен сделать на сайте: оставить заявку, оплатить заказ, записаться;
• какие системы уже работают: CRM, 1С, склад, телефония;
• что пробовали раньше и почему не подошло.

Для приложения вопросы брифа смещаются к поведению пользователя. Если взять наш демо-проект Капиталика, финансовое приложение, то в брифе важно понять, откуда берутся данные о деньгах пользователя, нужна ли связь с банком, как часто человек открывает приложение и что должен увидеть на первом экране. От этих ответов зависит заметная часть будущих требований.

ТЗ на разработку сайта

Состав документа зависит от проекта, но основа одна. Когда мы составляем техническое задание на сайт или веб-сервис, в него входят разделы:

1. Цели и задачи проекта, целевая аудитория, ключевые сценарии.
2. Структура: список страниц и разделов, карта сайта.
3. Функциональные требования: что делает каждая страница и каждая роль пользователя (гость, клиент, администратор).
4. Пользовательские сценарии: пошаговое описание пути от входа до целевого действия.
5. Требования к дизайну и адаптивности: на каких экранах сайт должен корректно выглядеть.
6. Интеграции: платежи, CRM, 1С, службы доставки, аналитика.
7. Нефункциональные требования: скорость загрузки, нагрузка, безопасность, резервные копии.
8. Технические характеристики: стек, хостинг, требования к серверу, браузеры.
9. Критерии приемки: по каким проверкам заказчик принимает работу.

Последний пункт часто пропускают, а зря. Требования заказчика, записанные как проверяемые условия ("форма отправляет заявку в CRM, менеджер получает уведомление"), снимают большинство споров на сдаче проекта.

Для мобильного приложения добавляем разделы, которых нет в задании на сайт: поддерживаемые версии iOS и Android, работа без сети, push-уведомления, правила магазинов приложений, доступ к камере и геолокации. Если приложение и сайт работают с одной базой, описываем общий бэкенд один раз и ссылаемся на него из обоих документов.

Пример технического задания на разработку сайта

Возьмем интернет-магазин фермерских продуктов, похожий на наш демо-проект Грядка. Плохая формулировка в ТЗ звучит так: "удобный каталог с фильтрами". Ее нельзя проверить, и каждая сторона поймет ее по-своему.

Та же задача в нашем техническом задании выглядит иначе:

• каталог разбит на категории двух уровней, в карточке товара фото, цена за килограмм или штуку, остаток на складе;
• фильтры: категория, ферма-производитель, цена от и до, наличие; фильтры сочетаются между собой;
• при нулевом остатке кнопка "В корзину" меняется на "Сообщить о поступлении";
• остатки и цены приходят из 1С по расписанию, частоту обмена согласуем с заказчиком.

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

Как написать техзадание на разработку сайта?

Если вы пишете ТЗ сами, держитесь такого порядка:

1. Четко сформулировать цель: какое действие посетителя приносит деньги или экономит время.
2. Описать аудиторию и ее главные сценарии, по одному абзацу на сценарий.
3. Составить структуру страниц и набросать схемы ключевых экранов, хотя бы от руки.
4. Перечислить интеграции и данные, которые сайт получает и отдает.
5. Для каждой функции записать, как проверить, что она работает.
6. Отдать документ нескольким подрядчикам и собрать вопросы: места, где вопросов больше всего, нужно дописать.

Типичные ошибки самостоятельных ТЗ: оценочные слова вместо условий ("быстрый", "современный", "удобный"), описание дизайна вместо логики, забытые роли (кто модерирует отзывы, кто меняет цены), отсутствие требований к админке. Каждую такую дыру исполнитель закроет по своему усмотрению, и результат может не совпасть с ожиданиями.

Правильно составить ТЗ без опыта сложно, и это нормально. Заказчик хорошо знает свой бизнес, но не обязан знать, как описать права доступа или обмен с 1С. Поэтому мы часто работаем в паре: вы даете знание предметной области, мы переводим его в требования проекта.

Разработка технических заданий на автоматизацию бизнес-процессов

Отдельный класс задач появляется, когда речь идет об автоматизированной системе для сотрудников: CRM под свой процесс продаж, учет заявок на складе, кабинет для дилеров, мобильное приложение для курьеров, как в нашем демо-проекте Трассер. Здесь ТЗ опирается на описание процессов "как есть" и "как будет".

Порядок работы такой:

• интервью с владельцами процессов и рядовыми сотрудниками, которые будут работать в системе;
• схемы процессов в нотации BPMN (стандартный способ рисовать бизнес-процессы блоками и связями);
• роли и права доступа: кто что видит и что может менять;
• модель данных: сущности, поля, связи;
• описание интеграций и API (программный интерфейс, через который системы обмениваются данными);
• прототип ключевых экранов, чтобы сотрудники увидели систему до разработки.

Техническое задание на разработку программного обеспечения для госзаказчика или крупной компании иногда требуют оформить по ГОСТ 34.602 (стандарт на ТЗ для автоматизированных систем). Оформляем по нему, если это условие договора. Для коммерческих проектов обычно хватает более легкой структуры.

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

Техническое задание на услуги

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

Мы готовим такие документы для заказчиков, которым нужно выбрать исполнителя по конкурсу. Разница с обычным ТЗ в формулировках: требования должны быть измеримыми и не привязанными к одному поставщику, иначе закупку оспорят. Технические характеристики описываем через результат ("страница открывается на смартфоне без горизонтальной прокрутки"), без названий конкретных продуктов.

Сколько стоит ТЗ на сайт?

Цену называем после брифа. Она зависит от числа ролей и сценариев, количества интеграций и от того, нужен ли прототип. ТЗ на сайт-визитку с формой заявки и ТЗ на маркетплейс с кабинетами продавцов несравнимы по объему.

Для ориентира по доле в бюджете: аналитика и ТЗ занимают 10-15 процентов стоимости разработки мобильного приложения. Эти деньги работают на следующих этапах: дизайнер не рисует лишних экранов, разработчики не переделывают логику после сдачи. Чтобы получить оценку, опишите задачу в заявке, менеджер проекта уточнит детали и пришлет состав работ.

Снизить стоимость можно подготовкой. Соберите заранее доступы к текущим системам, выгрузки данных, примеры документов, с которыми работают сотрудники, и список людей для интервью. Чем меньше времени уходит на поиск исходных данных, тем больше его остается на сами требования.