Привет всем! Меня зовут Кирилл Ларьков, я Скрам-мастер банка ВТБ и работаю с сервисными командами. В этой статье я хотел бы поделиться опытом по прогнозированию задач в сервисных командах, которым ранее и в страшных снах не снилось слово "прогнозы". Формат для данной статьи я выбрал сторителлинг, так как подобный пошаговый гайд будет полезен начинающим командам, которые пытаются справиться самостоятельно с прогнозированием задач.

Также в этой статье для сокращения содержания я ссылаюсь на этапы, с которыми хорошо знакомы практики канбан метода: F4P (Fit for Purpose), Upstream kanban. Советую вкратце ознакомиться с материалом, так как эти знания позволят сконцентрироваться на самом важном перед решением проблем, с которыми мы столкнёмся при прогнозировании задач.

(Лидеры): Уважаемые коллеги, мы переходим на сервисную модель. Теперь нам необходимо указывать точные сроки, когда услуга будет оказана, чтобы клиенты понимали, когда работы будут готовы. Итак, ваша команда оказывает услугу N, в какой срок вы её можете выполнить?

(Команды): Исходя из нашего опыта, мы можем предположить, что услугу N мы сделаем через 2 месяца (Что за странные вопросы со сроками? Мы работали себе спокойно в течение 3 лет. Теперь нас просят назначить сроки на все задачи. Должно быть, он шутит).

(Лидеры): Почему такой большой срок? Мы же работаем в спринтах. В конце каждого спринта должен быть инкремент, который несёт определённую ценность. Разве часть N не является ценностью? (Ребята, не говорите, что вы иногда курили бамбук, вместо того чтобы выполнять задачи).

(Команды): Это спорный вопрос, смотря что понимать под выполненной услугой. Наша деятельность в целом не вписывается в Agile, и мы не можем работать в узких спринтах. Срок достоверно мы указать не можем (Потому что не знаем, когда он уйдёт?). Поступающие к нам N на самом деле это: N1, N2, N3... То есть задачи всегда нетипичные и индивидуальные (У нас всегда есть обстоятельства, которые задерживают наши задачи. Мы не можем управлять смежниками!).

(Лидеры): Покажите на доске, какие у вас ведутся работы (Кажется, ребята периодически курят бамбук).

Лидеры на доске не нашли никакой лишней информации. Но обратили внимание, что информации по задачам явно не хватает.

(Лидеры): Коллеги, что значит "Подключение серверов"? Что в эти работы входит? Почему наши задачи не декомпозированы? Как вы вообще понимаете, что вы делаете? (Что происходит на досках, ничего не понимаем? Вроде никаких проблем никогда не было, и коллеги работали исправно).

(Команды): Каждый член команды занимается обслуживанием своих систем. Если бы вы сидели рядом, то понимали бы больше вещей. В команде все разделяют идеологию, что каждый ответственен за себя. Если у вас сейчас есть какие-то вопросы по тому, что в этих работах происходит, то мы можем вам в деталях объяснить, но нам потребуется время, чтобы достаточно понятно это объяснить. Нам вообще эта платформа для ведения задач не нравится, тратим на это лишнее время (ещё немного, и мы выскажем лидерам, что думаем об Agile, если они не прекратят отвлекать от работы).

(Лидеры): Коллеги, предлагаем назначить встречу, чтобы детальнее обсудить этот вопрос. Мы пригласим Скрам-мастера, чтобы он помог разобраться с тем, что у нас есть. Явно наши процессы не адаптированы под Agile (Уходим! Уходим!).

Вывод: Лидеры спасли свои жизни, а команды думают, что победили в этой дискуссии и отстояли своё право не планировать работы.

Лидеры рассказали Скрам-мастеру о своей проблеме, и он назначил встречи с каждым членом команды.

(SM): Добрый день! Поделитесь, какие задачи вы выполняете?

(Участник команды): Подключение серверов. Это очень сложный процесс, который...

(SM): А для чего вы это делаете? Какая цель вашей деятельности?

(Участник команды): Это необходимо для... (Очень сложные вопросы, о которых я раньше не думал. Как объяснить это обычному человеку такую информацию?)

--------------------------------------(Далее диалог продолжается по F4P)--------------------------------------

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

(Участник команды): Ну всё начинается... (Я расскажу как есть. Во всех подробностях. Пусть человек поймёт, какая сложная у меня деятельность).

(SM): А мы можем разделить это на этапы работ?

(Участник команды): Ну давайте попробуем.

Нам удалось обозначить этапы прохождения задачи. Единственное, что мы согласились не обозначать, так это метание задачи между этапами (задача могла возвращаться обратно в предыдущий этап). Мы договорились сделать промежуточные зоны, когда задача находилась в зоне неопределённости.

После нескольких дней диалог со Скрам-мастером продолжился.

(Участник команды): Слушай, я подумал насчёт этапов. Между этапами "Анализ" и "Работа с вендором" есть ещё один этап — "Создание документа".

(SM): Конечно, давай его добавим. По остальным этапам есть какие-то изменения?

(Участник команды): Нет, вроде нет. Там сложная ситуация вообще...

(SM): Давай попробуем определить, в каком случае мы берёмся выполнять задачи?

(Участник команды): Это происходит, когда...

---------------------------------------------------Обсуждение Upstream----------------------------------------------

(SM): А мы можем это сделать в формате критериев или чек-листа, по которому задача на 100% попадает в этап "Анализ"?

(Участник команды): Ну это легко... Эти критерии: x1, x2, x3. В других случаях мы не работаем (Хороший вопрос, наверное, стоит эти критерии записать, потому что, по сути, я не всегда их соблюдаю).

(SM): Давай такие же чек-листы сделаем и по остальным этапам (Итак, мы формируем DoD1, DoD2...).

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

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

(Участник команды): Слушай, мы проделали такую большую работу. Я до сих пор не понимаю зачем. Объясни, зачем мы нарисовали эту доску?

(SM): Так нагляднее понимать, какие происходят процессы. Теперь мы можем контролировать задачу. Подскажи, сколько у тебя сейчас задач на каждом этапе.

(Участник команды): 10 на "Анализ", 20 на "Создание документа", 5 на "Работа с вендором", 10 на "Исполнение" и 8 на "Тестирование".

(SM): Расскажи поподробнее, почему на каждом этапе столько задач. И по какой причине задач на этапе "Создание документа" больше, чем на других?

(Участник команды): Да, конечно... Касательно этапа "Создание документа", всё довольно просто — вендор 1 редко отвечает, поэтому наши задачи не выполняются вовремя. Но его можно понять, он перегружен.

(SM): А есть какие-то сроки на работу с вендором 1?

(Участник команды): Нужно поднять документы и почитать. Да, вроде у нас с ним есть SLA. Необходимо ему напомнить об этом и назначить встречу.

(SM): Я правильно понимаю, что и на этапе "Работа с вендором" у вас есть с вендором 2 также свой SLA?

(Участник команды): Да, с вендором 2 у нас есть свой SLA. Но необходимо это обсудить с...

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

(Участник команды): Слушай, жить стало на самом деле полегче. Интересно получается. Мне говорили, что мы все эти диалоги строим для обсуждения сроков, а мы разрешаем какие-то проблемы (Как хорошо, что теперь мою работу хоть кто-то понимает. Теперь-то у меня есть свидетель, который подтвердит, что моя работа не планируема).

(SM): Очень рад это слышать. Все наши действия вели к тому, что теперь мы можем посчитать время, за которое проходят задачи на каждом этапе.

(Участник команды): А зачем это нужно?

(SM): Мы можем на основе статистики собрать необходимую информацию, которая позволит установить ваш срок исполнения задачи.

(Участник команды): Хм... Давай попробуем. От нас всё равно требуют цифры, хорошо будет, если мы сможем их собрать.

(SM): Только давай договоримся, что мы не будем превышать количество задач, с которыми ты сейчас работаешь. Если один столбец, например, "Исполнение" заполнен, то ты не будешь брать новые и будешь закрывать текущие. Идёт? Наша главная задача: выполнять первым делом задачи, которые ближе к завершению.

(Участник команды): Идёт! (Странное правило, будто что-то изменится, но можно попробовать).

Мы собрали статистику по каждому этапу в течение месяца. На примере показан этап "Анализ". Такой вид распределения времени решения задач в формате Lead Time показался наиболее удобным. Мы увидели, что на всех этапах наблюдается подобная картина с распределением задач. Таким образом, мы установили, что каждый этап контролируется по времени.

(SM): Смотри, у нас есть данные, которые мы вместе собирали в течение месяца. Теперь мы можем определить, что 95% процентов работ у тебя завершаются в течение 4 дней.

(Участник команды): Ну вроде да.

(SM): За все этапы в сумме у тебя получилось около 10 дней с таким же процентом работ.

(Участник команды): Здорово! Значит, я теперь могу ставить SLA 10 дней?

(SM): Если не будет возникать форс-мажорных ситуаций, то да. Это один из способов подсчёта твоей задачи.

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

Стоит отметить, что большую часть времени участникам приходилось работать с разного рода блокерами, которые ранее не замечались и/или игнорировались.

На данную статью оказали большое влияние следующие работы:

Как прогнозировать время выполнения задач

Actionable Agile Metrics for Predictability: An Introduction, Daniel S. Vaca

Опыт по установке SLA с помощью инструментов Канбан метода: история сервисных команд