«Лекции по управлению программными проектами 2009 Содержание Стоимость Время МОСКВА 2009 МОСКВА С. Архипенков Лекции по управлению программными проектами Москва 2009 1 Содержание Отзыв на книгу Об авторе Благодарности ...»

Barry Boehm. «Software engineering economics». Englewood Cliffs, Barry Boehm, et al. «Software cost estimation with COCOMO II». Englewood Cliffs, NJ:Prentice-Hall, 2000.

«Function Point Programming Languages Table», Quantitative Software Management, Inc., 2005.

Лекция 7. Формирование команды Лидерство и управление Свое представление о вопросах, связанных с формированием и руководством командами разработчиков ПО, я подробно изложил в книге [1]. В этой лекции остановимся только на ключевых моментах этой деятельности.

В работе руководителя проекта есть две стороны: управление и лидерство, которые одинаково важны и не могут существовать в отрыве друг от друга.

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

Интеллектуальными людьми невозможно управлять. Творческие команды можно только направлять и вести. «Высокопроизводительное управление в отсутствие эффективного лидерства подобно упорядочению расстановки стульев на палубе тонущего «Титаника». Никакой успех в управлении не компенсирует провала в лидерстве» [2].

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

Лидерство, это в первую очередь, это умение управлять своей собственной жизнью и только потом другими людьми. Сверхвысокое значение коэффициента интеллекта IQ, к сожалению, в этом не поможет. Личная эффективность человека на 80% определяется его коэффициентом эмоционального интеллекта EQ (Emotional Intelligence) [3] – способностью понимать и эффективно взаимодействовать с другими людьми. Хорошая новость. В отличие от IQ, который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни. Если, конечно, прилагать к этому усилия.

Лидер должен получить признание команды. Для того этого необходимо:

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

Если руководитель не смог стать лидером, он будет вынужден применять в своей практике управленческие антипаттерны [1]. Для такого руководителя характерны чрезмерная настороженность, скрытность, неспособность делегировать полномочия. Он исходит из предпосылок индустриальной эпохи Генри Форда: «Работники ленивы, поэтому им необходимы внешние стимулы для работы. У людей нет честолюбия, и они стараются избавиться от ответственности. Чтобы заставить людей трудиться, необходимо использовать принуждение, контроль и угрозу наказания». Манфред Кетс де Врис [3] называет данное отклонение «параноидальным управлением».

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

Эффективный лидер обязан обладать следующими компетенциями:

Видение целей и стратегии их достижения.

Глубокий анализ проблем и поиск новых возможностей Нацеленность на успех, стремление получить наилучшие результаты.

Способность сочувствия, понимания состояния участников команды.

Искренность и открытость в общении.

Навыки в разрешении конфликтов.

Терпимость, умение принимать людей какие они есть, принятие их права на собственное мнение и на ошибку.

Умение мотивировать правильное профессиональное поведение Стремление выявлять и реализовывать индивидуальные возможности для профессионального роста каждого.

Способность активно "обеспечивать", "доставать", "выбивать" и т.д.

Не существует одной лучшей стратегии руководства. В зависимости от готовности участников рабочей группы выполнять задания руководителя, он должен использовать одну из 4-х стратегий [4]:

«Директивное управление». Руководитель говорит, указывает, направляет, устанавливает. Жесткое назначение работ, строгий контроль сроков и результатов.

«Объяснения». Лидер "продает", объясняет, проясняет, убеждает.

Сочетание директивного и коллективного управления. Объяснение «Участие». Лидер участвует, поощряет, сотрудничает, проявляет преданность. Приоритетное коллективное принятие решений, обмен идеями, поддержка инициативы подчиненных.

«Делегирование». Лидер делегирует, наблюдает, обслуживает. «Не мешать» - пассивное управление сформировавшегося лидера.

Применение этих стратегий можно проиллюстрировать на примерах (Рисунок 41).

Вас назначили руководителем в новый коллектив. Вы еще не получили признания, а дело делать надо. Стратегия: «Директивное управление».

Вы были участником команды. Вас назначили руководителем этой команды. Доверие есть, а уверенности в правильности ваших действий нет. Стратегия: «Объяснения».

Вас назначили руководителем в новый коллектив. Все знают о ваших прежних сложных и успешных проектах. Все признают ваше превосходство, но доверия к вам нет. Никто не знает, какой ценой были достигнуты ваши победы. Стратегия: «Участие».

Между вами и участниками установлено взаимное доверие. Все достаточно мотивированы на успех проекта. Каждый сам себе может быть руководителем. Стратегия: «Делегирование».

Рисунок 41. Ситуационное лидерство.

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

Обеспечить эффективность каждого участника рабочей группы.

Обеспечить эффективные процессы взаимодействия.

Правильные люди Рональд Рейган говорил: «Окружите себя самыми лучшими людьми, которых вы только сможете найти, передайте им в руки власть и не мешайте им».

За годы работы у меня сформировалось собственное видение правильного командного поведения. Эффективный командный игрок:

ответственность и увеличить личный вклад в общее дело.

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

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

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

Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как профессионализм в своих глазах и во мнении коллег.

Вместе с тем, встречаются патологии поведения, которые, на мой взгляд, неприемлемы в команде:

справедливости, способность на низкие поступки.

Синдром острого дефицита эмпатии. Эгоцентризм. Неуважение и невнимание к партнерам. Склонность к отрицательным оценкам других.

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

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

«Произвольничать, поступать самовольно, в обиду другим, нагло, дерзко» (с) В.Даль. Не путать со «свободой»!

«Социальный паразитизм». Стремление прожить вольготно за чужой счет там, где ответственность размыта, а личный вклад трудно четко Моя рекомендация: лечить патологию «хирургически» – избавляться от проблемных людей. Воспитывают в детском саду, ну еще немного в начальной школе. Дальше люди воспитываются только самостоятельно, а окружающие могут лишь помогать или не мешать в этом процессе. Убежден, что каждый взрослый человек имеет то, к чему он осознанно или неосознанно стремится.

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

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

Обучать. Если сотрудник не умеет, задача руководителя – «обучать», Помогать. Если у сотрудника не может выполнить работу, задача руководителя – «помогать», обеспечить исполнителя всем Вдохновлять. Если у сотрудника не достаточно желание выполнить работу, задача руководителя – «вдохновить», обеспечить адекватную мотивацию участника на протяжении всего проекта.

Мотивация Известно, что ни одна задача не будет решена за любое, отведенное на это время, если человек не захочет ее сделать. Он всегда найдет для оправдания этого 100 «объективных» причин, вместо того, чтобы найти хотя бы один способ решения задачи. У каждого участника рабочей группы должна быть личная цель (внутренняя мотивация), которую он сможет достичь, продвигая проект к Начните с себя! Вам нужно четко понимать, в чем состоит ваш выигрыш в случае успешного завершения проекта. Добиться от участников приверженности проекту больше, чем имеете вы сами, вам не удастся. Если у участника нет такой значимой личной цели, избавьтесь от него. Иначе вам придется потратить все свое время на «промывание его мозгов» и попытки мотивировать его на эффективную работу.

Мотивация должна начинаться с подбора сотрудников в команду. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям.

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

Все люди разные, а ситуаций, в которых они могут находиться в ходе проекта, бесчисленное множество. Бойтесь стереотипов. Если вы не учитываете индивидуальные особенности конкретной личности, то эффективность ваших взаимодействий сильно снижается. Модель объекта управления нам неизвестна, следовательно, не может существовать исчерпывающий набор правил, типа «если…, то…», по которым смог бы действовать руководитель.

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

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

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

Затем руководитель должен наблюдать за результатами своего воздействия – это и есть дополнительный контур обратной связи. Необходимо помнить, что понять человека можно, только слушая и слыша, что он говорит. Руководитель, который в течение недели не пообщался индивидуально с каждым из своих прямых подчиненных, зря получает зарплату. И совсем не обязательно разговор должен идти о статусе проектных работ. Порой, достаточно поговорить о погоде, кино или футболе. После этого руководитель анализирует полученные результаты и аккумулирует новый опыт (положительный или отрицательный) в своей «базе знаний».

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

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

Программист состоит из четырех компонентов: тело, сердце, разум и душа.

Телу необходимы деньги и безопасность.

Сердцу - любовь и признание.

Разуму – развитие и самосовершенствование.

Душе – самореализация.

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

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

В программной инженерии многие уже признали, что наиболее эффективные производственные процессы складываются в самоуправляемых и самоорганизующихся рабочих командах. Идеи командного менеджмента на Западе зародилась в начале 80-х годов. Эффективность команд в новых экономических условиях одними из первых оценили такие гиганты, как Procter & Gamble и Boeing [5]. Доктрина командного менеджмента предполагает ясность общих ценностей и целей, самоорганизацию и самоуправление совместной деятельностью, взаимный контроль, взаимопомощь и взаимозаменяемость, коллективную ответственность за результаты труда, всемерное развитие и использование индивидуального и группового потенциалов.

Если на Западе идеи командного менеджмента только зарождаются, то для России они имеют давние традиции. С XIII века в России существовали производственные артели - различные формы добровольных объединений людей с целью осуществления общей хозяйственной деятельности. Артель была добровольным товариществом совершенно равноправных работников, призванных на основе взаимопомощи и взаимовыручки решать практически любые хозяйственные и производственные задачи. Известный российский писатель и революционер, А.И. Герцен видел в коллективизме, в уникальности существующей сельской общины, в городской артели и в самобытной воинской организации казачества характерную черту жизни и психологии русского народа.

Позднее во времена СССР широкое распространение на производстве получили рабочие бригады, а в научно-исследовательских институтах временные научные творческие коллективы, которые объединялись на основе общности цели, взаимопомощи и коллективной ответственности за результат.

Истинный российский коллективизм (соборность) не имеет ничего общего с вульгарным коллективизмом: со стадностью, подавлением личности («я нет, есть только мы!», «я – последняя буква алфавита!»), уступчивостью, групповой психологией и слепым подчинением меньшинства большинству. Суть российского коллективизма в том, что человек ощущает себя элементом органичной системы, где он выполняет свою функцию, свою задачу, совершенно особенную, которую не выполняет никто другой и выполнить не может. Эту задачу он выполняет совершенно сознательно, стремясь к максимальной реализации своих целей.

Руководителю недостаточно стать лидером, надо еще суметь сплотить команду.

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

Forming. Формирование. Характеризуется избытком энтузиазма, связанного с новизной. Люди должны преодолеть внутренние противоречия, переболеть конфликтами прежде, чем сформируется действительно спаянный коллектив. На этом этапе многое зависит от руководителя. Он должен четко поставить цели членам команды, верно Storming. Разногласия и конфликты. Самый сложный и опасный период.

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

Norming. Становление. В команде растет доверие, люди начинают замечать в коллегах не только проблемные, но и сильные стороны.

Закрепляются и оттачиваются наиболее эффективные процессы взаимодействия. На смену битве амбиций приходит продуктивное сотрудничество. Четче становится разделение труда, исчезает дублирование функций. Руководитель перестает находиться в состоянии постоянного аврала, работа по построению команды на этом этапе – уже не тушение пожара, а скрупулезный труд по отработке Performing. Отдача. Команда работает эффективно, высок командный дух, люди хорошо знают друг друга и умеют использовать сильные стороны коллег. Все стремятся придерживаться выработанных общих процессов. Высок уровень доверия. Это лучший период для раскрытия индивидуальных талантов.

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

Если команда прошла все стадии формирования и вышла на фазу «Performing», не стоит полагать, что менеджер проекта может делегировать все свои полномочия и отправиться в отпуск. Задача менеджера на этом этапе - «точить пилу». Это значит поддерживать требуемый уровень мотивации, быть штурманом, искать новые пути и открывать новые возможности. Постоянно наблюдать и оценивать эффективность всех процессов, применяемых в проекте. Искать ответ на вопросы: «Что угрожает проекту?» «Что лишнее мы делаем?» «Что можно делать проще?» Работать на сокращение ненужных усилий вместо того, чтобы «стремиться к новым героическим подвигам».

Если руководитель не будет прилагать дополнительные усилия команда, рано или поздно, начнет «сползать» с плато наивысшей эффективности в состояние застоя и стагнации (Рисунок 42). Помните, что окружение и команда изменяются по ходу проекта. Прежняя мотивация ослабевает или перестает действовать. Изменяйте правила и процессы. Отказывайтесь от того, что перестало действовать или стало работать неэффективно. «Встряхивайте»

(Reforming) и возвращайте команду в стадию «Forming». Это позволит ей снова, пройдя через все этапы становления, выйти на новый более высокий уровень производительности. Разумеется, делать это следует, после сдачи очередного релиза программного продукта, ну и, возможно, в случае глубокого кризиса проекта.

Рисунок 42. Reforming. «Встряхивание» и перевод команды проекта на новый, более высокий, уровень производительности.

Выводы Эффективные команды не образуются сами по себе, они кристаллизуются вокруг признанного лидера. Для того чтобы стать лидером, необходимо:

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

Мотивация должна начинаться с подбора сотрудников в команду. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям.

Рабочая группа прежде, чем она станет эффективной командой, должна пройти четыре обязательных последовательных стадии: 1) Forming, 2) Storming, 3) Norming, 4) Performing.

Если руководитель не будет прилагать дополнительные усилия команда, рано или поздно, начнет «сползать» с плато наивысшей эффективности в состояние застоя и стагнации. Задача менеджера на этом этапе - «точить пилу»:

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

Дополнительная литература и источники С. Архипенков, "Руководство командой разработчиков программного обеспечения. Прикладные мысли", 2008 (http://www.happypm.com/sw_team_management.pdf).

Стивен Р. Кови, «7 навыков высокоэффективных людей. Мощные инструменты развития личности», 2-е изд., М., Альпина Бизнес Букс, Манфред Кетс де Врис, «Мистика лидерства. Развитие эмоционального интеллекта», М., Альпина Бизнес Букс, 2005.

Hersey P., Blanchard K.H. “Management of Organizational Behavior”, 6th ed., Englewood Cliffs: Prentice-Hall, 1993.

Л. Томпсон, «Создание команды», М., Вершина, 2005.

Лекция 8. Реализация проекта Рабочее планирование Управление - это расчленение, анализ, определение последовательности действий, конкретная реализация. Управление фокусируется на нижнем уровне:

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

Базовое расписание, составленное на этапе планирования проекта, служит ориентиром для мониторинга состояния дел на макроуровне. Для оперативного управления проектом используется рабочий план. Рабочее планирование рекомендуется выполнять методом «набегающей волны»: работа, которую надо будет выполнить в ближайшей перспективе, подробно планируется на низшем уровне ИСР, а далеко отстоящая работа планируется на сравнительно высоком Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист. Трудоемкость элементарной работы каждого из исполнителей должна быть от 4 до чел.*час. Если трудоемкость задачи не укладывается в эти пределы, следует провести декомпозицию работы.

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

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

Уточнение приоритетов задач на новую неделю.

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

Рекомендация - использовать правило «50/100». Если работа по задаче начата, то следует учитывать ее, как выполненную на 50%. А 100% поучает только протестированная и документированная работа.

Принципы количественного управления «Тем, что нельзя измерить, нельзя управлять». Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1-2 недели. Для каждого измеримого показателя должны быть определены его плановые значения. Для каждого планового значения должны быть определены три области критичности отклонений:

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

Измерения необходимо производить регулярно. Цель – выявить причины наступивших или возможных критичных и недопустимых отклонений.

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

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

Поскольку главная задача менеджера удержать проект в пределах «железного»

треугольника, то, в первую очередь, необходимо анализировать отклонения проекта по срокам и затратам. Делается это при помощи метода освоенного объема [1]. Приходилось сталкиваться с мнением, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки. Но если ИСР проекта, ориентирована на инкрементальную разработку, то это означает, что на верхних уровнях декомпозиции находятся компоненты проектного продукта и их функционал, а не производственные процессы. Следовательно, если в проекте реализованы, протестированы и документированы 50 % функциональных требований, то есть все основания полагать, что осталась приблизительно половина проектных работ.

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

Сначала оценивается отклонение от графика SV (Shedule Variance) в денежных EV (Earned Value) - освоенный объем. Плановая стоимость выполненных работ.

Объем выполненных работ, выраженный в терминах одобренного бюджета, выделенного на эти работы для плановой операции и элемента иерархической структуры работ;

PV (Planned Value) - плановый объем. Плановая стоимость запланированных работ. Утвержденный бюджет, выделенный на плановые работы, выполняемые в рамках плановой операции или элемента иерархической структуры работ.

Например. Пусть мы на текущий момент реализовали (протестировали и документировали) 20 функциональных требований, на каждое из которых было запланировано затратить по 40 чел.*час. по 1000 руб, то освоенный объем будет Если же на текущий момент планировалось реализовать только 15 требований, то плановый объем будет Следовательно, мы опережаем график (отклонение от графика положительное) на величину Как пересчитывается отклонение от графика, выраженное в денежных единицах, в сокращение сроков проекта иллюстрируется на Рисунок 43.

Если мы опережаем график, то это не обязательно означает что проект идет успешно. Хорошо это или плохо зависит от значения другого показателя метода освоенного объема: CV (Cost Variance) - отклонения по затратам, которое оценивается по формуле:

где AC, (Actual Cost) - фактические затраты. Фактическая стоимость выполненных работ. Фактические затраты на выполнение работ за определенный период в рамках плановой операции или элемента иерархической структуры работ.

Например, если мы для того что сократить время работ по проекту работали 25% времени сверхурочно и в выходные дни с двойной оплатой, то фактические трудозатраты составили:

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

Рисунок 43. Оценка и прогноз показателей по методу освоенного объема Отклонение от бюджета и по срокам в абсолютных денежных единицах недостаточно для характеристики проектов разных масштабов. Более наглядны относительные показатели: индекс выполнения сроков SPI (Schedule Performance Index) и индекс выполнения стоимости CPI (Cost Performance Index) которые характеризуют проект независимо от его размера. Если значения обоих индексов больше 1, то это свидетельствуют о благополучном состоянии в проекте.

Какие еще измеримые показатели целесообразно применять в управлении программным проектом?

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

Другой показатель - стабильность проекта, общее количество принятых (утвержденных спонсором или заказчиком) изменений в плане управления проектом. Чем выше нестабильность в проекте, тем больше сложность в управлении работами и ниже производительность участников.

Если кто-то думает что код это решение проблемы, то это не так. Код это новый источник проблем. Поэтому всегда следует измерять текущий размер проекта количество строк исходного кода, добавленных, измененных и удаленных в ходе выполнения проекта разработки ПО. Чем больше объем исходного кода, тем больше времени потребуется на внесение изменений и исправление ошибок.

При увеличении объема проектного продукта трудозатраты на каждую новую строку исходного кода увеличиваются. Если за номинал взять производительность проектной команды при производстве продукта в KSLOC, то та же команда на проекте в 100 KSLOC покажет производительность в 1.3 – 1.7 раз меньшую, а на проекте в 1000 KSLOC следует ожидать, что производительность снизится в 1.6 – 3.0 раза [2].

Большой объем кода так же потребует большего количества людей на его сопровождение. Поскольку, даже если будет выявляться только несколько критических ошибок в год, то для того чтобы их исправить в приемлемые сроки, например, за 24 часа, в продукте общим объемом в 1000 KSLOC то один программист с этим не справится. Это связано с тем, что для того чтобы исправить ошибку в ограниченные сроки необходимо оперативно выявить и устранить ее причину, а для этого надо хорошо знать архитектуру и код программного продукта. Чтобы эффективно сопровождать продукт подобного объема необходимо иметь в «горячем» резерве примерно 20 разработчиков, потому что 50 KSLOC, на мой взгляд, это предельный объем кода, который может удерживать в голове и эффективно сопровождать один человек. И еще проблема: чем этих людей занимать в свободное от исправлений ошибок время, если нет новых проектов развития продукта.

Следующий важный показатель состояния проекта – это средняя производительность, отношение текущего размера проекта к фактическим затратам по проекту. С. Макконнелл [2] приводит следующие показатели (минимальное, максимальное и среднее значение) производительности в KSLOC на один чел.*мес. фактических затрат для стандартных типов проектов объемом в 100 KSLOC:

300-7000 (800) - интранет система.

200-7000 (600) - бизнес система.

100-2000 (300) - Интернет система.

50-600 (100) - системное ПО, телекоммуникации.

20-300 (50) - системы реального времени.

Высокая производительность в проекте – это далеко не всегда хороший признак. Приходилось встречаться с проектами, в которых вследствие активного применения метода «copy+past», средняя производительность в разработке бизнес системы достигала 2000 SLOC/чел.*мес. Однако для реализации требуемого функционала было написано в 3 – 4 раза больше кода, чем это могло бы потребоваться при адекватной проработке архитектуры.

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

Дефектность продукта – количество выявленных дефектов на единицу объема продукта (например, KSLOC).

Доля не устраненных дефектов - отношение количества незакрытых максимально критичных и критичных дефектов к количеству выявленных несоответствий.

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

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

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

Завершение проекта Главная цель этой фазы – проверить и передать заказчику результат проекта.

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

Результаты проекта должны быть переданы во внедрение или сопровождение, или должным образом законсервированы для дальнейшего использования. Не должно оставаться «зависших» работ по проекту. Все линейные руководители всех участников должны быть извещены о завершении работ по проекту, и освобождении сотрудников.

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

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

Помним о том, что «вчерашние проблемы, это сегодняшние риски».

Итоговый отчет должен содержать следующую информацию:

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

Выводы Для оперативного управления проектом используется рабочий план.

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

Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1-2 недели. Для каждого измеримого показателя должны быть определены его плановые значения и допустимые отклонения.

В состав измеряемых показателей должны входить следующие характеристики Освоенный и плановый объемы работ и фактические затраты по Показатели прогресса и стабильности проекта.

Показатели качества программного продукта.

По результатам проекта обязательно должна быть реализована обратная связь.

Цель – сохранить результаты, знания и опыт, полученные в проекте, для более эффективного и качественного выполнения аналогичных проектов в будущем.

Дополнительная литература и источники «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.

Том Демарко, Тимоти Листер, «Человеческий фактор: успешные Заключение. Растите профессионалов Работа менеджера проекта подобна труду садовника.

Подобно тому, как садовник любовно отбирает наиболее подходящие растения для своего будущего сада, менеджер набирает людей, наиболее соответствующих целям проекта.

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

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

«Что посеешь, то и пожнешь» - этот закон одинаково применим как к труду садовода, так и к труду менеджера проекта. Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложите в людей часть своей души, и вам воздастся сторицей.