Организационная система управления проектами

Подбор команды проекта

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

· от задач и целей проекта;

· от характера работы, которая должна быть сделана;

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

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

Критерии отбора

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

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

· способность посвятить себя проекту;

· способность делегировать полномочия и разделять ответственность;

· компетентность в данной предметной области;

· ориентированность на выполнение задачи;

· способность переходить от одного вида работы к другому в зависимости от графика работ и необходимости;

· готовность признавать ошибки и принимать замечания;

· способность к пониманию планов, готовность работать в условиях жесткого графика и лимита ресурсов;

· готовность к сверхурочной работе, если необходимо;

· способность доверять, помогать другим и принимать помощь;

· умение быть игроком в команде, а не героем-одиночкой;

· предприимчивость, но при этом восприятие советов и предложений;

· способность работать с двумя и более начальниками;

· способность работать без и вне формальных иерархий и систем полномочий;

· знания и опыт в области систем управления проектами.

Различные подходы к формированию команд программных проектов

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

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

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

Предложение Миллза

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

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

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

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

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

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

Два секретаря. И администратору, и редактору нужны свои секретари; секретарь администратора будет вести корреспонденцию проекта и архивы.

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

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

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

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

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

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

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

Функциональные роли в коллективе разработчиков. Подход Центра объектно-ориентированной технологии компании IBM

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

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

Заказчик (Customer) -- реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки;

Планировщик ресурсов (Planner) -- выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации;

Менеджер проекта (Project Manager) -- отвечает за развитие проекта в целом, несет ответственность за распределение заданий и ресурсов, за соответствие результатов установленным требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов;

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

Архитектор (Architect) -- отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом;

Проектировщик подсистемы (Designer) -- отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами;

Эксперт предметной области (Domain Expert) -- изучает сферу приложения, поддерживает направленность проекта на решение задач данной области;

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

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

Специалист по пользовательскому интерфейсу (Human Factors Engineer) -- отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям;

Тестировщик (Tester) -- проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта;

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

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

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

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

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

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

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

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

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

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

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

Команда ХР проекта - роли для людей

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

Заказчик

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

зафиксировать сроки выпуска версий продукта;

принимать решения относительно запланированных составляющих программы;

знать ориентировочную стоимость каждой функциональной составляющей;

принимать важные бизнес-решения;

знать текущее состояние системы;

изменять требования к системе, когда это действительно важно.

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

Разработчик

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

получить достаточное знание вопросов, которые должны быть запрограммированы;

иметь возможность выяснения деталей в процессе разработки;

предоставлять ориентировочные, но откровенные оценки трудозатрат на каждую функциональную часть или историю пользователя;

корректировать оценки в пользу более точных в процессе разработки;

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

Роли внутри роли

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

Сторона заказчика

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

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

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

Сторона разработчика

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

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

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

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

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

Внешние роли

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

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

Проектная группа: подход MSF

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

Хотя модель группы разработчиков весьма конкретна, при знакомстве с MSF ее нужно рассматривать в качестве отправной точки. Разные коллективы реализуют этот каркас по-разному, в зависимости от масштаба проекта, размеров группы и уровня подготовки ее членов. Чтобы проект считался удачным, следует решить определенные задачи:

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

· соблюсти ограничения -- разработчики проекта должны уложиться в финансовые и временные рамки;

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

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

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

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

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

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

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

Табл. 1. Цели и роли

Цель	Роль
Удовлетворение требований заказчика	Менеджер продукта
Соблюдение ограничений проекта	Менеджер программы
Соответствие спецификациям	Разработчик
Выпуск только после выявления и устранения проблем	Тестер
Повышение эффективности труда пользователя	Инструктор
Простота развертывания и постоянное сопровождение	Логистик

В проектную группу должны входить:

· опытные руководители;

· инициативные сотрудники, способные принимать решения и нести ответственность за свое направление работы,

Их задача:

· сконцентрироваться на выпуске продукта:

· выработать общее представление о проекте.

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

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

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

· доверие -- делает действия людей согласованными, при этом все следуют принципу «мы делаем то, что обещали сделать»;

· уважение -- люди признают способности других, следуя правилу «каждый из нас необходим нашей группе»;

· согласие -- все должны знать и поддерживать цели проекта и верить в его успех;

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

Менеджер продукта

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

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

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

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

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

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

Менеджер программы

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

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

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

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

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

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

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

Разработчик

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

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

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

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

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

Тестер

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

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

Нельзя совмещать должности тестера и разработчика. Разделение этих обязанностей:

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

· повышает качество продукта за счет конкуренции между группами.

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

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

Часто упускают из виду и другие важные обязанности тестеров. К ним относятся:

· уведомление об ошибках и их отслеживание -- тестовая группа отвечает не только за управление изменениями, но и за систему выявления ошибок и информирования о них;

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

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

Инструктор

Цель группы обучения -- повысить эффективность труда пользователей. Поэтому инструкторы «принимают сторону» пользователей подобно тому, как менеджеры продукта представляют интересы заказчика. Однако перед пользователями инструкторы выступают в роли представителей проектной группы.

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

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

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

Логистик

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

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

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

Размеры группы и масштаб проекта

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

Крупные проекты

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

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

Тематические подгруппы

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

Функциональные группы

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

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

Небольшие проекты

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

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

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

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

Эффективность команды проекта

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

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

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

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

· неформальная атмосфера;

· задача хорошо понята и принимается;

· члены команды прислушиваются друг к другу;

· задачи обсуждаются коллективно с участием всех членов команды;

· все члены команды свободно выражают как свои идеи, так и чувства;

· конфликты и разногласия присутствуют, но выражаются и центрируются вокруг идей и методов, а не личностей;

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

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

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

· технических и/или функциональных, т.е. профессиональных навыков,

· навыков по решению проблем и принятию решений;

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

Признаками эффективной проектной команды являются:

· внутренняя организация;

· групповые ценности, на основе которых формируется чувство общности в команде и создается общественное мнение;

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

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

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

· закрепление определенных традиций.

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

команда управление программный

Список литературы по курсу:

1. Иванова Г.С. Технология программирования.- М.: из-во МГТУ им. Н.Э. Баумана, 2002.

2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000.

3. Липаев В.В. Программная инженерия: методологические основы. - М.: ТЕИС, 2006.

4. Костров А.В. Основы информационного менеджмента. - М.: Финансы и статистика, 2001.

5. Орлов С.А. Технологии разработки программного обеспечения. - СПб.: Питер, 2002.

6. Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы. Пер. с англ. - СПб.: Символ, 2001.

7. Уокер Ройс. Управление проектами по созданию программного обеспечения. Пер. с англ. - М.: Лори, 2002.

8. Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда И. Шафер. Управление программными проектами: достижение оптимального качества при минимуме затрат. Пер. с англ. - М.: Издательский дом «Вильямс», 2003.

9. Эдвард Йордон. Путь камикадзе: как разработчику программного обеспечения выжить в безнадежном проекте. Пер. с англ. - М.: Лори, 2001.

10. Скотт Кендалл. Унифицированный процесс. Основные концепции. Пер. с англ. - М.: Издательский дом «Вильямс», 2002.

11. Кент Бек. Экстремальное программирование. Пер. с англ. - СПб.: Питер, 2002.

12. Тимоти Пайрон. Использование Microsoft Project 2003. Пер. с англ. - М.: Издательский дом «Виьямс», 2005.

13. .Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. Пер. с англ. - СПб.: Питер, 2002.