А теперь представьте, что продавцу каждый раз приходится искать следующий контакт для прозвона: фильтровать массу карточек в разных статусах, удерживать концентрацию, чтобы не отвлечься на более приятные задачи...<\/p>\n
Как вы думаете, какова будет продуктивность по сравнению с первым сценарием?<\/p>\n
Во всех интерфейсах систем, которые предназначены для работы с задачами, стремитесь к однозначности:<\/p>\n
- \n
- У каждого члена команды есть одна ссылка, на которую он нажимает, чтобы увидеть свои задачи.<\/li>\n
- На доске нет мертвых задач, настроены быстрые фильтры.<\/li>\n
- Все формулировки задач предельно однозначны, и подсказывают, что нужно сделать.<\/li>\n<\/ul>\n
А у вас в таск-трекере порядок?<\/p>\n", "date_published": "2023-05-23T13:57:25+00:00", "date_modified": "2023-08-02T07:40:17+00:00", "_date_published_rfc2822": "Tue, 23 May 2023 13:57:25 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "126", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "59", "url": "https:\/\/blog.skalon.me\/all\/kak-minimizirovat-organizacionnoe-soprotivlenie-pri-vnedrenii-pr\/", "title": "Как минимизировать организационное сопротивление при внедрении проектного управления: подход «блэк бокс»", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/blackbox2@2x.png\")
\n<\/div>\nМой первый опыт внедрения проектного управления в компании был провальным.<\/p>\n
Я руководил проектным офисом — подразделением компании, отвечающим за разработку методологии проектного управления, формирование портфеля проектов, сбор отчетности по проектам и т. п. Я пытался заставить руководителей и кураторов проектов, не подчинявшихся мне напрямую, работать по новым правилам, например — проводить планерки по-новому, а они мне говорили: «Вася, ты будешь нам рассказывать, как планерки проводить? Мы и так отлично справляемся».<\/p>\n
Тогда я выяснил (а потом убеждался не раз), что проектный офис в компании находится в довольно слабой позиции, и даже мандат от первого лица не бесконечен.<\/p>\n
На основе того опыта я выработал подход к внедрению, который с тех пор применял много раз, и который полезен при внедрении многих организационных изменений. Сегодня поделюсь им с вами.<\/p>\n
Проектный офис часто «лезет не в свое дело»<\/h2>\n
Часто я вижу, как представители проектного офиса лезут в проекты с «добрыми советами»: пытаются обучить, заставить правильно проводить планерки, управлять рисками и т. д.
\nКогда на неё нет запроса, эта работа проектного офиса воспринимается как то, что он лезет, куда не просят, и говорит: «Вы неправильно живете» — проект неправильно оформили, не по процедуре, и т. д. Это как минимум раздражает, даже если правда.<\/p>\nИ если потом функциональные руководители приходят к биг боссам жаловаться на проектный офис, их административный вес обычно будет больше, даже если проектный офис прав. Потому что за каждым из функциональных руководителей стоит какая-то часть бизнеса, дающая очень конкретный и обычно измеримый вклад в общее дело. А проектный офис «координирует остальных участников», «задает правила игры»... а как конкретно помогает зарабатывать — очень сложно посчитать.<\/p>\n
Поэтому часто проектный офис скатывается в роль секретаря принеси-подай, бегает с жалобными глазами за руководителями, которые от него отмахиваются.<\/p>\n
Надо четко очертить границы проекта и не лезть в них<\/h2>\n
Мой инсайт заключался в том, чтобы представить себе проекты в качестве «черного ящика»: не важно, что происходит у него внутри, как именно руководитель проектов руководит. Но мне важны входы и выходы черного ящика. Моя линия аргументации примерно такая:<\/p>\n
- \n
- Компания инвестирует в проект определенные ресурсы. В обмен ожидает получить результат должного качества в согласованные сроки и бюджеты.<\/li>\n<\/ol>\n
- \n
- Для этого надо согласовать требования к результату, согласовать сроки и бюджеты. Это удобнее всего сделать с помощью паспорта проекта, реестра результатов с требованиями, графика контрольных точек (не принимайте за универсальный рецепт). Требования к этому оформлению вот такие (и я могу их обосновать<\/a>).<\/li>\n<\/ol>\n
- \n
- Проекту нужны коммуникации с руководством и промежуточный контроль — все это понимают, все взрослые люди. Поэтому раз в период вы будете предоставлять отчетность вот по этой форме. Она единая для всех проектов, руководству удобно ее смотреть, вам ее удобно предоставлять.<\/li>\n<\/ol>\n
- \n
- Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.<\/li>\n<\/ol>\n
Чего я этим добиваюсь?<\/p>\n
Во-первых, это очень справедливые требования, понятно, зачем они (обратите внимание, они полностью согласуются с конфликтной стратегией<\/a>). Они не вызывают отторжения, легко добиться их соблюдения.<\/p>\n
Во-вторых, этих требований минимально достаточно, чтобы четко очертить границы проекта и насколько возможно устранить основные неясности: что будем делать, кто должен делать, в какие сроки и т. п.<\/p>\n
В-третьих, этих требований достаточно, чтобы контролировать ход проекта «снаружи» через отчетность по контрольным точкам.<\/p>\n
Учить разумному, доброму, вечному можно только при наличии запроса<\/h2>\n
Благодаря тому, что границы проекта очень четко очерчены и выстроен качественный промежуточный контроль, любое нарушение быстро становится заметно.<\/p>\n
Например, не выполняется в срок контрольная точка из плана:
\n«2022-09-13 — Сдан в ОПЭ модуль „Бюджетирование“»
\nМы можем 13 сентября сходить в бухгалтерию, и посмотреть своими глазами, сдан модуль в эксплуатацию или нет. И вот уже у нас есть неоспоримый факт: не соблюдена контрольная точка, и разговор проектного офиса становится гораздо конкретнее, и от него так не отмахнешься.
\n— Не выполнили контрольную точку? Вы должны инициировать процедуру переноса сроков, эскалации и т. д.
\n— Систематически не выполняются контрольные точки? Вот вам рейтинг руководителей или КПЭ, вы в нем в красной зоне. И вот уже руководителю проектов сложно сказать «я таких проектов сделал сотни, не надо меня учить». Глядишь, он и сам приходит на вебинар по управлению сроками, рисками и т. д.<\/p>\nКонечно, это не единственное условие, чтобы проектный офис не посылали: надо уметь приносить ощутимую пользу как минимум руководству. Но из характерной для проектного офиса позиции «сбоку» это наиболее безопасный и надежный способ организовывать работу проектам: четкие границы и работа с фактами.<\/p>\n
К сожалению, я неоднократно сталкивался с тем, что проектный офис наступает на те же грабли, что и я когда-то: начинает с того, что пытается учить руководителей проектов, «сеять разумное, доброе, вечное» среди них, хочет «принести пользу руководителям, а не только заставить их заполнять бумажки»... и каждый раз это заканчивается абсолютно одинаково. Разумное, доброе, вечное не всходит, польза оказывается не востребована, очередная попытка внедрения проектного управления буксует.<\/p>\n", "date_published": "2022-09-13T18:40:08+00:00", "date_modified": "2022-09-13T18:39:28+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/blackbox2@2x.png", "_date_published_rfc2822": "Tue, 13 Sep 2022 18:40:08 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "59", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/blackbox2@2x.png" ] } }, { "id": "53", "url": "https:\/\/blog.skalon.me\/all\/esli-vy-chuvstvuete-chto-v-vashih-proektah-nedopustimo-mnogo-hao\/", "title": "Если вы чувствуете, что в ваших проектах недопустимо много хаоса, проверьте, возможно вы неправильно распланировали совещания", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/regular_meetings@2x.png\")
\n<\/div>\nКо мне часто обращаются менеджеры, которым надо «навести порядок», «вернуть чувство руля», «систематизировать бизнес». Симптомы типичны:<\/p>\n
- \n
- Каждый член команды усердно работает над своими задачами, но общий результат оказывается не достигнут.<\/li>\n
- Задачи ставятся и теряются, находятся тогда, когда уже поздно.<\/li>\n
- Очередной раз «перепрыгнули пропасть на 99%».<\/li>\n
- Менеджер чувствует, что проект «разъезжается»: в шквале текучки теряется фокус на результатах и поддерживать его требует огромных усилий.<\/li>\n<\/ul>\n
Одна из вещей, с которых я начинаю решать проблему, это настройка регулярных управленческих совещаний.<\/p>\n
Менеджер должен регулярно «проверять домашку», иначе все забьют<\/h2>\n
Вспомните школьные годы. Если вы точно знали, что вас спросят домашнее задание на следующем уроке, каковы были шансы, что вы его подготовите? Для большинства людей — близко к 100%. Для взрослых это работает так же.<\/p>\n
Система исполнения базируется на регулярных управленческих совещаниях, в ходе которых менеджеры систематически уделяют внимание тому, что происходит в их управляемом периметре.<\/p>\n
На этих совещаниях они неизбежно «спрашивают домашку», т. е. смотрят отчетность, в которой зафиксированы основные показатели: что планировалось сделать, что сделано, где прогнозируется отклонение и т. д.<\/p>\n
При этом повестка совещаний сформирована так, чтобы «охватить вниманием менеджера» все аспекты, требующие управления.<\/p>\n
Регулярные совещания должны охватывать разные горизонты и аспекты управления<\/h2>\n
На разных временных горизонтах от менеджера требуются разные решения: раз в квартал мы подводим итоги и планируем, раз в неделю мы «нарезаем планы» на задачи, раз в день — координируемся друг с другом.<\/p>\n
Также есть разные аспекты, которыми нужно управлять: сроки, закупки, риски, управление персоналом, качество и пр.<\/p>\n
Аспекты проиллюстрируем на примере рисков. Если мы в принципе планируем рисками управлять — выявлять, принимать меры, контролировать статус — то нам понадобится обсуждение рисков на совещании. В зависимости от того, насколько серьезно мы этим планируем заниматься, нам понадобится регулярная выделенная риск-сессия, или мы можем включить работу с рисками в повестку других совещаний.<\/p>\n
Также рисками можно управлять на нескольких горизонтах: выявлять риски проекта целиком, координировать действия по их предотвращению или подключать «план Б» на оперативном горизонте.<\/p>\n
Таким образом, настраивая систему управления на проекте я определяю, чем менеджер управляет и разрабатываю цикл управленческих совещаний, которые покрывают весь управляемый периметр.<\/p>\n
Как настроить график совещаний так, чтобы ничего не упускать?<\/h2>\n
Что значит, что цикл совещаний настроен? Это означает, что совещания проходят с заданной регулярностью и с должным уровнем качества. Для этого каждое из совещаний должно быть описано:<\/p>\n
- \n
- Регулярность, длительность, участники, роли участников<\/li>\n
- Типовая повестка<\/a><\/li>\n
- Материалы, в первую очередь — отчетность, заточенная под повестку<\/li>\n
- Правила подготовки (в виде чек-листов)<\/li>\n
- Правила проведения совещания (Например, как делаем доклад? Как поступаем, если возникла посторонняя тема в обсуждении? Предусмотрено ли вообще обсуждение на встрече?)<\/li>\n
- Правила обработки результатов (ведение протоколов и пр.)<\/li>\n<\/ol>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/regular_meetings_notion@2x.png\")
\n
- Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.<\/li>\n<\/ol>\n
- Проекту нужны коммуникации с руководством и промежуточный контроль — все это понимают, все взрослые люди. Поэтому раз в период вы будете предоставлять отчетность вот по этой форме. Она единая для всех проектов, руководству удобно ее смотреть, вам ее удобно предоставлять.<\/li>\n<\/ol>\n
- Для этого надо согласовать требования к результату, согласовать сроки и бюджеты. Это удобнее всего сделать с помощью паспорта проекта, реестра результатов с требованиями, графика контрольных точек (не принимайте за универсальный рецепт). Требования к этому оформлению вот такие (и я могу их обосновать<\/a>).<\/li>\n<\/ol>\n
- Компания инвестирует в проект определенные ресурсы. В обмен ожидает получить результат должного качества в согласованные сроки и бюджеты.<\/li>\n<\/ol>\n
![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table1@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table2@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table3@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table4@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/summary@2x.png.jpg\")
\n<\/div>\n