🔬 Это пост с разбором очередной части книги Дона Рейнертсена The Principles of Product Development Flow. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу pdflow.

В предыдущей части про экономический фреймворк стало понятно, что время цикла — важная метрика с точки зрения экономики разработки продукта.

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

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

© Страдающее Средневековье

Зачем рассматривать очереди

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

Вот перечень проблем, которые вызывают очереди:

• Увеличение цикла разработки: чем длиннее очередь — тем дольше рабочий продукт будет ждать, пока за него возьмутся. Если мы знаем про очереди, мы можем придумать, как спрогнозировать и посчитать потери от ожидания.
• Рост рисков: этапы обработки рабочих продуктов разделены длительным временем ожидания, поэтому растут риски. Чем дольше мы ждем — тем выше вероятность, что могут произойти нежелательные изменения на рынке, у конкурентов или в используемых технологиях.
• Увеличение вариабельности: когда мы сильно нагружаем наши мощности по разработке, сильно растет вариабельность. Подробнее — в следующих постах.
• Увеличение накладных расходов: чем больше РП сидит в очередях — тем длиннее очереди, больше встреч и отчетов.
• Снижение качества: из-за очередей мы получаем фидбек о сделанной работе позже. Если программист начал писать код исходя из неверных предпосылок и получил фидбек на следующий день — можно быстро откатиться и исправить. Если фидбек придет только через неделю, то придется выкинуть результаты работы за неделю.
• Снижение мотивации: нет необходимости торопиться и пилить дизайны для приложения за день или два, если продакт сможет посмотреть их только через неделю.

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

Коротко я вопроса очередей касался в первом посте про книгу. Там была такая иллюстрация:

Для ускорения разработки нужно уменьшить время цикла, т. е. завершить работы над рабочим продуктом быстрее, чем за 19 дней. Как это сделать? Ответ: сокращать «красные» этапы ожидания, когда РП висит в очереди на обработку; сокращение «зеленых» этапов сложнее и даст меньший эффект.

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

Теория очередей

Теория появилась в начале 20 века как практический метод решить задачу Копенгагенской телефонной компании: требовалось понять, сколько телефонных линий требуется для обслуживания какого-то количества абонентов. Задача на тот момент была нетривиальной: звонки поступали в случайном порядке и спрогнозировать их было невозможно, как и длительность каждого конкретного разговора.

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

Основные понятия

Термины и проч. по теории очередей — https://staff.um.edu.mt/jskl1/simweb/intro.htm

Процесс прибытия (Arrival Process): паттерн, по которому в очередь попадают новые объекты. Он описывает, как объекты (например, телефонные звонки) поступают в систему. Может быть случайным или детерминированным.
Механизм обслуживания (Service Mechanism): описывает, как обслуживаются объекты. Это может зависеть от таких факторов, как количество серверов (операторов), способ определения приоритетности задач и время, необходимое для обслуживания задачи (длительность звонка).
Сервер (Server): ресурс, который осуществляет работу над объектами из очереди; в нашем случае — оператор, который коммутирует звонки
Дисциплина очереди (Queue Discipline): означает порядок, в котором обслуживаются объекты. Распространены такие дисциплины, как «первым пришел — первым ушел» (FIFO), «последним пришел — первым ушел» (LIFO) и обслуживание на основе приоритетов.
Емкость (Capacity): количество объектов (например, абонентов), которые система может обслуживать одновременно.
Длина очереди (Queue Length): количество объектов, ожидающих в очереди.

Два важнейших показателя для очередей — заполняемость и время цикла. Зная их, можно измерять:

• количество РП в очереди, количество РП в сервисе, общее количество в системе;
• время, проведенное РП в очереди, в сервисе, в системе в целом.

Лямбда — это процесс прибытия, Мю — механизм обслуживания

На иллюстрации — тип очереди M/M/1/∞ в нотации Кендалла, именно с него Рейнертсен предлагает начать. В нотации элементы означают, в порядке очереди: «М» — тип процесса прибытия, «М» — тип механизма обслуживания, «1» — количество серверов, «∞» — максимальный размер очереди. «М» — значит «Марковский процесс», и он в нашем примере относится и к прибытию, и к сервису. Это означает, что в прибытии время между поступлениями распределено экспоненциально (меньший интервал между поступлениями более вероятен, чем больший), при этом следующий интервал прибытия не зависит от любых предыдущих. Для сервиса/обслуживания то же самое: длительность сервиса разная для каждого РП, на временном ряду длительности распределяются экспоненицально, длительность каждого следующего сервиса не зависит от предыдущих.
Если по простому описать этот тип очереди, получится примерно следующее: люди приходят на оформление визы независимо друг от друга и со случайными интервалами, встают в очередь в единственное окно, обслуживание каждого человека занимает примерно 15 минут, но иногда может и 30, а может и 5.

На практике

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

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

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

Принципы начнем рассматривать в следующих постах.