О роли PM и менеджменте больших масштабируемых проектов
Добрый день! Эта статья — попытка ответить на самые часто задаваемые вопросы об эффективном управлении ИТ-проектами, которые мне задавали во время и после семинара Vertamedia Experience Sharing, посвященному проектному менеджменту.
И чтобы наше общение не было обезличенным, я позволю себе сказать несколько слов о себе. Меня зовут Кирилл Сидоров, я работаю проектным менеджером в компании VertaMedia. Вся моя сознательная жизнь была связана с управлением проектами. Но управлению проектами в ИТ-сфере посвящены лишь последние 7 лет. До этого были разные отрасли: массовые мероприятия, экология, инновационное инвестирование и другие. Восемь лет назад, занимаясь инвестиционными проектами в инновационной среде, я почувствовал, что именно в ИТ я смогу быть максимально полезным. Меня манила эта динамично развивающаяся отрасль.
Кто такой ПМ
В моем понимании, проектный менеджер — это специалист, способный объединить вокруг себя проектную команду и обеспечить этой командой производство продукта (реализацию проекта), удовлетворяющего самым изысканным потребностям Заказчика. И не важно, внутренний это заказчик или внешний по отношению к компании. Казалось бы, что сложного в простом следовании техническим требованиям Заказчика — но не все так просто. Часто требования весьма завышены, сроки крайне сжаты, а бюджеты таковы, что без «магии» проект просто не реализуем.
Но бывает другая реальность — проект бессрочен, требования расплывчаты ибо заказчик сам до конца не понимает, чего хочет. Естественно, что проект в такой ситуации «разбивается» на этапы, очерёдность которых сильно зависит от уровня осознания Заказчиком конечного продукта. А если этого осознания нет? Тогда в дело вступает команда аналитиков, задача которых очень толерантно помочь Заказчику «превратить» идею в совокупность требований. Опять все кажется очень простым, однако команда аналитиков может помочь Заказчику сформулировать такие требования, что проектной команде они будут не под силу. И чтобы это не произошло, нужен сдерживающий фактор, гарантирующий, что требования не выйдут за границы компетентности проектной команды или будут в рамках, достижимых командой в разумные сроки. И таким сдерживающим фактором является ПМ.
Можно услышать много историй как в молодых командах проектными менеджерами становятся наиболее подготовленные или авторитетные разработчики. И не факт, что на момент такого «назначения» человек мечтает исполнять обязанности ПМ-а. Так же нет уверенности, что у человека есть задатки к такой деятельности или хотя бы базовые знания специфики управления проектами. Можно выйти на рынок и купить готового ПМ-а. Но давайте вместе ответим на вопрос: что лучше, купить или вырастить ПМ-а?
Купить или взрастить
Предлагаю рассмотреть этот вопрос с точки зрения управления рисками. Давайте ответим на вопрос: какие риски являются наиболее критичными в реализации ИТ-проектов?
Опыт позволяет говорить о трех наиболее значимых рисках в порядке убывания критичности:
— Реализовали не то, что нужно;
— Реализовали то, что нужно, но с опозданием;
— Реализовали не то, что нужно и с опозданием.
Итак, наиболее важно реализовать то, что ожидает Заказчик, а для этого нужно, чтобы ПМ «сходу» действительно понимал суть проекта. Не вызывает сомнений, что наиболее опытный разработчик из числа проектной команды будет лучше понимать суть проекта, чем нанимаемый сторонний ПМ. Именно поэтому мы предпочитаем растить своих ПМ-ов. Это позволяет эволюционным образом улучшать качество управления, так как вчерашний разработчик, который видел ошибки ПМ-а со стороны девелопмента, наиболее вероятно не будет допускать такие же. Более того, переход разработчика на уровень проектных менеджеров открывает другим менеджерам возможность получения обратной связи от «уже не разработчика», так как полностью устраняет возможный дискомфорт общения представителей разных «цехов».
Есть ещё один весомый аргумент в пользу «взращивания» своих ПМ-ов. Компании, которые работают на активно растущих рынках, сталкиваются с отсутствием единой терминологии, что создаёт немало проблем. Девелопер, который проработал определённый срок в компании, априори в той или иной мере владеет этим тезаурусом, а нанимаемый ПМ вынужден будет этот тезаурус осваивать, что на практике оказывается весьма непростым и затратным по времени делом.
Следует сказать пару слов о социо-культурных особенностях проектной команды. При приходе нового менеджера со стороны есть риск потери времени на изменение социо-культурной среды, что является следствием попыток нового руководителя «переделать» команду под «себя». Выходец из команды максимально вероятно будет следовать устоявшимся практикам общения — сохранять общность команды путём сохранения правил. Очень важно понимать, что назначение нового руководителя не всегда должно быть основанием для «ломания через колено» команды.
Изложенное выше якобы однозначно говорит о том, что «домашний» ПМ лучше. С другой стороны, человек со стороны со своим опытом может быть хорош тем, что привнесет новые опыт и новые практики управления из других компаний, с которыми местные «выращенные» специалисты могут быть незнакомы. Так же если команда «теряет» проект, то лучшим решением может быть привлечение «варяга», то есть стороннего ПМ-а, который помимо основных функций управления проектом выполнят ряд антикризисных мер. В кризисных ситуациях, особенно в длящихся долго, «поломать через колено» может быть лучшей стратегией. Но нужно помнить, что в столь радикальных мерах можно «выплеснуть ребёнка с водой».
Точка принятия решений
Выше под «выплескиванием ребёнка» подразумевалось недоведение проекта до минимального жизнеспособного состояния (Minimum viable product, MVP). MVP — это точка принятия решений. В момент инициирования нового проекта основная задача ПМ-а — «нащупать» эту точку.
Это точка важна по ряду факторов, среди которых я бы выделил следующие:
— Любые требования, выходящие за рамки MVP, могут быть пересмотрены по результатам эксплуатации продукта с минимально необходимой функциональностью;
— Если Заказчик получит MVP в оговорённые сроки, то вероятность отказа от проекта близка к нулю;
— Если Заказчик получит MVP немного ранее оговорённых сроков, то его удовлетворённость от сотрудничества значительно повышается.
Иными словами — требования, определяющие MVP, самые приоритетные. И тут мы не изобретаем «велосипед». Мы лишь строго следуем принципу Вильфредо Парето: 20% усилий дают 80% результата. В данном случае я не подразумеваю результат в виде доходности, я подразумеваю под словом результат удовлетворённость Заказчика, а следовательно MVP, который и составляет как правило 20% проекта, обеспечивает стабильность команде на оставшиеся 80%.
Но для того, чтобы удовлетворённость заказчика росла, ПМ-у необходимо чёткое представление о компетентности каждого члена проектной команды и его продуктивности. В противном случае у ПМ-а нет инструментов контроля сроков выполнения задач. А вопрос о возможности решения той или иной задачи в предполагаемые сроки становится центральным, так как без однозначного ответа на этот вопрос риск невыполнения обязательств в оговорённые сроки значительно повышается.
Закладывать разумные запасы временного ресурса опытному ПМ-у позволяют показатели ключевых индикаторов производительности (Key Performance Indicators, KPI) каждого члена команды. Я оставлю KPI без рассмотрения, так как это предмет иной статьи. Замечу только, что использование этих метрик минимизирует риск невыполнения взятых обязательств в срок.
Если с привлечением внешнего ПМ-а все более или менее понятно, то процесс взращивания ПМ-а из девелоперов заслуживает отдельного рассмотрения. И тут следует рассматривать два варианта: ПМ-а раньше не было в команде или ПМ раньше был в команде, но ушёл «по велению души».
Первый вариант мы уже частично рассмотрели, когда говорили о «превращении» девелопера в ПМ-а в условиях, когда существует «каста» или «цех» проектных менеджеров. А вот ситуация, когда ПМ-а раньше не было (что свойственно стартапам, например) не так тривиальна.
Из девелоперов в ПМ-ы
Новоиспечённому ПМ-у придётся стать единственной точкой коммуникации между Заказчиком и командой — шаг, который позволит снять нервное напряжение с разработчиков и систематизировать постановку задач. Как правило, это самая значимая проблема на ранних этапах: сотрудники проекта в хаотическом порядке ходят ко всем разработчикам с устными идеями — без приоритетов, без подробного описания, без понимания реальной ценности отдельно взятой задачи в рамках идеи проекта и т.д. Взять этот процесс под контроль удастся только поняв, сколько вообще задач поступает в команду и как эти задачи связаны друг с другом. И тут главное помнить, что «к сказанному нельзя вернуться». Поэтому все требования должны быть детально описаны, согласованы и приоритезированы в случае, когда ПМ совмещает роль бизнес-аналитика. Очень важно помнить при описании о необходимости единого толкования терминов, поэтому задача формирования единого тезауруса — это неотъемлемая часть формирования требований.
Описанные, согласованные, приоритезированные и понятные (подчеркиваю) требования позволяют выстроить упорядоченную очередь с последующим планированием итераций, что является фундаментом на пути построения роадмапов (road-maps) и конкретизации целей в долгосрочной перспективе.
Об оценивании сроков и их предварительной проверке мы уже немного говорили. Как показала практика, молодые команды едва ли могут оценивать даже небольшие задачи точнее, чем в днях. На этом этапе самое время учиться эстимировать ваши задачи. Я рекомендую идти от большого к меньшему: начните с оценки в днях и двигайтесь в сторону почасовой оценки, улучшая постепенно точность прогнозов на основе реальной статистики. Будете вы использовать для этого реальное время или стори-поинты (story-points) — ваше дело. Но понимать, сколько команда способна производить продукта за выбранный период времени, новоиспеченый ПМ просто обязан.
И тут на помощь приходят инструменты, без которых сложно представить эффективное проектное управление: трекинг системы, ведение бизнес и технической документации, разработка мокапов (mock-ups) и интерфейсов (вряд ли на этом этапе у вас появится UX инженер) и т. д. Не откладывайте использование инструментов в долгий ящик. Помните, что они не только позволяют решать задачи управления проектами, но и являются «точками» передачи критичных знаний. Именно поэтому стоит уделять много времени ведению документации.
Проблемы роста
На определённом этапе команда становится настолько большой, а задачи настолько различными, что приходит время делить проектную команду на несколько взаимосвязанных (например, frontend/backend) или самостоятельных команд (проекты с различным целевым назначением).
Координация работы нескольких команд в рамках одного проекта — «тяжёлый хлеб». Почему? Есть несколько причин:
1) В несколько раз больше требований — чтобы успевать собирать требования и преобразовывать их в понятные задачи для нескольких команд, необходимо непропорционально больше времени или выделенная роль аналитика. И чтобы не «утонуть» в сборе требований, ПМ должен выстроить такой режим коммуникации с Заказчиком, чтобы средне-долгосрочные планы были едино понимаемы обоими сторонами как можно раньше.
2) Требуется время на синхронизацию команд — это новый и отдельный процесс для ПМ-а. Если работа команд взаимосвязана, команды могут блокировать друг друга, что приведёт к потере эффективности.
3) Требуется время на формирование культуры производства — привить проектным командам понимание, что с результатом их труда придётся иметь дело не только заказчику, но и коллегам из соседних команд. Не факт, что это потребуется, но вероятность существует.
4) Требуется время на донесение сути продукта до проектной команды, что, если проекты взаимосвязаны, значительно поможет разработчикам принимать более правильные технические решения.
5) Требуются моральные и временные ресурсы на демонстрацию результатов — очень вероятно, что ваш заказчик (пусть даже он и часть вашей компании) уже глубоко погряз в бизнес процессах и не «тусуется» с вами постоянно в одном кабинете. При этом ваш продукт стал куда больше, чем то, что можно показать мимолётом. Обязательно выделяйте время для проведения демонстрации значимых этапов реализации. Это отличный способ обсудить текущее решение и получить по нему целостную обратную связь (фидбек), которая может стать основой развития проекта в форме, например, фича-листа.
6) Требуется больше времени на документирование — если у вас документации ещё нет, то это очень плохой знак! Хорошая техническая и бизнесовая документация значительно сокращает время внедрения каждого нового сотрудника. В последствии она будет экономить до одного месяца на вовлечение в проект каждого нового члена проектной команды.
А что дальше? Дальше, при активном росте компании, времени на выстраивание внутренних процессов проектных команд практически не остаётся. Вы оглянуться не успеваете, как у вас:
— Орда стэйкхолдеров — владельцы бизнеса, финансовые и кадровые специалисты, руководители отдела продаж, отдел поддержки клиентов, ключевые клиенты и т.д. Задачи «сыпятся» безостановочным потоком как из рога изобилия, а продукты отгружаются в совершенно различных направлениях;
— Отряды разработчиков — много команд, кто по SCRUM, кто по Kanban, где 5 человек, где 2, где есть Scrum-мастер, а где один «ниндзя» сидит в углу и выдаёт стабильный и крутой код, но он сильный мизантроп.
Кроме того, ещё есть временные задачи, которые хорошо бы отдать на аутсорсинг.
В такой обстановке скорее всего вы уже не будете ПМ-ом в классическом понимании. Вам судьба предлагает выбор. Вероятно, вы себя найдёте в одной из ипостасей: product manager, business analyst, intelligence analyst (trend spotter). И тогда вам придётся искать ответы на другие вопросы: как жить в этой среде, какие навыки, концепции и принципы применять и развивать, что такое системы и системные мышление, как и зачем децентрализовать процесс принятия решений. И может быть вам приглянется идея бережливого производства, и хорошим решением станет Scaled Agile Framework, но это уже другая история.
Иерархический структурированный микроменеджмент
Расскажу пару слов о практике управления проектами, которая на опыте оказалась «тупиковой». Изначально мы делили ПМ-ов на «сервер-сайд» и «фронт-енд-сайд». Такое разделение не позволило достичь приемлемого уровня синхронизации — казалось бы, задачи на каждой «стороне» сделаны, а целостного продукта не получается. Постепенно пришли к пониманию, что должно работать правило «один проект — один ПМ». Но так как проектов становилось больше, и количество ПМ-ов росло, нам потребовался человек, способный организовать работу ПМ-ов. Так родилась двухуровневая модель — стратегически-тактический и тактически-оперативный уровень.
Такая двухуровневая модель будет продуктивна до тех пор, пока «цех» ПМ-ов состоит из одного «главного» ПМ-а и не более чем пяти «полевых» ПМ. Иначе может возникнуть следующая проблема: «главный» ПМ, обеспечивая ресурсы для проектных команд, практически не будет заниматься контролем тактически-оперативного уровня. И чем больше проектов будет становится, тем менее руководитель будет способен контролировать свой цех. Попросту, ему нужны помощники, которые выступят своего рода «агрегаторами» и смогут поддерживать выбранную методологию. Таким образом, по уровням принятия решений «цех» разделяется на стратегические, тактические и оперативные уровни, формируя иерархический структурированный микроменеджмент.
В такой трехуровневой модели управления обязанности распределятся следующим образом. «Полевые командиры» или ПМ-ы оперативного уровня управляют небольшими командами конкретных проектов. Именно они общаются с девелоперами и принимают участие во встречах с Заказчиком. Как правило, ПМ-ы этого уровня и взращиваются из девов.
Следующий уровень — «штабные командиры», или ПМ-ы тактического уровня, отслеживает прогресс по нескольким проектам с целью независимого контроля удовлетворенности бизнеса. Данный уровень более остальных сконцентрирован на потребностях заказчиков и дистанцирован от девелоперов. Представители ПМ-ов тактического уровня менторствуют над «полевыми командирами». Их хлеб — это сроки по этапам и прогноз их выполнения. Данный уровень может комплектоваться ПМ-ами обоих типов — «домашними» и «варягами».
Перед стратегическим уровнем (PM Director) поставлены следующие цели — отладить процесс управления проектами, обеспечить по запросу информирование собственников о проектах, обеспечить Business Continue и Business Recovery, оптимизировать внутренние проектные затраты.
А цербер ли?
Прежде чем закончить наш разговор, я хочу задать вам вопрос — кем должен быть ПМ в команде — цербером (надсмотрщиком) или авторитетным специалистом?
Убеждён, что ответ на данный вопрос был найден вами при прочтении этой статьи. Если нет, я буду рад помочь — в комментариях или при живом общении на следующем мастер-классе VertaMedia Experience Sharing, куда я всех приглашаю.
