Управление проектами: дайджест публикаций
Устаревший скрам,
парадоксальная оценка трудозатрат,
мифы о канбане,
карта-процесса-опыта, шляпы,
убийственные дедлайны,
деградация тимлидов
и всё интересное, что писали на этой неделе про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест».
Основы, гайды и инструменты
Начнем с любимой темы - дискуссии про ценность и “истинность” скрама. Автор задается вопросом “почему мы следуем процессу, который называем Scrum, но при этом никто не следует процессу, который Scrum Guide определяет как Scrum”, со всем его комплексом артефактов. Ответ парадоксальный - это не мы (команды) такие ленивые и невнимательные. Это скрам устарел. Когда-то он помогал и был нацелен на достижение гибкости разработки, но единственное ценное, что от него осталось, - это объединение команды в общем потоке работы над проектом. А для этого никакой специальный фреймворк и не нужен…
А тут - очень интересный перевод статьи Сазерленда (гуру скрама) с комментариями от РП. Суть простая: уже стало практически догматом измерение трудозатрат в условных единицах (“попугаях”), а не в часах. Часы - фу, часы не отражают сложности процесса разработки, часы вредно влияют на гибкость и т.д. Внезапно в этой статье Сазерленд говорит нечто обратное, а именно, что на определенных проектах не только можно, но и нужно трекать время в часах и минутах. Это позволяет как упорядочить текущую разработку, так и прогнозировать объем будущих работ. То ли ересь, то ли норма - неясно, но почитать текст советую.
Канбан Метод одновременно очень известен и очень недооценён. С одной стороны, все знают Канбан-доски и стикеры. Многие компании «рисуют доски» и думают, что это Канбан Метод. Но, в результате, часто глубина метода остаётся незамеченной: управление рисками, вероятностное прогнозирование, балансировка системы. В этом материале - про “мифы” вокруг канбана, про то, чем канбан не является и чем он может быть для команды и проекта. Статья написана по следам выступления легендарного Алексея Пименова.
Карта процесса-опыта — это новый отечественный (!) метод визуализации развития продукта и проекта. Это своеобразный вариант CJM, нотаций вроде BPMN, который позволяет видеть процесс целиком, не только как собственно набор активностей, но как нечто, приносящее ценность потребителю, видеть весь путь производства ценности и (самое главное) корректировать его. Статья ёмко рассказывает о подходе.
Не всегда следует любой ценой избегать технического долга, в некоторых случаях его разумное использование становится стратегическим инструментом для достижения целей проекта. Однако для того, чтобы технический долг перестал ощущаться как что‑то пугающее и неконтролируемое, важно научиться осознанно им управлять. Команда должна воспринимать обсуждение долга как часть рабочего процесса, а не как негативный аспект работы. Если долг рассматривается как управляемая часть системы, он становится менее тревожным. Какими инструментами это сделать - читайте в материале.
Рассказ про использование метода в оценке задач и эффект от этого (в частности, сократилось время на встречи по оценке задач до 40 человеко-часов в месяц, а сэкономленное время можно направить на увеличение количества фич или технические задачи).
Как база знаний помогает компаниям перестать терять деньги на бесконечное обучение новичков, путаться в старых инструкциях и срывать сроки проектов. Про реальные сценарии использования, про то, как организовать работу с базой знаний внутри компании, а также про подходящие для разных проектов и задач базы знаний.
Хороший практический гайд по декомпозиции продуктовых и технических задач, который может помочь укладываться в сроки, при этом сохраняя кодовую базу проекта в хорошем состоянии.
Очень (!) детальный гайд по широко известному инструменту описания взаимодействия пользователя (или другого актора) с системой. Автор дает пошаговый процесс создания Use Case (от бизнес-требований до сценария), шаблон описания Use Case (структура и содержание), приводит инструменты для моделирования диаграмм процессов и дает рекомендации по написанию качественных Use Case.
Про Definition of Ready (DoR, список критериев, которые задача должна выполнить, чтобы команда могла начать её разработку) и Definition of Done (DoD, список требований, которые должна выполнить команда, чтобы задача считалась завершённой): чем полезны, как выглядят в “качественном виде”, как использовать на практике, как создавать и обновлять.
Бэклог продукта — это сердце любого продукта, динамичный инструмент управления, который отражает стратегию, потребности пользователей и технические возможности. В статье - о том, как наполнить бэклог, расставить приоритеты и избежать типичных ошибок.
P3.express — это система управления проектами, которая представляет собой алгоритм из 33 конкретных шагов. PM Head из заказной разработки перевел ведение проектов на эту методологию и рассказывает, чем это обернулось для команды и бизнеса.
Смешной кейс про то, как срок реализации задачи оценивался в 10 минут, а по факту вырос в 24 раза, и размышления, почему так могло произойти. И всё, в целом, просто - мы оцениваем по имеющемуся опыту, но не учитываем, что могут возникнуть те самые “неизвестные неизвестные”, о которых мы забыли даже подумать при оценке. Вывод - как тщательно требования ни собирай, все равно не избежать ситуаций столкновения с реальностью, которой все равно на наши прогнозы и опыт.
Про технику креативного мышления «шесть шляп» команды, которая хочет подружиться, размять мозги и заодно порешать важные вопросы, которая предполагает рассуждение над проблемой с шести точек зрения или ролей (позитивная, критическая, эмоциональная, фактологическая, креативная, модерационная).
Про использование простого, понятного, наглядного инструмента, который интегрируется с подходом Docs as code – Mindmap (Интеллект-карта). Этот метод позволяет организовывать требования в виде древовидной структуры, что делает процесс работы более гибким и наглядным.
Немного менее подробное руководство по “сторям” - для чего применяется, почему важна, как формулировать, как выглядит хорошая user story, как применять на практике, какие распространенные ошибки допускают при создании.
А тут развернутая рецензия на, пожалуй, самый культовый бизнес-роман для ПМов, Deadline ДеМарко. Если вы вдруг еще не читали его, то прочитайте хотя бы это краткое содержание, книга и ее идеи про человекоцентричность управления проектом нисколько не устарели.
Как определить, насколько глубоко на старте проекта надо продумывать его архитектуру? И на чем стоит сфокусироваться сразу, чтобы ее пришлось переделывать в процессе? Большой текст для тех, кто внимательно относится к технической архитектуре проекта, о ее ограничениях, эволюции, подчиненности продукту и бизнесу.
Напоследок еще интересный пост про архитектуру (в тч для проджектов) - автор собрал и структурировал очень много источников на одной доске в miro.
Менеджер проекта - карьера и навыки
Новая статья от Петра Жаркова - про списание трудозатрат, которое бы устроило все стороны и не приводило бы к конфликтам. Среди инструментов - списывать реально затраченное время в человекочасах, с включением “косвенных затрат” вроде кофе-брейков, созвонов с коллегами, и делать это раз в день.
Как не стать этим “ведущим дейликов” при переход в менеджмент (а такая угроза есть, и она губительна для сотрудника и команды, внедрить RACI-матрицу, принять тот факт, что тимлид должен быть играющим тренером).
Управление рабочей нагрузкой — это распределение задач между сотрудниками. Контролировать нагрузку нужно для повышения производительности работы, снижения текучки кадров и выгорания, сохранения мотивации к работе. Управление загрузкой команды включает в себя составление плана работ, распределение ролей по возможностям членов команды и мониторинг. Невозможно вручную следить, кто и чем занят. Для этого нужны инструменты, которые помогают мониторить загруженность команды и анализировать результативность.
Подходы к оценке проекта у разных подрядчиков существенно отличаются. А заказчик не понимает принципов ценообразования в коммерческих предложениях и без сравнения ожидаемых результатов на выходе не может принять верное решение. Из-за этого самый частый вопрос на предпроекте: «а можно подешевле?». Можно, но просто так дешевле ничего не бывает.Авторы - о том, на какие факторы оценки проекта стоит обращать внимание обеим сторонам на этапе предпродажи.
Про причины провалов проектов – как их можно сразу увидеть, и что с ними делать. Отличные кейсы по всем 5 причинам - неправильно просчитанному бюджету, незаинтересованность руководства, нежелание пользователей сотрудничать, нереализованные ожидания заказчика, непрочное целеполагание.
Собственно, сабж - про проекты, которые не удались или привели к снижению эффективности вместо ожидаемого роста. Среди причин - перед стартом проектов по-нормальному не были получены ответы на ключевые вопросы, например “Действительно ли данный процесс нужен и он не является избыточным?”, “Готов ли процесс к автоматизации?”, “Как долго данный процесс будет существовать?”.
Автор (якобы) кофеман и решил сравнить инструменты по аналогии с любимым напитком. Одни - как эспрессо, ничего лишнего (Trello, YouGile, MeisterTask), другие - с маштабированием (YouGile, ClickUp), третьи - с наворотами, печеньками, добавками. Причем есть и аргументы, и рекомендации по правильному приготовлению (эспрессо-трекеры - для начинающих команд, рафы - для крупных и сложных проектов).
Про внедрение таск-трекера и почему даже полезный софт превращается в проблему, и как сделать так, чтобы он действительно помог команде, а не мешал работать. Причины понятны - не видят пользы, боятся автоматизации и потери работы, не хотят разбираться, не понимают причин перехода. Материал - про то, что с этим делать (там целая инструкция из дюжины этапов).
Автор книги про “Бережливое управление людьми” (в статье есть ссылка на скачивание) написал лонг про то, как быть идеальным руководителем для других и для себя. Кладезь простых и интересных рецептов, как улучшить жизнь коллегам, не дать им выгореть и стабилизировать самооценку. Из любопытного: уровень счастья сотрудников прямо коррелирует с тем, как быстро им отвечают менеджеры/коллеги, и обратно - с тем, как часто им пишут во внерабочее время.
Про простую вещь, которая из второстепенного отчета стала сама по себе проектом и фичей. Команда 2GIS - про то, как отчеты-дайджесты изменений в проекте стали полноценным блогом, частью корпоративной культуры и центром вовлеченности сотрудников, пользователей и внешней аудитории. Рекомендую всем, у кого дергается глаз при мысли о релиз-ноутах.
Про “свич” из управление проектом в управление продуктом. Автору удалось, понравилось, тем более, что крайне пригождаются навыки проджекта - адаптивность, коммуникабельность, дисциплина и организованность. Бонус - советы и материалы по подготовке к переходу.
Рядом с управлением проектами стоит и т.н. “управление работой”, Work Management. Оно тоже про команду и про задачи, но с фокусом на процессы компании и их оптимизацию.
Экстраполяция аджайла на личные цели, задачи и планы - гайд по методу трёхуровневой декомпозиции целей Agile Results. Подойдёт всем, кто живёт в режиме неопределённости (то есть всем нам) и хочет научиться гибкому планированию. В основе методики - три вопроса (“что планирую на сегодня, что сделаю, что мне удалось узнать”) , которые нужно задать уже не команде, а себе.
Обстоятельно и интересно (и субъективно, конечно). Первое место - ClickUp, второе разделили Битрикс24 (приятно видеть), Jira, Weeek, Easy Project, на последнем - Monday.com.
Команда проекта рассказывает про переход с зарубежных трекеров (втч ClickUp) на отечественный аналог и заодно делится опытом трансформации процессов (например, как отказались от скрама только лишь из-за ухода miro).