Проектная команда под контролем: Как достигать результатов вместе бесплатное чтение

Понятие проектной деятельности.

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

Операционная деятельность

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

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

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

Проект

И вот мы постепенно подошли к понятию что такое проект.

«Проект – это временная попытка создать уникальный продукт, услугу или результат».

К основным свойствам проекта можно выделит следующее:

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

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

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

Стейкхолдеры: лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта. Термин на русский язык можно перевести, как «заинтересованная сторона».1 Кстати команда тоже подпадает под это определение и в целом воспринимается в двух разрезах – как ресурс для достижения целей проекта, и как стейкхолдер который определяет каким будет итоговый продукт.

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

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

Продукт

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

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

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

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

Разработка продукта – это путь от идеи до финальной версии, готовой к использованию.

Может состоять из проектов и фазы могут повторяться:

– формирование идеи;

– исследование;

– UX 3– «Путь клиента»;

– создание MVP

– тестирование

– разработка

– продвижение

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

Современные формы реализации ИТ проекта

В современной литературе по проектному управлению выделяют три основные формы – Традиционная, agile и гибридная. От выбранной формы реализации резко зависят роли, инструменты, права, полномочия и обязанности основных участников внутри проекта: Руководителя проекта и членов команды.

Традиционная

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

Рис.1.1. Водопадная модель управления проектами.

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

Рис. 1.2. Итеративная модель управления проектами

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

Сам итеративный подход обладает следующими свойствами:

– требования могут быть динамичны, в «водопаде» они фиксированы, и операции проходят

один раз, последовательно;

– планирование происходит методом набегающей волны4, в водопаде планирование выполняется только один раз;

– поставка продукта заказчику одна, в самом конце, как и в водопадной модели.

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

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

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

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

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

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

Закрытие: После завершения всех задач проекта, проводится финализация результатов и передача продукта заказчику. Выполняется один раз.

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

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

Agile

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

Agile концентрируется вокруг ключевых практик:

–Очередь задач

–Доска

–Итерации

–Пользовательские истории

–Таймбоксинг (англ.Timeboxing)

–Ежедневные собрания

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

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

Руководители в погоне за красивой записью в своё резюме начинают скоростное внедрение Agile в своих проекта, формально следуя процессам, описанным в «гайдах» без реального изменения культуры и подхода к работе. Без обучения команды и создания необходимых условий для успешного применения методологии у вас ничего не получится.

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

Самыми популярными фрейморками6 является Scrum и Kanban. Свод знаний о данных подходах опубликован в двух канонических книгах:

– Scrum Guide, произносится как «Скрам гайд», последняя версия издана в Ноябрь 2020, объём 16 страниц7

– Kanban Guide, произносится как «Канбан гайд», последняя версия издана в Декабре 2020 , объем 9 страниц.

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

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

–Указывать что и как делать команде и Scrum Master;

–Контролировать все и вся. Особенно через отчеты;

–Включать «начальника» и вносить в спринт новые срочные задачи;

–Позволять стейкхолдерам не конструктивно коммуницировать с командой;

–Позволять отчитываться “себе” на Daily Scrum.

Руководитель проекта по отношению к команде в первую очередь должен принести описание проблемы и предоставляет возможность найти способы решения команде, доверившись ей в том, что они добьются результата самым лучшим способом. Управление командой в Scrum или Kanban резко ломает традиционные менеджерские методы, к которым вы привыкли. А сами фреймворки вводит серьёзные ограничения на способы воздействия на команду проекта отказавшись от привычных постановок задач. Например, в SCRUM руководитель проекта не имеет права по-своему хотения прийти в команду и заставить выполнить задачу, которой нет в беклоге спринта.

Гибридная модель

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

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

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

Определение роли руководителя проекта

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

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

Часто возникает вопрос – важны ли глубокие знания в предметной области для РП? В качестве ответа предлагаю придерживаться формулы – чем сложнее и масштабнее проект, тем менее важны компетенции руководителя как эксперта в предмете, например «ИТ-шника», но сильнее необходимы как «управленца». Наличие «hard skills» в предметной области продукта становится крайне полезным, но перестает быть необходимым.

Жизненный цикл взглядов РП на команду проекта.

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

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

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

Рис. 1.4. Взгляд на команду проекта с точки зрения жизненного цикла проекта.

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

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

Разработка и Внедрение ключевой вопрос «Как?»:

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

Завершение, ключевой вопрос «А дальше?»

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

Первая мысль, которая приходит к начинающим руководителям длинных проектов – «Это так долго, у меня ещё куча времени. Ближе к концу будем думать о завершении». Время летит очень быстро, РП подхватывает вихрь рутинных операций, проблем, бед, и задумать о таких вещах уже нет времени. А ведь после проекта жизнь не заканчивается, есть этап «Сопровождения, а в ИТ проектах часто это делает таже команда что и создавала продукт. Все мы помним сказу Пушкина «Про золотую рыбку». Ведь если бы дед в первый момент задумался о всем жизненном цикле проекта по улучшению жизненных условий, возможно где-то раньше остановился бы и не оказался снова у разбитого корыта. В примере из реальной жизнь – можно построить менеджмент таким образом что половина компетентных сотрудников разбегутся по пути, а в конце некому будет обеспечить качественное сопровождение. И все потому, что не задумывались о конце и перегибали палку там, где можно было бы этого не делать.

Границы команды проекта, иерархия.

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

К Организационным единицам в проекте относится – Проектный комитет, Куратор проекта, Руководитель проекта, Команда управления проектом, Проектная команда. При этом в границы команды проекта подпадают только последние три.

Команда управления проектом, в английской литературе – «project team management», бывает централизованная и распределённая

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

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

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

Иерархическая схема команды проекта приведена на рисунке 1.3

Рис. 1.3. Иерархическая структура команды проекта.

Несколько тезисов по этому рисунку:

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

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

3. Внутри команды проекта возможны совместные активности двух типов:

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

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

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

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

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

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

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

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

Поэтому перед руководителем постоянно стоят вопросы «Кто» или «Что нужно сделать»? – в проект нужен человек с нужными навыками или для выполнения конкретной задачи или этапа. Например, сотрудник с навыками дизайнер UX/UI нужен только на начальном этапе, пока не сформировался интерфейс продукта. Но если помимо навыков в рисовании человек разбирается в смежных областях, например в Scrum и из него может получиться отличный Scrum Master, он может пригодиться для других этапов проекта. И вторая группа вопросов – «Искать или Готовить?». Мы хотим сразу готового специалиста и не готовы вкладываться в его развитие или же согласны взять сотрудника с «потенциалом», и довести его до необходимой «кондиции» за счёт различных форм обучения. На рынке почти невозможно сразу найти специалиста по узкоспециализированному ПО или оборудованию, которое может использоваться в техническом решении вашего проекта. Скорее всего придётся учитывать в плана проекта ранее заполнение потенциальными кандидатами вакансии, возможно даже несколькими. Обучать их, с прицелом что в нужный момент проекта они окажутся готовыми к выполнению запланированных операций.

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

Рис. 1.4. Таблица Должности – Задачи

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

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

В такие моменты нашим лучшим помощником становиться Excel и два вопроса: «Что делать?» и «Когда делать?». Для выполнения упражнения нам ещё понадобится план реализации проекта.

Шаг 1. Создайте новый файл и заполните первые 3 столбца названиями:

Рис. 1.5. Первый шаг заполнения состава команды.

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

Шаг 2. Заполните столбцы «Что делать» и «Когда делать». Возьмите за основу план проекта или иерархическую структуру работ. На забудьте указать задачи менеджмента, обучения пользователей, управление рисками и бюджетом, встречи с заказчиком. В когда делать можно указать, если известно конкретные даты начала и конца, или названия этапа жизненного цикла проекта, как на рис 1.6..

Рис.1.6. Заполненные столбцы «Что делать» и «Когда».

Шаг 3. «Кластеризуйте», по областям получившиеся задачи из столбца «Что делать. И отвечая на вопрос «Эти работы лучше подходят для…» и проставьте условные должности «Менеджер по…» или «Специалист по» , «Главный по…». Например – «Специалист по видеонаблюдению», на рисунке 1.7. обобщённые задачи и должность выделены фиолетовым и оранжевым.

Рис. 1.7. Результаты кластеризации.

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