Заметка

Как докручивать процессы в команде

После предыдущего поста о запуске процессов прилетел в личку вполне закономерный вопрос: что делать после запуска процесса? Как его докручивать?

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

Когда я в первый раз столкнулся с задачей развития процессов, то поначалу впал в ступор. Я делал какие-то действия, что-то выстреливало (иногда — в ногу). Результат был, но я не мог назвать его системным и управляемым. Конечно же, хотелось видеть чуть другую картину.

Но в какой-то момент в голове появилась мысль, что процесс — это тоже продукт. У него есть пользователи и ценность, которую он им даёт. И я подумал: а что, если подойти к развитию процесса как к развитию продукта? Немного подумав, я вспомнил про HADI-циклы.

Методология HADI

HADI — это методология тестирования гипотез. Расшифровывается так:

  1. Hypothesis — гипотеза. Какую идею проверяем?
  2. Action — действие. Как мы будем проверять идею?
  3. Data — данные. Как мы будем анализировать результаты идеи?
  4. Insights — выводы и инсайты. Анализируем, что у нас получилось, и делаем выводы.

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

HADI-циклы в реальном мире

Разберём выдуманный пример.

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

Техлид Вася прикидывает на колене процесс грумминга и договаривается о пробной итерации с разработчиками Петей и Колей. Вася, Петя и Коля проводят грумминг: разбирают задачки, что-то прибивают, что-то оценивают. Получают ряд задач, которые берут в спринт. Это действие.

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

Петя: «Прикольно, таски описаны, берёшь и делаешь, думать не надо».

Коля: «Чёт хз, созвон какой-то непонятный, но хоть техдолг в спринте поделать дали».

Тимлид: «Вот так бы всегда, задачи сразу с оценкой, я хоть планировать нормально могу».

Это данные.

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

  1. Процесс принёс пользу — получилось запланировать задачки в спринт.
  2. Описанные задачи помогают разработчику вспомнить, что вообще делать надо.
  3. Грумминг технических задач можно улучшить.

Это инсайты. Последний инсайт может стать рядом новых гипотез.

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