Организация очередей

by Владимир Бычко

Это очередь. Здесь ожидают.

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

Люди готовы стоять в очереди, если соблюдается несколько условий:

  1. Конец очереди виден.
  2. Продвижение в очереди заметно.
  3. Никто не лезет без очереди.

В разработке добиться корректной работы очереди возможно.

Начнём с визуализации очереди. Простейшее решение — trello, но есть множество значительно более функциональных сервисов.

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

После визуализации необходимо сформулировать несколько правил и неукоснительно следить за их исполнением.

Все новые запросы на доработку добавляются в конец бэклога.

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

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

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

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

Исполнителю морально тяжело, когда на нём «висит» множество запросов. Кроме того, возникают потери на переключение между задачами («транспортные расходы»). Рационально ограничить количество задач в единовременном производстве одной-двумя и выдавать новые задания только после окончания работ по старым. Из этого правила вытекает следующее:

Ограничение на время приёмки запроса. Заказчик должен в ограниченный срок либо признать запрос исполненным, либо обозначить претензии. Держать запрос «висящим на сдаче» месяцами, недопустимо.

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

Возможна «платная» очередь.

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