Dependency Mapping: как управлять связями между задачами и командами
В мультикомандных проектах задачи редко выполняются изолированно.
Большинство из них имеют зависимости - от данных, других задач, команд или внешней инфраструктуры.
Если такие зависимости не идентифицированы и не отслеживаются, они становятся источником сбоев в сроках, качестве и управляемости проекта.
Три типа рисковых зависимостей:
1. Блокирующие (Hard Dependencies)
Пример: задача не может стартовать без готового API или утвержденного макета.
2. Плавающие (Soft Dependencies)
Пример: смежная команда пообещала отдать результат «в течение недели», но у них другие приоритеты.
3. Распределённые (External Backlog Dependencies)
Пример: связанная задача ведётся в другой Jira-доске и не входит в сферу контроля вашей команды.
Стратегия управления зависимостями (Dependency Mapping)
1. Выявление и фиксация
Создаём карту зависимостей: визуально (например, через Miro или Notion) или в виде таблицы. Указываем источник, тип зависимости и степень риска.
2. Назначение ответственного
Каждая зависимость должна иметь владельца, отвечающего за коммуникацию и актуализацию статуса.
3. Включение в план
Зависимости учитываются в планировании: сроки, риски, буферы. Они становятся частью спринта или релизного плана, а не “фоном”.
4. Регулярный мониторинг
Формализуем точки синхронизации: кто, с кем и когда синкается. Это особенно критично при кросс-функциональных интеграциях.
📌 Вывод
Dependency Mapping - это не избыточная бюрократия, а базовый инструмент для устойчивости проекта.
Пока зависимости не описаны, ни один план не может считаться реалистичным.
В мультикомандных проектах задачи редко выполняются изолированно.
Большинство из них имеют зависимости - от данных, других задач, команд или внешней инфраструктуры.
Если такие зависимости не идентифицированы и не отслеживаются, они становятся источником сбоев в сроках, качестве и управляемости проекта.
Три типа рисковых зависимостей:
1. Блокирующие (Hard Dependencies)
Пример: задача не может стартовать без готового API или утвержденного макета.
2. Плавающие (Soft Dependencies)
Пример: смежная команда пообещала отдать результат «в течение недели», но у них другие приоритеты.
3. Распределённые (External Backlog Dependencies)
Пример: связанная задача ведётся в другой Jira-доске и не входит в сферу контроля вашей команды.
Стратегия управления зависимостями (Dependency Mapping)
1. Выявление и фиксация
Создаём карту зависимостей: визуально (например, через Miro или Notion) или в виде таблицы. Указываем источник, тип зависимости и степень риска.
2. Назначение ответственного
Каждая зависимость должна иметь владельца, отвечающего за коммуникацию и актуализацию статуса.
3. Включение в план
Зависимости учитываются в планировании: сроки, риски, буферы. Они становятся частью спринта или релизного плана, а не “фоном”.
4. Регулярный мониторинг
Формализуем точки синхронизации: кто, с кем и когда синкается. Это особенно критично при кросс-функциональных интеграциях.
📌 Вывод
Dependency Mapping - это не избыточная бюрократия, а базовый инструмент для устойчивости проекта.
Пока зависимости не описаны, ни один план не может считаться реалистичным.
👍1
Kill Criteria: как понять, что проект надо остановить, а не дожимать
В IT до сих пор жив культ “дожать до конца”.
Хотя некоторые проекты надо не спасать, а останавливать.
И чем позже вы это поймёте - тем больше сгорят ресурсов, денег и мотивации команды.
Почему так происходит?
1. Эффект невозвратных издержек
«Мы уже столько вложили - нельзя бросить». Но прошлые вложения не делают проект жизнеспособным.
2. Личное участие
PM или инициатор слишком эмоционально вовлечён и боится признать ошибку.
3. Отсутствие Kill Criteria
Никто не определил заранее, при каких условиях проект надо свернуть - поэтому он идёт по инерции.
Что такое Kill Criteria?
Это чёткие критерии, при которых проект следует остановить, заморозить или пересобрать.
Примеры:
- нет traction по метрикам спустя X недель;
- превышение бюджета на N%, без прогресса;
- негативный feedback от целевой аудитории;
- отсутствие команды/ресурса на поддержку;
- технологическая невозможность реализовать MVP.
📌 Kill Criteria ≠ неудача. Это управленческое решение, которое сохраняет фокус и экономит ресурс.
Как ввести Kill Criteria в практику
1. Обсудите их заранее.
На этапе планирования проекта проговорите: «Что будет сигналом к остановке?»
2. Заложите checkpoints.
Установите точки принятия решения: что делаем, если к этому моменту нет X?
3. Ведите документацию.
Чтобы не принимать решение «по ощущениям», фиксируйте критерии и договорённости.
4. Отделяйте проект от команды.
Убить проект - не значит уволить людей. Это про смену фокуса, а не про провал.
📌 Вывод
Хороший PM не тот, кто тянет любой проект до упора.
А тот, кто знает, когда остановиться - чтобы спасти силы для следующего.
В IT до сих пор жив культ “дожать до конца”.
Хотя некоторые проекты надо не спасать, а останавливать.
И чем позже вы это поймёте - тем больше сгорят ресурсов, денег и мотивации команды.
Почему так происходит?
1. Эффект невозвратных издержек
«Мы уже столько вложили - нельзя бросить». Но прошлые вложения не делают проект жизнеспособным.
2. Личное участие
PM или инициатор слишком эмоционально вовлечён и боится признать ошибку.
3. Отсутствие Kill Criteria
Никто не определил заранее, при каких условиях проект надо свернуть - поэтому он идёт по инерции.
Что такое Kill Criteria?
Это чёткие критерии, при которых проект следует остановить, заморозить или пересобрать.
Примеры:
- нет traction по метрикам спустя X недель;
- превышение бюджета на N%, без прогресса;
- негативный feedback от целевой аудитории;
- отсутствие команды/ресурса на поддержку;
- технологическая невозможность реализовать MVP.
📌 Kill Criteria ≠ неудача. Это управленческое решение, которое сохраняет фокус и экономит ресурс.
Как ввести Kill Criteria в практику
1. Обсудите их заранее.
На этапе планирования проекта проговорите: «Что будет сигналом к остановке?»
2. Заложите checkpoints.
Установите точки принятия решения: что делаем, если к этому моменту нет X?
3. Ведите документацию.
Чтобы не принимать решение «по ощущениям», фиксируйте критерии и договорённости.
4. Отделяйте проект от команды.
Убить проект - не значит уволить людей. Это про смену фокуса, а не про провал.
📌 Вывод
Хороший PM не тот, кто тянет любой проект до упора.
А тот, кто знает, когда остановиться - чтобы спасти силы для следующего.
🤔4
«Процесс ради процесса»
Как понять, что команда воспроизводит ритуалы - но не управляет
Процессы - это инструмент.
Но иногда они становятся самоцелью:
- встречи проходят по графику
- артефакты оформлены
- статусы обновляются
- метрики считаются
А результата нет.
И самое тревожное - это даже не вызывает вопросов.
📌 Признаки имитации управления:
1. Процессы работают, но система - нет
Delivery обсуждается регулярно, но поставки нестабильны.
Ретроспективы проводятся - но проблемы повторяются.
2. Ритуалы не связаны с принятием решений
Команда участвует в обсуждениях, но ключевые решения принимаются вне процесса - кулуарно, “по звонку”.
3. Отчётность “зелёная”, а у команды ощущение перегруза и хаоса
Если нельзя принять решение без новой встречи - процесс не помогает, а блокирует.
💬 Живой пример:
На ретро команда регулярно записывает «action items».
Проходит неделя и никто не вспоминает, что там решили.
И на следующей ретроспективе обсуждают то же самое.
Формально процесс есть.
Но он не приводит к изменениям - значит, не работает.
Что с этим делать:
1. Оценить функцию каждого процесса
- какую проблему он решает?
- какие сигналы даёт?
- на основе чего принимаются решения?
2. Проверить связь с результатом
Если процесс существует “по инерции”, а ценность утрачена - адаптируйте или убирайте.
3. Выключите процесс на 1-2 итерации
Если за это время ничего не сломалось - он был формальностью.
4. Сократите шум
Лишние статусы, шаблоны и согласования - это тоже издержки. Уберите всё, что не приносит ясности или пользы.
📌 Вывод
Процесс - не традиция. Это способ управлять рисками, фокусом и скоростью.
Если он не даёт прогноз и не помогает принимать решения - перед вами операционная инерция.
Управление - это не про “делать по Scrum’у”, а про создавать среду, где понятно, что происходит, и можно влиять на результат.
Как понять, что команда воспроизводит ритуалы - но не управляет
Процессы - это инструмент.
Но иногда они становятся самоцелью:
- встречи проходят по графику
- артефакты оформлены
- статусы обновляются
- метрики считаются
А результата нет.
И самое тревожное - это даже не вызывает вопросов.
📌 Признаки имитации управления:
1. Процессы работают, но система - нет
Delivery обсуждается регулярно, но поставки нестабильны.
Ретроспективы проводятся - но проблемы повторяются.
2. Ритуалы не связаны с принятием решений
Команда участвует в обсуждениях, но ключевые решения принимаются вне процесса - кулуарно, “по звонку”.
3. Отчётность “зелёная”, а у команды ощущение перегруза и хаоса
Если нельзя принять решение без новой встречи - процесс не помогает, а блокирует.
💬 Живой пример:
На ретро команда регулярно записывает «action items».
Проходит неделя и никто не вспоминает, что там решили.
И на следующей ретроспективе обсуждают то же самое.
Формально процесс есть.
Но он не приводит к изменениям - значит, не работает.
Что с этим делать:
1. Оценить функцию каждого процесса
- какую проблему он решает?
- какие сигналы даёт?
- на основе чего принимаются решения?
2. Проверить связь с результатом
Если процесс существует “по инерции”, а ценность утрачена - адаптируйте или убирайте.
3. Выключите процесс на 1-2 итерации
Если за это время ничего не сломалось - он был формальностью.
4. Сократите шум
Лишние статусы, шаблоны и согласования - это тоже издержки. Уберите всё, что не приносит ясности или пользы.
📌 Вывод
Процесс - не традиция. Это способ управлять рисками, фокусом и скоростью.
Если он не даёт прогноз и не помогает принимать решения - перед вами операционная инерция.
Управление - это не про “делать по Scrum’у”, а про создавать среду, где понятно, что происходит, и можно влиять на результат.
Стабильность спринтов
Признаки, что ваш процесс действительно работает, а не просто соблюдает ритуалы.
1. План = Факт
Команда берёт задач столько, сколько реально завершает.
Оценки не «на глаз», а на основе прошлых данных.
- Используется Definition of Ready. Нет «сырых» задач в начале спринта.
- Done значит “готов к продакшену”, а не “почти сделали”.
2. Velocity не прыгает туда-сюда
Измеряется на 3-5 спринтах.
Колебания в пределах ±15-20%.
Если больше - проблема в входящих, внешнем шуме или низкой зрелости команды.
3. Проблемы не повторяются
Ретроспектива - не круг обсуждений.
- Есть action items с владельцами и сроками.
- Решения внедряются, и команда это замечает.
4. Решения принимаются внутри команды
Не нужно «звонить наверх», чтобы поменять приоритет.
Вопросы решаются на планировании и дейли - значит, процесс управляет рисками.
5. Появляется прогнозируемость
PM и заказчик понимают: сколько делаем за спринт, когда будет готово.
А команда не живёт в вечном «а может, успеем».
6. Снижается напряжение
Никто не тащит “на себе”.
Процессы не выматывают, а создают ритм.
Это результат системного улучшения, а не чьей-то героичности.
📌 Вывод
Когда спринты становятся стабильными - это не случайность.
Это результат зрелых процессов: прозрачности, рефлексии и включённости.
Если этого нет - стоит начать не с задач, а с системы.
Признаки, что ваш процесс действительно работает, а не просто соблюдает ритуалы.
1. План = Факт
Команда берёт задач столько, сколько реально завершает.
Оценки не «на глаз», а на основе прошлых данных.
- Используется Definition of Ready. Нет «сырых» задач в начале спринта.
- Done значит “готов к продакшену”, а не “почти сделали”.
2. Velocity не прыгает туда-сюда
Измеряется на 3-5 спринтах.
Колебания в пределах ±15-20%.
Если больше - проблема в входящих, внешнем шуме или низкой зрелости команды.
3. Проблемы не повторяются
Ретроспектива - не круг обсуждений.
- Есть action items с владельцами и сроками.
- Решения внедряются, и команда это замечает.
4. Решения принимаются внутри команды
Не нужно «звонить наверх», чтобы поменять приоритет.
Вопросы решаются на планировании и дейли - значит, процесс управляет рисками.
5. Появляется прогнозируемость
PM и заказчик понимают: сколько делаем за спринт, когда будет готово.
А команда не живёт в вечном «а может, успеем».
6. Снижается напряжение
Никто не тащит “на себе”.
Процессы не выматывают, а создают ритм.
Это результат системного улучшения, а не чьей-то героичности.
📌 Вывод
Когда спринты становятся стабильными - это не случайность.
Это результат зрелых процессов: прозрачности, рефлексии и включённости.
Если этого нет - стоит начать не с задач, а с системы.
🔥3
Escalation Culture
Как выстроить зрелую систему эскалаций без крика и паники
В здоровой культуре управления эскалация - это не «жалоба наверх».
Это механизм, который помогает быстро убрать блокеры, а не искать виноватых.
Но часто всё наоборот:
- эскалации воспринимаются как скандал
- включаются слишком рано или слишком поздно
- процесс неформальный, а значит - субъективный
Как выглядит незрелая эскалация-культура:
- «Мы пробовали решить, но не получилось» → сразу зовём директора
- «Давайте потерпим ещё недельку» - вместо чёткого триггера
- «Мне просто нужно, чтобы это быстрее сделали» - но без контекста, цели и договорённостей
Как выстроить зрелую Escalation Culture:
1. Определите критерии эскалации
Что именно считается блокером? Когда пора звать на помощь?
Примеры: пропущенный SLA, отсутствие ответа >2 дней, технический риск.
2. Формализуйте уровни и роли
Кто первый поднимает флаг? Кто следующий? Какие каналы коммуникации?
Эскалация - это не прыжок через голову, а управляемая лестница.
3. Обеспечьте прозрачность
Эскалация ≠ подстава.
Команда должна знать, что и как будет происходить, если задача “застрянет”.
4. Фокус на решении, а не виновных
Цель эскалации - убрать препятствие, не искать крайнего.
Важно сохранять уважительный тон, контекст и фокус на цели проекта.
5. Обратная связь после
После эскалации - разбор. Что пошло не так? Что улучшить в процессе?
Это делает систему устойчивой, а не реактивной.
📌 Вывод
Эскалация - это не признак проблемы в команде.
Это признак зрелости системы.
Когда вы умеете поднимать флаг без шума, но вовремя - у проекта появляется шанс выжить даже в турбулентности.
Как выстроить зрелую систему эскалаций без крика и паники
В здоровой культуре управления эскалация - это не «жалоба наверх».
Это механизм, который помогает быстро убрать блокеры, а не искать виноватых.
Но часто всё наоборот:
- эскалации воспринимаются как скандал
- включаются слишком рано или слишком поздно
- процесс неформальный, а значит - субъективный
Как выглядит незрелая эскалация-культура:
- «Мы пробовали решить, но не получилось» → сразу зовём директора
- «Давайте потерпим ещё недельку» - вместо чёткого триггера
- «Мне просто нужно, чтобы это быстрее сделали» - но без контекста, цели и договорённостей
Как выстроить зрелую Escalation Culture:
1. Определите критерии эскалации
Что именно считается блокером? Когда пора звать на помощь?
Примеры: пропущенный SLA, отсутствие ответа >2 дней, технический риск.
2. Формализуйте уровни и роли
Кто первый поднимает флаг? Кто следующий? Какие каналы коммуникации?
Эскалация - это не прыжок через голову, а управляемая лестница.
3. Обеспечьте прозрачность
Эскалация ≠ подстава.
Команда должна знать, что и как будет происходить, если задача “застрянет”.
4. Фокус на решении, а не виновных
Цель эскалации - убрать препятствие, не искать крайнего.
Важно сохранять уважительный тон, контекст и фокус на цели проекта.
5. Обратная связь после
После эскалации - разбор. Что пошло не так? Что улучшить в процессе?
Это делает систему устойчивой, а не реактивной.
📌 Вывод
Эскалация - это не признак проблемы в команде.
Это признак зрелости системы.
Когда вы умеете поднимать флаг без шума, но вовремя - у проекта появляется шанс выжить даже в турбулентности.
🔥7👍1
Хроническая тревога PM-а
Когда ты держишь в голове десятки рисков
На дейли всё звучит стабильно.
Но ты уже не расслаблялся вторую неделю.
Потому что в голове крутится вот это:
- ключевой разработчик уходит в отпуск за 2 дня до релиза
- аналитик не проверил баг, который однажды уже срывал демо
- на проде обновлённый сервис может конфликтовать с API-партнёра
- оплата подрядчику не прошла, а без неё они не стартуют
Всё вроде бы под контролем.
Но ты ощущаешь себя как сапёр: один неверный шаг и всё рванёт.
Почему так происходит?
Потому что риски остаются на уровне интуиции.
Ты их чувствуешь, но они не зафиксированы.
Никто из команды про них не знает.
И весь контроль держится только на твоей ментальной перегрузке.
Что с этим делать:
1. Выноси риски из головы
Нет зафиксированного риска - нет управления. Только тревожность.
2. Визуализируй зону турбулентности
Прямо на доске: блокеры, узкие места, зависимые задачи.
Используй risk matrix, dependency map или отдельную swimlane.
3. Проводите pre-mortem-сессии
Пусть команда назовёт 10 причин, по которым проект может провалиться - и увидит, что ты не параноик.
4. Назначай владельцев риска
Если кто-то может повлиять - пусть отвечает.
PM ≠ единственный наблюдатель.
5. Обновляй карту рисков регулярно
Живой risk backlog снижает тревожность и помогает принимать решения, а не просто “переживать”.
📌 Вывод
Риски не должны жить у тебя в голове.
Если ты работаешь как radar mode 24/7 - это не геройство, а дырка в процессе.
Хорошее управление - это не постоянное беспокойство, а система, где риски видны и управляемы.
Когда ты держишь в голове десятки рисков
На дейли всё звучит стабильно.
Но ты уже не расслаблялся вторую неделю.
Потому что в голове крутится вот это:
- ключевой разработчик уходит в отпуск за 2 дня до релиза
- аналитик не проверил баг, который однажды уже срывал демо
- на проде обновлённый сервис может конфликтовать с API-партнёра
- оплата подрядчику не прошла, а без неё они не стартуют
Всё вроде бы под контролем.
Но ты ощущаешь себя как сапёр: один неверный шаг и всё рванёт.
Почему так происходит?
Потому что риски остаются на уровне интуиции.
Ты их чувствуешь, но они не зафиксированы.
Никто из команды про них не знает.
И весь контроль держится только на твоей ментальной перегрузке.
Что с этим делать:
1. Выноси риски из головы
Нет зафиксированного риска - нет управления. Только тревожность.
2. Визуализируй зону турбулентности
Прямо на доске: блокеры, узкие места, зависимые задачи.
Используй risk matrix, dependency map или отдельную swimlane.
3. Проводите pre-mortem-сессии
Пусть команда назовёт 10 причин, по которым проект может провалиться - и увидит, что ты не параноик.
4. Назначай владельцев риска
Если кто-то может повлиять - пусть отвечает.
PM ≠ единственный наблюдатель.
5. Обновляй карту рисков регулярно
Живой risk backlog снижает тревожность и помогает принимать решения, а не просто “переживать”.
📌 Вывод
Риски не должны жить у тебя в голове.
Если ты работаешь как radar mode 24/7 - это не геройство, а дырка в процессе.
Хорошее управление - это не постоянное беспокойство, а система, где риски видны и управляемы.
👍7
GERT: как планировать с учётом альтернатив и вероятностей
Иногда проекты развиваются по одному сценарию. А иногда - как в фильме Нолана: куча развилок, варианты, задержки, и всё зависит от того, как повернёт команда.
В таких случаях метод PERT или критический путь уже не спасают. Потому что они не учитывают альтернативные пути и вероятности событий.
Здесь на сцену выходит GERT - Graphical Evaluation and Review Technique.
💡 Что это за зверь?
GERT - это метод планирования, который позволяет учитывать:
- разные пути развития проекта
- вероятности наступления событий
- циклы и повторения
- логические условия (например, «если тест прошёл - идём дальше, если нет - возвращаемся на доработку»)
Это уже не просто линейная диаграмма, а гибкий граф, где каждая стрелка - это не факт, а гипотеза с вероятностью.
🔍 Пример на пальцах
Допустим, у вас задача «Обновить фичу»:
• Если тест прошёл успешно - идём на прод (90%)
• Если нет - откат и переделка (10%), потом снова тест
Это нельзя просто забить в Gantt, потому что Gantt не понимает вероятности и циклы.
А GERT - понимает. Он показывает, как эти развилки повлияют на общий срок и успех проекта.
Как работает GERT на практике?
1️⃣ Построить граф задач
Связываем задачи стрелками, добавляем условия (например, «только если»).
2️⃣ Указать вероятности на каждой развилке
Например: тест успешен - 90%, провален - 10%. Или фича будет принята - 80%, уйдёт на доработку - 20%.
3️⃣ Запустить симуляцию
Здесь вручную сложно справиться - обычно используют инструменты вроде:
• Microsoft Project с надстройками
• AnyLogic, Simul8, OpenProject (в продвинутых версиях)
• или Python/Excel с моделями Монте-Карло (если руки прямые)
Симуляция многократно “проигрывает” прохождение проекта по разным сценариям, и даёт:
• среднюю длительность проекта
• вероятность успеть в срок
• диапазон разброса
Что даёт GERT
- Видишь не только срок, но и риски сценариев
- Можешь оценить, сколько циклов итераций съест времени
- Учитываешь реальность, где тесты срываются, баги всплывают, а заказчик меняет требования
GERT - это про гибкость и честность в сложных проектах.
Особенно там, где есть тестирование, проверка гипотез, пилоты и много «если».
📌 Вывод
Если ваш проект - не линейная дорожка, а лабиринт с развилками,
если реальность не вписывается в прямые диаграммы - попробуйте GERT.
Пусть это звучит как “нишевая штука”, но знание таких инструментов отличает просто менеджеров от управленцев, которые реально умеют работать с неопределённостью.
Иногда проекты развиваются по одному сценарию. А иногда - как в фильме Нолана: куча развилок, варианты, задержки, и всё зависит от того, как повернёт команда.
В таких случаях метод PERT или критический путь уже не спасают. Потому что они не учитывают альтернативные пути и вероятности событий.
Здесь на сцену выходит GERT - Graphical Evaluation and Review Technique.
💡 Что это за зверь?
GERT - это метод планирования, который позволяет учитывать:
- разные пути развития проекта
- вероятности наступления событий
- циклы и повторения
- логические условия (например, «если тест прошёл - идём дальше, если нет - возвращаемся на доработку»)
Это уже не просто линейная диаграмма, а гибкий граф, где каждая стрелка - это не факт, а гипотеза с вероятностью.
🔍 Пример на пальцах
Допустим, у вас задача «Обновить фичу»:
• Если тест прошёл успешно - идём на прод (90%)
• Если нет - откат и переделка (10%), потом снова тест
Это нельзя просто забить в Gantt, потому что Gantt не понимает вероятности и циклы.
А GERT - понимает. Он показывает, как эти развилки повлияют на общий срок и успех проекта.
Как работает GERT на практике?
1️⃣ Построить граф задач
Связываем задачи стрелками, добавляем условия (например, «только если»).
2️⃣ Указать вероятности на каждой развилке
Например: тест успешен - 90%, провален - 10%. Или фича будет принята - 80%, уйдёт на доработку - 20%.
3️⃣ Запустить симуляцию
Здесь вручную сложно справиться - обычно используют инструменты вроде:
• Microsoft Project с надстройками
• AnyLogic, Simul8, OpenProject (в продвинутых версиях)
• или Python/Excel с моделями Монте-Карло (если руки прямые)
Симуляция многократно “проигрывает” прохождение проекта по разным сценариям, и даёт:
• среднюю длительность проекта
• вероятность успеть в срок
• диапазон разброса
Что даёт GERT
- Видишь не только срок, но и риски сценариев
- Можешь оценить, сколько циклов итераций съест времени
- Учитываешь реальность, где тесты срываются, баги всплывают, а заказчик меняет требования
GERT - это про гибкость и честность в сложных проектах.
Особенно там, где есть тестирование, проверка гипотез, пилоты и много «если».
📌 Вывод
Если ваш проект - не линейная дорожка, а лабиринт с развилками,
если реальность не вписывается в прямые диаграммы - попробуйте GERT.
Пусть это звучит как “нишевая штука”, но знание таких инструментов отличает просто менеджеров от управленцев, которые реально умеют работать с неопределённостью.
👍2❤1
Decision latency
Когда проект буксует не из-за задач, а из-за молчания
На дейли всё звучит нормально.
А команда третий день ждёт согласования - и замирает.
Если это про ваш проект - возможно, дело не в разработке, а в decision latency: задержке принятия решений.
Что это такое?
Decision latency - это время между моментом, когда решение стало необходимым, и моментом, когда его реально приняли.
Оно растёт, когда:
• неясно, кто отвечает за решение
• всё откладывается «до следующей встречи»
• решения боятся озвучить вслух - особенно если они непопулярны
• приоритет у формы (отчёт, статус), а не действия
🔍 Как это выглядит в реальности?
• ТЗ висит на согласовании 5 день - команда ждёт
• Выбор фреймворка затянулся - разработка не стартует
• Договор с подрядчиком ушёл «на подпись» - неделя простоя
• После демо фидбек дают через 2 недели, а задачи уже в проде
Если в трекере задачи висят со статусом «ожидает решения» больше 3 дней - у вас накапливается latency
Почему это критично?
1. Копится незавершённая работа (WIP)
2. Падает мотивация (люди перестают проявлять инициативу)
3. Решения начинают «выталкиваться вниз» - то есть на PM-а
4. Команда “ждёт разрешения” вместо того, чтобы двигаться
Что делать?
1. Назначайте владельцев решений
Если нет лица, принимающего решение - оно не появится.
2. Фиксируйте сроки на принятие
Не только на задачи, но и на выбор: «До пятницы - иначе по плану B».
3. Визуализируйте ожидание
Прямо в доске: «Ожидает решения от [имя/роль] с [дата]». Становится неудобно игнорировать.
4. Автоматизируйте повторяющееся
Регламент, шаблон, критерий. Всё, что можно не обсуждать, должно решаться без вас.
5. Покажите последствия
Иначе всё кажется “неважным”.
Например: «Если решение не принято до 17:00 - мы откладываем релиз на неделю».
💡 Вывод
Иногда проект срывается не потому, что команда медленная.
А потому что решения не принимаются. Или их никто не требует.
Хороший PM - это не только фасилитатор процессов.
Это человек, который выстраивает культуру ясности: кто решает, когда и зачем.
Когда проект буксует не из-за задач, а из-за молчания
На дейли всё звучит нормально.
А команда третий день ждёт согласования - и замирает.
Если это про ваш проект - возможно, дело не в разработке, а в decision latency: задержке принятия решений.
Что это такое?
Decision latency - это время между моментом, когда решение стало необходимым, и моментом, когда его реально приняли.
Оно растёт, когда:
• неясно, кто отвечает за решение
• всё откладывается «до следующей встречи»
• решения боятся озвучить вслух - особенно если они непопулярны
• приоритет у формы (отчёт, статус), а не действия
🔍 Как это выглядит в реальности?
• ТЗ висит на согласовании 5 день - команда ждёт
• Выбор фреймворка затянулся - разработка не стартует
• Договор с подрядчиком ушёл «на подпись» - неделя простоя
• После демо фидбек дают через 2 недели, а задачи уже в проде
Если в трекере задачи висят со статусом «ожидает решения» больше 3 дней - у вас накапливается latency
Почему это критично?
1. Копится незавершённая работа (WIP)
2. Падает мотивация (люди перестают проявлять инициативу)
3. Решения начинают «выталкиваться вниз» - то есть на PM-а
4. Команда “ждёт разрешения” вместо того, чтобы двигаться
Что делать?
1. Назначайте владельцев решений
Если нет лица, принимающего решение - оно не появится.
2. Фиксируйте сроки на принятие
Не только на задачи, но и на выбор: «До пятницы - иначе по плану B».
3. Визуализируйте ожидание
Прямо в доске: «Ожидает решения от [имя/роль] с [дата]». Становится неудобно игнорировать.
4. Автоматизируйте повторяющееся
Регламент, шаблон, критерий. Всё, что можно не обсуждать, должно решаться без вас.
5. Покажите последствия
Иначе всё кажется “неважным”.
Например: «Если решение не принято до 17:00 - мы откладываем релиз на неделю».
💡 Вывод
Иногда проект срывается не потому, что команда медленная.
А потому что решения не принимаются. Или их никто не требует.
Хороший PM - это не только фасилитатор процессов.
Это человек, который выстраивает культуру ясности: кто решает, когда и зачем.
👍4
Change Fatigue
Как я однажды чуть не угробил команду «из лучших побуждений»
В какой-то момент я заметил: команда просто замолкла.
Не возмущаются, не спорят, не саботируют - просто делают и молчат.
На дейли все говорят «в процессе». Никто не шутит. Даже Jira будто потухла.
Ни огонька в глазах, ни идей, ни желания. Всё через «надо».
А ведь мы же «всё правильно делали»:
- внедрили процессы,
- обновили ритуалы,
- провели стратегическую сессию,
- добавили OKR,
- запустили новые метрики…
И вот я стою перед командой на очередной встрече -
с вдохновляющим слайдом, красивой схемой нового процесса -
и ловлю их взгляд.
Он пустой.
Тогда я впервые услышал это слово:
Change fatigue - усталость от изменений.
Это не когда люди против. Это когда им уже всё равно.
Потому что вчера было одно, сегодня другое, а завтра - третье.
И ни одно не прижилось.
Это не метафора и не выдумка коучей. Это реальный эффект, признанный в change management:
чем больше перемен без стабилизации, тем ниже энергия у команды.
И да, типичная ошибка управленца - думать, что если изменения «в правильную сторону», то их много не бывает.
Бывает.
Как это выглядело у нас:
• Коллега соглашается со всем, но делает по-своему
• Команда пассивно принимает новшества и так же спокойно их игнорирует
• В фидбэке пишут: «всё норм», а потом в курилке жалуются
• Снаружи - движение, внутри - апатия
Что мне помогло:
1. Остановиться.
Не придумывать ещё одну инициативу. Просто выдохнуть.
Признать: я перегнул. Я - с хорошими намерениями - перегрузил.
(И поймал себя на мысли: «а не я ли стал тем, от кого сам когда-то хотел сбежать?»)
2. Спросить команду.
Не через форму и не в Notion.
Без презентаций. Без «нам надо».
Просто: «Ребят, что вас сейчас выматывает? Чего не хочется больше видеть?»
Тогда они заговорили. Впервые, за долгое время.
3. Сделать паузу в трансформации.
Не отменить - отложить.
Устаканить то, что уже есть.
Починить процессы, которые недожили до зрелости.
Вернуть команде ощущение контроля.
И вот к чему я пришёл:
Иногда не вовлечённость надо прокачивать, а признать усталость.
Не вдохновлять, а замедлиться.
Не мотивировать, а дать тишину.
Проект не спасают новые фреймворки, если команда выгорела от старых.
И лидерство - это не про «заряжать на изменения».
А про то, чтобы уметь смотреть в глаза людям, которые просто больше не могут - и быть рядом.
Как я однажды чуть не угробил команду «из лучших побуждений»
В какой-то момент я заметил: команда просто замолкла.
Не возмущаются, не спорят, не саботируют - просто делают и молчат.
На дейли все говорят «в процессе». Никто не шутит. Даже Jira будто потухла.
Ни огонька в глазах, ни идей, ни желания. Всё через «надо».
А ведь мы же «всё правильно делали»:
- внедрили процессы,
- обновили ритуалы,
- провели стратегическую сессию,
- добавили OKR,
- запустили новые метрики…
И вот я стою перед командой на очередной встрече -
с вдохновляющим слайдом, красивой схемой нового процесса -
и ловлю их взгляд.
Он пустой.
Тогда я впервые услышал это слово:
Change fatigue - усталость от изменений.
Это не когда люди против. Это когда им уже всё равно.
Потому что вчера было одно, сегодня другое, а завтра - третье.
И ни одно не прижилось.
Это не метафора и не выдумка коучей. Это реальный эффект, признанный в change management:
чем больше перемен без стабилизации, тем ниже энергия у команды.
И да, типичная ошибка управленца - думать, что если изменения «в правильную сторону», то их много не бывает.
Бывает.
Как это выглядело у нас:
• Коллега соглашается со всем, но делает по-своему
• Команда пассивно принимает новшества и так же спокойно их игнорирует
• В фидбэке пишут: «всё норм», а потом в курилке жалуются
• Снаружи - движение, внутри - апатия
Что мне помогло:
1. Остановиться.
Не придумывать ещё одну инициативу. Просто выдохнуть.
Признать: я перегнул. Я - с хорошими намерениями - перегрузил.
(И поймал себя на мысли: «а не я ли стал тем, от кого сам когда-то хотел сбежать?»)
2. Спросить команду.
Не через форму и не в Notion.
Без презентаций. Без «нам надо».
Просто: «Ребят, что вас сейчас выматывает? Чего не хочется больше видеть?»
Тогда они заговорили. Впервые, за долгое время.
3. Сделать паузу в трансформации.
Не отменить - отложить.
Устаканить то, что уже есть.
Починить процессы, которые недожили до зрелости.
Вернуть команде ощущение контроля.
И вот к чему я пришёл:
Иногда не вовлечённость надо прокачивать, а признать усталость.
Не вдохновлять, а замедлиться.
Не мотивировать, а дать тишину.
Проект не спасают новые фреймворки, если команда выгорела от старых.
И лидерство - это не про «заряжать на изменения».
А про то, чтобы уметь смотреть в глаза людям, которые просто больше не могут - и быть рядом.
5🔥13❤4👍4💯1
Second-order effects в управлении проектами
Я думал, мы упростили процесс. А оказалось - размыли ориентиры.
В начале всё выглядело логично.
Команда устала от перегрузки. Я решил: давайте упростим.
- убрали лишние митинги
- сделали баг-трекинг чуть гибче
- перестали жёстко фиксировать задачи на спринт
Команда вздохнула.
Работать стало легче. Темп вырос.
Мы будто сбросили рюкзак, полный кирпичей.
Но прошло пару недель и в рюкзак что-то подбросили обратно.
- задачи стали перескакивать между спринтами
- приоритеты стало сложнее согласовать
- на ретро звучит: «мы вообще в какую сторону идём?»
- и вот уже команда предлагает: «а если вообще без планирования?»
Что пошло не так?
Мы не просто облегчили процесс.
Мы поменяли логику системы.
Команда поняла:
- приоритеты теперь плавают
- задачи можно сдвигать
- фиксированность - опциональна.
Всё это не было написано в регламенте.
Но было ясно без слов.
Поведение системы поменялось, а с ним и культура.
Это и есть эффекты второго порядка - последствия, которые не очевидны сразу.
Сначала решение кажется удачным.
Но потом ты видишь: оно обучило команду вести себя иначе.
Не так, как ты ожидал, а так, как им стало удобнее.
Теперь, прежде чем что-то менять, я задаю себе 3 вопроса:
1. Что станет «нормой» через 2-3 спринта, если мы это внедрим?
2. Что команда перестанет делать, когда это правило заработает?
3. Какой тип поведения это решение поощряет? А какой - делает неудобным?
Потому что люди отлично умеют адаптироваться.
Даже к неопределённости. Особенно к ней.
Иногда решение, которое кажется шагом вперёд -
на самом деле поворот в сторону, который ты увидишь только издалека.
Я думал, мы упростили процесс. А оказалось - размыли ориентиры.
В начале всё выглядело логично.
Команда устала от перегрузки. Я решил: давайте упростим.
- убрали лишние митинги
- сделали баг-трекинг чуть гибче
- перестали жёстко фиксировать задачи на спринт
Команда вздохнула.
Работать стало легче. Темп вырос.
Мы будто сбросили рюкзак, полный кирпичей.
Но прошло пару недель и в рюкзак что-то подбросили обратно.
- задачи стали перескакивать между спринтами
- приоритеты стало сложнее согласовать
- на ретро звучит: «мы вообще в какую сторону идём?»
- и вот уже команда предлагает: «а если вообще без планирования?»
Что пошло не так?
Мы не просто облегчили процесс.
Мы поменяли логику системы.
Команда поняла:
- приоритеты теперь плавают
- задачи можно сдвигать
- фиксированность - опциональна.
Всё это не было написано в регламенте.
Но было ясно без слов.
Поведение системы поменялось, а с ним и культура.
Это и есть эффекты второго порядка - последствия, которые не очевидны сразу.
Сначала решение кажется удачным.
Но потом ты видишь: оно обучило команду вести себя иначе.
Не так, как ты ожидал, а так, как им стало удобнее.
Теперь, прежде чем что-то менять, я задаю себе 3 вопроса:
1. Что станет «нормой» через 2-3 спринта, если мы это внедрим?
2. Что команда перестанет делать, когда это правило заработает?
3. Какой тип поведения это решение поощряет? А какой - делает неудобным?
Потому что люди отлично умеют адаптироваться.
Даже к неопределённости. Особенно к ней.
Иногда решение, которое кажется шагом вперёд -
на самом деле поворот в сторону, который ты увидишь только издалека.
🔥9
Wardley Mapping: Иногда команда буксует не потому, что всё плохо. А потому, что каждый строит что-то своё.
Один - фичу.
Другой - прототип.
Третий - инфраструктуру «на века».
А обсуждаем мы всё это как «один проект».
Отсюда конфликты, непонимание, лишние усилия.
Когда я впервые увидел Wardley Mapping, у меня щёлкнуло.
Это не фреймворк и не диаграмма.
Это карта зрелости компонентов, которая помогает понять:
- что у нас уже стабильно
- а что ещё сырое и требует гибкости.
Он прост:
На карте - две оси.
Y - насколько компонент важен для пользователя.
X - от гипотезы до утилиты: насколько компонент стандартизирован и предсказуем.
Чем правее - тем меньше неопределённости, и тем больше можно полагаться на готовые решения.
Элементы проходят 4 стадии:
1. Генезис - идеи, гипотезы, туман.
2. Продукт - уже с формой, но без стандарта.
3. Коммодити - зрелое, можно брать с полки.
4. Утилита - инфраструктура. Просто работает.
Приведу пример:
Обсуждаем логирование.
Один говорит: «Берём готовое - всё давно есть».
Другой: «Нет, нужно кастомное, у нас особые кейсы».
Третий: «Да зачем всё это - просто пишем в консоль, потом разберёмся».
И все трое по-своему правы.
Просто они мыслят о компоненте на разных стадиях зрелости.
Wardley Map показывает:
- где мы сейчас,
- какие элементы стоит автоматизировать,
- где нужен discovery,
- а что уже можно не трогать.
С тех пор я смотрю на проекты не как на список задач,
а как на набор компонентов с разной степенью определённости.
И задаю себе три вопроса:
1. Это компонент - или эксперимент?
2. Мы строим - или используем готовое?
3. Важно ли это пользователю - или просто привычно нам?
Wardley Mapping не даёт готовых ответов.
Он убирает иллюзии, что мы все говорим об одном и том же.
Иногда не нужен новый процесс.
Нужно просто понять: мы вообще о чём сейчас?
Один - фичу.
Другой - прототип.
Третий - инфраструктуру «на века».
А обсуждаем мы всё это как «один проект».
Отсюда конфликты, непонимание, лишние усилия.
Когда я впервые увидел Wardley Mapping, у меня щёлкнуло.
Это не фреймворк и не диаграмма.
Это карта зрелости компонентов, которая помогает понять:
- что у нас уже стабильно
- а что ещё сырое и требует гибкости.
Он прост:
На карте - две оси.
Y - насколько компонент важен для пользователя.
X - от гипотезы до утилиты: насколько компонент стандартизирован и предсказуем.
Чем правее - тем меньше неопределённости, и тем больше можно полагаться на готовые решения.
Элементы проходят 4 стадии:
1. Генезис - идеи, гипотезы, туман.
2. Продукт - уже с формой, но без стандарта.
3. Коммодити - зрелое, можно брать с полки.
4. Утилита - инфраструктура. Просто работает.
Приведу пример:
Обсуждаем логирование.
Один говорит: «Берём готовое - всё давно есть».
Другой: «Нет, нужно кастомное, у нас особые кейсы».
Третий: «Да зачем всё это - просто пишем в консоль, потом разберёмся».
И все трое по-своему правы.
Просто они мыслят о компоненте на разных стадиях зрелости.
Wardley Map показывает:
- где мы сейчас,
- какие элементы стоит автоматизировать,
- где нужен discovery,
- а что уже можно не трогать.
С тех пор я смотрю на проекты не как на список задач,
а как на набор компонентов с разной степенью определённости.
И задаю себе три вопроса:
1. Это компонент - или эксперимент?
2. Мы строим - или используем готовое?
3. Важно ли это пользователю - или просто привычно нам?
Wardley Mapping не даёт готовых ответов.
Он убирает иллюзии, что мы все говорим об одном и том же.
Иногда не нужен новый процесс.
Нужно просто понять: мы вообще о чём сейчас?
👍7✍1
Всем привет! Я участвую в конкурсе Telegram-каналов
Я подал свой канал на конкурс @tg_contest_main.
Если вам откликается то, что я здесь пишу - про управление, команды и процессы - буду рад вашей поддержке.
📆 Голосование - с 7 по 14 июля, в открытой группе конкурса (сообщу позднее).
Сайт конкурса: https://tg-contest.tilda.ws
Спасибо, что вы здесь!
Я подал свой канал на конкурс @tg_contest_main.
Если вам откликается то, что я здесь пишу - про управление, команды и процессы - буду рад вашей поддержке.
📆 Голосование - с 7 по 14 июля, в открытой группе конкурса (сообщу позднее).
Сайт конкурса: https://tg-contest.tilda.ws
Спасибо, что вы здесь!
👍11🐳2🌭2🤮1💩1
Project Friction Audit
Как находить невидимые точки замедления проекта
Бывает, смотришь на проект - формально всё идёт: задачи в работе, спринты по расписанию, команда не простаивает. А прогресса будто нет. Движение есть, но оно как сквозь вязкую среду: гребём, а лодка почти не плывёт.
Это не баги, не риски, не блокеры.
Это трение.
Мелкие, почти незаметные замедления, которые по отдельности не критичны, но вместе отнимают энергию, время и внимание. Я стал их замечать, когда даже сильные команды с ясным планом вдруг начинали буксовать - без очевидных причин.
Где чаще всего прячется трение:
- Постоянные уточнения: кто за что отвечает, куда писать, где актуальная версия. Кажется, ерунда, но теряем часы.
- Ожидание ответов. Кто-то “просто подумает до завтра” - и у нас минус два дня.
- Устаревшие артефакты. Confluence вроде был, но уже никто не уверен - и начинается охота за инфой.
- Метрики ради галочки. Собираем, но не обсуждаем. Пишем отчёты, но никто не читает.
- Задачи «почти готово». Неделями висят в ревью или QA, без внятного статуса.
- Ритуалы без смысла. Дейли, где все «в процессе». Ретро, где «всё норм». Planning, на котором все мысленно уже на обеде.
Самое коварное в этом всём - это невидимость.
Мы не воспринимаем это как риски. Это просто фон, уже ривычный.
Но именно он выматывает сильнее, чем баг или дедлайн.
Что помогает:
1. Пройтись по Value Stream: где реально застревают задачи?
2. Заглянуть в aging report: что давно в работе и почему?
3. Спросить команду: что в процессе раздражает, но «так сложилось»?
4. Проверить ответственность: есть ли зоны, где её нет или, наоборот, слишком много «владельцев»?
Я это для себя называю аудитом трения - не процессов и не людей, а самого проекта. Как будто смотришь на мотор и ищешь: где буксует, где перегревается, где масло не доходит.
Часто PM пытается поднять velocity, а надо просто убрать то, что мешает двигаться.
И один вопрос, который я беру с собой в каждый проект:
Что мы делаем изо дня в день, но это никак не приближает нас к результату?
Иногда ответ на него менял у нас больше, чем новый фреймворк или воркшоп.
Как находить невидимые точки замедления проекта
Бывает, смотришь на проект - формально всё идёт: задачи в работе, спринты по расписанию, команда не простаивает. А прогресса будто нет. Движение есть, но оно как сквозь вязкую среду: гребём, а лодка почти не плывёт.
Это не баги, не риски, не блокеры.
Это трение.
Мелкие, почти незаметные замедления, которые по отдельности не критичны, но вместе отнимают энергию, время и внимание. Я стал их замечать, когда даже сильные команды с ясным планом вдруг начинали буксовать - без очевидных причин.
Где чаще всего прячется трение:
- Постоянные уточнения: кто за что отвечает, куда писать, где актуальная версия. Кажется, ерунда, но теряем часы.
- Ожидание ответов. Кто-то “просто подумает до завтра” - и у нас минус два дня.
- Устаревшие артефакты. Confluence вроде был, но уже никто не уверен - и начинается охота за инфой.
- Метрики ради галочки. Собираем, но не обсуждаем. Пишем отчёты, но никто не читает.
- Задачи «почти готово». Неделями висят в ревью или QA, без внятного статуса.
- Ритуалы без смысла. Дейли, где все «в процессе». Ретро, где «всё норм». Planning, на котором все мысленно уже на обеде.
Самое коварное в этом всём - это невидимость.
Мы не воспринимаем это как риски. Это просто фон, уже ривычный.
Но именно он выматывает сильнее, чем баг или дедлайн.
Что помогает:
1. Пройтись по Value Stream: где реально застревают задачи?
2. Заглянуть в aging report: что давно в работе и почему?
3. Спросить команду: что в процессе раздражает, но «так сложилось»?
4. Проверить ответственность: есть ли зоны, где её нет или, наоборот, слишком много «владельцев»?
Я это для себя называю аудитом трения - не процессов и не людей, а самого проекта. Как будто смотришь на мотор и ищешь: где буксует, где перегревается, где масло не доходит.
Часто PM пытается поднять velocity, а надо просто убрать то, что мешает двигаться.
И один вопрос, который я беру с собой в каждый проект:
Что мы делаем изо дня в день, но это никак не приближает нас к результату?
Иногда ответ на него менял у нас больше, чем новый фреймворк или воркшоп.
1🔥7❤2
Методы управления контекстом в команде
или как понять, что люди действительно понимают, над чем и зачем работают
Иногда в проекте всё выглядит стройно: задачи берутся, митинги идут по расписанию, в Confluence - полка артефактов. Но стоит задать команде пару простых вопросов и становится неловко. Кто-то не может объяснить, зачем делается фича. Кто-то ссылается на задачу в Jira, но не на цель. Кто-то просто делает, потому что «так написали».
И это не саботаж. Это потеря контекста - один из самых недооценённых рисков.
Контекст - это не только “что делать”. Это “зачем”, “почему именно так” и “что будет, если не сделать”.
На короткой дистанции можно ехать без этого. Но в длинной - начинается расфокус, ошибки, недопонимание. Команда вроде двигается, но у каждого свой вектор. А продукт становится набором странных решений, в которых уже никто не уверен.
Был у меня проект, где всё выглядело идеально - доска чистая, burn-down ровный. А потом вдруг сделали фичу, но с неверной логикой.
Когда начали разбираться - оказалось, цель фичи все поняли по-своему. Формально её озвучили на старте, но дальше каждый интерпретировал в своей плоскости. С тех пор я почти на каждой синке спрашиваю не «что делаете?», а «зачем это делаем?».
Что помогает удерживать общий контекст:
- Регулярно проговаривать цели задач и фич на уровне смыслов, а не только действий
- На встречах спрашивать «что изменится, когда это будет сделано»
- Делиться фидбеком от пользователей, бизнес-метриками и инсайтами
- Выводить цели и мотивации прямо в таски - чтобы были перед глазами
- Проверять: могут ли члены команды объяснить, зачем мы делаем ту или иную задачу (не на зачёт, а как сигнал)
Мы привыкли управлять временем, ресурсами, приоритетами. Но без управления контекстом - всё это начинает рассыпаться.
Как будто у всех есть карта, но каждый читает её на своём языке.
Я не верю в команды, которые работают «по плану», но без понимания смысла.
Это не движение. Это имитация.
или как понять, что люди действительно понимают, над чем и зачем работают
Иногда в проекте всё выглядит стройно: задачи берутся, митинги идут по расписанию, в Confluence - полка артефактов. Но стоит задать команде пару простых вопросов и становится неловко. Кто-то не может объяснить, зачем делается фича. Кто-то ссылается на задачу в Jira, но не на цель. Кто-то просто делает, потому что «так написали».
И это не саботаж. Это потеря контекста - один из самых недооценённых рисков.
Контекст - это не только “что делать”. Это “зачем”, “почему именно так” и “что будет, если не сделать”.
На короткой дистанции можно ехать без этого. Но в длинной - начинается расфокус, ошибки, недопонимание. Команда вроде двигается, но у каждого свой вектор. А продукт становится набором странных решений, в которых уже никто не уверен.
Был у меня проект, где всё выглядело идеально - доска чистая, burn-down ровный. А потом вдруг сделали фичу, но с неверной логикой.
Когда начали разбираться - оказалось, цель фичи все поняли по-своему. Формально её озвучили на старте, но дальше каждый интерпретировал в своей плоскости. С тех пор я почти на каждой синке спрашиваю не «что делаете?», а «зачем это делаем?».
Что помогает удерживать общий контекст:
- Регулярно проговаривать цели задач и фич на уровне смыслов, а не только действий
- На встречах спрашивать «что изменится, когда это будет сделано»
- Делиться фидбеком от пользователей, бизнес-метриками и инсайтами
- Выводить цели и мотивации прямо в таски - чтобы были перед глазами
- Проверять: могут ли члены команды объяснить, зачем мы делаем ту или иную задачу (не на зачёт, а как сигнал)
Мы привыкли управлять временем, ресурсами, приоритетами. Но без управления контекстом - всё это начинает рассыпаться.
Как будто у всех есть карта, но каждый читает её на своём языке.
Я не верю в команды, которые работают «по плану», но без понимания смысла.
Это не движение. Это имитация.
👍5❤4
Прокси-метрики: почему проект может казаться успешным, но только на графике
Иногда кажется, что проект идёт как надо: velocity растёт, задачи закрываются, релизы идут по плану.
А реального прогресса всё равно нет.
Команда загружена, статус-колонки заполнены, но пользы как будто нет. Почему?
Часто причина - в прокси-метриках.
Что это такое
Прокси-метрика - это не сама цель, а её косвенный признак.
Она может показывать движение, но не факт, что в нужную сторону.
Примеры:
• Velocity растёт - потому что задачи просто мельчат
• Покрытие тестами увеличивается, а количество багов не падает
• Количество релизов растёт, но критические ошибки остаются
На бумаге - успех.
По факту - проект буксует.
В чём опасность
Прокси-метрики часто выглядят красиво и легко трекаются.
Именно поэтому их любят показывать на статусных встречах.
Но за ними легко упустить настоящую ценность - ту, ради которой всё делается.
Типичные ошибки:
• Оптимизация под «закрытые задачи», а не под результат
• Увеличение релизов - без контроля качества
• Гонки за идеальной burn-down - в ущерб смыслу
Как работать с метриками правильно
1. Определи, зачем ты замеряешь:
Что именно ты хочешь улучшить? (Скорость? Надёжность? Предсказуемость?)
2. Свяжи метрику с реальной болью:
Есть ли прямая польза от улучшения этого показателя?
3. Используй не одну, а связку:
- Velocity + Aging WIP
- Кол-во релизов + % инцидентов
- Время реакции + Уровень SLA
4. Регулярно пересматривай метрики:
Проект растёт - и то, что было актуально вчера, может мешать сегодня.
Метрика - это не цель. Это инструмент.
PM не про красивую отчётность.
PM про результат, который можно объяснить и команде, и заказчику.
Иногда кажется, что проект идёт как надо: velocity растёт, задачи закрываются, релизы идут по плану.
А реального прогресса всё равно нет.
Команда загружена, статус-колонки заполнены, но пользы как будто нет. Почему?
Часто причина - в прокси-метриках.
Что это такое
Прокси-метрика - это не сама цель, а её косвенный признак.
Она может показывать движение, но не факт, что в нужную сторону.
Примеры:
• Velocity растёт - потому что задачи просто мельчат
• Покрытие тестами увеличивается, а количество багов не падает
• Количество релизов растёт, но критические ошибки остаются
На бумаге - успех.
По факту - проект буксует.
В чём опасность
Прокси-метрики часто выглядят красиво и легко трекаются.
Именно поэтому их любят показывать на статусных встречах.
Но за ними легко упустить настоящую ценность - ту, ради которой всё делается.
Типичные ошибки:
• Оптимизация под «закрытые задачи», а не под результат
• Увеличение релизов - без контроля качества
• Гонки за идеальной burn-down - в ущерб смыслу
Как работать с метриками правильно
1. Определи, зачем ты замеряешь:
Что именно ты хочешь улучшить? (Скорость? Надёжность? Предсказуемость?)
2. Свяжи метрику с реальной болью:
Есть ли прямая польза от улучшения этого показателя?
3. Используй не одну, а связку:
- Velocity + Aging WIP
- Кол-во релизов + % инцидентов
- Время реакции + Уровень SLA
4. Регулярно пересматривай метрики:
Проект растёт - и то, что было актуально вчера, может мешать сегодня.
Метрика - это не цель. Это инструмент.
PM не про красивую отчётность.
PM про результат, который можно объяснить и команде, и заказчику.
👍6
Behavioral Bottlenecks
Почему проект буксует, даже если процессы в порядке
Всё вроде шло нормально.
План есть, Канбан работает, груминг, планирование.
Но одна задача - «в работе» - висит уже третью неделю. Никто не трогает.
Я спрашиваю разработчика:
- Что там?
Он честно отвечает:
«Садился пару раз и бросал. Не знаю, как подступиться. Не хочу облажаться.»
Мысль пришла быстро:
это не баг в процессе. Это затык в голове.
Поведенческий bottleneck. Тихий, невидимый, но мощный.
Это не:
- плохая декомпозиция
- нехватка времени
- неопределённость требований
Это:
- страх начать
- перфекционизм
- избегание
- выученная беспомощность («я не справлюсь - лучше не начинать»)
Что можно сделать как PM:
1. Обсуждать не только прогресс, но и сопротивление.
Спрашивать не «сделал?», а «есть ли что-то, что мешает начать?»
2. Разрешать «начать плохо».
Иногда достаточно проговорить: «давай просто набросок», «первый коммит - черновик».
3. Декомпозировать эмоционально, а не только технически.
Что именно вызывает ступор? Не весь таск, а конкретный шаг.
4. Нормализовать паузы и честность.
Люди боятся признаться, что застряли. Особенно, если в команде не принято говорить «мне страшно» или «я не понял».
5. Отслеживать “стареющие” задачи.
Если тикет висит без коммитов или комментариев - это не таска, это сигнал.
Парадокс в том, что ты можешь идеально выстроить процессы и всё равно получить стагнацию.
Потому что процессы - это структура. А вот движение в ней делают люди. Со своими страхами, привычками и шаблонами.
Если их не видеть - проект будет тормозить. Тихо, незаметно, по-человечески.
Почему проект буксует, даже если процессы в порядке
Всё вроде шло нормально.
План есть, Канбан работает, груминг, планирование.
Но одна задача - «в работе» - висит уже третью неделю. Никто не трогает.
Я спрашиваю разработчика:
- Что там?
Он честно отвечает:
«Садился пару раз и бросал. Не знаю, как подступиться. Не хочу облажаться.»
Мысль пришла быстро:
это не баг в процессе. Это затык в голове.
Поведенческий bottleneck. Тихий, невидимый, но мощный.
Это не:
- плохая декомпозиция
- нехватка времени
- неопределённость требований
Это:
- страх начать
- перфекционизм
- избегание
- выученная беспомощность («я не справлюсь - лучше не начинать»)
Что можно сделать как PM:
1. Обсуждать не только прогресс, но и сопротивление.
Спрашивать не «сделал?», а «есть ли что-то, что мешает начать?»
2. Разрешать «начать плохо».
Иногда достаточно проговорить: «давай просто набросок», «первый коммит - черновик».
3. Декомпозировать эмоционально, а не только технически.
Что именно вызывает ступор? Не весь таск, а конкретный шаг.
4. Нормализовать паузы и честность.
Люди боятся признаться, что застряли. Особенно, если в команде не принято говорить «мне страшно» или «я не понял».
5. Отслеживать “стареющие” задачи.
Если тикет висит без коммитов или комментариев - это не таска, это сигнал.
Парадокс в том, что ты можешь идеально выстроить процессы и всё равно получить стагнацию.
Потому что процессы - это структура. А вот движение в ней делают люди. Со своими страхами, привычками и шаблонами.
Если их не видеть - проект будет тормозить. Тихо, незаметно, по-человечески.
👍12🔥6✍4
Meta-менеджмент: как управлять тем, как ты управляешь
В какой-то момент я заметил: я сам иногда становлюсь блокером.
Процессы настроены, команда зрелая, заказчик вменяемый, а я всё ещё микроконтролю, как будто мы в первом спринте на хаотичном старте.
Или наоборот: команда новенькая, фреймворки новые, куча неопределённости, а я уже ушел в стратегические обсуждения, забыв, что им не вдохновение нужно, а чтобы на доске было понятно, куда смотреть утром, и к кому идти, если все упало.
Так я впервые задумался о meta-менеджменте.
Это не про управление задачами. Это про управление собственным управлением.
Про то, как ты настраиваешь подход:
- под команду,
- под фазу проекта,
- под тип заказчика.
Иногда тебе нужен контроль, а иногда доверие. Где-то важна скорость - где-то устойчивость. Иногда ты фасилитатор - иногда директивный лидер.
И вот что не работает:
- делать “как привык”.
- “по книжке”.
- или “как в прошлом проекте”.
Каждый проект - это новая система координат.
И ты либо адаптируешь свою роль, либо становишься архаичным скриптом, который не считывает контекст.
Что помогает мне:
- раз в пару недель честно смотреть на то, как я сейчас управляю
- задавать себе неудобные вопросы:
• насколько моя модель соответствует текущей фазе проекта?
• нужен ли здесь такой уровень контроля?
• какие сигналы я игнорирую?
- и главное - быть готовым к тому, что мой стиль должен меняться.
Менеджмент - это не набор техник.
Это живой, адаптивный способ мышления.
И если ты умеешь управлять даже своим управлением - вот это и есть зрелость.
В какой-то момент я заметил: я сам иногда становлюсь блокером.
Процессы настроены, команда зрелая, заказчик вменяемый, а я всё ещё микроконтролю, как будто мы в первом спринте на хаотичном старте.
Или наоборот: команда новенькая, фреймворки новые, куча неопределённости, а я уже ушел в стратегические обсуждения, забыв, что им не вдохновение нужно, а чтобы на доске было понятно, куда смотреть утром, и к кому идти, если все упало.
Так я впервые задумался о meta-менеджменте.
Это не про управление задачами. Это про управление собственным управлением.
Про то, как ты настраиваешь подход:
- под команду,
- под фазу проекта,
- под тип заказчика.
Иногда тебе нужен контроль, а иногда доверие. Где-то важна скорость - где-то устойчивость. Иногда ты фасилитатор - иногда директивный лидер.
И вот что не работает:
- делать “как привык”.
- “по книжке”.
- или “как в прошлом проекте”.
Каждый проект - это новая система координат.
И ты либо адаптируешь свою роль, либо становишься архаичным скриптом, который не считывает контекст.
Что помогает мне:
- раз в пару недель честно смотреть на то, как я сейчас управляю
- задавать себе неудобные вопросы:
• насколько моя модель соответствует текущей фазе проекта?
• нужен ли здесь такой уровень контроля?
• какие сигналы я игнорирую?
- и главное - быть готовым к тому, что мой стиль должен меняться.
Менеджмент - это не набор техник.
Это живой, адаптивный способ мышления.
И если ты умеешь управлять даже своим управлением - вот это и есть зрелость.
🔥7❤3👍3👏1
Живой API: не контролировать, а соединять
Как-то поймал себя на фразе: «Сначала переведу с бэкэндского на менеджерский, потом на бизнесовый, потом на русский - и понесу наверх».
И ведь так и живем.
На одной встрече обсуждаем latency между микросервисами. На второй - бюджет. А на третьей меня спрашивают: «Зачем мы вообще это делаем?» И я такой - секунду, сейчас переформатируюсь.
Потому что ты не просто руководишь задачами. Ты соединяешь людей, культуры и системы, в которых одни говорят “мы почти сделали” - и имеют в виду “мы начали”, а другие слышат “через два часа зальём в прод”.
Это точка, в которой проект чаще всего и рассыпается - не внутри спринта, не в документации, а на стыке. Там, где кто-то говорит «всё понятно», но на самом деле не понял. Где коммуникация вроде была, но договоренности - нет. Где ожидания разъехались, а никто не заметил.
Я начал по-другому думать о своей роли, когда понял: быть хорошим PM-ом - значит быть тем, кто выдерживает стык. Кто умеет переключаться между языками, стилями, скоростями. Кто может говорить и с разработчиком, и с юристом, и с заказчиком - и при этом не быть «переводчиком», который просто меняет слова, а тем, кто соединяет смысл.
Ты не прокладка. Ты не координатор. Ты точка доступа. И от тебя зависит, пройдёт ли сигнал, или всё оборвётся.
И да, интерфейсы могут лагать. Особенно, если не слышат себя. Особенно, если держатся за привычный стиль управления вместо того, чтобы смотреть по сторонам.
Но как только ты начинаешь осознанно выбирать, каким быть в этом проекте - ты начинаешь управлять не задачами, а самим процессом управления.
Как-то поймал себя на фразе: «Сначала переведу с бэкэндского на менеджерский, потом на бизнесовый, потом на русский - и понесу наверх».
И ведь так и живем.
На одной встрече обсуждаем latency между микросервисами. На второй - бюджет. А на третьей меня спрашивают: «Зачем мы вообще это делаем?» И я такой - секунду, сейчас переформатируюсь.
Потому что ты не просто руководишь задачами. Ты соединяешь людей, культуры и системы, в которых одни говорят “мы почти сделали” - и имеют в виду “мы начали”, а другие слышат “через два часа зальём в прод”.
Это точка, в которой проект чаще всего и рассыпается - не внутри спринта, не в документации, а на стыке. Там, где кто-то говорит «всё понятно», но на самом деле не понял. Где коммуникация вроде была, но договоренности - нет. Где ожидания разъехались, а никто не заметил.
Я начал по-другому думать о своей роли, когда понял: быть хорошим PM-ом - значит быть тем, кто выдерживает стык. Кто умеет переключаться между языками, стилями, скоростями. Кто может говорить и с разработчиком, и с юристом, и с заказчиком - и при этом не быть «переводчиком», который просто меняет слова, а тем, кто соединяет смысл.
Ты не прокладка. Ты не координатор. Ты точка доступа. И от тебя зависит, пройдёт ли сигнал, или всё оборвётся.
И да, интерфейсы могут лагать. Особенно, если не слышат себя. Особенно, если держатся за привычный стиль управления вместо того, чтобы смотреть по сторонам.
Но как только ты начинаешь осознанно выбирать, каким быть в этом проекте - ты начинаешь управлять не задачами, а самим процессом управления.
👍9🔥6❤🔥2👏2