Компонентный подход в программировании

         

Метрики ПО


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

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

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

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

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

Самой простой и наиболее широко используемой метрикой является размер программы в строках ее кода (lines of code, LOC). Ее основное достоинство — понятность и простота вычисления. Ее недостатки — не очень хорошая адекватность в качестве метрики трудоемкости разработки программы, зависимость от используемых языков и технологий и трудность предварительной оценки размера ПО. Практика показывает, что качественная программа часто имеет несколько меньший объем, чем программа с теми же функциями, но менее удобная для сопровождения или совершающая больше ошибок. В то же время, на разработку первой программы может уйти в два-три раза больше усилий.

С другой стороны, производительность разных разработчиков очень сильно отличается, но обычно руководители групп и организаций примерно представляют себе среднее значение по группе или организации. В терминах строк кода она обычно лежит в пределах от 5000 до 50000 строк хорошо отлаженного кода без учета комментариев за 1 человеко-год.

Более хитрой метрикой сложности программы являются функциональные точки (functional points, FP) [4,5]. Количество функциональных точек в программной системе вычисляется примерно следующим образом.


увеличить изображение
Рис. 16.4.  Схема рассмотрения системы при оценке ее сложности в функциональных точках

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


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

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

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

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

Наиболее известным методом оценки трудоемкости и времени проекта, основанным на большом количестве данных из проведенных ранее проектов, является конструктивная модель стоимости версии II (Constructive Cost Model II, COCOMO II) [7,8,9].

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

На самых ранних этапах, когда примерно известны только общие требования, а проектирование еще не начиналось, используется модель состава приложения (Application Composition Model). В ее рамках трудоемкость проекта оценивается в человеко-месяцах по формуле

Effort = A*Size.



Size представляет собой оценку размера в терминах экранов, форм, отчетов, компонентов и модулей будущей системы. Каждый такой элемент оценивается с коэффициентом от 1 до 10 в зависимости от своей сложности.Коэффициент A учитывает возможное переиспользование части компонентов и производительность разработки, зависящую от опытности команды и используемых инструментов и оцениваемую числом от 4 до 50. A = (100 – (процент переиспользования))/производительность.На следующих этапах, когда требования уже в основном известны и начинается разработка архитектуры ПО, используется модель этапа предварительного проектирования (Early Design Model) и следующие формулы.

Для трудоемкости (в человеко-месяцах):

Effort = A*(Size)B*ME + (трудозатраты на автоматически генерируемый код)

Для времени (в месяцах):

Time = T*EffortS (0.28+0.2*(B-1.01))*Sced.

Коэффициент A считается равным 2,45, а T считается равным 3,67.Size — оценка размера ПО в тысячах строк кода.B — фактор процесса разработки, который вычисляется по формуле

B = 0,91 + 0,01*
 i=1..5Wi,

где факторы Wi принимают значения от 0 до 5:

W1 — предсказуемость проекта для данной организации, от полностью знакомого (0) до совсем непредсказуемого (5);W2 — гибкость процесса разработки, от полностью определяемого командой при выполнении общих целей проекта (0) до полностью фиксированного и строгого (5);W3 — степень удаления рисков, от полной (0) до небольшой (5), оставляющей около 80% рисков;W4 — сплоченность команды проекта, от безукоризненного взаимодействия (0) до больших трудностей при взаимодействии (5);W5 — зрелость процессов в организации, от 0 до 5 в виде взвешенного количества положительных ответов на вопросы о поддержке ключевых областей процесса в модели CMM (лекция 2).ME — произведение семи коэффициентов затрат, каждый из которых лежит в интервале от 1 до 6:

возможности персонала;надежность и сложность продукта;требуемый уровень повторного использования;сложность платформы;опытность персонала;использование инструментов;плотность графика проекта.EffortS обозначает оценку трудоемкости без учета плотности графика, а Sced — требуемое сжатие времени выполнения проекта.После того, как разработана архитектура ПО, оценки должны выполняться с использованием постархитектурной модели (Post-Architecture Model).



Формула для трудоемкости (в человеко-месяцах):

Effort= A*(Kreq*Size)B*MP + (трудозатраты на автоматически генерируемый код)

Для времени — та же формула, что и в предыдущей модели (в месяцах):

Time = T*EffortS(0.28+0.2*(B-1.01))*Sced.

Size = (размер нового кода в тыс. строк) + RSize, где



RSize = (размер переиспользуемого кода в тыс. строк) * (100 – AT)/100 * (AA + 0,4*DM + 0,3*CM + 0,3*IM + SU)/100

AT — процент автоматически генерируемого кода;AA — фактор трудоемкости перевода компонентов в повторно используемые, от 0 до 8;DM — процент модифицируемых для переиспользования проектных моделей;CM — процент модифицируемого для переиспользования кода;IM — процент затрат на интеграцию и тестирование повторно используемых компонентов;SU — фактор понятности переиспользуемого кода, от 10 для простого, хорошо структурированного, до 50 для сложного и непонятного; равен 0, если CM = DM = 0.Все коэффициенты, кроме Kreq и MP, имеют те же значения, что и в предыдущей модели.Коэффициент Kreq вычисляется как (1 + (процент кода, выброшенного из-за изменений в требованиях)/100).Коэффициент MP является произведением 17 коэффициентов затрат, имеющих значения от 1 до 6:

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

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


Окружение проекта


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



Организационная культура


При выборе той или иной стратегии действий менеджер проекта должен учитывать и организационную культуру организации-исполнителя и других связанных с проектом организаций. Организационной или корпоративной культурой называют совокупность общих убеждений, норм, ценностей и принятых стилей поведения служащих данной организации. Выделяют следующие виды организационной культуры [2,3].

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

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

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

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

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

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

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

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




Специфика управления персоналом


В силу того, что на поведение человека оказывают влияние многочисленные факторы, включая психологические и социальные, люди, работающие в проекте, не могут рассматриваться как обычные ресурсы. Люди склонны по-своему оценивать всю информацию, ставшую им доступной разными путями, преломлять ее через призму своего личного, уникального опыта и характера, и поступать, на первый взгляд, нерационально. Человеку чаще всего недостаточно слов "Вот задача, вот зарплата, — давай, работай!", чтобы начать делать то, что от него хотел бы руководитель проекта.

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

Производительность.

Одной из наиболее специфических черт управления персоналом при разработке ПО являются особенности производительности людей. Разработка программ остается в большой степени творческой деятельностью, требует зачастую весьма специальных знаний и умений, глубокого понимания вопросов организации информации и аккуратного планирования работы, поэтому нельзя ожидать от людей, участвующих в ней, каких-то средних показателей производительности. Опыт и многочисленные эксперименты [10,11] показывают, что производительность отдельных разработчиков в терминах объема и качества создаваемых ими программ за единицу времени может различаться до 10 раз, и этот разрыв можно наблюдать и в рамках одной организации, и в одной команде.

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

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

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

Соответственно, планирование хода проекта с надеждой на эту максимальную производительность с самой даты прихода разработчика в проект является самообманом. Замена одного из участников проекта на нового стоит значительно больше, чем разность их зарплат, а добавляя новых работников в проект, который отстает от графика, чаще всего вы только увеличите его отставание [10].




Рис. 16.9.  Производительность новых сотрудников в проекте

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

Знания и умения.

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

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

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


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

Мотивация персонала.

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

Считается, что потребности человека, определяющие основные цели его действий, образуют иерархию — пирамиду Маслоу (Maslow) [12], рис. 16.10.


Рис. 16.10.  Иерархия человеческих потребностей

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

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

Существует довольно много других подходов к мотивации.

Деление людей на 3 типа [6]:

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



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

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

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

Теория справедливости объясняет, почему так называемые "безбилетники" (free riders) — члены группы, менее интенсивно работающие по сравнению с остальными ее участниками, пользуясь высокими показателями производительности группы в целом, — оказывают пагубное воздействие на мотивацию коллектива в целом.

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

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



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

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

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



Развитие потенциала подчиненных можно осуществлять на основе модели ситуационного лидерства [13,14], основные положения которой состоят в следующем:

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




Рис. 16.11.  Развитие подчиненного в координатах способности и желания

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

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

Построение сплоченной команды.

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

Настоящую сплоченную команду нельзя сделать, сконструировать, — ее построение правильнее называть выращиванием. Как в педагогике или сельском хозяйстве, можно только посадить семена, создать благоприятные факторы и ждать, появится или нет нужный урожай. Факторы, которые способствуют созданию сплоченной команды, таковы [11].

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


Сплочению способствует поддержка общения между членами группы, не обязательно относящегося к работе, но связанного с выполнением общей деятельности. Обычно в качестве стимулов к этому используют совместные поездки, совместные обеды и торжества, совместный отдых. Нужно поддерживать и общение на рабочие темы — совместные обсуждения целей проекта, основных работ, способов решения возникающих задач, проводить "мозговые штурмы". В частности, члены команды не должны сидеть в удаленных помещениях, тем более — в разных городах. Для обсуждения общих вопросов должно быть выделено специальное помещение.Высокие стандарты качества. Группа должна быть объединена общим стремлением сделать результаты проекта лучше. Это придает команде некоторый оттенок элитарности, который сближает ее членов.Открытый стиль руководства. Доверие к членам группы, поощрение инициативы, самостоятельности и самоорганизации, поощрение поведения, нацеленного на сотрудничество. Член сплоченной группы сам всегда готов оказать помощь коллеге и не постесняется попросить помощь у других. Он доверяет своим товарищам и знает, что они также полагаются на него.Надлежащее техническое обеспечение работы команды и управление. Организация удобной для работы среды. Сотрудники команды должны видеть, что руководитель действительно заботится о том, чтобы им было удобнее работать вместе, чтобы они могли работать над проектом по существу, а не терять время на бюрократические и организационные вопросы.Поощрение индивидуальности и личностного отношения к работе, создание возможностей для самовыражения. Используя все грани своей личности, человек может внести наибольший вклад в общую работу.

Есть и набор факторов, которые наоборот, препятствуют сплочению команды.

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


Команда обычно готова поработать немного больше, когда близкий к завершению проект чуть-чуть не попадает в нужный срок. Но использование свыше 2 часов сверхурочных работ в день и более недели в месяц очень плохо сказывается на качестве результатов, на работоспособности и на мотивации людей.Защитный стиль руководства, при котором руководитель пытается контролировать результаты всех подчиненных, не доверяет им полностью. Лишение подчиненных возможности самим принимать решения в рамках их работы и проявлять самостоятельность губит инициативу. Насаждение конкуренции между членами одной команды порождает недоверие и разрушает сплоченность.Стандартизация и бюрократия. Неудобная для работы обстановка — шумные, тесные офисы, труднодоступность мест для проведения обсуждений, географическое разделение команды, размещение в далеких друг от друга помещениях или даже в разных городах — делает совместную работу слишком трудной, чтобы она могла приносить удовольствие.

Конфликты.

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

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

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


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

Выделяют пять основных методов поведения при конфликтах.

Уклонение. Стремление избежать конфликтной ситуации, замалчивать и игнорировать в максимальной степени.

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

Уклонение не разрешает конфликт. Чаще всего, при этом конфликт только усиливается и может проявиться вновь в более серьезной форме.

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

Такой метод применяется для сохранения хороших отношений, при необходимости избежать конфронтации для достижения общих целей.

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

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

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

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

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

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

Компромисс разрешает конфликт на среднее или долгое время.

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

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



Этот метод обеспечивает долговременное или полное разрешение конфликта.



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

Лидерство и влияние.

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

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

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

Влияние руководителя поддерживается и укрепляется за счет нескольких факторов.

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


Структура организации–исполнителя проекта


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

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

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

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

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

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


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

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

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

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

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

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

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




Управление коммуникациями и информационным обеспечением


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

Представительские связи.

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

Координация работ.

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

Обмен информацией внутри организации-исполнителя.

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

Разведка и сбор внешней информации.

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

Отдельными важными деятельностями в управлении коммуникациями являются составление предложений по проведению проектов и ведение переговоров.

Составление предложений.

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

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

Бюджет и финансовый цикл. Имеет ли возможный заказчик свободные средства для формирования бюджета проекта, и может ли он их получить в ближайшее время? Если нет, вряд ли стоит тратить время на разработку предложения именно сейчас, хотя терять связь с таким клиентом не надо.

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

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

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

Предложение обычно включает следующие разделы.

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

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

В ходе подготовки к переговорам нужно выполнить ряд действий.

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

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

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

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

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

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

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

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


увеличить изображение
Рис. 16.12.  Выбор стратегии проведения переговоров

Уступки. Это одностороннее изменение своей позиции в сторону увеличения ее выгодности для противоположной стороны.

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

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

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

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

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

Компромисс. Эта стратегия предполагает взаимные уступки сторон, которые, однако, могут не привести к выгодному для обеих решению.

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

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

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

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

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


Управление ресурсами


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

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

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

Уточнить имеющуюся структуру работ проекта для того, чтобы использовать ее в рамках выбранного процесса разработки. Например, структура работ может соответствовать набору функций, которые должны иметься в результирующем продукте. Использование процесса XP может потребовать составить план поставок не в соответствии с наборами поставляемых функций, а в соответствии с понедельным планом поставок. В этом случае тяжело предвидеть наборы функций, которые будет иметь очередная поставляемая версия продукта, но можно спланировать еженедельные поставки, их обкатку у пользователей, анализ результатов и доработки по его итогам.Установить зависимости между отдельными работами, присутствующими в уточненной структуре работ проекта. Зависимости могут иметь разный характер: "финиш-старт" (работа может быть начата только после конца другой), "старт-старт" (работа может быть начата только с началом другой), "старт-финиш" и "финиш-финиш". Если вы встречаете более сложную зависимость типа "работу можно начать, только если сделана некоторая часть другой", это признак того, что работы декомпозированы недостаточно детально и нужно разбить вторую работу на части.

Вставив фиктивные работы, не требующие ресурсов и времени, можно все зависимости привести к виду "финиш-старт".


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

Оценив время выполнения и трудоемкость каждой из работ, можно построить сетевую диаграмму проекта, пример которой приведен на рис. 16.5.
Расшифровка названий работ, их трудоемкости и время выполнения приведены ниже, в табл. 16.1.

Таблица 16.1. Работы проекта, сетевая диаграмма которого показана на рис. 16.5КодНазваниеТрудоемкость, ч*месВремя, мес
T1Формулировка целей и содержания проекта0,60,3
T2Сбор и анализ требований3,01,0
T3Разработка архитектуры6,02,0
T4Первичное планирование0,60,3
T5Разработка маркетинговых документов0,30,3
T6Реализация прототипа3,01,0
T7Детальное проектирование6,02,0
T8Испытания прототипа0,60,3
T9Анализ результатов испытаний и изменения проекта1,00,3
T10Детальное планирование1,00,3
T11Разработка и отладка пользовательского интерфейса3,01,0
T12Разработка пользовательской документации2,01,0
T13Реализация8,02,0
T14Тестирование4,01,0
T15Доработка по результатам тестирования4,01,0
T16Развертывание1,50,5
T17Обучение пользователей2,00,5
Если связи между работами в сетевой диаграмме превратить в вершины, а вершины-работы в связи (и добавить две новых вершины — начало и конец проекта), то получится так называемая PERT-диаграмма (PERT — program evaluation and review technique, техника оценки и обзора программ). PERT-диаграмма, соответствующая приведенной ранее сетевой, показана на Рис. 87. Часто различий между этими двумя видами диаграмм не делают, называя обе и сетевыми, и PERT-диаграммами.


увеличить изображение
Рис. 16.6.  PERT-диаграмма для рассматриваемого примера проекта

Сетевые и PERT-диаграммы используются для планирования продолжительности проекта и выделения критических путей — последовательностей работ от начала до конца проекта, сумма длительностей которых максимальна среди таких последовательностей. В примере, представленном на рис. 16.6, критических путей несколько — работы, лежащие на них, изображены жирными стрелками. Выполнить проект быстрее, чем за время, требующееся для прохождения по критическому пути, нельзя. Поэтому критические пути используют для планирования основных поставок в ходе проекта.


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

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


увеличить изображение
Рис. 16.7.  Диаграмма Ганта для рассматриваемого примера проекта

Расписание работ удобно изображать с помощью диаграмм Ганта (Gantt chart). Эта диаграмма показывает и связи между работами, и их длительность во времени. Диаграмма Ганта для рассмотренного примера показана на рис. 16.7.

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

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

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


увеличить изображение
Рис. 16.8.  График рассматриваемого проекта, построенный с учетом доступных ресурсов

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


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

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

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

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


Управление рисками


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

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

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

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

Риски проекта, влияющие на его ход.

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

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

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

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

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

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

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



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

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

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

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


Управление содержанием проекта и качеством


Управление содержанием проекта (project scope) является одним из критически важных для его успеха видов деятельности. Проект с нечетко определенным содержанием обречен на неудачу. Ясное же его определение — как постановка правильного вопроса — дает половину успешного ответа.

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

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

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

Основные элементы содержания проекта следующие.

Целевые критерии проекта.

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

Иерархическая структура работ (work breakdown structure).

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


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



Виды деятельности, входящие в управление проектом


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

Управление содержанием проекта и качеством.

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

Управление ресурсами проекта.

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

Управление рисками.

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

Управление коммуникациями и информационное обеспечение проекта.

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


Управление конфигурациями и изменениями.

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

Управление проектной средой и технологиями.

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

Контроль и мониторинг состояния проекта.

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



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

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


Задачи управления проектами


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

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

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

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

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

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


На уровне нескольких зависящих друг от друга проектов (такую группу проектов называют программой), в ходе которых создаются и дорабатываются несколько продуктов на единой платформе, а также могут оказываться различные услуги, связанные с этими продуктами, ценности связаны, прежде всего, с качеством общей архитектуры создаваемых продуктов.
В одном проекте работа иногда ведется по принципу "сдали и забыли", т.е. основные усилия направлены на то, чтобы заказчик подписал акт приемки работ или его аналог, после чего поставщик перестает отвечать за результаты, поэтому часто такой аспект качества ПО, как удобство внесения изменений, игнорируется. Однако для бизнеса организации в целом проведение таких проектов небезопасно. Среди исследователей и экспертов-практиков преобладает взгляд на любую программную систему как на систему развивающуюся, полезность которой значительно снижается, если нет возможности расширять ее, тем более — исправлять серьезные ошибки, которые всегда есть в сложных программах. Заказчик всегда сталкивается с проблемами поддержки ПО и рано или поздно столкнется и с необходимостью его развития. На уровне группы проектов игнорирование удобства модификации ПО, а также вопросов, связанных с организационными и экономическими последствиями из менений в общей архитектуре, просто губительно.
На уровне организации в целом или подразделения, в рамках которого может одновременно проводиться много проектов, связанных по предметной области, используемым технологиям и просто по вовлеченным в них людям, возникают другие ценности. Это может быть отлаженность производственных процессов, высокая технологическая экспертиза и технологическое лидерство в своей области, низкая текучка кадров, повышение оборота, прибыли, капитализации, доли продаж в рамках отрасли, занимаемого среди поставщиков такой же продукции места по экономическим и технологическим показателям.
Поскольку каждый проект проводится в рамках какой-то организации, то принятая в ней система ценностей влияет и на оценку каждого конкретного проекта (см.


далее).
Основные виды ресурсов, используемых в любом проекте, следующие.
Время.
Этот ресурс всегда жестко ограничен. Продолжительность проекта фиксирована, это одно из главных отличий проектов от обычной операционной деятельности, которой нужно заниматься неопределенное время. Чаще всего эти ограничения определяются интересами заказчика, выраженными в контракте, или решением руководства, основанном на анализе рынка и информации о действиях конкурентов.
Более того, даже при попытке создать "вялотекущий" проект без четкой установки его временных рамок (иногда при помощи такого приема руководство организации пытается выполнить нужные внутренние работы, не выделяя на них достаточных ресурсов), руководитель проекта должен настаивать на их определении. Иначе проекта как такового просто не получится — эффективное использование времени играет очень важную роль в успешности достижения необходимых результатов.
Бюджет.
Бюджет проекта тоже всегда ограничен — деньги, как известно, лишними не бывают. Деньги часто рассматриваются как практически универсальный эквивалент других ресурсов: за счет вложения дополнительных денег пытаются выиграть во времени, привлечь дополнительный персонал и пр. Однако полностью в деньги можно перевести только используемое оборудование и материалы, да и то с некоторыми потерями во времени на их приобретение и подготовку к работе.
Вместе со временем бюджет задает основные ограничения на содержание и возможные результаты проекта.
Персонал.
Персонал иногда рассматривается как возобновляемый ресурс, имеющий денежный эквивалент ("наймем проектировщика за 1500 у.е. в месяц"). Однако чаще всего люди ведут себя не совсем так, как оборудование или мебель, — они не позволяют себя "передвигать", "убирать" и "добавлять" с такой же легкостью. Имея определенный персонал, нельзя получить нужный результат с помощью заранее известной последовательности действий. Даже для получения одних и тех же результатов от одного и того же человека в разных обстоятельствах требуется применять различные подходы.


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

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


А если эти блоки еще и стоят кое-как, то при попытке передвинуть их программиста вообще может "завалить" — отладка полученной программы потребует колоссальных усилий.
Движение к нужному результату при разработке ПО очень тяжело проконтролировать. При возведении здания или постройке корабля можно непосредственно наблюдать за тем, как продвигается работа. При создании сложной программной системы силами многих разработчиков нужно аккуратно подбирать индикаторы того, как идут дела, иначе легко впасть в заблуждение относительно истинного положения вещей.Программные системы практически всегда уникальны.
Каждая из них обладает своим набором характеристик (включая все реализуемые функции, производительность при их выполнении, все элементы пользовательского интерфейса и т.п), так или иначе отличающихся от характеристик других программ, даже делающих "то же самое". Если обладающая нужными свойствами (в том числе и подходящей ценой) программа уже имеется, незачем создавать ее заново — достаточно приобрести ее или взять ее код и скомпилировать. Поэтому практически каждая разрабатываемая программа уникальна — она должна иметь такие характеристики, которыми не обладает ни одна уже созданная.
Тем самым, почти каждый проект по разработке ПО включает элементы творчества, создания того, чего еще никто не делал. Крупные же проекты требуют решения сразу нескольких ранее не решенных задач. Управление проектами с элементами творческой деятельности очень сильно отличается от управления проектами, в которых заранее ясно, что именно надо делать и как.Другое следствие этой уникальности ПО — отсутствие стандартных процессов разработки. Нет целостных подходов к созданию ПО, которые годились бы для всех случаев, а не только для определенного вида проектов. Кроме того, для хорошо определенных процессов, таких как RUP, XP, Microsoft Solution Framework или DSDM (Dynamic Systems Development Method, Метод разработки динамичных систем), недостаточно четко очерчены области их применимости.


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


Заинтересованные в проекте лица


Ход проекта также существенно зависит от намерений, действий, информирования и поддержки нужд его участников или заинтересованных лиц (stakeholders) — всех лиц и организаций, имеющих связанные с проектом интересы, или тех, на ком результаты проекта как-то отразятся. Заинтересованные в проекте лица могут играть в нем следующие роли.

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

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

Лидер проекта. Это наиболее авторитетный человек в команде проекта, к чьему мнению прислушиваются, кто принимает большинство технических решений по ходу проекта. Часто лидер и менеджер проекта — одно лицо.Заказчик. Это лицо или организация, которые получают результаты проекта в собственность того или иного вида.Пользователи. Это лица и организации, непосредственно использующие результаты проекта в своей деятельности.Организация-исполнитель. Это организация, в которой проводится проект и которая несет ответственность перед заказчиком за его выполнение. Такая организация может быть создана для проведения одного конкретного проекта и состоять только из его команды.Команда проекта. Это служащие организации-исполнителя, выполняющие работы по проекту. Менеджер проекта и лидер проекта входят в команду.Команда управления проектом. Это часть команды проекта, непосредственно участвующая в деятельности по управлению проектом.
Сюда входят менеджер проекта и его лидер, может входить секретарь менеджера, эксперты, помогающие в принятии решений и т.д.


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

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

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

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

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