Проект шёл по плану до совещания, на котором человек, чьей подписи никто даже не искал, заблокировал работу одной фразой:

"Я об этом ничего не знал"

Его просто не сочли достаточно важным, чтобы включить в карту стейкхолдеров.

😵‍💫Power/Interest Grid делит людей по власти и интересу:

🟢Высокая власть + высокий интерес — активно вовлекать

🟢Высокая власть + низкий интерес — держать удовлетворённым

🟢Низкая власть + высокий интерес — информировать

🟢И то, и другое низкое — минимальный мониторинг.

😐Типология Сэвиджа добавляет разрез «друг/враг/нейтральный».

👨‍🍳А Salience model — ещё и легитимность и срочность требований, помимо власти.

Тот заблокировавший проект человек не был формально главным по иерархии — но контролировал нужный ресурс, имел законное право влиять и, как оказалось, реагировал быстро.


Все 3 признака совпали — а карту стейкхолдеров строили только по должностям.

У себя в проектах карту стейкхолдеров теперь всегда сверяю не по оргструктуре, а по вопросу «кто может сказать нет на любом этапе» — список от этого обычно длиннее, чем ожидаешь на старте.

💬 Был у вас случай, когда «неважный» по должности человек оказывался неожиданно ключевым для судьбы проекта?

Подробнее💚в статье Дзен
💚Подписаться на ProPM_Hub

Команда, с которой я работала над одной из грантовых заявок, две недели не выходила из архитектуры решения.

А когда наконец сели считать заявку по методике оценки, оказалось: раздел, на который потратили меньше всего времени, весит в итоговом балле больше, чем вся техническая часть вместе взятая 😞.

📝Всего критериев 8
🟢Потенциал тиражирования — 50%.
🟢Окупаемость, соответствие приоритетным направлениям и применение ИИ — по 10%.
🟢Остальные четыре — по 5%.

Грантодателю не так важно разовое внедрение у одного заказчика — важно, что решение можно масштабировать на всю отрасль.

💚Заявка, где «потенциал тиражирования» — одна строка, и заявка с письмами о заинтересованности от нескольких заказчиков и конкретным типом тиражирования — это две разные заявки по баллам, даже при одинаково сильной технической части.

💬 Если бы вы сейчас распределяли время, уже потраченное на текущую заявку, по критериям с их весами — совпало бы это распределение с тем, как реально весит в оценке?

Подробнее 💚в Дзен
💚TG ProPM_Hub

💚Всех с пятницей))

💚Дзен
💚Присоединиться к ProPM_Hub

«Не бойтесь, что компьютер станет думать, как человек. Бойтесь, что человек станет думать, как компьютер» ))

🤖 Раз в несколько месяцев в комментариях под постами на PM-тематику всплывает один и тот же вопрос: а зачем вообще нужен руководитель проекта, если скоро всё это будет делать ИИ? Обычно вопрос звучит с иронией, но за ней — реальная тревога, и я не буду делать вид, что её не существует.

У меня нет теоретического ответа — только практический. Последние месяцы я осознанно разбираюсь, что именно ИИ умеет делать в моей работе, а не гадаю абстрактно. Вот что реально изменилось.

🎮Что забрал: черновик письма с нуля — раньше 20 минут форматирования мысли, теперь 3 минуты правки готового черновика. Разбор длинного протокола совещания на конкретные пункты и ответственных. Первый проход по объёмному документу — отчёту, ФЭО, комплекту ТЗ — прежде чем читать его самой целиком. Рутинные структурные задачи, которые раньше съедали часы, а по сути не требовали моего суждения — только внимательности.

😤Что не забрал и, подозреваю, не заберёт:

🟢Решение, кому именно позвонить первому, когда пилот начал буксовать, — заказчику, у которого испортится настроение, или подрядчику, у которого есть решение, но нет полномочий его принять.

🟢Понимание, что молчание конкретного человека на совещании — не согласие, а сигнал тревоги, потому что я знаю его манеру уже три года.

🟢Умение сказать «нет» руководству, когда это нужно, и просчитать, как именно это сказать, чтобы услышали.

Ни одна из этих задач не решается лучшим промптом — они решаются контекстом, которого нет ни в одном документе, потому что он живёт в отношениях между людьми.

📱Здесь, кстати, ничего принципиально нового:
RFM-анализ в Excel, автогенератор писем на макросах, дашборды загрузки команды в Superset — я осваивала новые инструменты для той же самой работы и до всякого ИИ, и каждый раз рутина уменьшалась, а не моя роль. Разница с ИИ — не в характере изменения, а в его скорости.

Вывод простой и не претендует на пророчество:
ИИ хорошо забирает то, что в работе было структурным трудом, а не суждением.

Чем больше в вашей роли РП именно суждения — согласовать интересы, взять на себя ответственность за нечёткое решение, удержать доверие команды в сложный момент — тем меньше причин для тревоги и тем больше причин научиться делегировать инструменту рутину, чтобы освободить время именно на это.

💬 А что из вашей работы РП уже забрал ИИ — и что вы бы никогда ему не доверили?

💚Дзен
💚TG ProPM_Hub

Про технологии или про конкретного человека?

🏭 Было. Производственный завод вёл технологическую подготовку по большей части на бумаге и в разрозненных файлах: техпроцессы существовали в головах нескольких опытных технологов, чертежи и маршрутные карты жили в разных папках без единой версии, а требования военной приёмки к хранению документов выполнялись вручную — с риском ошибиться при любой проверке.

🎮Стало. После проекта комплексной автоматизации — единое цифровое пространство для формирования и хранения технологических процессов по переделам, с автоматизированным контролем соответствия требованиям приёмки. Больше 50 автоматизированных рабочих мест, где раньше было ручное сопровождение.

Разница между «было» и «стало» здесь не в том, что появилось модное ПО. Она в том, что знание, которое раньше существовало только в головах нескольких людей, стало воспроизводимым процессом — и теперь не исчезает вместе с уходом конкретного технолога на пенсию.

Похожая логика — и в других проектах: например, там, где раньше данные о производстве собирались вручную по цехам, после внедрения единой информационной среды с подключением производственного оборудования к системе управления эти данные стали доступны в реальном времени, а не по итогам месяца.

🔗Общий урок из обоих кейсов: цифровизация производства редко проваливается на технологии. Она проваливается там, где не формализован процесс — то, что раньше держалось на памяти конкретных людей.

📝 А в вашей практике «было/стало» — это чаще про технологию или про то, что раньше держалось на конкретном человеке?

💚Дзен
🔗TG ProPM_Hub

🎮 #Мотивация

💚Дзен
💚Подписаться на ProPM_Hub

В начале карьеры я гордилась тем, что могу лично разрулить любую ситуацию в проекте: сорвался поставщик — договариваюсь, заказчик недоволен — еду, что-то не срослось у команды — доделываю, чтобы не подвести.

💚Со стороны это выглядело как надёжность. По факту это была геройская модель управления — и она давала результат ровно до тех пор, пока ситуация не начинала растягиваться на месяцы, а не на один аврал.

Издержки геройства оказались не там, где я их искала:

💚 Истощает самого героя
«Маска позитива» и постоянная готовность решать чужие проблемы забирают ресурс быстрее, чем кажется, — усталость копится незаметно, пока однажды не оказывается, что сил решать проблемы уже нет, а привычка тянуть всё на себе осталась.

💚 Лишает команду ответственности
Люди быстро привыкают, что «руководитель всё решит», и перестают предлагать свои варианты — не потому, что не способны, а потому что зачем, если решение всё равно найдётся.

💚 Маскирует системные проблемы
Пока герой лично закрывает каждую дыру, у процесса нет стимула становиться устойчивее — «заплатки» держатся, пока держится сам герой, а причина, почему дыры вообще появляются, никуда не девается.

Геройство работает на коротком отрезке — в конкретном аврале это иногда правда единственный рабочий вариант. Но если ситуация растягивается, герой не успевает восстановиться, начинает ошибаться и «сдувается» эмоционально — и тогда рискует уже не только он, а вся команда и результат проекта.

💬 А вы замечали за собой этот момент — когда геройское «я разрулю» стало не помощью, а способом снижения ответственности у команды?

Подробнее 💚в Дзен
💚TG ProPM_Hub

В 1990-х журналист Vanity Fair Майкл Карузо предлагал редактору идеи статей во время поездок в лифте — потому что поймать её на дольше было нереально. Отсюда термин elevator pitch: 30 секунд — 2 минуты, ровно время поездки в лифте.

Работает не только для инвесторов. 3 вопроса, которые укладываются в 30 секунд:

💚Кто ты — не должность из трудовой, а роль, понятная незнакомому человеку.

💚Какую проблему решаешь — не «чем занимаюсь», а «что было бы плохо без меня».

💚Чем подтверждено — факт или цифра, а не самооценка.

Полтора года назад мой ответ на «чем вы занимаетесь» звучал так: «руковожу приоритетными проектами, у нас гранты, PLM-системы, ОПК...». Это было честно, но не питч — список обязанностей, а не ценность.

Сейчас та же суть в одной фразе:

«Довожу сложные проекты цифровизации и импортозамещения до результата — там, где обычно рвётся: на стыке гранта, технологии, людей и партнёрской сети».

И цифра для 3го вопроса: в 2025 году направление дало 80%+ выручки дирекции с эффективностью в разы выше среднего по каналу.

Где это пригождается не только «в лифте»:
🟢 на стартовом совещании нового проекта, когда представляетесь команде и заказчику

🟢 в первую минуту разговора с новым ЛПР на площадке заказчика — второй попытки произвести впечатление не будет

🟢на собеседовании — но в обратную сторону: та же формула хорошо диагностирует кандидата.

А как звучит ваш ответ на «чем вы занимаетесь», если времени — 30 секунд? Пишите в комментариях.

Подробнее 💚в статье Дзен
💚TG ProPM_Hub

Задачи считают по штукам, а работу — по часам
 
📱 Один тикет — «поправить текст на кнопке». Другой тикет — «переписать интеграцию с внешним API, которая ломается на граничных случаях».

В трекере оба выглядят одинаково: одна закрытая задача. Если руководитель считает загрузку по количеству тасков, разработчик, который взял на себя вторую задачу, на дашборде выглядит менее продуктивным, чем тот, кто закрыл десяток мелких правок.

 
📱Мы столкнулись с этим при доработке внутреннего Task Tracker: считать загрузку «по головам задач» оказалось системной ошибкой, которая демотивирует именно тех, кто берёт сложные куски работы.
 
📝Решение — не тайм-трекинг (просить разработчиков ежедневно расписывать часы — отдельный источник раздражения и вранья), а весовой справочник трудоёмкости: каждый тип задачи заранее оценён в условных единицах (S/M/L), и дашборд загрузки суммирует не количество тасков, а их вес.
 
Это меняет разговор о загрузке в принципе: «у тебя мало задач» перестаёт значить «у тебя мало работы», если одна из этих задач весит как пять простых. И у руководителя появляется честная картина, кто реально перегружен, а кто просто закрывает тикеты быстрее, потому что они легче.
 
🥵Как у вас в команде считают загрузку — по количеству задач, по часам через тайм-трекинг, или как-то ещё?

 💚Дзен
🔗Присоединиться к ProPM_Hub

В срок и в бюджет — ещё не значит успех

Одна из самых частых ошибок, которые я вижу и в грантовых проектах, и в обычных ИТ-внедрениях, — путать «сдано в срок и в бюджет» с «проект удался»

🤔Разберу на двух типичных, обезличенных ситуациях:

🟢Проект «А» — классика: сроки соблюдены день в день, бюджет не превышен ни на рубль, все акты подписаны.

🟢Проект «Б» — с виду провал: исходная гипотеза не подтвердилась, срок сдвинулся на полгода.

По формальному критерию (треугольник время / бюджет / содержание) «А» — безусловный успех, «Б» — провал.
А по факту чаще выходит наоборот: продукт «А» реально используют на 10% от заявленного охвата, потому что требования собирали без участия будущих пользователей.
А «Б» после переформулировки задачи дал патентоспособный результат и новый, куда более перспективный виток финансирования.

Путаница в том, что один и тот же проект мы меряем по разным линейкам, не признаваясь себе в этом.

🙃Удобное разделение предложил ещё в 2002 году исследователь Кук-Дэвис:

успех управления проектом (сроки/бюджет) — одно измерение, успех самого проекта (реально ли он решил проблему) — совсем другое.

На практике их путают чаще, чем кажется, — особенно на защите итогов перед руководством, где красивые цифры по срокам легко прикрывают то, что продукт никто не использует.

🕵️‍♀️Для НИР-проектов этот вопрос ещё острее:
добросовестно полученный отрицательный результат — тоже валидный итог этапа, а не провал.

Мерить научный поиск по ИТ-линейке («не уложились в срок — плохо») — системная ошибка, которую я регулярно вижу у заказчиков грантовых НИОКР.

💚 А вы как определяете для себя, что проект «удался» — по факту сдачи, или через полгода-год после?

💚Дзен
💚TG ProPM_Hub

Карандаш, бумага и... лист с ценностями!

Когда меня когда-то собеседовали, руководитель не спросил про диплом. Взял лист бумаги, карандаш ✏️, схематично нарисовал рабочую задачу — и попросил решить. Потом ещё одну. Оффер пришёл в тот же вечер.

Я уже тогда понимала: резюме показывает, что человек умеет рассказывать об опыте. А задача вживую — умеет ли он этим опытом пользоваться.

Через год руководитель прислал мне лист «Ценности» — 11 позиций разбросанных хаотично на листе (карьерный рост, вознаграждение, руководитель, коллеги, престиж компании, ответственность, рабочее время и др.), которые нужно было расставить по убыванию значимости. Совпали почти все верхние позиции — и это многое объяснило про то, почему мы так легко сработались.

Теперь, когда подбираю людей сама, обязательно использую 3 фильтра:
🟢Хард-скилы — стандартное тестирование.
🟢Живая задача — не вопрос про прошлый опыт, а решение здесь и сейчас, без подготовки.
🟢Тест на ценности — совпадение верхних позиций с командой.

Закономерность подтвердилась на практике: если ценности не совпадают, человек всё равно уходит через полгода-год.

Хард-скилы можно дорастить, ценности — почти никогда не удаётся «подогнать» задачами или деньгами.

P.S. Ценности на обложке к посту приведены рандомно))

🤫А как вы проверяете кандидата — только по резюме и опыту, или тоже что-то смотрите вживую?

💚Дзен
🔗Присоединиться к ProPM_Hub

Один и тот же инженер оказался обещан трём разным руководителям проектов

😱На одну и ту же неделю — каждый был уверен, что его задача в приоритете. Разрешилось это не переговорами, а тем, что инженер не успел ни на одну задачу вовремя, и все три проекта сдвинулись одновременно.

Если ресурсы обещают разным РП без учёта общей загрузки, приоритет решает «кто громче попросил», а руководители тратят время на выбивание ресурсов друг у друга — это не проблема людей, это симптом отсутствия корпоративной системы управления проектами.

Конфликт на уровне «внутри одного РП с несколькими проектами» решается его личной приоритизацией.

👊Конфликт между разными РП за общий ресурс — только через governance-механизм: спонсора или комитет, который сравнивает проекты по единым критериям (инвестиционная пирамида McFarlan — от «обязательных» до «экспериментальных»), а не личными договорённостями.

Проектный офис — не отдел отчётности, а конкретный ответ именно на эту проблему.

💬 В вашей компании такие конфликты решаются формальным механизмом приоритизации, или каждый раз заново — переговорами и связями?

💚Дзен
🔗Подписаться на ProPM_Hub

Двух РП сравнивали на летучке

— не чтобы унизить, а чтобы понять, почему при похожих проектах результаты разные.

👊Один почти не появлялся у команды: присылал дашборды, требовал отчёты. Другой почти жил на площадке, разруливал блокеры в моменте, но плохо помнил, что там с бюджетом.

Оба искренне считали, что управляют проектом. Оба ошибались — в противоположные стороны.

Организация исполнения отвечает на вопрос «что сделать прямо сейчас, чтобы план сработал» — от плана к действию. Контроль исполнения — «соответствует ли происходящее плану» — от факта назад, к плану.
😯Первый РП управлял только через отчёты, не вмешиваясь в реальную работу: контроль был, исполнения не было.
📱Второй тушил пожары вручную, не сверяясь с метриками: исполнение было, контроля не было.

PMBOK явно говорит, что эти 2 процесса идут параллельно, а не по очереди — именно поэтому их легко перепутать, в отличие от инициации и закрытия, разнесённых во времени.

💬 Что из двух ближе вам — управлять через отчёты или через личное присутствие на площадке?

💚Дзен
💚TG ProPM_Hub

💚Всех с пятницей))

💚Дзен
💞Присоединиться к ProPM_Hub