Для примера можно рассмотреть описание требований учетной системы в ТЗ. В первую очередь возникает вопрос - а какие требования описывать в ТЗ? Если описывать все требования, которые нужны Заказчику (полное ТЗ), это означает, что 90% ТЗ описывает то, что уже есть в типовой программе. И только 10% посвящено реальной разработке. То есть, 90% работы по проектированию будет востребовано только для формального согласования функций, и по-сути, будет дорогим и ненужным бюрократизмом.
А если описывать только те функции, которые нужно изменить или разработать (ТЗ на отклонения), что действительно необходимо разработчикам, то Заказчик формально остается в неведении о 90% функциональности, которую он получит. Разработчику тут придется ссылаться на документацию к базовой программе и доступность программы для изучения и анализа самим Заказчиком.
Конечно, есть Заказчики, для которых формальное бюрократическое согласование - это главное. Они готовы оплатить работу по проектированию того, что уже давно создано, чтобы не нарушать корпоративные стандарты ведения дел. С их точки зрения ТЗ - это Документ, а на программный код печать и подпись не поставишь.
Но и в этом случае описать всю требуемую функциональность в полном ТЗ - задача не простая. Для этого нужно не только изучить учет и бизнес-процессы Заказчика, но и собственно программу. Так как обладая бездонным функционалом, учетные системы еще и постоянно меняются, иногда - радикально.
Комментариев нет:
Отправить комментарий