Я верю, что где-то существуют проекты, которые успешно и эффективно реализованы на основе ТЗ. Но это не точно… Проблема в том, что за всю свою карьеру я видел лишь одно ТЗ, очень очень давно. Начиная с проекта Додо ИС, такого больше не происходило. До сих пор помню как создавался движок для рекламных акций Додо ИС, когда я попросил Федора просто написать 5 акций, которые он хотел бы запустить.
На этот счет у нас в компании есть шутка: Если хочешь избавиться от заказчика — отправь его писать ТЗ.
Мы занимаемся разработкой для малого и среднего бизнеса, смена вектора в которых происходит очень быстро. Еще летом 2011 года в модели Додо каждая пиццерия должна была принимать свои заказы сама, в начале 2012 система была запущена в прод, а уже в марте схема была изменена и началась работа над единым call-центром. То же самое происходит абсолютно на всех наших проектах. Нет никакого смысла тратить время на разработку ТЗ, когда уже завтра его большую часть можно будет выбросить.
Нужно признать при этом, что разработка ТЗ — это очень сложный и объемный процесс, который может быть не менее сложным, чем написание самой программы. Очень тяжело продумать систему в чистом теоретическом пространстве. Поэтому большинство, а в нашем случае все, не рискуют вкладываться с отдельную разработку ТЗ. Да и Герман Греф уже давно убедил всех, что нет ничего лучше agile-подхода с точки зрения бизнеса.
Есть проекты, на которых мы были не единственными подрядчиками и наблюдали разработку относительно небольших блоков по ТЗ со стороны. Головная боль приходит вместе с первыми изменениями. Постоянные согласования, споры о том, что имелось в виду в том или ином пункте ТЗ, попытки добиться, чтобы исполнитель сделал изменения за свой счет, попытки доказать заказчику, что кривое ПО вполне удовлетворяет требованиям ТЗ, которое было подписано. Один из таких случаев закончился судебным разбирательством.
В нашем случае ТЗ заменяет живое общение с заказчиком о его бизнесе и будущих планах. Такое общение происходит постоянно на всем протяжении разработки проекта. Иногда со стороны даже трудно понять, что речь идет о разработки софта, уж очень разные темы обсуждаются. Таким образом задается контекст, который не записан ни в одном ТЗ. Все это позволяет очень быстро перестраиваться и адаптироваться к постоянно меняющимся условиям.
Кажется, что в нашем варианте все построено на доверии. Мое же мнение, что до определенного уровня всегда все строится на нем. Чудес не бывает, снижение рисков всегда стоит денег. И либо разработка ведется на доверии, либо тратится очень много денег на ТЗ и на договор…
И договор — это отдельная веселая тема 🙂
