🍉Всех с пятницей)) #Мотивация

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

😮 Я всегда учу через «почему»

Только разобравшись в причине, я по-настоящему понимаю, как работает система целиком — собственно, поэтому я в своё время и выбрала профессию инженера.

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

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

🙂Столкновение с реальностью

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

Один знакомый эксперт, который на тот момент работал в проектном офисе на очень высоком уровне государственного управления, прочитал несколько постов и сказал прямо:

«Ты рассказываешь как. Расскажи зачем».

Он предложил пример: "по полям, по полям синий трактор едет к нам 🚜. Он уже едет — это все видят. А почему? Куда? Надолго ли у него хватит ресурса, чтобы доехать?"

📝Как говорит мой руководитель, «осознать!» 🙂

Я решила перестроить подачу — писать посты, которые должны подтолкнуть не копировать шаблон устава или реестра рисков, а разобраться, зачем эти (и не только) инструменты вообще нужны. А ещё делиться личным опытом реализации проектов на стыке гранта, технологий и людей.

👀Почему так?

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

И еще, возможно, дело не в подаче, а в том, что мотивация разобраться «почему» должна родиться изнутри, или через преодоление :), а не быть предложенной, даже самой удачной метафорой снаружи. 😳

💬 А вам приходилось учить кого-то — и обнаруживать, что это не работает так, как сработало на вас?

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

Пример к посту

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

💚#Лидерство

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

#команда

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

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

Классическая кривая роста стоимости устранения дефекта по этапам жизненного цикла:

- На этапе концепции — условная «1x», поправить формулировку требования.

- На этапе разработки и проектирования — уже в 3–6 раз дороже: переделать часть модели, пересчитать смежные узлы.

- На поздних этапах — тестирование, эксплуатация — цена исправления той же ошибки вырастает до 500–1000 раз против концепции.

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

Та же самая ошибка, найденная при трассировке требований на старте проектирования, стоила бы правки одного пункта спецификации.

Отсюда и статистика причин переделки в инженерных проектах:


30% — неверные или неполные требования,

13% — сознательное отклонение от них ещё на старте.

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

Управленческий вывод простой и неприятный: экономия на трассируемости требований и ранней проверке на этапе концепции — это не экономия, а перенос той же стоимости, умноженной на сотни, на конец проекта, где её уже не спрятать.

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

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

💚 #Лидерство

У любого руководителя есть привычный баланс между ориентацией на задачу (директивность, контроль, результат здесь и сейчас) и ориентацией на отношения (диалог, вовлечение, развитие людей).

😯Комбинация даёт 4 базовых стиля — и у каждого есть эффективная версия, когда он совпадает с ситуацией, и неэффективная, когда применяется не к месту:

🟢низкая ориентация на задачу, высокая на отношения — Наставник, уместен с компетентной и мотивированной командой, которой не нужен надзор; та же мягкость там, где нужны структура и контроль, — уже Миссионер

🟢высокая ориентация и на задачу, и на отношения — Руководитель, ставит задачи и вовлекает одновременно; та же попытка совместить всё и сразу там, где нужен один чёткий приоритет, — уже Соглашатель

🟢высокая ориентация на задачу, низкая на отношения — Благожелательный автократ, директивен по делу без лишнего давления, уместен в авральных и ресурсно ограниченных ситуациях; та же директивность там, где команде нужны диалог и развитие, — уже Автократ

🟢 низкая ориентация и на задачу, и на отношения — Бюрократ, держит регламент там, где процесс и должен быть стабильным; та же отстранённость там, где нужна вовлечённость, — уже Дезертир

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

Какой из этих 8 стилей — ваш стиль по умолчанию, и совпадает ли он с тем, что реально нужно вашей текущей команде?

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

💚Всех с пятницей! Покидайте мемов))

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

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

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

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

😵‍💫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