Вопрос, который PM должен задать перед тем, как принять новую задачу
Перед тем как принять новую задачу, PM обычно спрашивает:
Гораздо полезнее другой вопрос:
В управлении потоком есть простое правило:
capacity не растет вместе с demand.
Если новая задача входит в систему, какая-то часть текущего commitment неизбежно замедляется.
Практика, которую легко проверить:
если приоритеты не изменились, нового приоритета на самом деле нет.
Есть только надежда, что система «растянется».
Именно так чаще всего и появляется перегруз:
не из-за сложности задач, а из-за неозвученных trade-offs.
Перед тем как принять новую задачу, PM обычно спрашивает:
«Это срочно?»
Гораздо полезнее другой вопрос:
«Какую работу мы откладываем, если берем это?»
В управлении потоком есть простое правило:
capacity не растет вместе с demand.
Если новая задача входит в систему, какая-то часть текущего commitment неизбежно замедляется.
Практика, которую легко проверить:
если приоритеты не изменились, нового приоритета на самом деле нет.
Есть только надежда, что система «растянется».
Именно так чаще всего и появляется перегруз:
не из-за сложности задач, а из-за неозвученных trade-offs.
❤6🔥6💯3
Почему Lead Time “в среднем нормальный”, а сроки все равно срываются
Многие PM-ы смотрят на средний Lead Time и считают, что все под контролем.
Проблема в том, что проекты редко ломаются по среднему значению, обычно это делают отдельные задачи, которые застревают надолго.
Когда часть задач закрывается быстро,
а часть регулярно живет по 20-30 дней, среднее выглядит аккуратно.
Но именно эти длинные задачи и двигают реальные сроки.
На практике они:
- сдвигают релизы,
- ломают ожидания,
- создают ощущение постоянных задержек, даже при “нормальных” метриках.
Практический прием:
для сроков и прогнозов смотри не на average Lead Time, а на верхнюю часть распределения - 85-90 percentile.
Расшифровка: 85 percentile Lead Time = 85% задач завершаются быстрее этого срока, а 15% - дольше.
Так ты сразу учитываешь риск редких, но долгих задач
и перестаешь удивляться, почему проект опять не уложился в обещанные даты.
Многие PM-ы смотрят на средний Lead Time и считают, что все под контролем.
«В среднем задача делается за 8 дней».
Проблема в том, что проекты редко ломаются по среднему значению, обычно это делают отдельные задачи, которые застревают надолго.
Когда часть задач закрывается быстро,
а часть регулярно живет по 20-30 дней, среднее выглядит аккуратно.
Но именно эти длинные задачи и двигают реальные сроки.
На практике они:
- сдвигают релизы,
- ломают ожидания,
- создают ощущение постоянных задержек, даже при “нормальных” метриках.
Практический прием:
для сроков и прогнозов смотри не на average Lead Time, а на верхнюю часть распределения - 85-90 percentile.
Расшифровка: 85 percentile Lead Time = 85% задач завершаются быстрее этого срока, а 15% - дольше.
Так ты сразу учитываешь риск редких, но долгих задач
и перестаешь удивляться, почему проект опять не уложился в обещанные даты.
🔥4❤2💯2
Почему “быстро закрываем задачи” ≠ “процесс под контролем”
Команды любят говорить:
PM обычно просто кивает, но бизнес все равно не понимает, когда ждать результат.
Причина проста:
скорость - это темп,
а контроль - это предсказуемость.
Если посмотреть control chart, почти всегда видно одно и то же:
- median выглядит нормально,
- но 85-95 перцентиль уезжают далеко вправо.
Трактовать это просто:
большая часть задач проходит быстро, но меньшая часть застревает надолго.
Именно они и ломают сроки и ожидания.
Практический тест для PM-а:
Перед тем как сказать «мы идем быстро», посмотри:
- насколько стабилен 85 перцентиль,
- растет ли хвост от месяца к месяцу,
- можешь ли ты сказать бизнесу:
Если не можешь - процесс ты не контролируешь, даже если «Done» растет.
Быстро ≠ предсказуемо, а управляем мы именно предсказуемостью.
Команды любят говорить:
«Мы быстро закрываем задачи».
PM обычно просто кивает, но бизнес все равно не понимает, когда ждать результат.
Причина проста:
скорость - это темп,
а контроль - это предсказуемость.
Если посмотреть control chart, почти всегда видно одно и то же:
- median выглядит нормально,
- но 85-95 перцентиль уезжают далеко вправо.
Трактовать это просто:
большая часть задач проходит быстро, но меньшая часть застревает надолго.
Именно они и ломают сроки и ожидания.
Практический тест для PM-а:
Перед тем как сказать «мы идем быстро», посмотри:
- насколько стабилен 85 перцентиль,
- растет ли хвост от месяца к месяцу,
- можешь ли ты сказать бизнесу:
«с вероятностью 85% задача будет готова за X дней»
Если не можешь - процесс ты не контролируешь, даже если «Done» растет.
Быстро ≠ предсказуемо, а управляем мы именно предсказуемостью.
🔥5❤3💯2👏1
Закон Литтла: что это такое и почему PM-ы часто используют его неправильно
В какой-то момент почти каждый PM открывает для себя закон Литтла и пытается понять, почему он не дает внятных сроков.
Формула выглядит просто:
Она связывает три вещи:
- сколько работы одновременно в системе,
- как быстро задачи завершаются,
- сколько времени задача в системе живет.
Из-за этой простоты формулу часто воспринимают как калькулятор сроков, подставили цифры - получили прогноз.
И здесь кроется ошибка:
А теперь к реальности
В большинстве команд:
- поток задач неровный,
- WIP скачет из-за срочных задач,
- throughput меняется от недели к неделе,
- часть задач застревает надолго.
В такой системе формула остается математически верной, но управленчески бесполезной.
PM считает по ней сегодня - выходит одно, а через неделю уже другое.
Ну и сразу делает вывод, что «закон не работает».
На самом деле он работает слишком честно. Он просто показывает, что процесс еще неустойчив.
Практический смысл закона Литтла для PM-а не в расчетах, а в диагностике.
Если при одинаковых условиях ты не можешь получить похожий результат, значит сначала нужно:
- стабилизировать WIP,
- выровнять вход задач,
- разобраться с хвостом Lead Time.
И только после этого формула начинает помогать с прогнозами.
Закон Литтла - не инструмент планирования, а проверка, готов ли процесс вообще к планированию.
В какой-то момент почти каждый PM открывает для себя закон Литтла и пытается понять, почему он не дает внятных сроков.
Формула выглядит просто:
WIP = Throughput × Lead Time
Она связывает три вещи:
- сколько работы одновременно в системе,
- как быстро задачи завершаются,
- сколько времени задача в системе живет.
Из-за этой простоты формулу часто воспринимают как калькулятор сроков, подставили цифры - получили прогноз.
И здесь кроется ошибка:
Закон Литтла ничего не предсказывает, он просто описывает связь в системе, которая ведет себя стабильно.
А теперь к реальности
В большинстве команд:
- поток задач неровный,
- WIP скачет из-за срочных задач,
- throughput меняется от недели к неделе,
- часть задач застревает надолго.
В такой системе формула остается математически верной, но управленчески бесполезной.
PM считает по ней сегодня - выходит одно, а через неделю уже другое.
Ну и сразу делает вывод, что «закон не работает».
На самом деле он работает слишком честно. Он просто показывает, что процесс еще неустойчив.
Практический смысл закона Литтла для PM-а не в расчетах, а в диагностике.
Если при одинаковых условиях ты не можешь получить похожий результат, значит сначала нужно:
- стабилизировать WIP,
- выровнять вход задач,
- разобраться с хвостом Lead Time.
И только после этого формула начинает помогать с прогнозами.
Закон Литтла - не инструмент планирования, а проверка, готов ли процесс вообще к планированию.
🔥5❤2👍2
Во многих проектах деградация сроков начинается не в delivery, а в upstream - в зоне формирования спроса и принятия решений.
Запрос существует, обсуждается, учитывается в планировании, но до явного commitment point не доходит. В результате растет decision latency: решения откладываются, приоритеты размываются, а система начинает неявно резервировать capacity под работу, которая формально еще не принята.
Эта форма upstream delay редко выглядит как проблема: работа продолжает двигаться, метрики исполнения остаются в пределах нормы, но предсказуемость постепенно снижается. Когда решение наконец принимается, работа заходит в delivery уже с накопленным давлением и ожиданиями, что и создает эффект «внезапного» сдвига сроков.
С точки зрения управления это не сбой исполнения, а запоздалое управленческое обязательство.
Проекты теряют контроль не из-за скорости выполнения, а из-за того, что ключевые решения в upstream принимаются позже, чем система способна безболезненно их absorb-ить.
Запрос существует, обсуждается, учитывается в планировании, но до явного commitment point не доходит. В результате растет decision latency: решения откладываются, приоритеты размываются, а система начинает неявно резервировать capacity под работу, которая формально еще не принята.
Эта форма upstream delay редко выглядит как проблема: работа продолжает двигаться, метрики исполнения остаются в пределах нормы, но предсказуемость постепенно снижается. Когда решение наконец принимается, работа заходит в delivery уже с накопленным давлением и ожиданиями, что и создает эффект «внезапного» сдвига сроков.
С точки зрения управления это не сбой исполнения, а запоздалое управленческое обязательство.
Проекты теряют контроль не из-за скорости выполнения, а из-за того, что ключевые решения в upstream принимаются позже, чем система способна безболезненно их absorb-ить.
❤3🔥3👍2
Aging WIP: метрика, которая может показать срыв срока заранее
Когда в проекте начинаются проблемы со сроками, то чаще всего смотрят на скорость или кол-во задач в работе.
Оба показателя полезны, но они плохо отвечают на главный вопрос: где именно поток начинает ломаться.
Aging WIP смотрит сразу на возраст задач, которые уже находятся в работе. Не на их количество и не на статус, а на то, сколько времени каждая из них проводит в потоке.
Если посмотреть на control chart, почти всегда видно одну и ту же картину: основная масса задач проходит за разумное время, а несколько «долго живущих» формируют длинный хвост. Именно они и создают риск срыва сроков, хотя внешне проект может выглядеть стабильным.
Практический ориентир здесь довольно прямолинейный. Если возраст задачи приближается или превышает 85-й перцентиль вашего lead time, вероятность того, что она выйдет вовремя, резко падает, даже если по ней нет явных блокеров и эскалаций.
В этом и есть ценность Aging WIP: он позволяет увидеть риск до того, как он проявится в сроках и ожиданиях бизнеса. Внимание смещается с абстрактного «мы двигаемся» на конкретный вопрос:
По сути, это метрика не про производительность команды, а про состояние потока. И если ее не смотреть, о проблемах почти всегда узнают постфактум.
Когда в проекте начинаются проблемы со сроками, то чаще всего смотрят на скорость или кол-во задач в работе.
Оба показателя полезны, но они плохо отвечают на главный вопрос: где именно поток начинает ломаться.
Aging WIP смотрит сразу на возраст задач, которые уже находятся в работе. Не на их количество и не на статус, а на то, сколько времени каждая из них проводит в потоке.
Если посмотреть на control chart, почти всегда видно одну и ту же картину: основная масса задач проходит за разумное время, а несколько «долго живущих» формируют длинный хвост. Именно они и создают риск срыва сроков, хотя внешне проект может выглядеть стабильным.
Практический ориентир здесь довольно прямолинейный. Если возраст задачи приближается или превышает 85-й перцентиль вашего lead time, вероятность того, что она выйдет вовремя, резко падает, даже если по ней нет явных блокеров и эскалаций.
В этом и есть ценность Aging WIP: он позволяет увидеть риск до того, как он проявится в сроках и ожиданиях бизнеса. Внимание смещается с абстрактного «мы двигаемся» на конкретный вопрос:
почему именно эта работа живет дольше нормы и что в системе этому способствует.
По сути, это метрика не про производительность команды, а про состояние потока. И если ее не смотреть, о проблемах почти всегда узнают постфактум.
❤3🔥3💯2
Почему прогноз по срокам нельзя строить по среднему
Когда в проекте отвечают на вопрос «когда будет готово», чаще всего называют средний срок. Но lead time почти всегда распределен с длинным хвостом: несколько задач живут намного дольше остальных и именно они как раз и создают риск.
Среднее значение этот риск скрывает.
Оно хорошо описывает прошлое, но плохо помогает прогнозировать будущее. Две команды с одинаковым средним lead time могут иметь совершенно разную надежность.
Перцентили решают эту проблему:
Если 85-й перцентиль равен 14 дням, это означает, что в 85% случаев задачи завершались не дольше этого срока. Вот и честная база для разговора с бизнесом.
Проверьте себя:
сравните средний lead time и P85. Если между ними большая разница, система нестабильна, и любые обещания «по среднему» - это ставка на удачу.
Когда в проекте отвечают на вопрос «когда будет готово», чаще всего называют средний срок. Но lead time почти всегда распределен с длинным хвостом: несколько задач живут намного дольше остальных и именно они как раз и создают риск.
Среднее значение этот риск скрывает.
Оно хорошо описывает прошлое, но плохо помогает прогнозировать будущее. Две команды с одинаковым средним lead time могут иметь совершенно разную надежность.
Перцентили решают эту проблему:
P85 или P90 отвечают не на вопрос «за сколько в среднем», а на вопрос «с какой вероятностью мы уложимся».
Если 85-й перцентиль равен 14 дням, это означает, что в 85% случаев задачи завершались не дольше этого срока. Вот и честная база для разговора с бизнесом.
Проверьте себя:
сравните средний lead time и P85. Если между ними большая разница, система нестабильна, и любые обещания «по среднему» - это ставка на удачу.
❤3👍3💯1👨💻1
Когда выбирать P85, а когда P90 и почему медиана часто подводит
Когда начинают говорить про сроки, первой всплывает медиана (срок, за который закрывается половина задач). Она кажется логичной: показывает «обычный» сценарий и хорошо смотрится в отчетах.
Но медиана почти не помогает, когда речь идет о риске. Она описывает центр распределения, но полностью игнорирует хвост. А вот именно хвост и ломает ожидания: те самые задачи, которые внезапно живут в разы дольше нормы.
P85 уместен там, где речь идет о внутренних обязательствах: когда задержка неприятна, но допустима, и важен баланс между скоростью и надежностью. Это рабочий уровень уверенности для большинства управленческих решений внутри команды или продукта.
P90 нужен в других условиях: когда есть внешние обещания, контракты или высокая цена ошибки. В этом случае лучше заранее учитывать редкие болезненные задержки, чем потом объяснять, почему «в среднем все было нормально».
Практический вывод простой:
Если вы обсуждаете сроки с бизнесом, медиана почти всегда будет слишком оптимистичной. Выбор между P85 и P90 - это вопрос не методологии, а какую неопределенность вы готовы принять.
Когда начинают говорить про сроки, первой всплывает медиана (срок, за который закрывается половина задач). Она кажется логичной: показывает «обычный» сценарий и хорошо смотрится в отчетах.
Но медиана почти не помогает, когда речь идет о риске. Она описывает центр распределения, но полностью игнорирует хвост. А вот именно хвост и ломает ожидания: те самые задачи, которые внезапно живут в разы дольше нормы.
Перцентили смотрят на ситуацию честнее.
P85 уместен там, где речь идет о внутренних обязательствах: когда задержка неприятна, но допустима, и важен баланс между скоростью и надежностью. Это рабочий уровень уверенности для большинства управленческих решений внутри команды или продукта.
P90 нужен в других условиях: когда есть внешние обещания, контракты или высокая цена ошибки. В этом случае лучше заранее учитывать редкие болезненные задержки, чем потом объяснять, почему «в среднем все было нормально».
Практический вывод простой:
Если вы обсуждаете сроки с бизнесом, медиана почти всегда будет слишком оптимистичной. Выбор между P85 и P90 - это вопрос не методологии, а какую неопределенность вы готовы принять.
👍4❤2🔥2
Почему оценки ломаются, даже когда данные корректны
В проектах иногда возникает чувство, что оценки считали аккуратно, исторические данные есть, метод выбран верный, а сроки все равно начинают расходиться с реальностью.
Обычно проблема не в самих оценках, а в изменении системы, внутри которой эти оценки применяются. По ходу проекта по-другому начинают приниматься решения, появляется больше параллельной работы, усложняются зависимости и согласования. Работа выглядит похожей, но поток уже ведет себя иначе.
Есть и еще одна вещь, которую оценки почти всегда недооценивают - основную вариативность дает не сама работа, а время ожидания между ее этапами: паузы, блокировки, внешние решения. Именно там и накапливается риск, который потом неожиданно проявляется в сроках.
Практический вывод здесь довольно приземлённый: если оценки перестали сходиться, имеет смысл сначала проверить не метод, а контекст. Насколько текущая система похожа на ту, по данным которой строился прогноз.
Когда это сходство теряется, даже корректные оценки перестают быть надежным ориентиром.
В проектах иногда возникает чувство, что оценки считали аккуратно, исторические данные есть, метод выбран верный, а сроки все равно начинают расходиться с реальностью.
Обычно проблема не в самих оценках, а в изменении системы, внутри которой эти оценки применяются. По ходу проекта по-другому начинают приниматься решения, появляется больше параллельной работы, усложняются зависимости и согласования. Работа выглядит похожей, но поток уже ведет себя иначе.
Есть и еще одна вещь, которую оценки почти всегда недооценивают - основную вариативность дает не сама работа, а время ожидания между ее этапами: паузы, блокировки, внешние решения. Именно там и накапливается риск, который потом неожиданно проявляется в сроках.
Практический вывод здесь довольно приземлённый: если оценки перестали сходиться, имеет смысл сначала проверить не метод, а контекст. Насколько текущая система похожа на ту, по данным которой строился прогноз.
Когда это сходство теряется, даже корректные оценки перестают быть надежным ориентиром.
👍3❤2
Почему попытки «выровнять загрузку» команды почти всегда увеличивают сроки
Если сроки начинают плыть, в проектах часто предлагают «сбалансировать загрузку»: убрать простои, равномерно распределить задачи, держать команду постоянно занятой чем-то.
Проблема в том, что при высокой загрузке система становится крайне чувствительной к любым отклонениям. Любая задержка, уточнение или зависимость сразу превращаются в ожидание, потому что свободного буфера просто нет. Работа хоть и продолжается, но время прохождения задач растет.
Этот эффект давно описан в теории очередей: при загрузке, близкой к 100%, время ожидания растет нелинейно, даже если средняя скорость работы не меняется. В проектах это выглядит так: команда делает не меньше, а сроки становятся все менее предсказуемыми.
Практический ориентир для PM-а простой:
Если throughput остается примерно тем же, а lead time растет, проблема не в людях и не в скорости, а в перегруженной системе. В этот момент верное решение - не «ускоряться» и не «ровнее распределять задачи», а сознательно оставить запас по загрузке. Это единственный способ, которым система может переваривать вариативность и не ломать сроки.
Если сроки начинают плыть, в проектах часто предлагают «сбалансировать загрузку»: убрать простои, равномерно распределить задачи, держать команду постоянно занятой чем-то.
Проблема в том, что при высокой загрузке система становится крайне чувствительной к любым отклонениям. Любая задержка, уточнение или зависимость сразу превращаются в ожидание, потому что свободного буфера просто нет. Работа хоть и продолжается, но время прохождения задач растет.
Этот эффект давно описан в теории очередей: при загрузке, близкой к 100%, время ожидания растет нелинейно, даже если средняя скорость работы не меняется. В проектах это выглядит так: команда делает не меньше, а сроки становятся все менее предсказуемыми.
Практический ориентир для PM-а простой:
Если throughput остается примерно тем же, а lead time растет, проблема не в людях и не в скорости, а в перегруженной системе. В этот момент верное решение - не «ускоряться» и не «ровнее распределять задачи», а сознательно оставить запас по загрузке. Это единственный способ, которым система может переваривать вариативность и не ломать сроки.
👍4❤3🔥2💯1
Почему влеты (expedite) незаметно ломают команду и как с ними работать
Срочные задачи часто любят оправдывать: «это важно», «тут горит», «это исключение». Команда поднажала, задачу сделали, проект вроде бы спасли.
А проблема в том, что система запоминает не аргументы, а последствия.
Каждый expedite прерывает поток. Работа начинает откладывается, контекст рвется, внимание команды перескакивает. Даже если срочных задач немного, они создают вариативность, которую потом долго приходится разгребать.
Lead time растет не в момент влета, а позже, когда система пытается вернуться в нормальный режим.
Есть легкий признак того, что expedite стали проблемой:
Как с этим работать на уровне PM-а
Во-первых, срочность должна быть ограниченным классом работы, а не режимом по умолчанию. Если expedite можно добавить в любой момент и без последствий, система неизбежно начнет на них опираться.
Во-вторых, каждый expedite должен иметь цену. Даже не в деньгах, а в явном trade-off: что именно откладывается или замедляется. Пока этой цены нет, срочность остается бесплатной и потому бесконтрольной.
Третье, полезно смотреть не на количество влетов, а на их эффект. Допустим, если после срочных задач растет aging обычной работы или увеличивается разброс lead time, значит expedite уже не исключение, а источник системного риска.
Срочные задачи почти всегда неизбежны, но управляемыми они становятся только тогда, когда их влияние видно не по ощущениям, а по данным.
Срочные задачи часто любят оправдывать: «это важно», «тут горит», «это исключение». Команда поднажала, задачу сделали, проект вроде бы спасли.
А проблема в том, что система запоминает не аргументы, а последствия.
Каждый expedite прерывает поток. Работа начинает откладывается, контекст рвется, внимание команды перескакивает. Даже если срочных задач немного, они создают вариативность, которую потом долго приходится разгребать.
Lead time растет не в момент влета, а позже, когда система пытается вернуться в нормальный режим.
Есть легкий признак того, что expedite стали проблемой:
срочные задачи «спасают» сроки по отдельным кейсам, но общий разброс сроков увеличивается. Команда работает больше, а предсказуемость падает.
Как с этим работать на уровне PM-а
Во-первых, срочность должна быть ограниченным классом работы, а не режимом по умолчанию. Если expedite можно добавить в любой момент и без последствий, система неизбежно начнет на них опираться.
Во-вторых, каждый expedite должен иметь цену. Даже не в деньгах, а в явном trade-off: что именно откладывается или замедляется. Пока этой цены нет, срочность остается бесплатной и потому бесконтрольной.
Третье, полезно смотреть не на количество влетов, а на их эффект. Допустим, если после срочных задач растет aging обычной работы или увеличивается разброс lead time, значит expedite уже не исключение, а источник системного риска.
Срочные задачи почти всегда неизбежны, но управляемыми они становятся только тогда, когда их влияние видно не по ощущениям, а по данным.
👍3🔥3🤔2❤1
Forecast ≠ Commitment: почему сроки нельзя замораживать
Когда PM называет срок, он обычно говорит о прогнозе. И этот прогноз строится на текущей картине: загрузке команды, приоритетах и правилах работы системы в данный момент. В момент планирования расчет, как правило, корректен и понятен.
Проблемы возникают немного позже, когда проходит время и контекст меняется. В проекте становится больше срочных задач, согласований и параллельной работы. Команда формально та же, но система, в которой она работает, уже другая.
При этом сроки продолжают восприниматься как обязательство, хотя изначально они были прогнозом. Здесь и появляется разрыв.
Если система изменилась, а сроки остались прежними, управление подменяется ожиданием, что реальность подстроится под старые цифры. Поэтому задача PM - не только зафиксировать план, но и возвращаться к его основаниям, прямо проговаривая, при каких условиях сроки остаются валидными.
Сроки редко срываются внезапно, чаще они просто не пересматриваются, когда система, для которой они считались, уже живет по другим правилам.
Когда PM называет срок, он обычно говорит о прогнозе. И этот прогноз строится на текущей картине: загрузке команды, приоритетах и правилах работы системы в данный момент. В момент планирования расчет, как правило, корректен и понятен.
Проблемы возникают немного позже, когда проходит время и контекст меняется. В проекте становится больше срочных задач, согласований и параллельной работы. Команда формально та же, но система, в которой она работает, уже другая.
При этом сроки продолжают восприниматься как обязательство, хотя изначально они были прогнозом. Здесь и появляется разрыв.
Forecast описывает ожидаемый результат при определённых условиях, а commitment предполагает, что эти условия будут удержаны или изменены осознанно.
Если система изменилась, а сроки остались прежними, управление подменяется ожиданием, что реальность подстроится под старые цифры. Поэтому задача PM - не только зафиксировать план, но и возвращаться к его основаниям, прямо проговаривая, при каких условиях сроки остаются валидными.
Сроки редко срываются внезапно, чаще они просто не пересматриваются, когда система, для которой они считались, уже живет по другим правилам.
👍3🔥2