OKR как бесконечное топливо для развития инженерных практик
Привет! Меня зовут Женя, я IT-менеджер в продукте QIWI Кошелек, над которым работают 5 фиче-команд (на начало написания статьи). В этом посте расскажу вам про наш опыт внедрения OKR («Цели и ключевые результаты», Objectives and Key Result») для непрерывного улучшения процессов разработки и развития инженерных практик. Как мы всё это делали, как теперь выглядят наши процесс и что нам дал OKR — под катом.
Я пришел в компанию QIWI разработчиком в отдел развития серверных приложений примерно 7 лет назад. На тот момент в компании еще не было продуктового подхода, мы работали в проектном стиле. Разработка была сосредоточена не вокруг продукта, а вокруг компетенции. Были отделы базы данных, серверных приложений, веб-разработка, мобильная разработка. Чтобы какая-то фича дошла до пользователя, ей предстоял довольно извилистый путь:
Фича начинала вариться в отделе баз данных.
Затем она попадала в отдел серверных приложений, где пилился хардкорный бэкенд.
И только потом — в спринты других отделов, собственно, в веб и в мобильную разработку.
Как вы понимаете, такими темпами фича могла делаться по несколько месяцев.
Бизнес всё это дело не особо устраивало, и так в компании началась Agile-трансформация, стали внедрять scrum, а затем LeSS (Large-Scale Scrum). LeSS — это когда несколько scrum-команд работают над одним продуктом, где каждая команда кроссфункциональная и может взять любой элемент бэклога.
В рамках перехода на scrum от разработки были следующие ожидания:
Во-первых, мы стремимся к тому, чтобы инкремент поставлялся каждый спринт, мы хотим как можно раньше доставить ценность до пользователя, чтобы раньше получить фидбек.
Во-вторых, мы хотим проверять много гипотез, потому что пользователей очень много, сегментов много, и сложно понять, какая именно фича лучше зайдет пользователям. При этом важно, чтобы скорость разработки на долгой дистанции тоже не падала.
В-третьих, мы должны поддерживать необходимый уровень качества продукта, как внешнее так и внутреннее.
После того как мы оформились в фиче-команды, я немного поработал разработчиком, а потом стал лидом бэкенда. Передо мной стояла задача развивать бэкенд-комьюнити. Глядя на все эти ожидания, я понимал, что без развития инженерных практик и инженерной культуры мы так далеко не уедем, ведь всем командам нужно работать над одним большим продуктом и обеспечивать регулярные поставки фич с нужным уровнем качества.
Один из принципов в Agile — непрерывное техническое совершенствование и улучшение проектирования, это позволяет делать продукт гибким, а гибкость это про то, что мы должны вносить изменения легко и быстро. Если упрощать, то организационная гибкость ограничена технической гибкостью.
Мы собрались всем бэкенд-комьюнити, набросали проблемы в разработке, из-за которых мы можем замедляться в поставке инкрементов. Помимо проблем еще нагенерили улучшения, с помощью которых мы бы смогли соответствовать ожиданиям. Список получился достаточно внушительным.
Приведу несколько примеров задач, которые мы обсуждали.
Проблема долгого разворачивания новой БД, тогда оно занимало от двух до четырех недель.
Узнаем с опозданием, что какой-то функционал не работает, а также не всегда можно оперативно понять, что именно сломалось.
Нет договоренностей, как пишем тесты, что покрываем и на каком уровне пирамиды тестирования.
В общем, запустили community по развитию подходов разработки, это была регулярная встреча раз в спринт (две недели). Мы собирались все вместе (было около 15 разработчиков) и обсуждали наши проблемы и улучшения. Для оптимизации (как нам тогда казалось) мы пытались обсуждать в один момент времени сразу несколько проблем.
Как это выглядело?
Приоритизация бэклога.
Голосованием выбирали, какие элементы бэклога стоит взять в работу в первую очередь. Каждый голосовал за какие-то 2–3 элемента.
Обсуждение проблемы и поиск следующего шага, который мог бы приблизить нас к решению проблемы.
На встрече все вместе обсуждали, какой следующий шаг можем сделать и кто готов взять его на себя. После переходили к следующему элементу бэклога. За одну встречу успевали обсудить от 3 до 5 задач.
На следующей встрече проходились по статусу и повторяли шаг 2, снова искали следующий шаг.
Все, вроде бы, ничего, мы начали регулярно обсуждать проблемы и улучшения, но прогресс нас не сильно устраивал. За несколько месяцев мы не так уж и много закрыли проблем, было ощущение, что мы топчемся на месте.
Мы провели ретро по работе нашего community, выделив ключевые проблемы:
Непонятно, что должно быть на выходе.
Когда мы обсуждали задачи, думали только про следующий шаг. Не было конечного понимания, каким мог быть первый инкремент, который стал бы приносить пользу.
Размытый фокус
Мы все вместе пытались обсуждать каждую задачу, а нас было немало — около 15 человек. У разработчиков и так много фокусов: выполнить цель спринта, участие в PBR и проработка будущих задач, помочь коллеге с обучением, пофиксить баг и т.д. А тут еще дополнительный фокус, где нужно погрузиться во все задачи, которые вместе обсуждаем.
Сложность с коммуникацией. Обсуждать задачи, когда на встрече много участников, очень сложно, нужны практики фасилитации. Иначе самые активные обсуждают, а другие выпадают.
В это время я читал книгу под названием «OKR — Измеряйте самое важное» Джона Дорра. Она меня сильно зацепила.
Расскажу очень коротко что такое OKR.
Расшифровывается как «Цели и ключевые результаты», Objectives and Key Result. Суть в том, что цели компании каскадируются сверху донизу, то есть наверху есть глобальные цели компании, которые чаще всего ставятся топ-менеджментом, затем есть цели продукта или департамента, а ещё конкретные OKR, которые привязаны к верхнеуровневой цели, их уже генерят сами команды.
Цель — это направление, в котором мы идём, или что хотим улучшить. Цель неизмерима, она дает вектор. Поэтому на помощь приходит понятие «ключевые результаты» — метрики, которые уже можно взять и измерить, они будут показывать, как вы продвигаетесь в рамках поставленной цели.
Принципы OKR
Как у любой уважающей себя методологии, у OKR есть принципы.
Прозрачность. Важно, чтобы все участники этого процесса понимали, что мы делаем, для чего, почему это важно и что это нам принесет.
Амбициозные цели. Они должны драйвить и быть поставлены так, чтобы они мотивировали их достигать. А ещё они должны быть чуть-чуть сложными, чтобы выполнить эту цель за итерацию было достаточно тяжело.
Фокусировка. Это про то, что не стоит пытаться объять необъятное и сразу сделать вообще всё, а лучше сфокусироваться на самом важном, что принесет наибольшую ценность.
Успех достижения цели не влияет на деньги, потому что, если пытаться ключевые результаты привязывать к деньгам, получится, что их начнут просто хакать, пытаться показывать ключевые результаты красивыми, а какая там ценность будет на самом деле — непонятно.
У меня появилась мысль взять за основу фреймворк OKR и применить его к нашему community. Обсудили с ребятами, что нам стоит изменить в работе. Ключевое, что мы сделали:
Начали описывать цель и ключевые результаты, которые хотим достигнуть в ближайшем приближении. Пусть это будет небольшое улучшение, но оно уже сможет приносить пользу как можно раньше.
Сделали итерации, на которые ставили цели и фокусировались на их достижении. По результату окончания итерации ожидаем инкремент, который будет уже приносить улучшение в работе.
Для достижения каждой цели формируется небольшая рабочая группа, где есть лид, который помогает задрайвить цель.
Разработчики стали фокусироваться на достижении одной, максимум двух целей.
Как теперь может выглядеть цель на итерацию?
Поработав в новом формате, мы стали получать больше результатов, обратная связь от ребят улучшилась, повысилась вовлеченность.
В общем, мы решили масштабировать наш процесс на весь продукт, а не только на backend community. Так как команды у нас кроссфункциональные, где каждая команда может сделать фичу от начала до конца, то и улучшать процесс разработки стоит на уровне команд, а не только на уровне платформ (я имею в виду backend, WEB, IOS, android и QA).
Как сейчас выглядит наш процесс непрерывного развития разработки
Немного раскрою каждый этап процесса
Генерация целей и ключевых результатов происходит в каждой фиче-команде. Каждая команда предлагает по две цели на итерацию, которые, по их мнению, приблизят нас к верхнеуровневой цели. На этом этапе еще не происходит комитмента по целям, это пока только кандидаты на итерацию.
Выбор целей и формирование рабочих групп. После того как все цели от команд были представлены, каждый разработчик выбирает, над какой целью он хотел бы работать и в какой роли. Когда разработчик сам выбирает цель, это как бы его внутренний комитмент, мотивация достигнуть цель выше, чем если бы эту цель ему навязали. Наша рекомендация — не вписываться в больше двух целей, чтобы не растерять фокус.
Мы выделили 3 роли:
Лидер OKR. Выполняет роль драйвера цели на текущую итерацию, помогает держать группу в фокусе. Организовывает необходимые встречи с рабочей группой.
Эксперт, хорошо разбирающийся в тематике, над которой ребята будут работать. Готов делиться опытом, давать обратную связь.
Последняя роль — те, кто готов на себя брать задачки. Это могут быть ребята, которые не являются пока еще экспертами, но готовы погружаться и брать на себя задачи для достижения цели.
Все эти роли могут комбинироваться. Такое разделение сделали для прозрачности, чтобы участники могли понимать, от кого и что ожидать, набрался ли кворум, чтобы стартануть OKR. Таким образом у нас получаются рабочие группы, состоящие из участников разных команд и разной экспертизы. Например, для достижения какой-то цели могут понадобиться эксперты от разных платформ back, front, qa.
Работа над целями. По целям, в которых собралась рабочая группа, начинается активная фаза.
Лид собирает ребят, которые будут работать над целью, они уточняют ключевые результаты, исходя из того, какой состав получился и какая есть экспертиза. Затем они начинают декомпозировать, детализировать и строить план работы. Дальше начинают работать над этими целями, выделяют определенный процент времени в спринтах и на планировании каждого спринта закладывают время на работу над целями. В конце — подведение итогов, где ребята обсуждают, что им удалось достичь, какие были сложности.
Завершается всё подведением итогов, где каждая рабочая группа показывает, что удалось сделать за итерацию, как теперь может поменяться developer experience. Презентация проходит на спринт-ревью — это совместное событие продукта, где присутствуют все команды.
Далее итерация повторяется. Сама итерация у нас длится четыре спринта, один спринт длится две недели. Первые две недели уходят на генерацию целей, формирование рабочих групп, а потом уже начинается активная фаза работы над целями.
Что нам удалось сделать в рамках OKR
Мы создали около 40 различных best practice. Так как у нас работает много команд над одним продуктом, приходят новые разработчики и применяется T-shape (Наташа писала в этом посте), наличие таких best practice очень помогает синхронизироваться по тому, как мы пишем тесты на всех уровнях пирамиды тестирования, как мы проектируем приложения, какие у нас есть принципы разработки, code style, какие подходы к мониторингу и так далее.
Но не best practice едиными — мы сделали много классных инструментов, например, теперь можно создать базу данных за пару кликов. Раньше на создание новой базы данных приходилось тратить около двух-четырех недель, а сейчас создание базы на тесте занимает пять минут, в продакшене чуть подольше из-за согласований, но в любом случае — это день-два.
Наличие best practice, кстати, помогло нам понять, какие подходы и принципы мы используем к мониторингу и к алертам. Это позволило нам внедрить dashboard as code, который позволяет автоматически генерировать дашборды для приложений на наши типовые метрики (время ответа, количество запросов, количество ошибок).
Автоматизировали патчсетирование на PostgreSQL через Liquibase, что позволило нам писать автотесты на слой DAO, поддерживать изоморфность сред и сделать авторелизы.
Внедрили mock-сервер, который нам очень помог повысить стабильность наших тестов, внедрили мониторинг и много других инструментов.
Чего мы достигли с помощью OKR
Во-первых — фокусировка на самом важном. Мы не пытались одновременно решать очень много задач, мы формулировали несколько целей, пытались сфокусироваться на маленьком scope, но сделать понятный и полезный инкремент.
Во-вторых, это позволило объединить разработчиков из разных команд. Несмотря на то, что у нас несколько команд и каждый разработчик работает в своей команде, мы один продукт, мы как одна большая команда. Это позволило повысить коммуникацию, пошарить экспертизу. Поработав в рабочей группе с другим коллегой, у которого есть какой-то опыт в одной области, ты можешь перенять себе.
В-третьих, лучшее понимание, куда мы двигаемся в разработке и какие перед нами стоят цели. Повысилась вовлеченность: почти все разработчики регулярно вписываются в работу над целями. Поработав так, мы получили значимые результаты.
А вот что главное я извлек лично для себя. Важно иметь общую разделяемую цель и давать возможность разработчикам самим участвовать в достижении этой цели совместными усилиями, тогда вы получите классные результаты.
Применяете OKR в своей работе? Если да, то какие плюсы и минусы успели заметить?
