Расползание масштаба – существенный риск в проектах разработки программного обеспечения. В статье рассматривается, почему это так, и как предотвратить или минимизировать риск.
Что такое расползание масштаба? Новое программное обеспечение обычно разрабатывается вследствие того, что заказчик (который может быть внутренним или внешней организацией) указывает потребность. Следующий шаг – установление того, как программное обеспечение будет удовлетворять эту потребность; особенно, какая функциональность будет разработана. Это масштаб проекта. Исходя из оценок, составляются планы проекта по разработке и предоставлению оговоренной функциональности, и согласуется дата окончания. Начинается разработка, и проект выглядит успешно продвигающимся вперед. Но затем заказчик понимает, что есть дополнительные требования, которые он забыл упомянуть, или дополнительные элементы функциональности, необходимые ему. Часто добавление таких дополнений по желанию заказчика вызывает увеличение продолжительности проекта, приводящее к превышению сроков и дополнительным затратам, приводящим к разрушению границ проекта, потенциальной неудовлетворённости клиента и потере репутации из-за сдачи проекта с опозданием. Как бороться с расползанием масштаба Важно, чтобы функциональные требования вырабатывались вначале и записывались в выражениях, понятных заказчику. Например, подробный анализ процесса, который будет поддерживать программное обеспечение, возможно, проиллюстрированный снимками экрана в натуральную величину, поможет разъяснить, как новая система будет работать с точки зрения пользователя. Функциональные требования должны быть согласованы и подписаны заказчиком, и должны содержать задание по проекту. Оно утверждает, что только функциональность, точно описанная в требованиях, входит в масштаб проекта, и что все, не описанное в них, не входит в масштаб. Когда заказчик позднее указывает дополнительные элементы, обращаются к требованиям: описана или упомянута в них требуемая функциональность? Если нет, то новая доработка не входит в масштаб. Следующий шаг – вычисление влияния разработки новой функциональности. Какие дополнительные усилия потребуются? Как это повлияет на общую продолжительность проекта? Какие дополнительные расходы придется понести, и как это повлияет на границы проекта? Если влияние незначительное, можно согласиться включить новую функциональность в существующий проект, но в идеале ее нужно утвердить письменно путем выпуска измененных требований. Риск здесь в том, что заказчик считает, что прецедент был создан, и что дальнейшие изменения будут сделаны аналогично: важно сообщить причины для разрешения изменений в данном случае. По всей вероятности, дополнительные доработки вызовут задержку и/или дополнительные расходы. Заказчика нужно поставить в известность о последствиях изменения в виде воздействия на сроки и стоимость, и должна быть написана спецификация дополнений и изменений (со своей собственной формулировкой масштаба). Затем заказчик решает, готов ли он заплатить больше, и может ли он принять пересмотренную дату окончания проекта. Если он согласен, новая спецификация должна быть подписана, как и ранее. Действительно ли нужна формулировка масштаба? Можно считать, что написание достаточно подробной спецификации потребует больше времени и расходов , чем гарантирует ценность всего проекта. Например, если ожидается, что весь проект займет всего несколько недель, а написание подробной спецификации займет 5 дней, то анализ затрат и выгод покажет, что это не стоит делать. Если это так, оцените вероятность риска (на основе ваших данных о заказчике и исходя из того, насколько вы уверены в том, что все требования были указаны) и возможное воздействие, и встройте достаточные непредвиденные расходы в ваши оценки сроков и расходов, чтобы покрыть почти все самые крупные изменения в спецификации.
Newer news items:
Older news items:
|