Много о рисках проекта, стори-пойнты и почему они не работают, обзор ИСУП, пирамида Минто и FFF, приоритезация бэклога и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

Основы, гайды и инструменты

Считаем риски: как планировать спринт без сюрпризов

Про фундаментальную формулу управления рисками: риск = вероятность × критичность, где критика воспринимается как воздействие на сроки, бюджет, качество или репутацию. Есть классификатор рисков — внешние (задержки команд, API), внутренние (техдолг, баги) и организационные (отпуска, инфраструктура). Важно внедрять оценку рисков уже на этапе планирования, а не после — например при отказе или баге. Риски должны быть учтены в оценке задач, с резервами на неопределённость. Плюс — проактивные стратегии (предусмотреть «план B»).

5 причин, почему ваши Story Points не работают (и что делать)

О слабых сторонах Story Points: они не отражают поток задач, дают иллюзию точности и плохо масштабируются между командами. Да и в целом, Story Points — лишь внутренний инструмент для выравнивания понимания, но для прогнозов важны еще и другие метрики. Автор предлагает применять статистику (Monte Carlo) и прогнозировать диапазоны вероятностей, а не использовать фиксированные значения SP.

Зачем нужны и как использовать Story Points?

Автор объясняет, что Story Points — это командная относительная оценка, учитывающая сложность, риски и накладные издержки. Основная цель — повысить предсказуемость командного потока, а не сравнивать скорость разных групп. Если использовать их как универсальную метрику межкомандного сравнения — возникает искажение и снижение ценности.

Lean в IT: как сократить потери и повысить эффективность на практике

Про адаптацию практики бережливого производства для IT-процессов. Суть Lean — выявить потери (время ожидания, лишние действия, дефекты) и систематически их устранять через Kaizen-подход. Отсюда и акцент на эмпирический переход: сначала пилотирование, затем масштабирование — вместо «бросания» всей команды сразу. Ну и надо обучать команду анализу потока создания ценности, визуализировать “узкие места”.

Топ‑7 систем управления проектами. Все для контроля задач и команды

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

Как заморозить проект, но не отморозить команду

Бывает, что проект “замораживают”, - и автор пишет, что в этом случае делать, чтобы вообще не расстаться с сотрудниками и компанией) Из основного - необходимость ухода из режима активной разработки, сохранения поддержки и переориентации команды, чёткая коммуникация, проактивная трансформация ролей. Такой подход сохраняет мотивацию участников, позволяя избежать демотивационных синдромов.

Problem solving в ИТ

Про инструменты мышления для решения проблем в условиях неопределённости. Это подход длительного поиска решения, не шаблонная техника, а итеративный путь через гипотезы его причин и тестирование решений. Включает анализ корней проблемы (все эти ваши “5 почему”), генерацию вариантов решений и их прототипирование.

«А так ли хорош TOGAF?»

Авторы критически оценивают TOGAF как стандарт архитектуры предприятия — его применимость в проектах и ограничения. TOGAF охватывает бизнес-, data-, application- и технологическую архитектуру — но требует прям большой адаптации к проектному контексту. PM должен настраивать их под масштабы и срок проекта, без внедрения лишней бюрократии, поэтому рекомендуется использовать TOGAF как базис, но облегчённый, чтобы не выйти из agility.

Пирамида Минто в ИТ: как быстро добиваться результата в разговоре с коллегами

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

FFF: методология, которая принимает реальность

Про опыт применения метода FFF (First Features Freeze) — ранней заморозки объема задач (скоупа) перед разработкой, чтобы избежать излишней неопределённости. Подход позволяет зафиксировать первичный объем работ, не блокируя будущее развитие, и оставляет пространство для изменений. Особенно полезен для интеграционных проектов и крупных модулей.

Приоритизация бэклога: MoSCoW, ICE и RICE, и почему нам этого не хватило

Команда Content AI делится опытом: классические фреймворки (MoSCoW, ICE, RICE) перестали справляться с ростом бэклога. Авторы представляют собственный кастомный метод, учитывающий сложность фич, бизнес-приоритеты и технический долг, с итеративным пересмотром приоритетов на основе данных и обратной связи.

Неработающие принципы Agile. Когда Agile не принесёт эффекта

Про причины, по которым Agile-принципы могут провалиться — от формального применения до отсутствия адекватной поддержки и культуры. Если ритуалы проводятся «по книжке» и без “зачем?”, то теряется смысл и энергия команды, да и вообще происходит нарушения главного принципа гибкости, что приводит к “затоксичиванию“ разработки.

«Спринт без смысла»: как Agile-принципы превратились в рутину — и что с этим делать

И еще один текст про «Agile-детокс», практической направленности) Автор - за пересмотр каждой церемонии, каждой ретроспективы под вопросом «зачем?». Всё лишнее и чересчур ритуальное нужно вычистить, не тратить время и силы на “псевдо-деятельность”. И в итоге команда снова начинает думать «мы делаем А не потому, что должны, а потому, что это приносит ценность».

Концепция проекта: как собрать команду

Как выстроить концепцию проекта, чтобы привлечь нужную команду: нужно ясно описать цель, ценность и результаты. Kick-off встреча на этой основе позволяет определить роли, ожидания и зоны ответственности ещё до старта. Из важного еще - упор на коммуникацию с ключевыми стейкхолдерами и оформление документа концепции, который станет договорённостью между заказчиком и командой.

Руководство по ресурсному планированию

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

Менеджер проекта - карьера и навыки

Как выбрать AI‑курс для менеджера: подробный разнос

Обзор-анализ огромного выбор AI‑курсов, доступных сегодня с выводом, что не все из них полезны PM на практике. Большинство - про поверхностное понимание «что такое LLM», хотя основной целью должны быть прикладные навыки. Так что если выбираете, то смотрите в сторону программ с бизнес-кейсами и реальными задачами, а не общими популярными лекциями.

Трудности перевода: истории работы проджекта

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

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

YooMoney описывает комплекс мер для ускорения доставки фич: оптимизация CI/CD, внедрение trunk-based development и feature flags, автоматическое тестирование, «горячую замену» без деплоя — и регулярные ретроспективы. Роль ПМа - участие в формировании дорожных карт и приоритетов. Такой подход улучшил скорость вывода продукта и снизил ошибки в проде.

4, 3, 2, 1 — поехали! Реальная история запуска IT-продукта за четыре месяца

Про важность участия PM в архитектурных решениях, чтобы поддерживать стратегическую гибкость проекта. Если архитектура формализована с начала (а такое бывает), PM может существенно снизить межкомандные зависимости и ускорить процессы. Особенно важны ранние спринты - сразу плюс 100 к управляемости.

Как методы Toyota, Дэвида Аллена, Барака Обамы и Мари Кондо делают IT-специалистов эффективнее и спокойнее

Как внедрение agile‑процессов возможно не только в IT‑разработке, но и в операционных подразделениях. Суть та же: короткие итерации, визуализация задач (канбан), регулярные ретроспективы и фокус на эффективности операций, а ПМ выступает как фасилитатор. Плюс использование PDCA-цикла и прочих привычных инструментов.

Бесстыжий тимлид: как уязвимости делают сильнее

Коллеги из Avito - про то, как честные признания менеджера (“лидера”) о страхах и ошибках формируют доверие и усиливают командный дух. Такие лидеры создают культуру, где проблемы обсуждаются открыто, а команда предлагает решения без страха. В IT, где давят дедлайны, умение показать уязвимость помогает команде выразить идеи и быстро реагировать на вызовы. ПМ может перенять практику такой эмпатии: открытость на ретроспективах, запрос мнения о решениях, признание ограничений.

Как развивать навыки в неопределённости

Все мы в неопределенности, а проджекты - в особенности) Автор делает фокус на трёх направлениях обучения: любопытство, потребности команды и тренды рынка. Такой фильтр помогает выбирать приоритетные навыки, не отвлекаясь на всё подряд. Ключевой инструмент — создание ИПР (индивидуального плана развития) с критериями успеха сразу на ранней стадии. А дальше - регулярная проверка через интервью-ревью, чтобы развитие шло верным путем…

Техники антипродуктивности

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

Как все успевать и не выгорать. 42 способа

Да, там именно 42 способа борьбы с выгоранием, включая Kanban, GTD, ZTD и утренние привычки и т.д. И это не просто сборник - автор подчеркивает: без понимания “зачем” методы работают лишь наполовину, да и сам способы необходимо адаптировать под контекст и команду. Еще рекомендация - вводить привычки по шагам и измерять их эффект на циклами ретроспектив (ну типа “атомных привычек”).

Тревожность и производительность: как стресс влияет на работу

Рассказ о том, как умеренный стресс по закону Йеркса–Додсона (еще одна ненужная информация) повышает концентрацию и работоспособность, но при чрезмерном — вызывает падение эффективности и риск выгорания, особенно в ИТ‑сфере. Ну и мы как менеджеры должны распознавать разницу между конструктивным напряжением и вредным тревожным состоянием у сотрудников (и у себя, ха-ха). Рекомендации — развивать эмоциональный интеллект и формировать поддерживающую среду с помощью 1:1, командных встреч и здоровых границ. Важно обеспечивать баланс: не провоцировать сверхнагрузки, но сохранять умственный тонус.

10 вопросов scrum‑мастеру: что делает и почему его зарплата 300 тысяч

Про роль Scrum‑Masterа как фасилитатора процесса, устраняющего блокеры, курирующего спринты и обеспечивающего комфорт команды. Отличие его от проект-менеджера — в заботе о качестве процесса, а не о сроках и бюджете, балансируя интересы бизнеса и команды. Из важного — знание Agile‑метрик (velocity, capacity, focus factor), умение фасилитировать, владение инструментарием для планирования и трекинга. Ну и, разумеется, софты - эмпатия, коммуникация, адаптивность, лидерство без авторитета, обучаемость и умение «слышать» команду.

Цифры есть — смысла нет

Обвинение в адрес KPI и NPS как к формализованным цифрам без контекста, которые часто приводит к неправильным действиям команд. Без обоснования метрики превращаются в форму отчётности, которая искажает поведение и смещает фокус. Рекомендация - рассматривать метрики не как самоцель, а как инструмент, обеспечивая понимание их связи с бизнес- и проектными целями, сопоставлять данные с качественными инсайтами (интервью, ретроспективы, анализ рисков). И конечно, метрики требуют периодического пересмотра и адаптации под культуру команды и изменяющиеся условия.

Команда проекта

10 промптов вместо споров об ИИ: как мы сэкономили недели разработки

Как занкомые дискуссии об ИИ заменили набором чётких промптов, ускоряющих согласование архитектурных решений, - и от дебатов перешли к результатам. в действие: гипотезы тут же проводятся в чат‑боте, снижают неопределённость и ускоряют итерации. Результат — проект/продукт реализовался быстрее, а конфликтов по направлению и набору фич стало куда меньше.

Испытательный срок: 12 шагов к успеху

Ozon Tech описывает испытательный срок как полноценный мини-проект, состоящий из 12 миссий для новых сотрудников, с адаптацией в бизнес-процессы, с побуждением к микро-инициативам и т.д.. Важный элемент — фидбэк‑циклы и ретроспективы на каждом этапе.

Не искали волшебников, а вырастили их сами: история создания команды автоматизаторов без магии

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

Как мы внедрили единый шаблон тикетов для разработчиков и упростили работу команды

Рассказ СА про внедрение “унифицированного тикета” и как он улучшил обмен информацией между командами. Шаблон стал единым языком для всех ролей и для всей немаленькой компании. В итоге — решение задач ускорилось, ошибки коммуникации, особенно между аналитиками и разработчиками, снизились.

Как управлять распределёнными командами

Практические советы по управлению распределёнными командами, с учетом разных часовых поясов, разрывов во времени коммуникации и прочего. Из основного - важность доверия и минимизация микроменджмента, регулряные встречи в доступное всем время, четко поставленные задачи, не требующие уточнений. Ну и про недостатки таких команд тоже есть (и как их компенсировать).

Лидерство и подходы к управлению командой интеллектуалов

Про управление IT-командами как дирижирование оркестром, где лидер должен стать визионером, а не контролёром. Специалисты — интеллектуалы (интеллектуалы же?), поэтому подходы «строгость» и «микроменеджмент» скорее демотивируют, чем улучшают результат. Главные качества лидера: честность, постоянное развитие, умение слушать и делегировать, формируя автономию и доверие.

Как я внедряла обратную связь в команде, и почему это было больно

Интересный кейс внедрения “Performance Review” в ранней стадии стартапа, - изначально было сильное сопротивление, а потом… Потом автор смог доработать формат, упростить опросники, и вообще снять напряжение в коллективе. Ну, и в итоге этот процесс стал важной частью корпоративной культуры.

«Работа вне офиса вредит компаниям» — это миф? Разбираемся

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

45 командных игр для сплочения коллектива и тимбилдинга

Целых 45 инструментов для сплочения и развития команды - импровизационные упражнения, совместные задачи и мини‑проекты для раскрытия личностей и ролей. До “голодных игр” и прочих комиссарок не дотягивают, конечно, но в целом набор интересный.

Управление проектами: дайджест публикаций #35