Попса

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

Тег: очередь

Приоритеты или ресурсы?

Вводная:

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

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

Аналитики работают на два продукта, их ресурсов априори недостаточно.
 
 

Вопрос:

Как определить, какой запрос нужно взять в работу? Кажется, что решение лежит на поверхности — запрос с высшим приоритетом. Однако есть один подводный камень — высшее руководство назначает приоритеты, исходя из нужд клиента и совершенно не думает о наличии/отсутствии у разработки ресурсов, чтобы тот или иной запрос выполнить.
 
 

Первый вариант решения:

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

Результат: Месячный лаг, негатив от всех клиентов, не заработали ничего.
 
 

Второй вариант решения:

Смотрим на очередь, видим запрос на продукт № 1. Проверяем наличие ресурсов в команде продукта № 1 и осознаём, что их нет. В то же время, в продукте № 2 свободные разработчики имеются, мало того, ощущается недостаток задач. Берём запрос на продукт № 2, проводим через аналитиков, сразу же отдаём в работу, получаем деньги.

Результат: Заказчик высокоприоритетного запроса недоволен, высшее руководство тоже — запрос с высшим приоритетом не пошёл в работу. Сделали запрос с более низким приоритетом, заработали деньги.
 
 

Вывод:

В ситуации, когда приоритетами управляет высшее руководство, а аналитики работают на все продукты сразу, правильный алгоритм определения запроса для взятия в работу таков:

  1. Выяснить наличие ресурсов во всех продуктах.
  2. Взять в работу самый приоритетный запрос на этот продукт.

Единая точка входа

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

Бардак

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

Результат:

  1. Менеджер не владеет точной информацией о текущей загрузке разработчиков и не может нормально планировать.
  2. Разработчиков часто дёргают, не дают уйти в поток.
  3. Внедренцы конфликтуют из-за разработчиков.
  4. В первую очередь делают запросы тех, кто «громче кричит», а не те, которые стратегически более важны.
  5. Сроки срываются, очередь копится, организация теряет деньги, клиенты нервничают.

 
 
Приведённый ниже подход снижает скорость, но повышает предсказуемость разработки:

Корректная организация работ

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

Подробнее о работе с очередями можно прочитать в посте «Об очередях».

Об очередях

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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