Лекции по управлению программными проектами

         

Главные риски программных проектов и способы реагирования


Мой список из пяти главных причин провала программных проектов — следующий:

  • Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
  • Отсутствие необходимых ресурсов и опыта.
  • Отсутствие рабочего взаимодействия с заказчиком.
  • Неполнота планирования. «Забытые работы».
  • Ошибки в оценках трудоемкостей и сроков работ.

Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели и требования. Цитата из жизни: «Была бы разработана хорошая программа, а какой процесс автоматизировать с ее помощью, мы найдем». К этому можно добавить только одно: «Когда человек не знает, к какой пристани он держит путь, для него никакой ветер не будет попутным» (Сенека Луций Аней, философ, 65-3 до н.э.)

К часто упускаемым требованиям можно отнести:

  • Функциональные
  • Программы установки, настройки, конфигурации.
  • Миграция данных.
  • Интерфейсы с внешними системами.
  • Справочная система.
  • Общесистемные
  • Производительность.
  • Надежность.
  • Открытость.
  • Масштабируемость.
  • Безопасность.
  • Кросплатформенность.
  • Эргономичность.

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

Если вероятность изменений требований проекта высока, то возможны следующие подходы для реагирования на данный риск:

  • Переоценка проекта каждый раз, когда требования добавляются / изменяются (уклонение).
  • Итерационная разработка. Контракт с компенсацией затрат на основе «Time & Materials» (передача риска Заказчику).
  • Учет в оценках трудоемкости и сроков возможности роста требований, например, на 50% (резервирование риска).


И еще, при сборе требований следует соблюдать принцип минимализма Вольтера: «Рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть». Для большинства программных продуктов применим принцип Парето: 80% ценности продукта заключены лишь в 20% требований к нему.

Если у нас в проекте недостаточно квалифицированных специалистов, то мы можем снизить последствия этого риска, применив следующие действия:


  • Привлечь экспертов-консультантов на начальных этапах.
  • Учитывать в оценках трудоемкости издержки на обучение сотрудников.
  • Уменьшать потери от текучести кадров, привлекая на начальном этапе избыточное число участников.
  • Учесть в оценках «время разгона» для новых сотрудников.


Для установления открытых и доверительных отношений с заказчиком, необходимо предпринимать следующие шаги:


  • Постоянное взаимодействие.
  • Согласование пользовательских интерфейсов и разработка прототипа продукта.
  • Периодические поставки тестовых версий конечным пользователям для их оценки.


При планировании работ по проекту часто «забывают»:


  • Обучение.
  • Координация работ.
  • Уточнение требований.
  • Управление конфигурациями.
  • Разработка и поддержка скриптов автосборки.
  • Разработка автотестов.
  • Создание тестовых данных.
  • Обработка запросов на изменения.


И еще. Не стоит надеяться, что участники проекта будут каждую неделю по 40 часов работать именно над вашим проектом. Есть множество причин, по которым они не смогут работать по проекту 100% своего времени. К списку наиболее распространенных причин этого относятся:


  • Сопровождение действующих систем.
  • Повышение квалификации.
  • Участие в подготовке технико-коммерческих предложений.
  • Участие в презентациях.
  • Административная работа.
  • Отпуска, праздники, больничные.


Рекомендация, планировать, что разработчики, которые назначены в ваш проект на 100% будут реально работать над вашими задачами в среднем от 24 до 32 часов в неделю.

Ошибкам в оценках трудоемкости и сроков проекта и походам, которые позволяют их минимизировать, буде посвящена следующая лекция.


Содержание раздела