🔥 10 самых интересных публикаций по управлению проектами за 5–19 сентября (I) ++ 😭++ Когда ведущий аналитик превратился в мини-РП: признаки перегруза и как вернуть роль в норму Про ловушку сильного онолитега, которая начинается знакомо и невинно. Аналитик лучше всех знает проект — ну пусть заодно уточнит срок. Всё равно идет на встречу — пусть соберет состояние задач. Знает, где зависло согласование, — пусть проконтролирует. Через несколько месяцев именно к нему все ходят за состоянием проекта, он отвечает за сроки, которыми напрямую не управляет, а собственные требования дописывает вечером. Причем снаружи это легко принять за рост и доверие: человеку ведь поручают всё больше важного. Но стоп, а если завтра аналитик перестанет собирать состояния работ, напоминать о сроках и координировать людей, кто вообще должен этим заниматься? И если ответ — руководитель проекта, то где-то незаметно расползлись границы ролей.

😔 Внедрили систему управления проектами сразу всем — и получили саботаж. Как внутренний инструмент стал тиражным продуктом Очень хороший, особенно для одинесников, рассказ о внедрении системы управления проектами. Первому крупному клиенту дали всё сразу: единые правила, полный набор возможностей, учет задач, сроков, ресурсов — красота. Пользователи посмотрели и сказали примерно: работать в этом не будем. Тогда команда сделала довольно интересный «опытный запуск наоборот»: оставила всех пользователей, но резко сократила количество фич. Сначала только проекты, задачи, календарный план и отчетность; а остальное добавляли постепенно. И заработало. Пример того, почему “пользователи сопротивляются изменениям” - это иногда результат “мы попытались за один день изменить им вообще всё”.

😮 Дефицит компетенций: почему сильная команда может сорвать проект Как фраза «у нас сильная команда, по ходу разберемся» должна чуток пугать РП. Сотрудник может быть прекрасным спецом в привычной среде, но новый проект внезапно потребует от него совсем другого: принимать решения при нехватке информации, спорить с заказчиком, договариваться между подразделениями или делегировать часть ответственности другим. И средняя высокая оценка сотрудника этого не показывает. Автор предлагает идти от обратного: еще до старта представить критические ситуации, в которых проект может посыпаться, а затем проверить, есть ли в команде люди, способные в этих ситуациях действовать нужным образом. Да, та самая “учебная тревога”.

🤫 От хаоса к системе: насколько реально построить AI-first команду за полгода Кейс Cloud.ru о том, как заставить 300 с лишним человек не просто потыкаться в  ИИ, а прям встроить его в работу. Начали с замера: кто уже применяет ИИ, кто не применяет и почему. Потом собрали больше 40 идей, выбрали восемь проектов, организовали обучение на собственных задачах и через полгода снова всё измерили. По их данным, доля использующих ИИ выросла с 72 до 84%. И если главным препятствием сначала было незнание, то через полгода — уже нехватка времени.

👍 Как выбрать информационную систему управления проектами: возможный методологический подход Большой разбор того, почему выбирать систему управления проектами с вопроса «а сколько стоит лицензия?» - фигово. Автор предлагает сначала разобраться, чем именно организация собирается этой системой управлять: отдельными задачами, проектами, программами или целым портфелем; какие уже существуют процессы, уровни управления, ограничения безопасности и требования к данным. Потому что система в итоге просто цифровым способом воспроизводит принятую модель управления. Если та противоречива, автоматизация сделает противоречия не меньше, а заметнее и дороже (см поговорку про "автоматизированный бардак")