Руководитель проекта должен обеспечить четкое видение проекта у команды внедрения, контролировать ход работ и вести диалог с членами группы в областях их ответственности, координировать разрешение внутренних и внешних конфликтов, обеспечивать взаимодействие между группой внедрения и остальными подразделениями, владеть методологической базой и лидерскими качествами. Некомпетентность или ограниченное участие менеджера проекта ведет к серьезным рискам успешного завершения работ по проекту и принятия результатов заказчиком.
Руководитель проекта отвечает за подбор команды внедрения, которой предстоит выполнить все работы по проекту. В ее задачи входят обследование предприятия, проектирование и оптимизация бизнес-процессов с помощью внедряемой системы, разработка и тестирование отдельных модулей, внедрение и интеграция в общую ИТ-инфраструктуру. Команда внедрения проекта может состоять из представителей заказчика и сторонних консультантов, представителей подрядчика. В ее состав могут входить аналитики, проектировщики, разработчики (программисты), тестировщики, отладчики, технические писатели, риск-менеджеры, руководители функциональных подразделений, ключевые пользователи, эксперты и другие специалисты. Экспертами являются опытные руководители и ключевые сотрудники заказчика, знающие бизнес компании и готовые передавать знания и опыт другим членам команды проекта. Эксперты часто способны заранее предвидеть последствия тех или иных решений, поэтому нужно стремиться к ситуации, когда для принимаемых решений, особенно на стадии концептуального дизайна системы, этими людьми производится формальная или неформальная экспертная оценка.
Для крупных ИТ-проектов может быть полезно участие аудитора, который позволяет выполнить независимую оценку реального состояния управления проектом, оценить адекватность затрат и соблюдение формальной методологии ведения проекта.
В проектах внедрения велика доля подрядчика или поставщика ИТ-услуг, что обусловлено сложностью и масштабами проектов внедрения. Интересы субподрядчиков в таких случаях не распространяются на успешность проекта в целом. Поэтому руководитель и команда управления проектом должны уделять особое внимание качеству поставляемых товаров и услуг.
В программной инженерии многие руководители отдают предпочтение самоуправляемым и самоорганизующимся рабочим командам. Эффективность команд в новых экономических условиях одними из первых оценили такие гиганты, как Procter & Gamble и Boeing. Принципы командного менеджмента предполагают ясность общих ценностей и целей, самоорганизацию и самоуправление совместной деятельностью, взаимный контроль, взаимопомощь и взаимозаменяемость, коллективную ответственность за результаты труда, всемерное развитие и использование индивидуального и группового потенциалов.
Компания Microsoft выделяет следующие основные принципы построения команды.
1. Команда равных с четкой ответственностью за область деятельности, общей ответственностью за результат и с открытым информационным обменом. Каждая роль отвечает за конкретную цель качества в общем решении.
2. Представление интересов всех участвующих сторон, которые необходимы для успешной разработки ПО. Представление всех аспектов для управления и балансировки проекта в целях предотвращения неполноты, ошибок и однобоких решений.
3. Адаптация для соответствия характеру/масштабу проекта. Масштабируемость команд от небольших групп до сложных оргструктур.
Преимущества модели команды MSF заключаются в высокой производительности, поскольку непроизводительные трудозатраты на поддержание формальных и субординационных связей сведены к минимуму. Также характерна сравнительно легкая масштабируемость, где каждый элемент в схеме команды может быть, в свою очередь, циклом. К преимуществам еще можно отнести сильную положительную мотивацию труда и равно высокую заинтересованность всех участников в конечном успехе. К недостаткам можно отнести тот факт, что для формирования команды MSF нужны равно квалифицированные и равно заинтересованные участники. Критическое значение имеют коммуникабельность, умение и готовность работать в коллективе, поскольку демократичная модель команды MSF плохо сопрягается с жесткой иерархической моделью подразделения.
Для эффективной организации работ по проекту необходимо точно определить, кто за что отвечает и кто что делает. Для этого используется матрица распределения ответственности, строкам которой назначены все работы проекта (взятые, например, из структуры декомпозиции работ), а столбцам – все роли, используемые в проекте. Если в проекте есть несколько сотрудников, играющих одну и ту же роль, то заводится несколько столбцов. Другими словами, в матрице распределения ответственности столько строк, сколько всего работ в проекте, и столько столбцов, сколько всего исполнителей в проекте. Если какой-то сотрудник, играющий определенную роль, назначен ответственным за выполнение определенной работы, то на пересечении соответствующих строки и столбца делается отметка.
Матрица распределения ответственности является удобным инструментом управления. Она позволяет быстро и в наглядной форме ответить на важные для менеджера вопросы, такие, например, как: кто отвечает за данную работу, есть ли работы, за которые никто не отвечает или за которые отвечают несколько исполнителей.
Помимо матрицы ответственности, существует матрица совмещения ролей, позволяющая отследить нарушения в совмещении ролей одним и тем же сотрудником. Так, например, руководитель проекта может принимать участие в тестировании или анализе бизнеса, но при этом крайне не рекомендуется его участие в разработке информационной системы (рис. 24).
Рис. 24. Матрица совмещения ролей для ИТ-проекта согласно PMbOK
Из профессиональных программистов получаются отличные тестировщики. Однако наихудшим сочетанием ролей считается «разработчик-тестировщик», поскольку разработчик проводит тестирование по остаточному принципу и не может найти неожиданные ошибки. Хороший разработчик убежден, что он пишет программы правильно, и ему психологически тяжело допустить, что где-то в его коде может быть ошибка. Поэтому подобное совмещение ролей приводит к низкому качеству тестирования, способствует появлению рисков и большого количества ошибок при интеграционном тестировании. Повышается вероятность пропуска или ненахождения критических дефектов, тестирование не является процессом с заданными входными и выходными данными и критериями завершения.
