что такое lead time в логистике

lead time

Полезное

Смотреть что такое «lead time» в других словарях:

lead time — ➔ time * * * lead time UK US noun [C] COMMERCE ► the time it takes after receiving an order to deliver the goods or services to a customer: »The result of this new approach is a shorter lead time and lower costs … Financial and business terms

lead time — lead times 1) N COUNT Lead time is the time between the original design or idea for a particular product and its actual production. [BUSINESS] They aim to cut production lead times to under 18 months. 2) N COUNT Lead time is the period of time… … English dictionary

lead-time — (lēdʹtīm ) n. The time between the initial stage of a project or policy and the appearance of results: a long lead time in oil production because of the need for new exploration and drilling. * * * … Universalium

lead time — [ˈli:d taım] n [U] the time that it takes to make or produce something … Dictionary of contemporary English

lead time — lead′ time [[t]lid[/t]] n. the period of time between the initial phase of a process and the emergence of results, as between the planning and completed manufacture of a product • Etymology: 1940–45, amer … From formal English to slang

lead time — Time between the initiation of a new project and its delivery date. ► “Given such uncertainties as the Middle East and the long lead time needed to develop major oil fields, rising prices seem inevitable.” (Fortune, Oct. 30, 1995, p. 88) … American business jargon

lead time — [lēd] n. Manufacturing the period of time between the decision to make a product and the beginning of actual production … English World dictionary

Lead time — A lead time is the period of time between the initiation of any process of production and the completion of that process. Thus the lead time for ordering a new car from a manufacturer may be anywhere from 2 weeks to 6 months. In industry, lead… … Wikipedia

lead time — noun the time interval between the initiation and the completion of a production process the lead times for many publications can vary tremendously planning is an area where lead time can be reduced • Hypernyms: ↑time interval, ↑interval * * *… … Useful english dictionary

lead time — UK [ˈliːd ˌtaɪm] / US [ˈlɪd ˌtaɪm] noun [countable/uncountable] Word forms lead time : singular lead time plural lead times the time between planning something and starting to do it Local firms learned how to reduce lead time by 75–95% while… … English dictionary

Источник

lead time

Тематики

время выполнения заказа
Время с момента размещения заказа до его выполнения. Когда планирование и производство работают на уровне или ниже своих производственных возможностей, время выполнения заказа равно времени выпуска (throughput time). Когда же спрос превышает возможности системы, дополнительное время требуется для того, чтобы спланировать работу и сделать заказ. Поэтому время выполнения заказа превышает время выпуска. См. время выпуска.
[http://www.up-pro.ru/library/production_management/lean/glossary_termin.html]

Тематики

время опережения
время упреждения
—
[Я.Н.Лугинский, М.С.Фези-Жилинская, Ю.С.Кабиров. Англо-русский словарь по электротехнике и электроэнергетике, Москва, 1999 г.]

Тематики

Синонимы

время производственного цикла
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]

Тематики

время протекания процесса
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]

Тематики

длительность цикла
1. Диапазон времени, необходимого для исполнения процесса (или серии операций);
2. В контексте логистики, время между выявлением потребности в размещении заказа и получением товаров. Отдельные компоненты длительности цикла могут быть следующими:
время подготовки заказа (order preparation time),
время в очереди, время обработки (processing time),
время перемещения или транспортировки,
время получения (receiving time) и
время контроля (inspection time).
[http://www.abc.org.ru/gloss.html]

Тематики

период начального развертывания
Время от момента вывода спутника на орбиту до начала его опытной эксплуатации.
[Л.М. Невдяев. Телекоммуникационные технологии. Англо-русский толковый словарь-справочник. Под редакцией Ю.М. Горностаева. Москва, 2002]

Тематики

Полезное

Смотреть что такое «lead time» в других словарях:

lead time — ➔ time * * * lead time UK US noun [C] COMMERCE ► the time it takes after receiving an order to deliver the goods or services to a customer: »The result of this new approach is a shorter lead time and lower costs … Financial and business terms

lead time — lead times 1) N COUNT Lead time is the time between the original design or idea for a particular product and its actual production. [BUSINESS] They aim to cut production lead times to under 18 months. 2) N COUNT Lead time is the period of time… … English dictionary

lead-time — (lēdʹtīm ) n. The time between the initial stage of a project or policy and the appearance of results: a long lead time in oil production because of the need for new exploration and drilling. * * * … Universalium

lead time — [ˈli:d taım] n [U] the time that it takes to make or produce something … Dictionary of contemporary English

lead time — lead′ time [[t]lid[/t]] n. the period of time between the initial phase of a process and the emergence of results, as between the planning and completed manufacture of a product • Etymology: 1940–45, amer … From formal English to slang

lead time — Time between the initiation of a new project and its delivery date. ► “Given such uncertainties as the Middle East and the long lead time needed to develop major oil fields, rising prices seem inevitable.” (Fortune, Oct. 30, 1995, p. 88) … American business jargon

lead time — [lēd] n. Manufacturing the period of time between the decision to make a product and the beginning of actual production … English World dictionary

Lead time — A lead time is the period of time between the initiation of any process of production and the completion of that process. Thus the lead time for ordering a new car from a manufacturer may be anywhere from 2 weeks to 6 months. In industry, lead… … Wikipedia

lead time — noun the time interval between the initiation and the completion of a production process the lead times for many publications can vary tremendously planning is an area where lead time can be reduced • Hypernyms: ↑time interval, ↑interval * * *… … Useful english dictionary

lead time — UK [ˈliːd ˌtaɪm] / US [ˈlɪd ˌtaɪm] noun [countable/uncountable] Word forms lead time : singular lead time plural lead times the time between planning something and starting to do it Local firms learned how to reduce lead time by 75–95% while… … English dictionary

Источник

Контроль Lead Time

Грузопоток из КНР в РФ высок и продолжает активно расти. Количество ввозимых товаров увеличивается. На успешность экономического сотрудничества российских предпринимателей с китайскими производителями влияет целый ряд факторов.

Что такое профессиональная услуга управление Lead Time

Логист нашей компании, а не сам заказчик или его подрядчик, будет планировать производство и доставку. Делегирование задачи планирования и контроля сроков производства специалистам «АВМ Логистика» снимает с вас не только саму нагрузку.

За счет обращения по всем вопросам в комплексе к одному профессиональному исполнителю, отлично разбирающемуся во всех вопросах доставки товаров на направлении КНР-РФ, вы значительно снизите расходы, повысите эффективность бизнес-процессов.

Услуга управление Lead time позволяет точно определить время от момента формирования заказа на изготовление партии товара на выбранном вами заводе или фабрике до получения готового продукта.

Какие сроки предлагают производители и что получается в реальности

Производители КНР далеко не одинаковы. Есть ответственные, а есть такие, которые работают на массового заказчика по типовым установкам, с учетом собственных представлений о сотрудничестве.

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

Услуга управления Lead time, по сути, важна всем, кто налаживает сотрудничество с китайскими заводами и фабриками. Особенно важно заказать ее при:

Почему возникает НС? Именно из-за ошибочного планирования производства и сроков доставки, а также при отсутствии опыта, знаний специфики работы с китайскими производителями. В результате для поддержания бизнеса хотя бы на самоокупаемом уровне приходится пользоваться авто- или авиадоставкой, что обходится дороже.

Специалисты «АВМ Логистика» имеют опыт управления lead time (одновременно более чем 120 заводов). Предоставьте нам статистику продаж (как быстро товар уходит с полок, например по неделям), и мы рассчитаем какие позиции (SKU) и когда необходимо поставить на ваш склад, утвердим эти сроки с вашими заводами и проконтролируем производство, отгрузку и доставку.

Компания «АВМ Логистика» с головным офисом в Москве работает с 2017 года.

Наша команда – это частично распределенная сеть сотрудников, которые находятся, в том числе, в Китае.

Занимаемся в основном железнодорожными перевозками из Китая от одного контейнера и таможенной очисткой импортных грузов.

Для воздействия на китайских производителей у нас есть разные методы:

В целом, здесь нет ничего секретного, но везде есть свои нюансы. Например, разговаривать с разными сотрудниками производителя надо, конечно, не вместе, а по отдельности, чтобы сопоставить сказанное и найти разночтения («странности»), о которых позже надо переспросить других сотрудников.

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

Существует целый ряд факторов, которые сразу сообщат специалисту о том, что поставщик где-то вас обманывает или может обмануть, например, что сроки могут быть сорваны или качество не будет соответствовать заявленному. Некоторые из них:

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

Не хотите, чтобы ваш заказ изначально был обречен на провальный срыв сроков, обращайтесь в «АВМ Логистика» по поводу услуги управления Lead time. Чтобы клиенты не беспокоились, объясним:

Планирования производства в КНР и доставки в РФ: цены и особенности выполнения заказов с применением услуги Lead Time

AVM Logistics сотрудничает с юридическими лицами РФ. Мы предлагаем схему «одно окно». По каждому заказу назначается персональный, опытный менеджер. Скоро также появится вариант заказа через личный кабинет (ЛК) на нашем сайте.

Источник

Метрики в Scrum и Kanban

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.

Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник») и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.

Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:

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

Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.

Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.

А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?

Источник

Синхронизация продуктовых команд в Sportmaster Lab (часть 2)

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

Метрики

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

Наша самая главная метрика — Lead Time: это характерное время, за которое задача доходит от одной из четырех контрольных точек (появление идеи, ТПР, Х и ТПО) до установки на продуктив.

.

Как видим, они образуют иерархию вложенности. Мы используем величины Lead Time, выраженные в рабочих, а не календарных днях. Если над одним продуктом работает больше одной команды, то TTM, Customer Lead Time и Х Lead Time относятся к продукту в целом, а Lead Time для потока у каждой команды может быть свой.

Устоявшейся терминологии для разных Lead Time пока нет, поэтому аналогичные по смыслу показатели у других авторов можно встретить под другими названиями, например, для потокового Lead Time (тот, который самый короткий) часто используется термин Cycle Time. Здесь буду придерживаться нашего варианта «жаргона», извините, если что.

Также часто используются метрики потока — количество задач, входящих и выходящих из области за период времени, и количество задач, находящихся в области на определенный момент. Эти показатели можно видеть на CFD-диаграмме или на диаграмме потока задач (которая, на наш взгляд, легче читается). Например, для области «Поток» диаграмма потока задач с шагом в неделю выглядит так:

Потоковая диаграмма

Прогнозирование с использованием показателей Lead Time разных уровней

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

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

Визуализация эпиков и задач продуктовой команды на карте жизненного цикла

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

В эпик входят четыре задачи, одна из которых уже завершена, две в работе и одна еще не взята в поток и находится в области «Готово к взятию», на вершине бэклога. Исходя из ситуации, дата завершения эпика будет определяться, скорее всего, выполнением задачи, которая еще не взята в поток. Эпики переводятся в область «Поток» после того, как хотя бы одна из вложенных задач попала в поток, и считаются завершенными, когда все вложенные задачи завершены.

Чтобы понять, сколько времени обычно нужно, чтобы провести задачу через поток, рассмотрим спектральную диаграмму Lead Time для потока этой команды за последние три месяца:

Спектральная диаграмма LeadTime

Спектральная диаграммы для отдельных типов задач

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

Теперь посмотрим, как можно мониторить движение эпика на всем жизненном цикле, от идеи до реализации при помощи статистики Lead Time разных уровней:

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

Рассмотрим одну из таких задач. Плановую дату ее исполнения обозначим как день «Д». Построим «LeadTime-профиль» продукта/команды, которая будет ее выполнять, в виде таблицы:

Пример «LeadTime-профиля»

Дни – рабочие, неделя соответствует 5 рабочим дням. 85% вероятность выполнения РП считает приемлемой.

Далее имеет смысл отслеживать задачи, входящие в эпик, по отдельности. Предположим, что их три, в области «Готово к взятию» они расположены на втором, пятом и шестом месте по приоритетам (см. рисунок ниже). Мы уже знаем, что если задача находится на самом верху области «Готово к взятию», то с вероятностью 85% она будет выполнена не позже, чем через 6 дней. Остается понять, сколько нужно времени, чтобы все три задачи эпика попали в поток. Посмотрев на потоковую диаграмму, мы увидим, что команда берет в поток в среднем 15 задач в неделю, то есть примерно по три задачи в рабочий день. Шесть задач будут взяты в работу, скорее всего, не позднее, чем за два дня. Поскольку день «Д» близко, РП стоит проследить, чтобы в бэклог поверх «его» задач не были помещены дополнительные задачи. Не стоит забывать, что команда принимает обязательства выполнить задачу только в момент ее взятия в поток, а до этого возможны изменения приоритетов.

Когда задачи 2, 5 и 6 попадут в поток?

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

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

Важно: при движении эпика по жизненному циклу все виды Lead Time нужно измерять для той части эпика, которая дошла до продуктива.

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

Нужно ли автоматизировать прогнозирование сроков исполнения задач?

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

Мы с командой портала метрик (особенная благодарность Диме Новикову!) попробовали сделать такой автоматический прогноз для задач в области «Готово к взятию». Идея была в следующем: для каждой задачи, которая сейчас находится в бэклоге, рассмотрим количество и типы задач, расположенных в бэклоге выше нее. В исторических данных по работе этой команды ищем похожие ситуации — когда выше некоторой задачи в бэклоге находился примерно такой же набор задач по количеству и типам. Смотрим, сколько времени у команды занимало выполнение такого набора задач в прошлом, получаем вероятностное распределение, из которого можно с разной степенью вероятности сделать прогноз дат, когда интересующая нас задача попадет на продуктив,

Полученные нами оценки сроков оказались весьма расплывчаты и малополезны. Сначала мы, естественно, пытались найти и исправить недостатки в прогнозной модели или подборе параметров, но существенного улучшения не происходило. Одной из основных причин этого было то, что задачи в бэклоге не двигались упорядоченно, как патроны в обойме, снизу вверх, а меняли приоритеты и перемещались вверх и вниз. В бэклог поступали новые задачи, которые брались в работу быстрее, чем те, что лежали в бкэлоге до них. В результате некоторые задачи «пролетали» существенно быстрее, а другие «зависали», и их положение в бэклоге на момент прогноза влияло на их судьбу гораздо меньше, чем мы ожидали. То есть наше базовое предположение, что задачи в бэклоге движутся в основном снизу вверх, не оправдалось.

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

«Самосбывающийся прогноз»

Автоматизированное прогнозирование обычно применяют для тех событий, на которые потребитель прогноза повлиять не может – погода, покупательский спрос, движение автобуса в пробках, etc… А на движение продуктовых задач потребители прогноза (команда и заказчики) имеют большое влияние. Если прогноз не устраивает заказчика и/или команду, то есть как минимум три инструмента для исправления ситуации:

Договориться об изменении приоритета задачи.

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

Реализовать сначала менее трудоемкое, временное решение с образованием.

Достижение необходимого срока возможно без штурмовщины, если:

Задача действительно нужна, кто-то ждет ее выполнения и прилагает периодические усилия для поддержания ее приоритета.

Продуктовая команда работает в штатном режиме: осуществляет регулярное управление техническим долгом; большая часть задач команды не имеет жестких дедлайнов и их можно «подвинуть» в случае необходимости; команда не работает со 100% напряжением, у нее есть резерв для маневра.

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

Изменение зон ответственности при работе со сроками

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

В «проектной» парадигме базовый алгоритм работы со сроками следующий.

В «продуктовой» парадигме:

Заказчик проявляет регулярное внимание к задаче, актуализирует ее приоритет и оценку ценности в сравнении с конкурирующими задачами. Команда (исполнитель), как правило, не берет на себя ответственность за выполнение задач к определенному сроку. Вместо приложения усилий для достижения сроков по отдельным задачам команда концентрируется та том, чтобы все свои задачи выполнять одинаково быстро и предсказуемо.

Таким образом в продуктовой парадигме ответственность за достижение сроков в большей степени ложится на сторону заказчика. Рабочая гипотеза состоит в том, что в обмен повышается общая эффективность приложения усилий заказчиком: выше вероятность получить то, что нужно, к нужному сроку, меньше неактуальных задач, сделанных потому, что их забыли отменить. Проверкой этой гипотезы мы сейчас и занимаемся в SM Lab :).

Что может сделать команда для повышения своей прогнозируемости.

Для того чтобы работа команды была прогнозируемой, нужно чтобы у показателей Lead Time разброс (дисперсия распределения) был поменьше. Даже при небольшом разбросе не нужно забывать, что это вероятностный, а не детерминистический прогноз, отклонения всегда возможны, и ни одна команда не может быть на 100% предсказуемой. Но если распределение имеет большую дисперсию, то этот показатель полностью теряет предсказательную силу.

Для внешних интересантов интереснее всего предсказуемость задач как раз в левой части жизненного цикла, в областях «идеи» и «решили делать». От этих прогнозов зависят решения, которые принимаются при формировании дорожных карт и бизнес-планов. Будет ли готова новая функциональность к началу новой коллекции, или надо сразу отложить ее внедрение на полгода, до следующей коллекции? На какой период планировать дополнительные ресурсы, связанные с этим? И множество других важных вопросов. В идеале, заказчик хочет знать, «когда будет готово», сразу же, как только он высказал новую идею — в наших терминах это значит, что дисперсия распределения Time to Market должна быть как можно меньше. К сожалению, обеспечить такую предсказуемость в области идей для команды очень сложно, так как эта область в наименьшей степени подвержена ее влиянию. Если каждую идею прорабатывать сразу до такой степени, чтобы по ней можно было дать обоснованный срок реализации, у команды не останется времени на полезную работу – все уйдет на детальную проработку идей, которые никогда не будут реализованы.

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

Такой подход позволяет постоянно и предсказуемо работать с новыми идеями, не превращая область в свалку идей.

Предсказуемое поведение Customer Lead Time дает заказчикам хорошую точку опоры, «границу стакана», которую не стоит переходить, и позволяет заботиться о судьбе своих идей и обеспечивать их переход через ТПР раньше, чем они попадут в «красную зону».

Выводы

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

Для контроля сроков применяются методы визуализации и прогнозирования. Управление осуществляется через динамическое изменение скоупа и приоритетов.

Условием применимости такого подхода является «антихрупкость» системы в целом, которая обеспечивается регулярным и превентивным применением технических и организационных практик, обязательных для продуктовых команд.

Источник