Устаревший скрам, парадоксальная оценка трудозатрат, мифы о канбане, карта-процесса-опыта, шляпы, убийственные дедлайны, деградация тимлидов и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест».

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

Карго-культ Scrum: почему команды копируют форму, но теряют суть

Начнем с любимой темы - дискуссии про ценность и “истинность” скрама. Автор задается вопросом “почему мы следуем процессу, который называем Scrum, но при этом никто не следует процессу, который Scrum Guide определяет как Scrum”, со всем его комплексом артефактов. Ответ парадоксальный - это не мы (команды) такие ленивые и невнимательные. Это скрам устарел. Когда-то он помогал и был нацелен на достижение гибкости разработки, но единственное ценное, что от него осталось, - это объединение команды в общем потоке работы над проектом. А для этого никакой специальный фреймворк и не нужен…

Апокриф Agile

А тут - очень интересный перевод статьи Сазерленда (гуру скрама) с комментариями от РП. Суть простая: уже стало практически догматом измерение трудозатрат в условных единицах (“попугаях”), а не в часах. Часы - фу, часы не отражают сложности процесса разработки, часы вредно влияют на гибкость и т.д. Внезапно в этой статье Сазерленд говорит нечто обратное, а именно, что на определенных проектах не только можно, но и нужно трекать время в часах и минутах. Это позволяет как упорядочить текущую разработку, так и прогнозировать объем будущих работ. То ли ересь, то ли норма - неясно, но почитать текст советую.

Канбан Метод: не магия, а логика. Наводим порядок в хаосе

Канбан Метод одновременно очень известен и очень недооценён. С одной стороны, все знают Канбан-доски и стикеры. Многие компании «рисуют доски» и думают, что это Канбан Метод. Но, в результате, часто глубина метода остаётся незамеченной: управление рисками, вероятностное прогнозирование, балансировка системы. В этом материале - про “мифы” вокруг канбана, про то, чем канбан не является и чем он может быть для команды и проекта. Статья написана по следам выступления легендарного Алексея Пименова.

Что такое карты процесса-опыта, зачем они нужны разработчикам и как их применять

Карта процесса-опыта — это новый отечественный (!) метод визуализации развития продукта и проекта. Это своеобразный вариант CJM, нотаций вроде BPMN, который позволяет видеть процесс целиком, не только как собственно набор активностей, но как нечто, приносящее ценность потребителю, видеть весь путь производства ценности и (самое главное) корректировать его. Статья ёмко рассказывает о подходе.

Как найти управу на технический долг

Не всегда следует любой ценой избегать технического долга, в некоторых случаях его разумное использование становится стратегическим инструментом для достижения целей проекта. Однако для того, чтобы технический долг перестал ощущаться как что‑то пугающее и неконтролируемое, важно научиться осознанно им управлять. Команда должна воспринимать обсуждение долга как часть рабочего процесса, а не как негативный аспект работы. Если долг рассматривается как управляемая часть системы, он становится менее тревожным. Какими инструментами это сделать - читайте в материале.

Оценка срока и трудозатрат на реализацию задач с помощью Монте-Карло

Рассказ про использование метода в оценке задач и эффект от этого (в частности, сократилось время на встречи по оценке задач до 40 человеко-часов в месяц, а сэкономленное время можно направить на увеличение количества фич или технические задачи).

Гайд по менеджменту знаний: 6 решений для разных бизнес-задач

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

Декомпозиция задач: как разработчику съесть слона?

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

Руководство по Use Cases

Очень (!) детальный гайд по широко известному инструменту описания взаимодействия пользователя (или другого актора) с системой. Автор дает пошаговый процесс создания Use Case (от бизнес-требований до сценария), шаблон описания Use Case (структура и содержание), приводит инструменты для моделирования диаграмм процессов и дает рекомендации по написанию качественных Use Case.

Как не залипнуть в бесконечных уточнениях задач? DoR и DoD в помощь

Про Definition of Ready (DoR, список критериев, которые задача должна выполнить, чтобы команда могла начать её разработку) и Definition of Done (DoD, список требований, которые должна выполнить команда, чтобы задача считалась завершённой): чем полезны, как выглядят в “качественном виде”, как использовать на практике, как создавать и обновлять.

Формирование бэклога продукта: полное руководство для PO

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

Все по полочкам: как мы внедряли методологию управления проектами P3.express

P3.express — это система управления проектами, которая представляет собой алгоритм из 33 конкретных шагов. PM Head из заказной разработки перевел ведение проектов на эту методологию и рассказывает, чем это обернулось для команды и бизнеса.

Стиральная машина позволила мне иначе взглянуть на сроки разработки ПО

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

Метод шести шляп, который поможет уйти от линейного мышления

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

Использование Mindmap для написания требований

Про использование простого, понятного, наглядного инструмента, который интегрируется с подходом Docs as code – Mindmap (Интеллект-карта). Этот метод позволяет организовывать требования в виде древовидной структуры, что делает процесс работы более гибким и наглядным.

Как User Story делает разработку понятной

Немного менее подробное руководство по “сторям” - для чего применяется, почему важна, как формулировать, как выглядит хорошая user story, как применять на практике, какие распространенные ошибки допускают при создании.

Почему жёсткие сроки убивают проект и как его спасти

А тут развернутая рецензия на, пожалуй, самый культовый бизнес-роман для ПМов, Deadline ДеМарко. Если вы вдруг еще не читали его, то прочитайте хотя бы это краткое содержание, книга и ее идеи про человекоцентричность управления проектом нисколько не устарели.

5 принципов архитектуры ПО для старта проекта

Как определить, насколько глубоко на старте проекта надо продумывать его архитектуру? И на чем стоит сфокусироваться сразу, чтобы ее пришлось переделывать в процессе? Большой текст для тех, кто внимательно относится к технической архитектуре проекта, о ее ограничениях, эволюции, подчиненности продукту и бизнесу.

Конспект по архитектуре ПО и System Design

Напоследок еще интересный пост про архитектуру (в тч для проджектов) - автор собрал и структурировал очень много источников на одной доске в miro.

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

Как наладить управление ИТ командой, не привлекая внимания санитаров (про оценки и списания)

Новая статья от Петра Жаркова - про списание трудозатрат, которое бы устроило все стороны и не приводило бы к конфликтам. Среди инструментов - списывать реально затраченное время в человекочасах, с включением “косвенных затрат” вроде кофе-брейков, созвонов с коллегами, и делать это раз в день.

Тимлид или ведущий дейликов?

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

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

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

Ценообразование проектов автоматизации

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

Почему проваливаются проекты внедрения? Топ-5 причин и возможные решения

Про причины провалов проектов – как их можно сразу увидеть, и что с ними делать. Отличные кейсы по всем 5 причинам - неправильно просчитанному бюджету, незаинтересованность руководства, нежелание пользователей сотрудничать, нереализованные ожидания заказчика, непрочное целеполагание.

Примеры неудачной автоматизации и чек-лист перед началом работ

Собственно, сабж - про проекты, которые не удались или привели к снижению эффективности вместо ожидаемого роста. Среди причин - перед стартом проектов по-нормальному не были получены ответы на ключевые вопросы, например “Действительно ли данный процесс нужен и он не является избыточным?”, “Готов ли процесс к автоматизации?”, “Как долго данный процесс будет существовать?”.

Топ систем управления проектами в 2025 году: выбираю подходящий инструмент

Автор (якобы) кофеман и решил сравнить инструменты по аналогии с любимым напитком. Одни - как эспрессо, ничего лишнего (Trello, YouGile, MeisterTask), другие - с маштабированием (YouGile, ClickUp), третьи - с наворотами, печеньками, добавками. Причем есть и аргументы, и рекомендации по правильному приготовлению (эспрессо-трекеры - для начинающих команд, рафы - для крупных и сложных проектов).

«Мы просто обновили рабочий таск-трекер, а команда обновила резюме»

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

Хватит выгорать! Инструкция для директоров. Бережливая организация

Автор книги про “Бережливое управление людьми” (в статье есть ссылка на скачивание) написал лонг про то, как быть идеальным руководителем для других и для себя. Кладезь простых и интересных рецептов, как улучшить жизнь коллегам, не дать им выгореть и стабилизировать самооценку. Из любопытного: уровень счастья сотрудников прямо коррелирует с тем, как быстро им отвечают менеджеры/коллеги, и обратно - с тем, как часто им пишут во внерабочее время.

«Доставили»: как мы превратили релиз-ноуты в продуктовый блог

Про простую вещь, которая из второстепенного отчета стала сама по себе проектом и фичей. Команда 2GIS - про то, как отчеты-дайджесты изменений в проекте стали полноценным блогом, частью корпоративной культуры и центром вовлеченности сотрудников, пользователей и внешней аудитории. Рекомендую всем, у кого дергается глаз при мысли о релиз-ноутах.

Путешествие из проджекта в продакты: какие навыки помогут построить карьеру

Про “свич” из управление проектом в управление продуктом. Автору удалось, понравилось, тем более, что крайне пригождаются навыки проджекта - адаптивность, коммуникабельность, дисциплина и организованность. Бонус - советы и материалы по подготовке к переходу.

Системы work management: выбор решения для команды

Рядом с управлением проектами стоит и т.н. “управление работой”, Work Management. Оно тоже про команду и про задачи, но с фокусом на процессы компании и их оптимизацию.

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

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

Табличка со сравнением 12 популярных таск-трекеров по 50 параметрам от наших аналитиков

Обстоятельно и интересно (и субъективно, конечно). Первое место - ClickUp, второе разделили Битрикс24 (приятно видеть), Jira, Weeek, Easy Project, на последнем - Monday.com.

Scrumban через WEEEK. Кейс российского аналога Miro Эсборд

Команда проекта рассказывает про переход с зарубежных трекеров (втч ClickUp) на отечественный аналог и заодно делится опытом трансформации процессов (например, как отказались от скрама только лишь из-за ухода miro).

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