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