Анализ требований — фундаментальный и самый дорогой этап разработки.
Требования заказчика могут уточняться и меняться в любой момент. Это верно как для проектной разработки, так и для продуктовой. Мы считаем считаем это нормальным и заранее закладываем на это время при оценке работ.И в том, и в другом случае желательно проектировать решение так, чтобы изменения были предсказуемы. На этапе анализа требований надо подготовиться к: "А мы тут подумали, что хотим по-другому".
Есть разница во взаимодействии с Заказчиком в зависимости от подхода к разработке.
Проектная разработка — когда заказчик "чужой человек". Ему нужна система и все равно, что происходит в процессе разработки, какие усилия прикладывает команда. Он ждет свою систему для бизнеса.
Не учел "хотелку", которую он подразумевал под формулировкой в договоре — сделал за свой счет или договорился на платные доп. работы. Как повезет.
После завершения разработки заказчик может продолжить сотрудничество с IT-компанией, может забрать решение и уйти в другую, или полностью остановить разработку. Ему все равно — загружены разработчики задачами или нет. За это отвечает IT-компания, где есть проекты.
Продуктовая разработка — когда заказчиком является компания, в которой Вы работаете. За исследования бизнеса и формулировку требований к системе отвечает владелец продукта (Product owner).
Заказчик в курсе, что происходит в команде разработки. В процессе требования могут уточняться и меняться. Если команда вышла за срок разработки из-за изменения требований, то это неприятно. Но все с пониманием относятся к этому.
Когда текущий набор задач по созданию системы завершается, то обычно уже готов набор новых. Компании не выгодно, чтобы разработчики стояли.
Екатерина Ананьева
Основатель IT-школы системного анализа и проектирования GetAnalyst
k@getanalyst.ru
Мы используем файлы cookie, для персонализации сервисов и повышения удобства пользования сайтом. Если вы не согласны на их использование, поменяйте настройки браузера.