Нравится ли вам политика в рабочих моментах? Многие из вас ответят на этот вопрос "нет, политика на работе мне не нравится". Политика мешает делать дело, она забирает наши силы и время и не дает реализовать планы и задумки. Поэтому мы ее не любим.
Но при запуске почти любого проекта всегда много политики. Если коротко описать что такое проектный менеджмент, то можно сказать, что это менеджмент, основанный на здравом смысле плюс политика. Поэтому если ты становишься руководителем проекта, то без политики никак. Надо постоянно договаривать разные команды, поставщиков, пользователей, людей, которые дают деньги, регуляторов и исследователей. Они все хотят разного, у них различные цели и ограничения, стимулы, а вы не можете им приказывать, у них есть свои руководители.
Итак, у нас есть ситуация - многим не нравится политика, но политика нужна для того, чтобы запускать проекты. Является ли эта ситуация проблемой или нет? Собираемся ли мы что-то с ней сделать или просто откажемся от перспективного карьерного пути, признаемся вслух, что управление проектами не для нас и никогда не перейдем на эту карьерную ступеньку?
Я считаю, что это не ситуация, а проблема, с ней надо что-то сделать, ее не надо принимать как данность. И вот почему - почти все мы на практике неплохо умеем в политику, у нас у всех есть этот опыт. И этот опыт называется жизнь в семье.
Сравните футбольную команду и семью. У команды всегда есть конкретная цель - выиграть матч, выиграть чемпионат, выйти на второе место турнирной таблицы. Есть четкое распределение ролей - защитник, полузащитник, нападающий, вратарь. У тренера есть полный контроль играющего состава и тактики игры. У капитана команды есть полный контроль над игроками на поле. Неподчинение командам строго наказывается.
Другое дело семья. У семьи нет общих целей, у всех свои, главное, чтобы эти личные цели не мешали друг-другу. И совсем хорошо, чтобы личные цели складывались в одном направлении. В семье нет четкого распределения ролей, разве что есть общие договоренности, что в основном готовит муж, а убирается жена, за исключением детской комнаты, за чистоту которой отвечают дети. Ни у кого нет полного контроля, можно только попросить, договориться, обменять одну услугу на другую. И из семьи нельзя никого уволить и нанять нового члена, который будет относиться к обязанностям ответственнее.
Метафора спортивной команды и семьи применима к управлению подразделением и проектом.
В подразделении все свое - нельзя прийти и сесть за компьютер чужого отдела или поехать на чужом служебном автомобиле или зайти в 1С бухгалтерского отдела, если вы работаете в отделе разработки. И уж тем более никто не пустит бухгалтера делать чертежи и 3D-модели деталей и узлов в Catia и отправлять их изготовителю дорогого оборудования.
В подразделении есть должности и подписанные директором должностные инструкции, всегда понятно, кто руководитель, кто имеет право отдать распоряжение, а кого можно вообще не слушать. У подразделения есть свой выделенный бюджет, четко очерченный круг обязанностей и строгие цели по показателям, за выполнение которых платят премию.
В проектах есть общая инфраструктура, примерно как домохозяйство у семьи, вместо инструкций есть написанные общими словами регламенты, политики и порядки, примерно как общие правила в семье, есть разделяемые между проектами и инициативами ресурсы, примерно как семейный бюджет, и есть множество стейкхолдеров со своими интересами, которые надо согласовывать. В проектах мы работаем с теми людьми, кого в них выделили, без особых возможностей выбора. И проектные цели на старте обычно довольно размытые, им далеко до обыденной определенности бизнес-целей подразделения.
Эта неопределенность и зыбкость границ, неявные мотивы участников, отсутствие общих понятных правил и порождает политику, которая многих отпугивает, потому что мало кто понимает, как с ней работать.
Но жизнь в семье и есть работающая модель управления мини-проектами, и опыт работы с этой моделью можно перенести из дома на работу. Надо только этот опыт осмыслить и отрефлексировать.
--------------------------------------------------------
Ключевая проблема при переходе от регулярного менеджмента к управлению проектами заключается в том, что при всей внешней похожести содержательно это совсем разная деятельность. И главная ошибка начинающих руководителей проектов, которые вот только пошли на повышение, заключается в том, что они пытаются применить методы управления, методы, которые опираются на ту или иную реализацию цикла PDCA, к управлению проектами. Они пытаются спланировать проект так, как планировали бы исполнение производственного плана, бюджета закупок, плана продаж, выпуск обновлений, графика наём персонала, плана поставок, аудитов, монтажа кабельных линий и серверных стоек, словом, чего угодно, что уже делали сто раз и что хорошо понятно.
А теперь представьте, что вы попытаетесь так спланировать что-нибудь в семье, кроме поездки в отпуск. Не получится, будет сто причин, почему детальный план разобьется об реальность. Цикл "спланировать-сделать нужное-свериться с планом-понять причины отклонений и откорректировать план", цикл, который часто называют циклом Деминга-Шухарта, PDCA, не работает в семье и не работает в стартующих проектах. Потому что политика.
Ниже я приведу основные причины, по которым в проектах нельзя на старте применять цикл PDCA. После запуска проекта его применять обязательно, но на старте он только помешает. И после того, как мы разберемся, почему планирование на старте проекта отличается от планирования уже запущенного проекта, я объясню, почему запускать проекты надо с помощью цикла [[D-RCSA-P]], цикла исследования действием.
Три основные группы причин, по которым PDCA на старте проекта вам не поможет, а только запутает
Эпоха "стройки в чистом поле" и утопических замыслов закончилась.
PDCA нацелен на создание нового в условиях, когда этому созданию мало что мешает. Например, строительство дома на пустом участке, создание нового приложения, которое не требует множества интеграций в инфраструктуру, производство рекламного ролика или открытие еще одного сетевого магазина в новой локации. В этих случаях действительно можно сделать хороший план и реализовать его с достаточной степенью контроля. Программы и их результаты встраиваются в существующие организационно-технические ландшафты проблем и решений (Халл Э., Джексон К., Дик Д. Инженерия требований. – Litres, 2019.), программы почти всегда реализуются в браунфилд, обременены наследственностью, требуют преемственности и учета существующих интересов наравне с новыми. Утопический замысел создателей встретится с повседневными рутинными практиками и они его раздавят, преобразят и поглотят. В результате любой план является гипотезой, которую надо проверять действием.
Продуктовые фреймворки, основанные на планировании, несмотря на свою успешность, не решают многих проблем, возникающих именно на запуске проекта.
Они работают на уровне поставки конкретного продукта, но перестают работать на уровне сложных переплетений всего проекта. Да и на уровне продуктов есть множество проблем с реализацией замысла. Поэтому проектный замысел должен порождаться и реализовываться многими участниками, а не небольшой группой из 2-3 человек (допустим, владелец продукта, руководитель проекта, спонсор), как это происходит в случае PDCA.
Политика, которая возникает при запуске проекта - это хаос, организованный, неорганизованный или дезорганизованный. Управлять этим хаосом нельзя, можно только направлять его развитие, а для этого необходимо постоянно изучать ваш конкретный хаос.
Чтобы изучать хаос, нужна оптика, чтобы увидеть его внутреннюю структуру. Нужен трафарет, через который вы посмотрите на мир вашего проекта и увидите структуру. Хаос каждой организации, каждого предприятия индивидуален, поэтому каждый менеджер должен стать исследователем своего проекта, если он хочет направлять ее развитие.
----------------------------------------------------------------
Цикл [[D-RCSA-P]] нацелен на создание решений, которые будут выживать в существующем ландшафте и будут изменять его в нужном направлении.
Он постоянно дает информацию, необходимую для защиты программы от давления окружающей среды и атак конкурентов за ресурсы проекта. Он преодолевает сопротивление постоянным давлением и мягкой силой, а не жесткой волей спонсора. Он основан на практиках системной инженерии, которые я развернул на 180 градусов, и теперь это не системная инженерия, а системный реинжиниринг.
И если вы думаете, что времени и сил на освоение нового подхода нет, то у меня для вас хорошие новости - скорее всего это время и силы появятся, если вы освоите рутинные практики цифрового минимализма.
Если вы думаете, что нет технологий, то они есть
Если вы думаете, что нет курсов, то они есть
Первый сигнал проблем в проекте - это фраза "Верь мне, я знаю, что делаю"
Начнем с самого главного - с хаоса, политики и постоянно улучшающегося самообмана, в котором живут организации. Без понимания этих проблем изучение цикла исследования действием будет пустой тратой времени.
Я начну со случая, описанного Chris Argyris. Flawed Advice and the Management Trap: How Managers Can Know When They’re Getting Good Advice and When They’re Not, 2000, p.53. Это типовая ситуация, которая знакома большинству из нас, надо только подставить вместо дирекции по ИТ другое подразделение, поставщика или проектную группу.
Исполнительный директор крупной компании по производству электроники сказал директору по ИТ, что в департаменте ДИТ существует большая проблема. ДИТ обходился компании слишком дорого, в нем было слишком много народа, которые с точки зрения других отделов не оправдывали своего существования.
Исполнительный директор сказал директору по ИТ, что проблема всплывает уже не в первый раз и ему начинает надоедать отсутствие прогресса в ее решении. И если ДИТ не улучшит качество своих сервисов и не снизит бюджеты, то ничего хорошего ждать не стоит, в департаменте просто появится новый директор, который наведет порядок.
Директор по ИТ созвал совещание, которое начал с того, что:
а) ДИТ не обеспечивает необходимую поддержку бизнеса
б) польза от ДИТ минимальна
в) бюджеты на ИТ постоянно растут
Директор видел решение в том, чтобы обеспечить пользователей и внутренних заказчиков необходимыми сервисами и полнее удовлетворять их потребности. Для этого создать план разработки продуктов и план выпуска доработок в существующих системах.
Сотрудники ДИТ ответили ему на это так:
а) мы уже озабочены потребностями бизнеса
б) но бизнес сам не знает, чего он хочет
в) бизнес понятия не имеет, сколько времени занимает реализация их запросов, им все надо вчера
г) нас задрали их бесконечные жалобы
д) ресурсов не хватает, мы все перегружены
Директор ответил на эти реплики следующим:
Раз у нас нет согласованного плана разработок, то мы не можем обсудить то, как мы используем имеющиеся ресурсы.
В этой ситуации у нас есть два выбора - то, к какой категории мы приписываем проблему, определяет варианты решений. Первый - ничего не менять в своей работе, и я думаю, что это нас приведет к катастрофическим последствиям. Второй путь - вырваться из текущего порочного круга и начать действовать по другому.
(Директор пытается запустить проект трансформации)
Его подчиненные ответили тем, что поменять подход руководителей бизнес-подразделений не получится. Один из них сказал директору: "Хотите попробовать сами, да пожалуйста!"
Директор ответил: "Хорошо, если планировать бесполезно, то что вы предлагаете?"
- Его подчиненные уже на эмоциях повторили:
- а) проблему решить нельзя, потому что бизнес требовал, требует и будет требовать невозможного
- б) ДИТ и так работает на пределе, никакое планирование не поможет. Цитата: "Все стоящие специалисты покидают компанию. Починить это невозможно."
- В конце встречи директор воскликнул: "Мы должны исправить ситуацию потому что у нас нет выбора! Мы не можем называть себя взрослыми людьми, если не можем найти выход из сложившейся ситуации."
- Очевидно, что в этой ситуации все разочарованы, расстроены и не доверяют друг другу. Вследствие этого они строят разговор таким образом, что никакой конструктивный диалог становится попросту невозможен. Например, они делают предположения в отношении руководителей бизнес-подразделений и дают им оценки так, что ничего нельзя проверить:
- Бизнес не знает, чего он хочет.
- Бизнес ставит задачи с нереалистичными сроками.
- Когда мы укладываемся в эти нереалистичные сроки, они требуют еще более нереалистичные сроки.
- Проблему нельзя решить потому что бизнес попросту неисправим.
- Директор с одной стороны хочет, чтобы его подчиненные начали сотрудничать, а с другой не хочет выглядеть несправедливым. В отличие от своих подчиненных он скрывает свои чувства и выглядит спокойным и рассудительным, хотя когда я попросил его написать на листке бумаги свои мысли в тот момент, он зафиксировал следующее:
- Это какой-то детский сад
- Они не понимают, как себялюбиво выглядят их претензии
- Мне иногда хочется вызвать их родителей на серьезный разговор. Им надо повзрослеть или всех нас уволят.
- Когда я спросил его, почему они всего этого не сказал вслух, он удивился: "Это бы только ухудшило ситуацию".
- Что интересно, когда я спросил подчиненных директора, что по их мнению он думал во время этого разговора, они слово в слово повторили все, что написал директор на листке. В реальности ему не удалось скрыть свои мысли и чувства от других.
- Что же произошло? Случилось то, что обычно случается на старте любого проекта. Надо решить две проблемы:
- саму бизнес-проблему, из-за которой и затеяли весь проект, и
- проблему, которая возникла из-за того, что люди защищают свои позиции, не доверяют друг другу, пытаются скрыть это недоверие от других и делают вид, что никакой проблемы в реальности нет и все работают в одной команде на общую цель
- Решение второй проблемы занимает куда большее количество ресурсов, чем решение первой, поэтому нечего и надеяться на то, что целей проекта можно достичь, не решив проблемы с недоверием внутри команды и самообманом.
- Вспомним, с чего все начиналось: бизнес-проблема заключалась в высоких затратах на ИТ и слабых результатах. Все согласились с описанием проблемы, но вот по разному определили причины ее возникновения. Директор по ИТ пошел на встречу с тремя предположениям как провести эффективное совещание:
- Я должен провести совещание так, чтобы мои цели и задачи были выполнены. Мое определение успеха заключается в том, что подчиненные разработают убедительный для моего руководства план по снижению затрат.
- Для меня важно вовлечь подчиненных в разработку плана. Тогда у них будет мотив выполнить его.
- Если подчиненные будут недовольны моими действиями, я должен подавить свои чувства и сосредоточиться на рациональных вещах, например, на разработке плана. Чувствам можно дать волю, когда я останусь наедине с собой.
- Подчиненные думали аналогично. Они чувствовали, что должны предлагать решения. Их определение успеха заключалось в том, что директор должен был понять, что корнем проблемы были руководители бизнес-функций. Кроме того, они считали, что директор должен активнее продвигать интересы ДИТ перед топ-менеджментом. И он считали, что их аргументация была абсолютно рациональной, а голос они повышали только для того, чтобы донести всю важность и серьезность ситуации до директора.
- ------------------------------------------
- Как видим, стратегии директора и его подчиненных были очень похожими:
- Высказаться по поводу ситуации двусмысленно либо противоречиво
- Вести себя так, будто никаких проблем с логикой высказывания нет
- Сделать двусмысленность или противоречивость высказывания необсуждаемой
- Сделать необсуждаемость необсуждаемой.
- Мы часто видим такое поведение, например, однажды топ-менеджер сказал мне следующее: "Мы хотим, чтобы вы были применяли инновационные подходы и не боялись рисков. Мы даем вам свободу действий. При этом, конечно, мы ожидаем, что вы не допустите возникновения проблем или неприятностей для компании".
- Другими словами, все участники этого совещания находятся в режиме модели 1
- Они ставят цели и пытаются их достичь, а не пытаются выработать совместное понимание успеха
- Максимизируют выигрыш и минимизируют проигрыш, а значит, воспринимают любое изменение своих целей как признак слабости
- Не показывают отрицательных эмоций, т.к. считают их признаком некомпетентности, недипломатичности или неспособности справиться с ситуацией
- Рассуждают и ведут себя рационально, остаются объективными, рассудительными и подавляют чувства
- Чтобы достичь этих результатов люди пытаются:
- Выстраивать ситуацию и контекст самостоятельно, с полным контролем происходящего, планировать в секрете от всех, убеждать других в верности своей оценки ситуации
- Владеть повесткой и контролировать задачи
- Защищать себя, выражаться абстрактно и обтекаемо, не упоминать конкретные случаи, скрывать свои чувства и мотивацию
- Беречь чужие чувства и решать самостоятельно, что надо знать человеку, а чего не надо, не давать всю информацию, врать во благо, имитировать благодушие.
- Другими словами, они делают все, чтобы сказать окружающим: "Верьте мне, я знаю, что делаю".
- Но такое поведение не позволяет нам научиться ничему новому. Эксперт - это тот, кто знает все, чему он может научиться, тем более не у других экспертов? А в проектах приходится учить что-то новое по определению, в проектах нельзя быть абсолютно уверенным в своих знаниях и навыках. Поэтому хотя успешная реализация стратегии "Верьте мне, я эксперт" позволяет контролировать ситуацию, сохраняет репутацию и авторитет, за это приходится платить высокую цену - люди воспринимают такую позицию как жесткую, необсуждаемую и мало доверяют людям, которые занимают эту позицию. Проектная группа теряет способность учиться, а вместе со способностью учиться теряет способность сделать проект.
- Модель мышления №1
- Тут надо сказать пару слов про способность к обучению. Люди и организации стремятся к эффективности своих действий. В случае, когда надо сделать что-то нестандартное, выполнить не рутинный проект, люди и организации привлекают консультантов, ученых и опытных менеджеров. И привлеченные специалисты дают советы как поступать в той или иной ситуации, учат команду новому. Советы бывают разными - некоторые выглядят привлекательно, некоторые сомнительно. Но большая часть даже привлекательных, интересных советов нереализуема. Слишком много общих слов, идей, нестыковок и логических скачков. Большинство советов и рекомендаций просто слишком далеки от реальности и их нельзя привязать к конкретному контексту конкретной деятельности.
- Это возникает потому, что в основе этих рекомендаций лежат не выраженные явно, но мощные предположения и гипотезы о том, что такое эффективное действие. И эти предположения и гипотезы, когда их применяют в нестандартных проектных ситуациях, как раз и приводят команду и самих экспертов к неспособности учиться. Эти предположения и гипотезы, Модель мышления №1, делает советчиков слепыми не только по отношению к нестыковкам в своих рекомендациях, но и заставляет их не замечать собственную слепоту. Плохие, нереализуемые советы не есть результат их низкой квалификации. Они просто профессионалы по ошибкам, отточившие свой навык до совершенства.
- И это не голословное утверждение, десятки лет исследований показали, что мы все в массе в основном используем Модель мышления №1. И именно эта модель мышления определяет то, как работает большинство организаций и предприятий. В основу работы изначально заложены шаблоны мастерского игнорирования и профессионального совершения и сокрытия ошибок, прикрытых сверху заведенным порядком, который защищает нас (и в особенности руководство) от последствий ошибок и наказания. Поверх этого всего еще и действует запрет на обсуждение этих шаблонов и заведенных порядков. А поверх этого запрета действует запрет на обсуждать этот запрет.
- И эта организационная слепота:
- а) прекрасно работает
- б) не требует сил и времени на исполнение
- в) принимается за должное (мастерство не пропьешь)
- г) работает на автомате и бессознательно
- Разберем, что же произошло на совещании:
- Как видим, обе стороны включили Модель мышления №1, настаивают на верности своей позиции, не слышат и не видят другую сторону. Стратегия "по умолчанию" работает.
- Высказаться по поводу ситуации двусмысленно либо противоречиво
- Вести себя так, будто никаких проблем с логикой высказывания нет
- Сделать двусмысленность или противоречивость высказывания необсуждаемой
- Сделать необсуждаемость необсуждаемой.
Модель мышления №2 - выход из тупика организационной слепоты, постоянно улучшающегося самообмана в конструктивный диалог с помощью цикла исследования действием.
Но прежде, чем мы перейдем к изучению цикла исследования действием [[D-RCSA-P]] применительно к управлению проектами, нам надо развенчать основной миф проектного управления, нашу основную анти-компетенцию. Главный миф проектного управления - нам нужен какой-то подход или инструмент для планирования и контроля исполнения проектов. PMBOK, Agile, канбан, Скрам, SAFe, MS Project, JIRA, Trello, Wrike. Проблема не в планировании и не в коммуникации и не в подходах. Проблема в том, что мы не умеем читать, понимать и исполнять даже свои проектные планы, не говоря уже о планах, которые частично или полностью составили другие. Мы обращаемся с планами проектов точно также, как с планами покупок в магазинах, планами поездок, планами продаж и графиками выхода на работу. Да, планы регулярной, рутинной деятельности очень-очень похожи по виду на проектные планы. Но работать с ними надо кардинально по-другому, там свои лайфхаки.
Комментариев нет:
Отправить комментарий