Зачем нужно техническое задание
Техническое задание защищает и заказчика, и подрядчика. Заказчик получает то, что ему нужно, а не то, что подрядчик понял. Подрядчик точно знает, что входит в работу, и может назвать честный срок и цену. Без задания каждая сторона держит в голове свою картинку, и они расходятся к концу работы.
Многие заказчики откладывают разработку, потому что думают, что сначала нужно написать толстый документ на языке программистов. Это не так. Хорошее задание для небольшой программы помещается на нескольких страницах и написано обычными словами.
Что должно быть в техническом задании
| Раздел | Что в нём описать | Пример |
|---|---|---|
| Цель | какую проблему решает программа | заявки теряются между сайтом и мастерами |
| Пользователи | кто работает и что делает каждый | диспетчер, мастер, бухгалтер, руководитель |
| Процессы | как идёт работа по шагам | заявка, назначение, выезд, акт, оплата |
| Данные | что хранится | клиенты, адреса, наряды, работы, цены |
| Документы | что печатается или отправляется | акт, счёт, чек |
| Связи | с чем обмениваться данными | 1С, сайт, банк, телефония |
| Где работает | компьютер, телефон, без сети | мастер на телефоне, часто в подвале |
| Права | кто что видит и меняет | мастер видит только свои наряды |
| Готовый результат | что считаем выполненной работой | наряд проходит от заявки до акта в 1С |
Последний раздел самый полезный. Если заранее договориться, что считается готовым, спорить в конце не о чем.
Пример короткого ТЗ
Для небольшой программы техническое задание может выглядеть так. Это пример структуры, ваши пункты будут своими.
- Цель. Заявки с сайта и звонков попадают к мастерам без ручного переноса, акты уходят в 1С сами.
- Пользователи. Диспетчер (2 человека), мастера, бухгалтер, руководитель.
- Процесс. Заявка, назначение мастера, выезд, работы и материалы, оплата, подпись, акт.
- Исключения. Клиента нет дома, нужна запчасть, клиент отказался от работ, повторный вызов.
- Данные. Клиенты и адреса, наряды, прайс работ, материалы, мастера.
- Документы. Акт, счёт, чек по шаблонам компании.
- Связи. Форма на сайте, 1С, SMS клиенту.
- Где работает. Диспетчер на компьютере, мастер на телефоне, в том числе без связи.
- Права. Мастер видит только свои наряды и свой заработок, бухгалтер документы и оплаты.
- Готовый результат. Наряд проходит путь от заявки до акта в 1С на настоящих данных.
Такое задание занимает две-три страницы, и по нему уже можно назвать срок и цену. Подробности уточняются на прототипе экранов.
Как описать процессы
Процесс лучше описывать так, как вы рассказали бы новому сотруднику. По шагам, с тем, кто делает каждый шаг и что получается в конце.
Пример описания процесса выездной службы:
- Клиент оставляет заявку на сайте или звонит диспетчеру.
- Диспетчер записывает адрес, задачу и удобное время, назначает мастера.
- Мастер получает наряд на телефон, едет, отмечает, что на месте.
- На объекте мастер выбирает работы из прайса, фотографирует, берёт оплату и подпись клиента.
- Акт и чек уходят клиенту, бухгалтерия получает акт в 1С.
Это пример того, как можно описать процесс. Ваш будет своим, но формат подойдёт любому. Так устроена наша программа Control Brigade: «Электронный заказ-наряд».
Отдельно опишите исключения: что делать, если клиента нет дома, если нужна запчасть, если клиент отказался платить. Именно на исключениях чаще всего ломаются программы, написанные «по основному сценарию».
Как описать экраны
Рисовать экраны самому не обязательно. Достаточно сказать, что сотрудник должен видеть и делать на каждом. «Диспетчер видит все заявки на сегодня, видит, какие без мастера, и может назначить мастера в два нажатия».
Если есть примеры программ, которые вам нравятся или не нравятся, покажите их. Это экономит много времени. Мы рисуем прототип экранов и показываем его до начала разработки, чтобы правки были на бумаге, а не в готовой программе.
Требования к данным и переносу
Отдельно стоит описать, какие данные уже есть и что с ними делать. Клиенты в таблице, прайс в документе, остатки в 1С. Подрядчику нужно знать, откуда переносить данные при запуске и в каком они виде.
Приложите к заданию примеры: выгрузку клиентов, прайс, пару заполненных бланков. По ним видно, какие поля действительно используются, а какие давно пустые. Перенос данных мы делаем сами при запуске, и чем раньше видны данные, тем меньше сюрпризов.
Что не нужно писать в ТЗ
- Язык программирования и базу данных. Это выбирает подрядчик, и он за это отвечает.
- Цвет каждой кнопки. Дизайн согласуется отдельно на прототипе.
- Всё, что может понадобиться через три года. Опишите первую версию, остальное добавится по ходу.
- Общие слова вроде «удобный интерфейс» и «быстрая работа». Вместо них опишите, что сотрудник должен сделать и за сколько действий.
Первая версия и следующие
Хорошее задание делит работу на версии. Первая закрывает главное, без чего программа не нужна. Остальное идёт в следующие версии, когда первая уже работает и сотрудники подсказали, что действительно нужно.
Так программа запускается быстрее, а деньги не тратятся на функции, которые потом не понадобятся. Первая версия у нас обычно готова в течение месяца. Как проходит разработка: «Разработка системы учёта», «Своя CRM с нуля» и «Мобильное приложение для бизнеса». Что происходит после запуска: «Доработка программы».
Кто пишет техническое задание
Есть три варианта:
- Заказчик пишет сам. Получается быстро, но часто пропускаются исключения и связи, потому что заказчик о них не думает.
- Подрядчик пишет за отдельные деньги. Получается подробно, но иногда дольше и дороже, чем нужно небольшой компании.
- Заказчик рассказывает, подрядчик оформляет. Мы работаем так: на встрече задаём вопросы, описываем процессы и показываем черновик экранов. Отдельно за ТЗ платить не нужно, это часть разработки.
Как подготовиться к первой встрече
- Список того, что сейчас мешает, своими словами.
- Кто будет пользоваться программой и сколько этих людей.
- Таблицы, бланки и документы, которые вы сейчас используете.
- Программы, с которыми нужно связать новую: 1С, сайт, банк.
- Две-три ситуации, на которых работа сейчас ломается.
С этим за одну встречу можно понять задачу и назвать примерный срок и цену. Мы работаем по Екатеринбургу и Свердловской области и приезжаем на встречу.
Частые ошибки в техническом задании
- Описывать решение вместо задачи: «нужна кнопка экспорта» вместо «бухгалтер должен получать акты в 1С».
- Пропускать исключения. Основной сценарий работает, а первый же отказ клиента ломает процесс.
- Забывать про права. Через месяц выясняется, что мастера видят выручку всей компании.
- Не договариваться о готовом результате. Работу невозможно принять, потому что непонятно, что считать готовым.
- Писать задание на два года вперёд. Половина пунктов устаревает до запуска.
Сколько стоит разработка по ТЗ
Цена зависит от объёма первой версии. Разработка у нас стоит от 15 000 ₽, если задача небольшая, дешевле. Примерную цену можно посчитать в калькуляторе: выберите, что нужно сделать, с чем связать и где будет работать программа. Точную назовём после разговора о задаче.
Расскажите, что сейчас мешает в работе. Мы зададим вопросы, поможем описать задачу и покажем, как будет выглядеть программа.