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

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

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

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

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

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

Апокриф Agile ^[3]

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по Use Cases ^[11]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тимлид или ведущий дейликов? ^[28]

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

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

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

Ценообразование проектов автоматизации ^[31]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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