Как составить техническое задание для разработчиков?

В это трудно поверить, но за всё время в разработке с 2000 года ни разу не встретили полноценного технического задания (ТЗ). И это при том, что повидали множество разнообразных документов. К сожалению, ни про один не можем сказать, что он полностью удовлетворял требованиям ТЗ.

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

В России ТЗ пишется согласно двум ГОСТам: 34.602.89 «Техническое задание на создание автоматизированной системы» и 19.201-78 «Техническое задание». А свод знаний по управлению проектами (PMBOK) и её российские адаптации вообще не оперирует термином ТЗ.

Для удобства собрали ключевые различия в таблицу:

Напрашивается вывод: вместо ТЗ лучше использовать термин «проект» и опираться на сопутствующую документацию. Четыре ключевых документа позволят сузить содержание задачи (SCOPE), снизить стоимость и уменьшить сроки:

1. Организационная структура – для ролевого описания оптимизируемых активностей:

2. Визуализированная схема изменяемого процесса с указанием:
   1. участников
   2. содержаний этапов
   3. информационных систем

3. Важные пользовательские истории. Ролевые модели – описываем кто, что, когда и в какой последовательности выполнил в рамках рассматриваемого процесса:
   1. Заказчик – Максим Горький, букет «Ромашки», сумма 2’900 руб., дата заказа 08.03.22. Описанные действия выполнялись одним днём – 08.03.22
      1. Этап 1-2. Заказчик заказывает на сайте букет «Ромашки».
      2. Этап 2-3. Заказчик оплачивает букет онлайн, Колл-центр уточняет содержимое Заказа и время доставки.
      3. Этап 3-4. Колл-центр подбирает в соответствии с адресом доставки ближайший розничный магазин.
      4. Этап 4-5. Флорист собирает букет. Оставляет заявку курьеру.
      5. Этап 5-6. Курьер появляется в розничной точке. Флорист пробивает чек и передаёт букет курьеру.
      6. Этап 6-7. Курьер передаёт Заказ Получателю и сообщает о передаче товара.
      7. Этап 7-8. Колл-центр закрывает Заказ.
      8. Этап 8-9. Финблок проверяет финансовые показатели сделки.
4. Критерии приёмки проекта – сценарии и методики тестирования. Ключевой инструмент управления качеством разработки. Со стороны Заказчика назначается ответственный за контроль. Проверки выполняются в тестовом контуре.
   1. Заказ на сайте с выбором букета.
   2. Создание клиента.
   3. Создание товара.
   4. Создание заказа в учётной системе. Отработка цепочки документов.
      1. Закупка.
      2. Установка цен.
      3. Комплектация.
      4. Эквайринговая операция.
      5. Реализация.
      6. Расчёт себестоимости.
   5. Контроль финансового результата сделки
      1. Валовая прибыль – себестоимость, продажа, прибыль.
      2. Отчёт о прибылях и убытках – корректное отражение в структуре доходов.

Создание перечисленных документов структурирует ожидания Заказчика от проекта. Позволяет точнее спрогнозировать стоимость и сроки реализации желанных доработок. Уменьшает количество правок и корректировок в части расширения задуманного функционала.

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

Желающие получить максимум от разработчиков и ускорить перекладывание процессов на новые рельсы должны озаботиться созданием соответствующих шаблонов и документов после утверждения проекта. Обкатка процедур подготовит сотрудников и поможет выявить нюансы.