ПОКАЗАТЕЛИ УПРАВЛЕНИЯ

ПОКАЗАТЕЛИ УПРАВЛЕНИЯ

Применяются три фундаментальных набора метрик управления: технический прогресс, финансовое состояние и прогресс в найме персонала. Изучая эти аспекты, управляющие проектом могут оценить, укладывается ли проект в бюджет и в сроки. Финансовое состояние — это то, что хорошо понятно всем; оно существовало всегда. Большинство менеджеров.
имеют информацию о расходовании ресурсов в терминах финансовых затрат и сроков. Проблема заключается в том, чтобы оценить величину технического прогресса. В традиционных проектах, промежуточными продуктами которых являлись исключительно бумаги, полагались на субъективные оценки или на количество завершенных документов. Эти материалы отражали затраты, но были не слишком показательны относительно полезности выполненной работы.
Показатели управления, рекомендуемые в настоящей работе, включают в себя стандартное финансовое состояние, которое основано на системе приобретенной стоимости, объективных параметрах технического прогресса, адаптированных к основным критериям измерения для каждой большой команды или организации, и параметры, касающиеся персонала, которые позволяют понять динамику внутри команд.
13.2.1 Работа и прогресс.
Различные виды деятельности при итерационной разработке проекта могут быть измерены посредством определения объема планируемой работы, выраженного в объективных единицах измерения, с дальнейшим отслеживанием прогресса (объем работы, выполненной к настоящему моменту) по отношению к плану (см. рис. 13.1). У каждой большой команды в организации должен существовать по крайней мере один аспект прогресса, относительно которого проводятся измерения. Для обычных команд (см. главу 11) стандартными аспектами могли бы быть:.
■ Команда, занимающаяся архитектурой ПО: продемонстрированные варианты использования.
■ Команда, занимающаяся разработкой ПО: количество SLOC, подпадающих под управление изменениями, количество закрытых SCO.
■ Команда, занимающаяся оценкой ПО: число открытых SCO, время (в часах) выполненного тестирования, соответствие критериям оценки.
■ Команда, занимающаяся управлением созданием ПО: число пройденных контрольных точек
13.2.2 Предусмотренные в бюджете расходы и затраты.
Для контроля над проектом требуется постоянно вычислять затраты на протяжении всего жизненного цикла. Использование метрик работы и прогресса может дать более объективную оценку технического прогресса для ее сравнения с финансовыми затратами. Для итерационного процесса разработки представляется важным детально планировать ближайшие действия (обычно для временного интервала менее шести месяцев) и составлять планы дальнейших действий в виде грубых оценок, которые должны уточняться по мере того, как истекает интервал времени текущей итерации и становится критичным планирование следующей итерации.
Отслеживание финансового прогресса обычно принимает форму, характерную для данной организации. Единственным общим подходом к измерению финансового состояния является применение системы приобретенной стоимости, которая позволяет детально определить затраты времени. Его недостатком при использовании для проектов по созданию ПО традиционно является невозможность объективной и точной оценки технического прогресса (процента завершенной работы). Это свойственно стадии разработки проекта. Тем не менее системы приобретенной стоимости доказали свою эффективность на стадии производства, для которой характерны правильное отслеживание реальных показателей по сравнению с планами и предсказуемые результаты. Другие метрики обеспечивают основу для получения подробных и реалистичных количественных данных по обратной связи для планирования и сверки, особенно на стадии производства, где финансовые и временные затраты являются наивысшими.
Современные процессы создания ПО легко поддаются измерению финансового состояния посредством подхода приобретенной стоимости. Основными параметрами системы приобретенной стоимости, обычно исчисляемой в долларах, являются следующие:.
■ План расходов: вид кривой планируемых для проекта затрат относительно планируемых сроков. Для большинства проектов по созданию ПО (и других трудоемких проектов) вид этой кривой повторяет вид кривой найма персонала.
■ Реальный прогресс: техническое выполнение относительно планируемого прогресса, который лежит в основе кривой финансовых затрат. В нормально развивающемся проекте реальный прогресс неотступно следует за планируемым прогрессом.
■ Реальная стоимость: кривая реальных затрат на проект для реального графика выполнения. В нормально развивающемся проекте эта кривая неотступно следует за планируемой кривой.
■ Приобретенная стоимость: определяется стоимостью реального прогресса.
■ Рассогласование затрат: разность между реальными затратами и приобретенной стоимостью. Положительные значения относятся к ситуациям, связанным с перерасходом бюджета; отрицательные значения соответствуют ситуациям, связанным с экономией бюджета.
■ Рассогласование сроков: разница между планируемыми затратами и приобретенной стоимостью. Положительные значения относятся к ситуациям, связанным с отставанием от графика; отрицательные значения соответствуют ситуациям, связанным с опережением графика.
На рис. 13.2 дается графическое представление этих параметров и приводится простой пример состояния проекта.
Основной целью других основных метрик является обеспечение команд по управлению и разработке более объективным подходом к оценке реального прогресса с наибольшей точностью. Из всех параметров системы приобретенной стоимости реальный прогресс является наиболее субъективной оценкой. Поскольку большинство менеджеров точно знают, сколько затрат они произвели и какая часть времени использована, то разногласия при выполнении точных оценок финансового благополучия касаются правильности оценки реального прогресса.
Для пояснения сильных и слабых сторон системы приобретенной стоимости рассмотрим процесс разработки этой книги, который во многих отношениях напоминает процесс разработки ПО. Реальный прогресс может быть оценен по текущему состоянию каждой главы, которое определяется относительно количества страниц, запланированных для данной главы. Я отслеживал состояние каждой части (являющейся связной последовательностью глав), используя следующие определения состояний и приобретенную стоимость (приобретенный процент завершенности):.
■ от 0 до 50%: содержимое не готово.
■ 50%: содержимое в черновом виде; автор завершил первую черновую версию текста и рисунков.
■ 65%: начальная версия текста; завершено предварительное редактирование текста.
■ 75%: версия, подлежащая рецензированию; завершено редактирование текста и рисунков.
■ 80%: обновленная версия; проверена взаимная согласованность глав.
■ 90%: рецензированная версия; автор включил в текст комментарии внешних рецензентов.
■ 100%: окончательная редакция; редактор завершил чистовую обработку текста.
Оценки «процента завершенности» выполнялись субъективно на базе моего опыта написания сложных документов. Я планировал работать в течение 10 месяцев и потратить $10 000 на вспомогательные мероприятия. В таблице 13.2 приведены мой прогресс и соответствующая приобретенная стоимость на четвертом месяце работы. Хотя уже было написано вчерне около 400 страниц из планировавшихся 425, я оценивал завершенность своего труда только в 60%, используя средневзвешенное значение.
Таблица 13.2.
Определение реального прогресса при разработке книги (пример)
Компонент
Страницы
%
Состояние
Часть 1
60
75%
Версия, подлежащая рецензированию
Насть II
75
75%
Версия, подлежащая рецензированию
Насть III
90
65%
Начальная версия текста
Часть IV
30
65%
Начальная версия текста
Часть V
130
50%
Черновик
Остальное (предисловие, глоссарий, индекс)
40
25%
Содержимое не готово
Если построить кривую зависимости планируемых затрат от времени, подобную изображенной на рис. 13.2, то можно будет оценить, нахожусь ли я в рамках бюджета и в рамках графика. На рис. 13.3 показаны мой план и оценка на четвертом месяце, когда я опережал свой график на 20% и потратил на 30% меньше запланированного бюджета.
Этот пример является хорошей отправной точкой для обсуждения ключевых атрибутов планирования и оценки реального прогресса: создания объективной основы, описания подходящей декомпозиции работ и планирования с надлежащим качеством.
Рис. 13.3. Оценка прогресса при написании книги (пример)
Я ввел объективные критерии для определения процента завершенности данного компонента. (Для другого автора такие критерии могут оказаться неоптимальными.) Они основаны на моем опыте, на моем собственном стиле разработки и на абсолютно понятных взаимоотношениях с техническим редактором. Аналогично, для проектов по созданию ПО культура команды, опыт команды и стиль разработки (процесс, его строгость и его зрелость) будут управлять выбором критериев, используемых для объективной оценки прогресса.
Я выполнил декомпозицию работы, разбив ее на части (группы глав), что является самым простым подходом к отслеживанию прогресса. Так же, как и для ПО, это было совершенно естественным при наличии хорошо разработанной архитектуры книги. Тем не менее мне пришлось несколько раз изменять архитектуру (схему и направление) в первые месяцы. Детальная компонентная проработка на ранних стадиях жизненного цикла написания книги привела бы к необходимости малопривлекательных переделок и отвлекла бы меня от улучшения архитектуры. Более пригодная для отслеживания прогресса проекта в целом декомпозиция работ (учитывающая вклад автора, редактора, художников, рецензентов, составителей и издателя) должна организовываться самим процессом, при этом прогресс в создании должен явно отслеживаться только для отдельных компонентов.
Я планировал работу с точностью, подходящей для проекта, выполняемого одним лицом. Я принял решение не заниматься подробным отслеживанием прогресса, пока не будет полностью написана черновая версия компонента. На ранних стадиях я отслеживал прогресс с помощью простой субъективной оценки степени завершенности начальных черновых материалов. В том же духе следует работать и с большими проектами, используя такой уровень точности планирования, который согласуется с те* кущим состоянием проекта и с вероятностью повторного планирования.
13.2.3 Динамика изменений в командах и штатном расписании.
Итерационная разработка должна сначала вестись небольшой командой до тех пор, пока все риски в требованиях и архитектуре не будут разрешены подходящим образом. В зависимости от наложения итераций и других характерных для данного проекта обстоятельств штатное расписание может меняться. Типичное для выполнения отдельных одноразовых задач по разработке (например, для построения корпоративной информационной системы) изменение численности задействованных в проекте сотрудников приведено на рис. 13.4. Разумно ожидать, что группа сопровождения для такого рода проектов окажется меньше группы разработки. При создании коммерческого продукта размеры групп поддержки и разработки могут оказаться одинаковыми. Когда долгоживущие, постоянно улучшаемые продукты подвергаются изменениям, сопровождение является всего лишь постоянным созданием новых улучшенных версий.
Отслеживание реального найма сотрудников по сравнению с планируемым является необходимым и хорошо понимаемым параметром управления. Существует еще один важный для управления показатель изменения движущей силы проекта — отношение увольняющихся и вновь принимаемых. Увеличение штата может замедлить общий прогресс проекта, поскольку давно работающим сотрудникам придется тратить производительное время на введение новых сотрудников в курс дела. Низкий процент ухода хороших сотрудников является признаком успеха. Сильной мотивацией для разработчиков является возможность привести что-либо в действие; это постоянная тема, лежащая в основе эффективного итерационного процесса разработки. Если такая мотивация отсутствует, хорошие разработчики уходят в другое место. Рост незапланированного увольнения людей — т.е. числа людей, преждевременно покидающих проект, — является одним из наиболее наглядных показателей того, что
Рис. 13.4. Типичное изменение численности сотрудников.
этот проект ожидают проблемы. Причины преждевременного увольнения могут быть различными, но обычно это неудовлетворенность персонала методами управления, отсутствие командной работы или высокая вероятность провала в процессе достижения поставленных целей.