Почему не нужно жесткое ТЗ на разработку ПО

Четыре года мы работали с проектами «с нуля» по распространенной схеме:

1. Приходит заказчик, описывает проблему и желаемое решение.
2. Мы изучаем бизнес-процессы и составляем детальное техническое задание.
3. Подписываем договор, получаем предоплату и приступаем к работе.
4. Сдаем работу с проверкой ТЗ и получаем оставшуюся часть оплаты.

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

Учесть все требования и нюансы нереально. Продукт на этом этапе воспринимается как следующий Новый Год. Будут мандарины, елка, подарки и бой курантов. Конкретные детали — в следующем декабре после двадцатого числа.

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

Между составлением ТЗ и сдачей рабочей версии проходит несколько месяцев. У заказчика за это время может многое поменяться — а значит, снова оттянется время внедрения продукта.

В итоге у заказчика возникают сложности:

«Так просто и дорого»

Проходит несколько недель, мы ищем обратной связи и встречаем негатив. Заказчик считает, что делали долго и дорого. Начинаем разбираться. Оказывается, часть функционала не используется. Зато много жалоб от менеджеров по продажам, для которых не реализовали систему напоминаний на email. В техническом задании про неё ни слова.

«Кто вообще писал ТЗ?»

Ситуация возникает, когда меняется руководитель проекта. Хуже всего, когда собственник бизнеса активно участвует в проекте, а затем делегирует всё сотруднику. Последний не знает планов на будущее, которые закладывались при проектировании. Начинается долгий разбор, что и для чего нужно.

«Это так не работает»

Поменялись бизнес-процессы, появились новые отделы или исчезли старые — ТЗ стало неактуальным. Возможность масштабирования и гибкого изменения должна быть заложена в техническое задание. На практике этому редко уделяется внимание.

Мы скорректировали подход, чтобы заказчик получал нужный бизнесу продукт быстрее. Как стали работать:

1. Составляем общее описание проекта и список функций, которые нужны в ближайшее время.
2. Называем примерную стоимость всего проекта и первого этапа, на котором внедряем самые важные функции. Первый этап не должен занять больше 3−4 недель.
3. Подписываем договор, получаем полную оплату первого этапа и приступаем к работе.
4. Сдаем результат. Упор на функции, на уровне интерфейса — минимализм.
5. Ждем пожеланий по доработке или внедрению новых функций и начинаем новую итерацию.

Быстрая разработка минимального продукта (3−4 недели) и дальнейшее развитие небольшими итерациями.

После каждой итерации можно внедрить решение и проверить, удобно оно или нет.

Снижение затрат заказчика на доработки продукта — правки коснутся небольшой части, не придется вносить большие изменения.

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