vakito написал(а):
Резюмирую: зачастую из-за того, что в спецификацию надо писать множество ерунды "по регламенту", ее составление становится тяжким бременем и для функциональщика, и для разработчика.
+1
Излишняя формализованность приводит к тому, что сначала смотрят как работает прога, и только потом, что написано по этому поводу в ТЗ. Т.о. ТЗ зачастую является обузой и ненужным балластом.
Имел опыт написания ТЗ по "полной программе" (какую привел тов.Parazit), и с уверенностью могу сказать, что половина пунктов нах. не нужна (а из оставшихся некоторые требуются только ну для
очень крупных разработок). Говорю с уверенностью, т.к. в итоге этот геморрой сподвиг меня на глубокое изучение ABAP и написание ТЗ самому себе в целях ускорения процесса
С другой стороны, есть опыт работы вообще без ТЗ и полноценного контроля за постановщиком и разработчиком. Оба после запуска в продуктив становятся "незаменимыми" сотрудниками, а при необходимости внесения более или менее серьезных изменений, зачастую вся разработка делается заново!
В общем к чему это я... считаю что оптимальным решением будет компромисс между консультантами и разработчиками.
Эдакое "спартанское" ТЗ, где указаны все ключевые моменты, а подробности при необходимсоти нужно смотреть или в коде программы, или в инструкциях пользователей, или в самой транзакции/отчете.
P.S. со слезами вспоминаю ТЗ типа проверок на сторно другой датой. 3-5 листов полного маразма, вместо 1 ))
Вход
Регистрация
FAQ пользователя
Поиск
