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

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

Команда

Команда, в которой я работаю, разрабатывает публичное API и является одним из основных поставщиков данных для 2gis.ru и коммерческих партнеров. Любой поисковый запрос с 2gis.ru идёт через нашу команду — мы формируем данные в ответе.

Приходящий в команду набор задач условно можно представить так:

• Must-have задачи, над комплексной реализацией которых трудится весь отдел или компания. Их нельзя не сделать.
• Задачи на поддержку продукта. Если что-то сломается — должно быть время на починку.
• Техдолг. Наличие этих задач зависит от потребности и количества других. К сожалению, в борьбе приоритетов они первые кандидаты на выбывание.
• Задачи от заказчиков. Те задачи, которые не включены в планы отдела, но нанесут добро одному конкретному заказчику.

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

Пример: задача must-have — порелизить beta.2gis.ru ^[1], задача от заказчика — добавить новое поле в ответ приложения.

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

Как было раньше

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

Собирали весь список задач, выставляли приоритеты и оценки в гуглодоке. Это требовало много сил, нервов и времени — поэтому у нас родилась роль «план-мастера», передаваемая внутри команды. Человек с этой ролью, помимо своих основных задач, раз в месяц сверял правильность формул по вычислению ресурсов, собирал must-have задачи, хотелки от заказчиков и командные пожелания. Он же проводил долгие командные встречи по оценке этих задач и пытался утрамбовать их в единый список работ, исходя из собственных представлениях о приоритетах. Подход был далёк от идеала.

Проблема 1. Заказчикам не ясно, что происходит с их задачами

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

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

Гуглодока не была информативной. Она была и списком задач на месяц, и бэклогом задач, который переносился из листа в лист. Задачи терялись и дублировались. Было непонятно, куда вставлять задачу, как понять, взяли её в месячный спринт или нет. Да и вообще гуглдока выглядела отталкивающе.

Проблема 2. Канбан-доска не отражает действительность

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

Проблема 3. Команде не ясно, что происходит с задачами

Внутри команды не было четкого понимания, откуда берутся задачи, что будет следующим и что будет с теми, что лежат на дне канбан-доски. Те, кто брался погружаться в тонкости процесса, не разделяли радости планирования и старались больше никогда не возвращаться к роли «план-мастера». Большинство пребывало в неведении.

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

Сделать заказчику прозрачно

1. Отказались от утрамбовывания задач всех типов в один большой и сложный спринт. Как и раньше, раз в несколько месяцев проходит набор крупных задач на весь отдел, после которого понятны must-have задачи на ближайший период. В прошлом мы старались жестко разбить и упаковать их по месяцам, обещая релиз всех задач к концу месяца. Невыполнение каких-то задач вызывало у заказчика непонимание, когда они выпустятся. Теперь мы даём оценку, сколько их всего войдет в несколько месяцев, и приблизительно разбиваем по месяцам. В таком случае мы даем заказчику более размытую оценку по срокам — например, будет сделано в феврале или в марте — но заказчиков устраивает такие договоренности. Это дало им понимание того, что мы сделаем, не давая ложных обещаний и не перегружая спринт.
2. Ушли от приоритизации в гуглодоке к приоритизации в jira. Практика распространилась на техдолг, задачи от заказчиков и задачи на поддержку продукта. Этим мы решили проблему сложности инструмента.
3. Отказались от приоритизации не must-have задач от заказчиков. «Если не можешь определить приоритет — переложи эту задачу на инструмент», — подумали мы и придумали инструмент «карусель заказчиков».
   

   Алгоритм работы карусели следующий: раз в неделю мы в дополнение к основному набору must-have задач берём ещё одну задачу от заказчика. От кого именно — определяется таблицей, такой же, как в примере ниже. А так как порядок кольцевой, то отсюда и название инструмента.

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

   • Заархивировали все задачи из бэклога старше года. Это было очень приятно, учитывая, насколько старые задачи там встречались. Самый старый тикет пролежал там больше 4 лет.
   • Вручную промаркировали все задачи персональной меткой заказчика, чтобы можно было настроить быстрые фильтры на доске в jira, в рамках которых заказчик и определяет приоритет среди своих задач. Работа масштабная, но результат определенно того стоил. Заказчик видит список всех когда-либо созданных им задач, меняет приоритеты, не уведомляя команду.
   

4. После того, как с бэклогом стало удобно работать, мы вернулись к истокам kanban и начали снова считать и делать акцент на Cycle time задачах — среднему времени, за которое задача проходит через kanban-доску. Эта цифра теперь говорит заказчику, за какое время его задача дойдет до релиза и когда попадёт на доску. То есть решается проблема прогнозируемости.

Сделать команде прозрачно

1. Навели порядок на доске. Всё ненужное и неактуальное, что кроется в глубоком todo, закрыли, а то, что нужно сделать — положили в бэклог. Канбан-доска снова стала отражать поток задач, как он есть. Введение лимитов на очередь перед разработкой — todo — и на очередь перед выпуском в релиз — done — помогло поддерживать доску в актуальном состоянии. Чтобы напоминать команде о необходимости слежения за ограничениями, написали бота, который при нарушении лимитов пишет об этом в командный чат. Тут, убив двух зайцев, мы решили вторую и третью проблему прошлого процесса: доска отражает действительность и команда понимает, что происходит.
   
2. Раз бэклог — инструмент планирования задач, нужно поддерживать его в актуальном состоянии. В свете всех изменений мы завели регулярную встречу, на которой командно отсматриваем пришедшие задачи и задаём вопросы по срокам и требованиям. Большой плюс этого решения — требования уточняются/пишутся до попадания задачи на доску, то есть мы проводим упрощенную аналитику заранее, не тратя время при разработке.

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

   Роль «план-мастера» превратилась в дополнение к роли дежурного, отвечающего за саппорт проекта в течение недели. Ему нужно закидывать задачи на доску и проводить еженедельную встречу.

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

Как стало

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

Что хочется сделать дальше:

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

Решали что-то из подобных задач? Поделитесь идеями в комментариях.

Хотите продолжения? Присоединяйтесь к завтрашней прямой трансляции ^[2] DevDay Manage IT ^[3].

Автор: Partridge

Источник ^[4]