Техническое задание гарантирует юридическую безопасность клиентам, мы оформляем его в приложении к договору почти всегда. Исключение — работы для постоянных клиентов, продукты которых развиваем более 6 лет.
ТЗ должно помогать создавать хороший продукт, для этого нужен определенный уровень детализации в зависимости от проекта.
При создании ПО для оборудования, где предполагается много расчетов и есть технические зависимости, необходим максимум подробностей. Нужно раскрыть все моменты, без которых проект не реализовать. Например, мы создавали конструкторы для крупного завода. В проекте много вычисляемых параметров, которые критически важны для разработки и должны быть в ТЗ.
Если ПО затрагивает только бизнес-процессы, строгое техническое задание не нужно. Посмотрите примеры на доработку ПО и разработку нового. Если опасаетесь зависимости от разработчика, согласуйте создание подробной документации. Лишняя формализация не принесет пользы в таких проектах.
Почему для бизнесового ПО не нужно строгое ТЗ
Долгое составление
Уточнение даже небольшого вопроса затягивается на недели. В лучшем случае техническое задание согласовывали за полтора месяца.
Ошибки при создании
Учесть все нюансы в ТЗ нереально. По ходу разработки меняется многое. У компании всегда появляются новые данные или идеи для корректировки требований.
Нет быстрой обратной связи
Компания ждет итоговый вариант, чтобы внедрять. Смотреть на промежуточные результаты не горит желанием: «Как примем, так и скажем, что и как».
«Важного нет, зато есть ненужное»
Компания считает, что делали долго и дорого. Начинаем разбираться. Оказывается, часть функционала не используется. Зато много жалоб от менеджеров по продажам, для которых не реализовали систему напоминаний на email. В ТЗ про неё ни слова.
«Кто вообще писал ТЗ?»
Ситуация возникает, когда меняется руководитель проекта. Хуже всего, когда собственник бизнеса активно участвует в проекте, а затем делегирует всё сотруднику. Последний не знает планов на будущее, которые закладывались при проектировании. Начинается долгий разбор, что и для чего нужно.
«Это так не работает»
Поменялись бизнес-процессы, появились новые отделы или исчезли старые — ТЗ стало неактуальным. Возможность масштабирования и гибкого изменения должна быть заложена в техническое задание. На практике этому редко уделяется внимание.
Эффективный формат при работе над бизнесовым ПО
- Составляем общее описание проекта и список функций, которые нужны в ближайшее время.
- Называем примерную стоимость всего проекта и первого этапа, на котором внедряем самые важные функции. Первый этап не должен занять больше 3−4 недель.
- Подписываем договор с ТЗ на первый этап, получаем полную оплату первого этапа и приступаем к работе.
- Сдаем результат. Упор на функции, на уровне интерфейса — минимализм.
- Дорабатываем с учетом обратной связи и начинаем новую итерацию.
Что это дает компании-заказчику
Быстрая разработка минимального продукта (3−4 недели) и дальнейшее развитие небольшими итерациями.
После каждой итерации можно внедрить решение и проверить, удобно оно или нет. Внести изменения.
Снижение затрат на доработки продукта — правки коснутся небольшой части, не придется вносить большие изменения.
Работа в порядке приоритета — реализуем сначала то, что нужно в первую очередь.
Нюансы при работе с ТЗ
Если заказываете написание ТЗ в одной компании, а разрабатывать будет другая, согласуйте с последней требования. Иначе разработчики могут попросить доработать техническое задание.
Сохраняйте связь с авторами ТЗ, чтобы при возникновении вопросов быстро получить ответы.
Не рассматривайте техническое задание как неизменную сущность. Некоторые пункты могут потерять актуальность. Появится часть требований, которые нужно внести. Главное — достичь бизнес-целей.