Привет всем! Меня зовут Кирилл Ларьков, я Скрам-мастер банка ВТБ и работаю с сервисными командами. В этой статье я хотел бы поделиться опытом по прогнозированию задач в сервисных командах, которым ранее и в страшных снах не снилось слово «прогнозы». Формат для данной статьи я выбрал сторителлинг, так как подобный пошаговый гайд будет полезен начинающим командам, которые пытаются справиться самостоятельно с прогнозированием задач.
Также в этой статье для сокращения содержания я ссылаюсь на этапы, с которыми хорошо знакомы практики канбан метода: 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): Только давай договоримся, что мы не будем превышать количество задач, с которыми ты сейчас работаешь. Если один столбец, например, «Исполнение» заполнен, то ты не будешь брать новые и будешь закрывать текущие. Идёт? Наша главная задача: выполнять первым делом задачи, которые ближе к завершению.
(Участник команды): Идёт! (Странное правило, будто что-то изменится, но можно попробовать).
(SM): Смотри, у нас есть данные, которые мы вместе собирали в течение месяца. Теперь мы можем определить, что 95% процентов работ у тебя завершаются в течение 4 дней.
(Участник команды): Ну вроде да.
(SM): За все этапы в сумме у тебя получилось около 10 дней с таким же процентом работ.
(Участник команды): Здорово! Значит, я теперь могу ставить SLA 10 дней?
(SM): Если не будет возникать форс-мажорных ситуаций, то да. Это один из способов подсчёта твоей задачи.
Вывод: В сумме было потрачено около 2 месяцев с каждым участником команды, чтобы определить SLA для подобной ситуации. В данном примере я пропустил некоторые этапы, по которым пришлось проходиться с каждым участником. Зачастую коллегам приходилось несколько дней думать над теми процессами, с которыми они работают, и в некоторых случаях всё приходилось начинать сначала и описывать этапы ещё раз. Стоит отметить, что большую часть времени участникам приходилось работать с разного рода блокерами, которые ранее не замечались и игнорировались, но благодаря доске стали видны.
Стоит отметить, что большую часть времени участникам приходилось работать с разного рода блокерами, которые ранее не замечались и/или игнорировались.
На данную статью оказали большое влияние следующие работы:
Как прогнозировать время выполнения задач
Actionable Agile Metrics for Predictability: An Introduction, Daniel S. Vaca
ссылка на оригинал статьи https://habr.com/ru/articles/833490/
Добавить комментарий