ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2015 / Выпуск №6 (49) / Не меняйте проекты, как перчатки. Часть 4. Команда проекта ИТ

Рубрика: Управление проектами

 Марина Аншина, председатель Комитета по стандартам, Российский Союз ИТ-директоров

Не меняйте проекты, как перчатки
Часть 4. Команда проекта ИТ

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

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

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

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

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

А создать команду и лелеять ее в течение всего проекта – задача очень сложная. Поэтому намного проще сосредоточиться на бюджете, сроках, а в случае чего просто стукнуть кулаком по столу. А потом руководитель проекта может сказать: «Я сделал все, что было в моих силах, просто команда подвела». И будет категорически неправ. Потому что, во-первых, в выборе этих людей он принимал определяющее участие, а во-вторых, не сумел их толком организовать.

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

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

Команда проекта – это временное объединение специалистов, непосредственно принимающих участие в выполнении проекта.

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

В ИТ-проектах в команду обычно включают следующие группы людей (см. таблицу 1).

Таблица 1. Группы в команде ИТ-проекта

*SLA – Service Level Agreement – договор об уровне сервиса, определяющий параметры предоставляемых услуг.

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

С точки зрения классической методики управления проектами РМВоК для этого существует отдельный процесс – управление человеческими ресурсами, состоящий из нескольких подпроцессов:

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

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

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

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

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

• Каждому члену команды должны быть понятны цели и ограничения проекта, его масштабы, его значение и его роль.
• Каждому члену команды должны быть понятны его вклад в общее проектное дело, права и ответственность, что делать, если… Помочь в этом может матрица ответственности, которую иногда называют RACI-матрицей**,
  пример которой приведен в таблице 2, где:
  • R , Responsible – роль отвечает за выполнение задачи;
  • A, Accountable – роль контролирует выполнение задачи, для одной задачи – только одна роль;
  • C, Consulted – роль консультирует ответственных в ходе выполнения задачи;
  • I, Informed – роль, которую необходимо уведомлять о выполнении задачи.
• Всем должна быть доступна вся не только необходимая, но и полезная информация (конечно за исключением той, которую надо защищать).
• Из вечных вопросов «Что делать?» и «Кто виноват?» второй стоит использовать только как сильнодействующий яд в малых дозах (как лекарство).

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

Таблица 2. Пример матрицы ответственности (RACI)

** Матрица RACI – матрица, в которой по горизонтали описываются роли (иногда функциональные подразделения), а по вертикали – работы, процессы или их стадии, в ячейках на пересечении ставится: R , Responsible, A, Accountable, C, Consulted, I, Informed.

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

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

Автоматизированные системы при правильном использовании могут существенно облегчить жизнь команде и улучшить результаты проекта. Ключевое слово тут – «правильном».

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

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

Приведем для примера описание команды Скрам (Scrum), одной из наиболее популярных методологий гибкой разработки ПО (достаточно существенная часть всех ИТ-проектов).

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

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

Скрам-мастер (Scrum Master) – ответственный за успех проекта. Именно он является связующим звеном между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или Командный лидер (тимлид). Хочу подчеркнуть, что Скрам-мастер не раздает задачи членам команды и не контролирует выполнение их каждым ее членом, ведь команда Скрама является самоорганизующейся и самоуправляемой.

Скрам-мастер:

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

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

Обязанности Владельца продукта таковы:

• Отвечает за формирование видения продукта.
• Управляет ROI.
• Управляет ожиданиями заказчиков и всех заинтересованных лиц.
• Координирует и приоритезирует работы.
• Предоставляет понятные и тестируемые требования команде.
• Взаимодействует с командой и заказчиком.
• Отвечает за приемку кода в конце каждой итерации.

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

Команда Скрама отвечает за:

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

Считается, для более эффективного общения команда должна находиться в одном месте и даже в одной комнате.

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

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

Новая область знаний включает процессы:

• Определение заинтересованных сторон.
• Разработка Плана управления заинтересованными сторонами.
• Управление вовлечением заинтересованных сторон.
• Контроль вовлечения заинтересованных сторон.

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

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

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

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

В начало⇑

Комментарии отсутствуют

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