Техническое задание для программиста: шаблон из 12 вопросов, после которого цена не меняется

«Нужна система, где клиенты могли бы заказывать, а мы видели заказы» — такое описание мы получаем часто. Оно честное, но по нему можно сделать и за 500 €, и за 15 000 €. Техническое задание — это не документ для программиста, а способ вам самим понять, что вы покупаете. Ниже — двенадцать вопросов, которые превращают описание из трёх предложений в документ, по которому цена и срок фиксируются.

Почему трёх предложений недостаточно

У программиста, получившего расплывчатое описание, два выхода: задать двадцать вопросов или решить самому. Второй путь быстрее — и самый дорогой, потому что через месяц выясняется, что «заказы» означали ещё и счета, и отслеживание доставки, и три роли сотрудников. Каждое «а ещё нужно бы» после старта стоит в 2–3 раза дороже того же пункта в задании.

Двенадцать вопросов

О цели

1. Какую проблему решаем? Одно предложение: «Заказы принимаем по телефону и забываем; хотим, чтобы клиент заказывал сам, а мы получали уведомление». Не «хотим современную систему».
2. Как измерим, что получилось? Число: «80 % заказов приходят через систему за 3 месяца», «время на администрирование падает с 10 до 3 ч/нед».
3. Кто будет пользоваться? Все роли с числами: 2 администратора, 6 мастеров, ~300 клиентов в месяц. Каждая роль — отдельный набор экранов и отдельная цена.

О работе

1. Как это делается сегодня? Шаг за шагом, с инструментами: «клиент звонит → записываем в бумажный календарь → вечером переносим в Excel → за день звоним напомнить». Именно из этой строки программист видит, что автоматизируется.
2. Что система должна делать в первой версии? Список из 5–10 действий, каждое начинается с глагола: «клиент выбирает услугу и время», «администратор видит список дня», «система отправляет напоминание за день».
3. Чего в первой версии точно НЕ нужно? Не менее важный список. «Онлайн-оплаты — нет, программы лояльности — нет, мобильного приложения — нет». Это удешевляет первую версию вдвое и позволяет запуститься за недели, а не месяцы.

О данных и системах

1. Какие данные храним? Объекты и их поля простым языком: «клиент — имя, телефон, заметки; заказ — услуга, время, цена, статус». Персональные данные отмечаются отдельно — от этого зависят хранилище и часть про GDPR.
2. С чем должна соединяться? Существующие системы и их роль: «сайт на WordPress (форма остаётся), бухгалтерская программа (экспорт счетов), Google Календарь (графики мастеров)». Каждая интеграция — строка в смете.
3. Откуда берутся существующие данные? Если у вас 2 000 клиентов в Excel — перенос это работа. Если данных нет — проще.

О границах

1. Бюджет и срок. Не «сколько будет стоить?», а «у нас до 3 000 € и хотим до марта». Тогда программист предложит, что помещается, вместо того чтобы гадать. Ориентиры: один автоматизированный поток — от 150 €, система со своей базой данных и ролями — от 1 500 €; подробная таблица цен на веб-системы — на странице услуги.
2. Кто с вашей стороны принимает решения? Один человек, который отвечает на вопросы в течение дня. Проекты, где решения принимает «команда», длятся вдвое дольше.
3. Что будет после запуска? Кто поддерживает, кто меняет тексты, кому звонить, если не работает. Порядок поддержки договаривается до, а не после.

Один лист, а не двадцать

Хорошее ТЗ для небольшого проекта — 1–2 страницы. Если получается десять, проект слишком велик для первой версии: вернитесь к вопросу 6 и перенесите половину в «позже».

Пример: заполнено за 40 минут

Автосервис, 3 мастера. Проблема: запись по телефону, 15 звонков в день, двойная запись раз в неделю. Успех: половина записей онлайн за 2 месяца, двойных — 0. Роли: клиент, администратор, мастер. Сегодня: звонок → бумага → вечером в Excel. Первая версия: клиент выбирает услугу, мастера, время; администратор видит день и меняет; мастер видит свой день на телефоне; система отправляет SMS-напоминание за день. Не в первой версии: оплаты, заказ деталей, история клиентов с фото. Данные: клиент (имя, телефон, автомобиль), запись (услуга, мастер, время, статус). Интеграции: нет; позже — бухгалтерия. Существующие данные: нет. Бюджет: до 2 500 €, до февраля. Решает: владелец, отвечает в тот же день. После запуска: тексты сами, техподдержка — по потребности.

По такому листу предложение с точной цифрой — на следующий день.

Чего в задании не писать

• Технологий. «Должно быть на PHP» или «хотим React» — если только у вас нет команды, которая будет это поддерживать. Выбирать технологию под задачу — работа программиста.
• Деталей дизайна. «Кнопка синяя, круглая» — это решается на макетах, не в задании. Достаточно: «стиль как на нашем сайте» или ссылки на два примера.
• «Простая», «интуитивная», «современная». Эти слова ничего не фиксируют. Вместо них — конкретное действие и время: «клиент записывается за 3 нажатия».

Что сделать завтра

Скопируйте двенадцать вопросов в документ. Ответьте на первые шесть — это половина работы, и её достаточно для первого разговора. Остальные заполните вместе с программистом: это лучше, чем гадать. Если после вопроса 6 список «не нужно» короче списка «нужно» — вернитесь и перенесите ещё минимум два пункта.

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

Должен ли ТЗ писать программист?

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

Что, если по ходу проекта захотим что-то поменять?

Нормально и ожидаемо. Разница в том, что изменение оценивается отдельно («это +2 дня и +300 €»), и вы решаете, стоит ли оно того сейчас или во второй версии. Без задания нечего сравнивать, и спор «это же было очевидно» неизбежен.

Фиксирует ли задание цену?

Да — мы договариваемся о цене и сроке по нему до начала, и они не меняются, если не меняется задание. В этом и смысл: обе стороны знают, что будет сделано.