9.0 Водопад против циклического управления проектами (часть 2) – оценка времени и ресурсов

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

Однако в действительности существует слишком много неопределенностей, чтобы дать точное приближение:

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

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

Программные риски #

ПО для управления проектами никогда не будет полностью безошибочным. Даже для хорошо известных программ, которые широко используются (например, Word, Excel, Explorer, OS X, PHP и Flash), в Интернете есть списки известных недостатков. На рынке регулярно появляются новые версии, исправляющие программные ошибки. Иногда заказчики требуют, чтобы программное обеспечение работало без ошибок. В действительности, однако, такая цель сделала бы создание программного обеспечения невозможным. Кроме того, программные сбои часто не связаны с программой.

Flash использовался для создания обучающей игры. Клиент согласился получить игру в виде файла и установить ее на свой сервер. В ходе проекта клиент попросил добавить в игру функцию рекордов, чтобы повысить конкурентоспособность игроков. Для этого потребуется код сценария PHP. Разработчики игры разработали и протестировали код скрипта на собственном сервере под управлением Linux. Это было успешно. Клиент получил код игры и скрипта. Однако клиент использовал сервер Windows, и по какой-то причине скрипт перестал работать должным образом. Лучшие оценки не сохранились. В конечном итоге программисту требуется неделя, чтобы исправить проблему. Как оказалось, PHP и Windows не всегда хорошо работают вместе. Скрипт в целом не содержал ошибок! Он смог заставить его работать с помощью хака, и все остались довольны – но кто должен платить за эту дополнительную неделю труда?

Другой проект по разработке программного обеспечения также включал создание обучающих приложений. Проблема заключалась в том, что программное обеспечение отлично работало для разработчиков, но не для клиента. Исчерпав все остальные возможности, программист решил нанести визит клиенту. Как выяснилось, клиент работал на машине Pentium III с начала 1990-х годов. Медлительность компьютера способствовала низкой производительности программного обеспечения. Кроме того, программисты опробовали программу на Pentium III, и она работала хорошо. Дальнейшее обследование показало, что компьютер клиента работал медленно из-за заражения вирусом и шпионским ПО.

Управление неопределенностями при разработке проекта #

Неопределенность, показанная в приведенных выше примерах, усложняет процесс разработка планов проекта . Кроме того, это усложняет переговоры между сторонами. Кто-то должен нести риски, связанные с дополнительным трудом, который необходимо выполнить. Если оплата производится почасово, все риски ложатся на клиента. Когда согласована установленная плата (как в случае с проектами, финансируемыми за счет грантов), разработчик программного обеспечения несет риск. Когда задействовано более двух человек, ситуация усложняется. В этом сценарии, кто должен нести стоимость дополнительных часов, отработанных над проектом?

Часто возникают споры о том, кто должен нести ответственность за задержки. Часто ответственного человека сложно определить. Вполне вероятно, что ни одна из вовлеченных сторон не виновата, поскольку «задержка» была вызвана неправильной первоначальной оценкой количества требуемых часов. Избыточные часы работы над проектом и вопрос о том, кто должен платить, являются частыми причинами разногласий в индустрии информационных технологий.