Блог Flowtino — планирование и работа с досками

Годовое планирование без театра

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

1 мин чтения

Асинхронные стендапы: что работает, когда никто не в одной комнате

Ежедневный асинхронный стендап, который просто переносит живую встречу в текст, — худшее из двух миров. Несколько изменений делают его реально полезным.

1 мин чтения

Основы планирования загрузки: перестаньте планировать 100% чьего-то времени

Планы, предполагающие полную доступность, неверны с первого дня — встречи, прерывания и переключение контекста не исключение, а часть работы.

1 мин чтения

Непрерывное планирование и годовое: какой режим отказа вам ближе

Годовое планирование проваливается тем, что неверно одиннадцать месяцев из двенадцати. Непрерывное — тем, что никогда не даёт стабильной цели. Большинству команд нужна смесь.

1 мин чтения

Межфункциональное планирование: где обычно тихо проваливаются передачи

Планы чаще ломаются на стыках между командами, чем внутри них. Межфункциональное планирование — это в основном про то, чтобы сделать эти стыки видимыми.

1 мин чтения

Журнал решений: как перестать пересматривать уже решённое

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

1 мин чтения

Зависимость и блокер: слова, которые команды путают, а не стоило бы

Зависимость известна заранее. Блокер — это зависимость, которая вас удивила. Если относиться к ним одинаково, скрывается, сколько блокеров можно было предотвратить.

1 мин чтения

Оценка задач без угадывания

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

1 мин чтения

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

Лечение от расползания скоупа — не отказ на каждый новый запрос, а сделать компромисс видимым в момент запроса, а не после.

1 мин чтения

Как фасилитировать групповое решение удалённо, чтобы оно не тянулось неделями

Очно решение можно закрыть за одну встречу, потому что комната чувствует момент консенсуса. Удалённо этот сигнал пропадает, если не заменить его осознанно.

1 мин чтения

Как менять приоритеты без потери доверия команды

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

1 мин чтения

Как планировать запуск продукта без суматохи в последнюю неделю

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

1 мин чтения

Как провести дизайн-спринт без обязательства на пять дней

Классический дизайн-спринт длится пять дней — именно поэтому большинство команд его никогда не проводят. Сжатая версия даёт большую часть пользы.

1 мин чтения

Как провести воркшоп по планированию, который заканчивается решениями, а не только заметками

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

1 мин чтения

Как написать бриф проекта, который не пропускают

Слишком длинный бриф пролистывают, слишком короткий — неправильно понимают. Правильная длина — та, что помещается на один экран.

1 мин чтения

Веха и дедлайн: почему их путаница ломает планы

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

1 мин чтения

Mind-карты для планирования: хорошая стартовая точка, плохая конечная

Mind-карты отлично подходят для хаотичного первого часа планирования и плохо — как артефакт, по которому пытаются работать шесть недель спустя.

1 мин чтения

Устав проекта: единственный документ, который стоит писать медленно

Большинство проектных документов стоит писать быстро и часто обновлять. Устав — исключение: его стоит сделать правильно один раз, потому что на него ссылается всё последующее.

1 мин чтения

Чек-лист запуска проекта, который предотвращает сюрпризы на третьей неделе

Большинство проблем проекта, всплывающих на третьей неделе, были на самом деле решены — или не решены — на нулевой. Чек-лист запуска ловит их рано.

1 мин чтения

Квартальный ритм планирования: достаточно долго, чтобы иметь смысл, достаточно коротко, чтобы скорректировать

Квартальное планирование лежит в удобной середине — достаточно долго, чтобы взять направление, достаточно коротко, чтобы ошибка не была катастрофой.

1 мин чтения

RAID-лог: риски, допущения, проблемы и зависимости в одном месте

Четыре разных аспекта планирования обычно живут в четырёх разных документах — или нигде. RAID-лог собирает их там, где их реально можно проверить.

1 мин чтения

Планирование для распределённой команды: что реально меняется

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

1 мин чтения

Реестр рисков, который маленькая команда реально будет вести

Формальные реестры рисков умирают под собственным весом. Лёгкая версия — одна строка на риск, пересмотр раз в месяц — выживает.

1 мин чтения

Roadmap на одной странице: ограничение, которое улучшает ясность

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

1 мин чтения

Почему 'единый источник истины' — обычно мечта, и как к ней приблизиться

Почти каждая команда утверждает, что у неё один источник истины для планирования. У почти каждой на самом деле их три, и они тихо не совпадают.

1 мин чтения

Карта стейкхолдеров: кто должен знать что и когда

Большинство провалов коммуникации в проекте — не про скрытие информации, а про то, что никто не понял, кому она на самом деле нужна.

1 мин чтения

Шаблоны статус-апдейтов, которые реально читают

Большинство статус-апдейтов либо слишком длинные, чтобы их читать, либо слишком размытые, чтобы по ним действовать. Шаблон с тремя конкретными полями решает обе проблемы.

1 мин чтения

Структура разбивки задач: насколько детально — это слишком детально

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

1 мин чтения

Velocity команды: инструмент прогноза, а не оценка эффективности

Velocity показывает, сколько команда исторически успевает за спринт. В момент, когда её используют для оценки команды, а не для прогноза работы, она перестаёт быть честной.

1 мин чтения

Roadmap по темам: планирование вокруг проблем, а не фич

Roadmap на основе фич фиксирует решение раньше, чем вы подтвердили проблему. Roadmap на основе тем фиксирует проблему и оставляет место найти правильное решение.

1 мин чтения

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

Большинство постмортемов полагаются на память — а именно там реальная последовательность событий тихо переписывается. Реплей таймлайна убирает гадание.

1 мин чтения

Визуальная коллаборация для удалённых команд: чем заменить доску, которой нет

Удалённые команды теряют физическую доску и обычно заменяют её худшим вариантом: длинной асинхронной перепиской, пытающейся описать диаграмму словами.

1 мин чтения

Еженедельный ритуал планирования на 20 минут

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

1 мин чтения

Work breakdown structure и roadmap: разная высота, разная аудитория

Структура разбивки работ и roadmap описывают один проект на совершенно разных уровнях масштаба. Путать аудиторию для каждого — частая ошибка планирования.

1 мин чтения

Лимиты WIP: правило канбана, которое команды принимают, а потом тихо игнорируют

Лимиты незавершённой работы — самое влиятельное правило канбана и самое часто нарушаемое. Вот почему команды его ломают и чего это стоит.

1 мин чтения

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

Негрумленный бэклог растёт, пока ему больше никто не верит. Груминг не про идеальность — он про то, чтобы верх списка всегда был правдой.

2 мин чтения

Burndown и burnup: разница, которая реально важна

Обе диаграммы отслеживают прогресс, но только одна показывает, когда под командой поменялся объём работы. Эта разница решает, какой из них доверять.

2 мин чтения

Определение готовности: документ на два предложения, который пропускает большинство команд

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

1 мин чтения

Матрица Эйзенхауэра, адаптированная для команд, а не для одного человека

Квадранты срочное/важное отлично работают для личного списка дел. Масштабирование на команду требует одного дополнительного правила: кто решает, что срочно.

2 мин чтения

Основы флоучартов для тех, кто не инженер

Не нужно образование в computer science, чтобы описать процесс. Хватит нескольких фигур и одного правила про стрелки, чтобы начать.

1 мин чтения

Как проводить ретроспективу, которую не боятся

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

1 мин чтения

Сейчас / Дальше / Потом: формат roadmap, который не врёт про уверенность

Roadmap с датами подразумевает точность, которой у вас нет. Сейчас/Дальше/Потом честен в том, что 'потом' — это направление, а не дата.

1 мин чтения

OKR и roadmap: это не один и тот же документ

OKR описывает, как выглядит успех. Roadmap описывает, как вы туда доберётесь. Путаница между ними — причина, почему многие циклы планирования не дают ни того, ни другого.

2 мин чтения

Planning poker: почему вроде бы несерьёзная игра даёт лучшие оценки

Planning poker работает не из-за карт — он работает, потому что заставляет давать независимые оценки до того, как кто-то заякорит комнату своим числом.

2 мин чтения

Премортем: находить причины провала до того, как он случился

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

2 мин чтения

Матрица RACI: полезный инструмент или бюрократический театр?

У RACI плохая репутация, потому что её обычно строят один раз, на воркшопе, и больше не трогают. При лёгком использовании она решает реальную проблему.

2 мин чтения

Планирование спринта за 30 минут (а не за 3 часа)

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

1 мин чтения

Свимлейны: когда доске нужно больше, чем колонки

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

2 мин чтения

Story mapping: увидеть весь путь пользователя до того, как начать строить

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

2 мин чтения

Визуальное мышление против таблиц: когда сетка перестаёт помогать

Таблицы отлично работают с числами и плохо — со связями. В момент, когда план в основном про то, как всё связано, сетка начинает мешать.

2 мин чтения

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

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

2 мин чтения

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

Большинство брейнштормов рождают стену стикеров и ноль решений. Вот структура, которая превращает сырые идеи в кластеры, с которыми можно реально работать.

2 мин чтения

Матрица решений: как принять решение без бесконечных споров

Пошаговое руководство по построению матрицы решений, которая превращает хождение по кругу между вариантами в сравнение, которое может проверить каждый.

2 мин чтения

Канбан или диаграмма Ганта: что на самом деле должно управлять проектом

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

2 мин чтения

Приоритизация задач: практический фреймворк, который реально работает

Влияние, трудоёмкость, срочность, зависимости — простая система оценки задач для приоритизации, которая не разваливается на реальном бэклоге.

2 мин чтения

Основы планирования дорожной карты: как превратить видение в план

Практическое руководство по планированию roadmap — как разбить большую цель на этапы, расставить приоритеты и сделать дорожную карту живым инструментом, а не файлом, который никто не открывает.

2 мин чтения