Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?

Мы в SmartHead занимаемся заказной разработкой цифровых продуктов под ключ. В нашем портфолио много разных проектов: от интерактивных маркетинговых инсталляций, промосайтов, приложений для соцсетей до робототехники, медицинских симуляторов и интеграционных сервисов.

1111

Пока читал статью, сбоку слышал какой-то голос. Он саркастически комментировал ))
"Не пишите подробное ТЗ. Нам ведь придется много читать, много считать, много думать, мы боимся ошибиться с оценкой. Мы чувствуем себя некомфортно без неопределенности, за счет которой можно потом выезжать."
"Не описывайте детали подробно. Вдруг мы этого не умеем, нам будет трудно убедить вас в том, что вам нужно другое (вон тот плугин к битриксу, мы его уже умеем, а заодно и на битрикс переедем)."
"Не используйте UML, BPML и прочую шнягу. Вы видели на рынке специалистов, которые в них умеют? А действительно умеют? А сколько они стоят?"
"Не рисуйте интерфейс. Ведь тогда мы не сможем применить наш любимый фрамеворк или куски из прошлых проектов."

Впрочем, статья справедлива для плохого(!) и "подробного" (запутанного) ТЗ.

Если честно, не вижу никаких минусов в продуманном и подробном техзадании. Оно совсем не обязательно становится догмой, его тоже можно менять и корректировать. Но вот в качестве устойчивой платформы для разработки оно подходит гораздо лучше, чем "давайте балабонькать про бузинесс-цели".

1
Ответить

Ну, это немного передергивание:)

Статья про то, что "не надо считать что чем подробнее тем лучше". Разумеется, это не равно утверждению "чем меньше, тем лучше". Что-то действительно может требовать подробного и грамотного описания. Например, специфика предметной области, не доступная на уровне здравого смысла (или контринтуитивная).

Кстати, обычно, большинство людей чувствуют себя комфортнее как раз в определенности. И выезжают за счет того что "дык у вас в ТЗ так написано. А чего не написано - того нет". Неопределенность сложнее для обоих сторон и требует грамотной работы с ней. Но маскировка неопределенности фантазиями и глупостями (читай "плохо написанное ТЗ") - хуже чем "явная" неопределенность.

Ответить