10.0 Водопад против циклического управления проектом (часть 3) – жизненный цикл проекта и результаты

На протяжении всего жизненного цикла проекта пользователи должны иметь возможность тестировать все промежуточные результаты. #

Клиентам настоятельно рекомендуется определять свои потребности как можно точнее на этапах определения и проектирования. Это сложно по двум причинам. Для начала потребители имеют ограниченное представление о потенциале и невозможности информационных технологий. Они не имеют представления о том, что возможно или должно быть осуществимо, и не знают, чего им следует или не следует желать. Во-вторых, потребители часто не имеют четкого представления о собственных бизнес-процессах.

Многочисленные ИТ-инициативы включают компьютеризацию текущих бизнес-процессов организации. Несмотря на то, что потребители работали с процессами в течение длительного периода времени, им часто не хватает способности разрабатывать свои собственные бизнес-процессы. Они могут хорошо работать по-своему, но не могут указать, что это за манера. Перед разработкой программного обеспечения, которое будет способствовать компьютеризации, необходимо точное определение процесса. Сложность клиентов возрастает из-за необходимости объяснять текущие процедуры.

Критерии определения #

Часто список критериев, составленный на этапе определения, бывает неполным. Программисты создают программное обеспечение в соответствии с этим частичным списком на этапе внедрения. Когда потребители сталкиваются с бета-версиями нового программного обеспечения, становятся очевидными дополнительные потребности. «Выглядит неплохо, но не могли бы вы исправить это, чтобы мне не приходилось постоянно вводить свой пароль?» Программисты часто сетуют на то, что клиенты не уверены в том, чего они хотят. Заказчики утверждают, что, будучи экспертами, разработчики программного обеспечения должны были заранее определить, чего хотят клиенты.

Был создан комплексный функциональный дизайн программного проекта, который включал автоматизированную обработку приложений для веб-сервиса. Были составлены многочисленные запросы клиентов. После добавления нескольких экранов и блок-схем программисты могли приступить к работе.

Управление клиентами и ограничениями #

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

Когда программа была предоставлена для тестирования, клиент обнаружил, что многие приложения имеют исключения. Эти заявки не могут обрабатываться автоматически и должны обрабатываться вручную. Однако программа работала полностью автоматически.

В управление проектами водопада требует тестирования реальных результатов проекта по завершении фазы реализации. Это поздно стадия развития . Между этапом определения, этапом проектирования и этапом реализации могут пройти месяцы или даже больше года. Если недостатки дизайна обнаруживаются на поздней стадии проекта, изменение программы без полного запуска нового проекта может оказаться дорогостоящим, а то и невозможным. Учитывая, что практически невозможно определить все критерии заранее, желателен рабочий подход, позволяющий тестировать (промежуточные) результаты.

Анализ требований #

Сравнивая несколько потенциальных компаний-разработчиков программного обеспечения, клиент поинтересовался их возможностями. Одна сторона колебалась и ставила под сомнение выполнимость многих требований заказчика. Противоположная сторона была представлена агрессивным торговым агентом.

Когда клиент интересовался выполнимостью конкретного запроса, продавец звонил своим кодировщикам. «Можем ли мы создать функцию, которая выполняет X?» Программист, мысливший в основном техническими терминами, сказал, что все теоретически возможно. Ни программист, ни продавец не беспокоились о управление проектом осуществимость (например, время, деньги, сложность и риск).

Волнение торгового представителя превзошло сдержанное поведение собеседника. Клиент выбрал агрессивное предложение торгового представителя. Затем недавно приобретенный проект был передан руководителю проекта и команде программистов.

Спустя некоторое время стало ясно, что проект не оправдывает ожиданий заказчика. Отчасти это было связано с тем, что процедуры были для клиента намного сложнее, чем казалось изначально. Во время жаркого обмена мнениями между двумя сторонами клиент сказал, что продавец «заявил, что функциональность X не будет проблемой.