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

С. Архипенков

Назад Содержание Вперёд

Сроки

Ф. Брукс [3] писал: «Чтобы родить ребенка требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи. Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер».

Там же Брукс приводит исключительно полезную, но почему-то редко применяемую, эмпирическую формулу оценки срока проекта по его трудоемкости. Формула была выведена Барии Боэмом (Barry Boehm) на основе анализа результатов 63 проектов разработки ПО, в основном в аэрокосмической области. Согласно этой формуле, для проекта, общая трудоемкость которого составляет N ч.*м. (человеко-месяцев), пожно утверждать что:

• Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (N ч.*м.)^1/3. То есть оптимальное время в месяцах пропорционально кубическому корню предполагаемого объема работ в человеко-месяцах. Следствием является кривая, дающая оптимальную численность проектной команды (Рисунок 15).
• Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.
• Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне зависимости от количества занятых в нем! (Рисунок 16)

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

Рисунок 15. Закон Б.Боэма

Для сколь-нибудь серьезного программного проекта недостаточно определить только срок его завершения. Необходимо еще определить его этапы — контрольные точки, в которых будет происходить переоценка проекта на основе реально достигнутых показателей.

Контрольная точка — важный момент или событие в расписании проекта, отмечающее достижение заданного результата и/или начало / завершение определенного объема работы. Каждая контрольная точка характеризуется датой и объективными критериями ее достижения.

Как мы говорили ранее, современный проект разработки ПО должен реализовываться с применением инкрементального процесса. В этом случае контрольные точки должны соответствовать выпуску каждой промежуточной версии ПО, в которой будет реализована и протестирована определенная часть конечной функциональности программного продукта. В зависимости от сложности и масштаба проекта продолжительность одной итерации может составлять от 2 до 8 недель.

Рисунок 16. Следствия закона Б.Боэма

Соответствующий раздел концепции нашего проекта-примера будет иметь следующий вид.

9. Сроки проекта

   9.1. 03.03 старт
   9.2. 28.11 завершение
   9.3. Контрольные точки:
   9.3.1. 15.04 ТЗ утверждено
   9.3.2. 30.04 1-я итерация завершена. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).
   9.3.3. 15.05 Монтаж оборудования у заказчика завершен .
   9.3.4. 30.05 Базовое ПО установлено у заказчика.
   9.3.5. 15.06 2-я итерация завершена. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика
   9.3.6. 02.09 3-я итерация завершена. Акт передачи системы в опытную эксплуатацию утвержден
   9.3.7. 28.11 Система передана в промышленную эксплуатацию.

Риски

Риск — неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта [1].

Как правило, в случае возникновения негативного риска, почти всегда стоимость проекта увеличивается и происходит задержка в выполнении мероприятий, предусмотренных расписанием проекта. Управлению рисками проекта будет посвящена отдельная лекция.

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

В случае нашего проекта-примера раздел «риски» будет выглядеть следующим образом.

10. Риски проекта

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

Критерии приемки

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

В рассматриваемом примере раздел «Критерии приемки» будет выглядеть следующим образом:

11. Критерии приемки. По итогам опытной эксплуатации система должна продемонстрировать следующие показатели:

    11.1. Средние затраты сотрудников Отдела «123» на регламентную обработку одного заказа не превышают 4 чел.*час.
    11.2. Срок регламентной обработки 1-го заказа не более 2 недель.
    11.3. Время поиска и предоставления информации о наличии дополнительной документации не более 1 мин.
    11.4. Время предоставления информации о сделанных заказах и истории их обработки не более 1 мин.
    11.5. Система хранит всю информацию о сделанных заказах и истории их обработки.
    11.6. Показатель доступности системы 98%.

Обоснование полезности проекта

Этот раздел концепции должен содержать краткое технико-экономическое обоснование проекта:

• Для кого предназначены результаты проекта.
• Описание текущей ситуации «As Is». Какие у потенциального заказчика существуют проблемы.
• Каким образом результаты проекта решают эти проблемы («To Be»).
• Насколько значимо для клиента решение данных проблем (оценка экономического эффекта).
• Какие преимущества в итоге из этого может извлечь компания-исполнитель проекта.

Соответствующий раздел в концепции проекта-примера будет иметь следующий вид.

12. Обоснование полезности проекта

    12.1. Для Заказчика:
    12.1.1. Повышение производительности обработки заказов в 2 раза.
    12.1.1.1. "As Is": 2500 заказов/год по 8 чел.*час.
    12.1.1.2. "To Be": 2500 заказов/год по 4 чел.*час.
    12.1.1.3. Экономия: 2500 * 4 * $50 = $500 000 в год.
    12.1.2. Повышение оперативности контроля
    12.1.2.1. "As Is": Ежемесячная отчетность.
    12.1.2.2. "To Be": Отчетность on-line.
    12.1.3. Повышение удовлетворенности клиентов:
    12.1.3.1. Сокращение срока обработки заказа в 2 раза.
    12.1.3.2. Сокращение времени на поиск необходимой документации в 10 раз
    12.1.3.3. Повышение оперативности обновления каталога 10 раз. 12.2. Для компании-исполнителя:
    12.2.1. Высокая стратегическая ценность. Дает устойчивое увеличение рынка и завоевание нового рынка.
    12.2.2. Финансовая ценность выше среднего. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы.

Выводы

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

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

Приоритет проекта определяется на основе оценки трех показателей:

• Финансовая ценность.
• Стратегическая ценность.
• Уровень рисков.

Дополнительная литература и источники

1. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
2. С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.
3. Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.

Назад Содержание Вперёд