🔥 Интересные публикации по управлению проектами за 23-31 октября (1) 🍑 Черный октябрь "Яндекса": анатомия архитектурной и управленческой катастрофы, которую списали на форс-мажор Да, куда же без этого. За четверо суток в октябре из строя вышли три дата-центра "Яндекса", облако легло, финтех-подразделение провело 11 дней в ручной сверке балансов. Удобно списать всё на форс-мажор, мол, ни одна архитектура такого не выдержит. Но вот автор препарирует поминутную хронику и показывает: между потерей первой и второй зоны доступности прошло 74,5 часа, то есть время на спасение системы было, но им не воспользовались. Физическое поражение площадок стало лишь триггером, а масштаб катастрофы- следствием просчётов в управлении мощностями и оценке рисков на уровне высшего руководства. В общем, если у вас есть план на случай аварии, который никто не репетировал и не проверял на реальном сценарии,- это ерунда, а не план. 👀 Метрики команды врут поодиночке или почему теперь я смотрю их парами Автор начинает с прекрасного результата: время до первой проверки изменений сократилось с 6 часов до 36 минут. Только потом выяснилось, что дефектов после выпуска- в 2,6 раза больше. Отсюда идея: почти любой показатель команды опасно читать отдельно. Скорость проверки нужно смотреть вместе с размером изменений и качеством, время выполнения- с количеством одновременно начатой работы, процент успешных выпусков- с самим числом выпусков. Хороший пример, когда рост ошибок на 65% сначала хотелось лечить ужесточением проверки кода, а настоящая причина оказалась... ну конечно же, в плохо подготовленных требованиях и нереалистичном планировании. 😮 Первые 30 минут руководителя проекта, или как обнаружить проблемы до того, как они сорвут сроки Про полезную привычку РП не начинать день с разгребания почты (или чатов, что там у вас). Сначала полчасика подремать посмотреть на проект целиком: какие задержки действительно способны сдвинуть конечный срок, не исчез ли запас времени, где возникает конфликт за дефицитного спеца, где нужно управленческое решение. Проблема обнаруживается не тогда, когда инженер уже нужен двум руководителям одновременно, а когда это противоречие видно в будущем плане. И в целом, менеджер проекта нужен не для того, чтобы быстрее всех отвечать на сообщения (эх, жаль), а чтобы раньше других увидеть последствия. 😐 Первый проект Process Mining: как выбрать процесс для оптимизации, собрать команду и не застрять на этапе пилота Инструкция по первому проекту процессной аналитики. До старта предлагается определить несколько конкретных вопросов к процессу и выбрать участок, где есть и доступные данные, и измеримый эффект, и владелец, готовый потом что-то изменить. Потому что построить красивую картинку as is- еще не результат. Один из показателей успешности опытного запуска у авторов прямо так и сформулирован: принято ли хотя бы по одной найденной проблеме решение об изменении процесса. Если нет, команда просто произвела еще одну презентацию. Еще есть рекомендация заранее проверить качество истории в исходных системах: есть ли даты смены состояний, сквозные идентификаторы и достаточная глубина данных и прочие нужные штуки. 😊 Куда уходит зарплата разработчика: как мы приоритизируем бэклог и связываем задачи с бизнесом Или о том, как перестать выделять место в плане тому, кто громче всех попросил об этом. Коллеги из Аспро сначала сравнивали задачи по единому правилу, но довольно быстро поняли, что это не поможет им куда-то двигаться. Поэтому задачи связывают с направлениями и конкретными показателями, а после выпуска проверяют, произошло ли ожидаемое изменение. Еще хорош кусок про срочные работы. Они выглядят бесплатными (“ну добавили небольшую задачу, всего-то”). На деле она прерывает постановщика, разработчика, проверяющего и вытесняет что-то уже запланированное. Поэтому под такие работы заранее выделяется часть мощности команды, а на очередную срочную просьбу задается прекрасный вопрос: "Хорошо. А какую уже запланированную задачу мы ради этого не сделаем?". По словам автора, после него половина срочного внезапно перестает быть срочной.

Вайб-проекты от Сбера 😉 Что ж, Сбер в концепции Vibe PPM предлагает передать ИИ-агентам значительную часть управления проектами: от составления планов до контроля исполнения. Кратко: ✅Руководитель задаёт нужный результат и ограничения, а агенты определяют, как организовать работу, и обращаются к человеку, когда требуется его решение. 😐 Планы и отчёты должны автоматически перестраиваться при изменении целей, а проблемы — обнаруживаться постоянно, без ожидания очередного совещания (ну-ну). 🤴 Агенты разных проектов смогут согласовывать использование общих ресурсов по заранее установленным правилам. Ночью они будут разбирать накопленный опыт и обновлять свои рабочие инструкции, чтобы следующие проекты учитывали ошибки предыдущих. 😨 Проектный офис предлагается превратить из сборщика отчётности в команду, которая настраивает агентов и следит за правилами их работы. 😮 Целевой ориентир — 15–25 (!!!) проектов на сотрудника проектного офиса вместо 3–5. При этом ответственность остаётся у людей — даже если со временем они разучатся самостоятельно выполнять работу, которую передали ИИ. — Пока главный вопрос для меня - сколько же проблем в проектах возникает из-за медленной обработки информации, а сколько из-за того, что так называемые люди не могут договориться или проходят бюрократические круги ада. С инфой-то агенты вполне могут помочь, а вот со вторым всё сложнее... А если проектов всё-таки станет в несколько раз больше, хотелось бы увидеть такую же смелость в пересмотре зарплат.💰 Или это Сбер так намекает, что, чтобы выжить, перформить теперь придется по-жесткому?.. #внезапное

🔥 Самые интересные (ну или просто норм) публикации по управлению проектами за 11–18 октября (2) ⭐️ Сколько разработчиков может вести тимлид: 7 ошибок при росте команды Команда выросла с 6 человек до 12, а руководитель продолжает работать так, будто ничего не изменилось (пишет код, проверяет изменения, принимает финальные решения и остается главным носителем знаний). В итоге очередь растет уже не у разработчиков, а у самого начальника. Автор не пытается вывести магическое число типа “руководитель может управлять ровно семью людьми”, ибо всё зависит от зрелости сотрудников, сложности работы и тд. Но после определенного размера команды прежняя модель действительно перестает работать. Главная мысль: при росте команды нужно проектировать заново не только структуру команды, но и собственную должность. То, что было сильной стороной начальника на шести людях, на двенадцати легко становится главным ограничением всей системы. 💪 Самый дорогой источник потерь в проектах, о котором никто не говорит Автор начинает с Mars Climate Orbiter, который NASA потеряла из-за того, что две команды использовали разные единицы измерения. Причем обе считали правильно. Ошибка возникла не внутри работы специалистов, а на стыке между ними. Дальше эта история переносится на обычные проекты: требования передали, но не сверили понимание; проблема обнаружилась, но осталась в переписке; у результата передачи между подразделениями вообще нет владельца. Всё это выглядит как работа, люди заняты, отчеты идут — поэтому потери почти невидимы. А потом появляются ожидание, повторная работа, выгорание, незапланированные подрядчики и сдвиг экономического эффекта. В управлении проектами почти никто системно не считает стоимость плохой координации, хотя именно она регулярно съедает больше всего времени. 🤴 Как мы сделали мобильные релизы более предсказуемыми без потери скорости поставки Команда регулярно находила серьезные ошибки буквально перед выпуском, - ну и авторы заметили, что это слишком поздно. Проверка должна подтверждать готовность, а фактически впервые обнаруживала проблемы. Поэтому часть контроля перенесли раньше, ввели обязательное подтверждение проверки изменений до общей сборки и поменяли порядок отдельных операций. Один только перенос внешней проверки на более ранний этап сократил два выпуска на два дня каждый. Условно, принялись лечить не симптом, а место его возникновения.  🚬 Карта автономии AI: как решить, что агенту можно делать без человека Текст предлагает обсуждать не «насколько умна модель», а каждое конкретное действие: прочитать данные, подготовить предложение, изменить запись, отправить сообщение, удалить и тд. Потому что цена ошибки и возможность ее отменить у них совершенно разные. Получается несколько уровней самостоятельности: от простого совета человеку до действия в заранее установленных границах. 90% точности ничего не говорит о допустимости автоматизации, пока мы не знаем цену остальных 10%. До передачи действия машине нужно определить худший реалистичный исход, владельца риска, способ остановки и восстановления.  ❓ Внедрение проектного офиса: проектный, управленческий и продуктовый подходы Про создание проектного офиса - с 3 сторон. 1) это обычный проект: есть сроки, ресурсы и конкретный первый результат. 2) новая управленческая функция, а значит, офис должен иметь реальные полномочия влиять на правила принятия решений, иначе получится просто фабрика отчетов. И, наконец, 3) это внутренний продукт для руководителей и команд: его шаблоны, правила и услуги должны кому-то реально помогать, а не существовать потому, что «так положено». Отсюда подход к запуску: не пытаться сразу внедрить идеальную систему из всех возможных процессов и документов, а начать с минимального набора, который решает конкретную проблему бизнеса.