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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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