пятница, 4 ноября 2016 г.

Зачем проектным менеджерам системный менеджмент (чтобы делать ИСР с покрытием не 92, а 99%)


Несколько месяцев назад столкнулся с ситуацией, когда одна девушка доросла с обычного бухгалтера до главного, ее переманил конкурент, но отдел кадров не смог ее трудоустроить, т.к. у нее не было не то что диплома, но даже аттестата об окончании средней школы и результатов ЕГЭ. Арифметические действия она делала исключительно с помощью калькулятора и в принципе не понимала, что такое дроби. Ей было 28 на тот момент и три попытки сдать ЕГЭ окончились ничем. Человек прошел кучу аудиторских и камеральных проверок практически без замечаний. Казалось бы, забавная история, но в этой ситуации находится большинство операционных менеджеров, руководителей проектов включая. Эта самая "ориентированность на результат" и отсутствие понимания того, как работает вся система в целом, опора на "многолетний опыт в проектах различного размера и разных индустриях", разработка проектной документации с использованием "экспертной оценки и исторических данных". И полная неспособность понять главную причину неизменности моего любимого слайда ПиЭмАй "Пульс профессии 2011-2012-2013-2014 и далее", что основной причиной проблем в проектах по прежнему является неточные требования и оценка объемов работ. Одураченные случайностью, как и было сказано. Все РП используют индукцию при построении планов, и это спокойно уживается у них в голове с определением "проект - это уникальное бла-бла-бла". Уникальное, конечно, но мы возьмем все старые данные и подходы, применим здравый смысл (с) и двинемся дальше. Это, на мой взгляд, приводит к ситуации, в которой РП, в особенности в рисковых проектах, становится грушей для битья.
Я сам много раз шел в проект без понимания того, как конкретно этот план принесет заявленные в бизнес-кейсе эффекты, и даже как конкретно мы этот план исполним, я имею в виду часть интеграции планов по областям. Картинка до этого была такой - есть баналитик, который ищет проблему и предлагает обоснованное решение, а РП это такой парень, который за фиксированный прайс и срок это решение реализует. И эта модель жива и наиболее распространена в Штатах, например. Один мой знакомый, проходя собеседование в американской компании, сказал, что хочет позицию ПиЭма, на что СЕО его удивленно спросил: "Так это же те, которые таблички в Экселе рисуют и отчеты пишут, что тут интересного? Наверное, продакт менеджером?"
Ситуация далека от идеальной, т.к. никакой командной работы при таком разделении труда быть не может, только групповая, а она сильно ограничена по предельному проходу и сложности. Групповая работа предполагает, что один человек в пределах своей компетенции может принимать все необходимые решения и выполнять всю работу, и такая проектная группа может брать только типовые и не очень сложные задачи либо опираться на звездных исполнителей, расположенных в критических областях бизнеса, что, конечно, не делает эту архитектуру устойчивой и тем более воспроизводимой. Мало какой инвестор даст под такое денег и архетип пределов роста у такой компании наступит достаточно быстро.
Таким образом, команда должна разбираться в проекте в целом и давать ценные замечания своим коллегам в рамках их профессиональной деятельности. Любой любому, и тогда это полетит. Это предполагает под собой выполнение двух условий:
  1. Системный подход в головах у участников команды. Все единообразно понимают холон и могут свободно по нему двигаться вверх и вниз.
  1. Знания, информация и данные находятся в экзокортексе и они актуальны. Вы не можете дергать команду для пояснения деталей холона во время своих рассуждений.
 
Я давно обещал Анатолию Левенчуку, что когда будет четкое понимание и однозначная обратная связь от окружения по поводу полезности курса системного менеджмента, я напишу отзыв о тренинге, и этот момент настал. Итак, для чего нужен системный менеджмент руководителю проекта?
  1. Для определения полного содержания проекта не на основе эвристик, а на основе компактной и очень широко применимой мыслительной модели. Для понимания, кто такие стейкхолдеры (стандарты проектного управления не дают ни малейшего разумного объяснения, кто это и с чем их едят), как их ожидания преобразуются в требования и каким должен быть продукт проекта (условно), чтобы они были счастливы.
  1. Для формирования плана проекта, который реально позволит контролировать ключевые аспекты и узкие места в работах проекта, а не слепо доверять заверениям исполнителей о том, что все под контролем. Доверие возникает только из понимания ситуации в ее динамике и theory of mind исполнителя. Во втором СМ не поможет, но в первом вполне даст удовлетворительный ответ. Одним из примеров может быть список KPI для всех команд проекта, который будет подстроен под конкретный проект, а не слепо взят из базы или из опыта, и который позволит отследить цепочку получения результата.
  1. Для эффективной бюрократии там, где это возможно. Артефакты должны помогать выполнять работу, а не прикрывать мягкие места исполнителей и ответственных за плохие решения. Заодно уже и про принятие решений. Хорошие решения могут приводить к плохим последствиям, и наоборот, и без системного мышления очень сложно разобраться, какое решение было плохим, а какое хорошим.
 
Конкретный пример использования СМ. Две недели назад я сменил место работы, город, перешел с DIY в FMCG. И одна из первых задач у меня была, помимо того, что надо снять квартиру и вообще обустроить жизнь в Москве, за три недели разработать и запустить программу развития. Я успел три раза разработать и уточнить стратегию, провел пять десятков встреч, разработал черновик бизнес-архитектуры as is и начал рисовать to be, доделаю к концу года. За две недели я понял ключевые проблемы и продуктивно участвую в производственных совещаниях и фасилитирую дискуссии. Я понимаю ключевых стейкхолдеров и отслеживаю их интересы, я разобрался в ключевых ИТ сервисах, поддерживающих бизнес-процессы. Вы когда-нибудь стояли рядом с коммутационным шкафом? Такое щелк-щелк каждую секунду, иногда по нескольку раз. Вот и у меня так же - стейкхолдер-интерес, система, требование, работа, команда, технология, метод описания, описание. И сразу архитектура в голове дорисовывается в Архимейте, надо только сесть и быстро все записать.
Вход в новый проект - это сложно для всех, тут и опыт важен, и навыки взаимодействия и конечно, это все имеет значение. Но, только СМ дает ТЕХНОЛОГИЮ, т.е. повторяемость и воспроизводимость этого входа в проект. Специалист, владеющий технологией, однозначно бьет даже крутого ремесленника, хотя Левши всегда были в России в почете. Порядок бьет класс, системный менеджмент бьет "25 лет опыта и более 60 выполненных проектов". Я выбираю быть на выигравшей стороне, свой выбор вы делаете сами.

Комментариев нет:

Отправить комментарий