Как составить техническое задание, если вы не технарь

Часть 3 из 4 · Серия «Разработка без сюрпризов»

Слово «техническое» в названии сбивает с толку. Кажется, что от заказчика ждут технических решений: какая платформа, какая база, как реализовать фильтр. И человек либо честно признаётся, что не знает, либо — что хуже — идёт читать статьи и приносит требования, значения которых сам не понимает.

На самом деле от вас нужно противоположное. Заказчик приносит задачу, исполнитель приносит решение. Если вы приносите решение, вы берёте на себя ответственность за его правильность, не имея для этого ни данных, ни опыта. А отвечать за результат всё равно придётся подрядчику — и вот здесь начинаются споры.

Разберём, что писать вместо технических требований.

Зачем ТЗ нужно вам, а не подрядчику

Распространённое заблуждение — что ТЗ пишут для исполнителя. Пользы вам от него больше, и вот почему.

Оно обнаруживает расхождения до того, как за них заплатили. Вы говорите «личный кабинет», подрядчик слышит «страница с историей заказов», а вы имели в виду согласование индивидуальных цен и отгрузку по договору. Оба уверены, что поняли друг друга. Выясняется это на демонстрации, когда работа уже сделана.

Оно позволяет сравнить предложения. В первой части разбирали, почему две сметы различаются втрое. Одинаковое описание задачи, отданное трём подрядчикам, — единственный способ сравнить ответы честно.

Оно защищает от бесконечных «а ещё бы хотелось». Причём обе стороны: заказчика — от «это не входило в объём», подрядчика — от бесплатного расширения работы.

Описывайте процесс, а не решения

Простое правило: если в формулировке есть название технологии — скорее всего, это не ваша часть работы.

Правая колонка полезнее для оценки, чем левая: из неё исполнитель поймёт задачу и предложит решение, о котором вы могли не знать. Из левой он поймёт только то, что вы уже всё решили.

Что описать обязательно

Шесть блоков. Если закроете их, у вас уже будет ТЗ лучше, чем у большинства.

Кто покупает. Розница, опт, юрлица — если сегментов несколько, они почти наверняка ведут себя по-разному и требуют разной логики.

Как принимают решение. Что человек знает, когда приходит: точное название товара, задачу («нужно закрыть стену»), марку оборудования. От этого зависит вся навигация по каталогу.

Что происходит после заказа. Весь путь: куда падает заявка, кто её видит, кто подтверждает наличие, кто выставляет счёт, кто передаёт в доставку. Это самая ценная часть описания и почти всегда самая недооценённая.

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

Откуда берутся товары и цены. Заводятся руками, приходят от поставщиков, выгружаются из учётной системы. Как часто меняются.

Какие системы уже есть. 1С, CRM, касса, служба доставки, склад. Даже если интеграция не планируется сейчас — назовите их. Это влияет на то, как проектируют систему.

Формулировки, из-за которых возникают споры

Все они объединены одним: их нельзя проверить.

• «Удобно», «красиво», «современно» — у вас и у подрядчика разные представления, и выяснится это при приёмке.
• «Интуитивно понятно» — то же самое.
• «Как у конкурента» — вы не знаете, что у него внутри, сколько это стоило и работает ли оно на самом деле. Ссылаться на чужой сайт можно, но конкретно: «нравится, что размер подбирается по таблице, а не вводится вручную».
• «Быстро работает» — без числа это не требование.
• «И всё остальное как обычно» — самая дорогая фраза в списке.

Заменяйте на проверяемое:

было:  админка должна быть удобной
стало: менеджер меняет цену и остаток без обращения к разработчику

было:  оформление заказа должно быть простым
стало: покупатель оформляет заказ не более чем за три шага,
       регистрация не обязательна

Проверяемая формулировка — та, про которую можно сказать «да» или «нет», глядя на готовый результат.

Каталог и заказ: что нужно указать для оценки

Эти два блока сильнее всего влияют на трудоёмкость, поэтому их стоит описать подробнее остальных.

По каталогу:

• сколько позиций сейчас и сколько ожидается через год;
• сколько уровней категорий;
• есть ли варианты одного товара — цвет, размер, объём — и отличаются ли они ценой и остатком;
• сколько характеристик и по каким нужны фильтры;
• откуда приходят данные и как часто обновляются.

По заказу:

• как платят: карта, счёт, наличные при получении, рассрочка;
• как доставляют: свои курьеры, службы, самовывоз, транспортные компании;
• нужны ли документы — счёт, УПД, акт;
• куда попадает заказ после оформления.

Это ровно те сведения, из-за отсутствия которых смета превращается в «от и до».

Что можно не описывать

Спокойно оставьте исполнителю:

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

Если подрядчик просит вас определиться с технологией — это повод задать встречный вопрос, а не идти читать сравнения фреймворков.

«Можно начать без ТЗ» — и чем это отличается от «ТЗ не нужно»

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

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

Если подрядчик говорит, что документ вообще не нужен, — это красный флаг из предыдущей части, а не гибкость.

Структура, которую можно заполнить самому

Восемь пунктов. Пишите прозой, без терминов — этого достаточно, чтобы получить осмысленную оценку.

1. Что за бизнес и что продаём. Пара абзацев.
2. Кто покупатели. Сегменты и чем отличаются.
3. Что не устраивает сейчас. Конкретные ситуации, а не «сайт устарел».
4. Каталог. Объём, структура, варианты, откуда данные.
5. Заказ и оплата. Как платят, как доставляют, какие документы.
6. Кто работает с сайтом. Роли и что каждый делает сам.
7. Существующие системы. Что уже используется в компании.
8. Что считаем успехом. По каким признакам поймём, что получилось.

Последний пункт пропускают чаще всего, а он самый полезный: он переводит разговор с «сделайте красиво» на «менеджер перестал вбивать заказы вручную».

Частые вопросы

Обязательно ли ТЗ, если проект небольшой?

Формальный документ — нет. Но письменное описание задачи нужно всегда, хотя бы на страницу. Устные договорённости забываются одинаково у обеих сторон.

Кто должен писать ТЗ — заказчик или подрядчик?

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

Что делать, если сам не знаешь, чего хочешь?

Описывать не желаемое, а текущее: как сейчас устроен процесс и что в нём раздражает. Из этого получается ТЗ лучше, чем из фантазий о функциях.

Можно ли менять требования по ходу работы?

Можно и почти всегда приходится. Важно, чтобы в договоре был описан порядок: как оценивается изменение и как оно влияет на сроки и цену.

Нужно ли описывать дизайн?

Требования бренда — да. Всё остальное лучше обсуждать на прототипах: описывать словами внешний вид — занятие неблагодарное.

Что дальше

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

Можно начать и без готового ТЗ — покажите текущий сайт, и план работ соберём вместе: siteko.net/development.