На связи Антон Бевзюк и Дмитрий Кожевников, инженерные менеджеры Mindbox. 

В Mindbox большая команда, и мы долгое время искали способ, как масштабировать Agile. Пробовали Kanban, Scrum, XP, LeSS — все не то. Полгода назад перешли на Pipedrive Agile Framework и остались довольны: уменьшили количество рутинных задач, повысили уровень счастья среди разработчиков и стали быстрее выпускать фичи — реализовали обновления, которых клиенты ждали годами. Готовы поделиться опытом.

Статья будет полезна тем, кто хочет организовать работу команды из более чем 100 разработчиков и сбалансировать развитие продукта и поддержку. Мы подробно расскажем, какие сложности испытывали и как Pipedrive Agile Framework помог с ними справиться, какие ошибки допустили во время внедрения, поделимся советами, как их не повторить, и дадим подробные гайды по запуску фреймворка.

Исходные условия работы команд разработчиков

У Mindbox есть особенности, которые повлияли на внедрение Pipedrive Framework.

13 автономных команд. Последние годы Mindbox рос на 30–40% в год. В итоге продукт стал настолько сложным, а команда такой большой, что мы выделили восемь продуктовых зон: платформы данных, рассылки, рекомендательные системы и так далее. В каждой зоне была своя команда, а в особо крупных зонах — несколько. В конце 2022 года численность сотрудников выросла до 239. Над продуктом работают около 150 разработчиков в 13 командах.

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

Растущий toil. Toil — это рутинная работа: исправление дефектов, багов, реакция на алерты, отработка обращений в саппорт. Mindbox — высоконагруженный продукт: у нас на поддержке 900 компаний разного размера, которые генерируют более 20 тысяч запросов в секунду. Это создает нагрузку на инфраструктуру и требует поддержки, то есть формирует toil.

Особенная культура. В Mindbox культура самоуправления: у каждого есть право вето и возможность принять любое решение, дать публичную обратную связь. Вертикальный и горизонтальный рост сотрудников не ограничен. Подробнее об этом можно узнать в интервью с работающими, уволенными и уволившимися сотрудниками. Культурный контекст повлиял на выбор фреймворка и скорость его внедрения.

Опыт масштабирования Agile до Pipedrive Framework

Чтобы организовать работу, мы пробовали разные инструменты. Какие-то не подошли совсем, некоторые внедрили частично, но сократить toil и ускорить выпуск фич это не помогло.

Kanban

Kanban прижился во всех командах разработки. У каждой есть своя доска, в которую попадают задачи на продуктовые и технические доработки, баги. Из входящей очереди карточки поступают в колонку «В работе»: по внутренним правилам одновременно в работе могут находиться не больше 3–5 задач (ограничение зависит от размера команды). После того как работа закончена, карточка попадает в колонку «Приемка», чтобы продакт-менеджеры проверили, правильно ли ведет себя обновление с точки зрения бизнеса и решает ли проблему, ради которой заводилась задача. Когда продакт принимает задачу, карточка перемещается в колонку «Готово с последнего статуса», чтобы команда обсудила результат на дейлике. После карточка передвигается в колонку «Готово».

Scrum

Из Scrum взяли отдельные элементы. Например, разработчики вместе с product owner определяют цели, работают небольшими итерациями по одной-две недели, в начале итерации планируют свою работу, а в конце — ищут способы улучшения процессов в ретроспективе.

XP

Extreme Programming удалось внедрить частично. Например, у нас есть автоматизированный CI/CD, автотесты, рефакторинг и микросервисы, покрытые SLA.

LeSS

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

Two pager

Two pager — это небольшой документ, в котором кратко зафиксированы цель и ключевые результаты — objectives and key results (OKR) каждой команды на полгода. Two pager помогает быстро понять, в чем основной фокус команды на полгода и как будет выглядеть результат.

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

OKR создаются по W-фреймворку: коммуникация происходит поочередно между C-level и командами. Сначала C-level формулирует контекст и общую стратегию. Затем команды изучают потребности клиентов и формулируют two pager — планы, которые они смогут осилить, и при этом согласованные с общим контекстом. Следующий этап — интеграция: C-level, продакт-менеджеры и участники команд обсуждают готовые two pager, проверяют, насколько они помогают компании достичь цели, выясняют зависимости между командами и интегрируют их в two pager друг друга. Результат фиксируется в виде публичного контракта — в Mindbox это сообщение в канале Slack в духе: «Мы договорились о такой-то цели, будем к ней бежать. Если кто-то возражает, приходите обсуждать». Если возражений нет, OKR считаются утвержденными.

Идея классная, но с 13 командами запустить процесс целеполагания с two pager оказалось сложнее, чем мы думали. Менеджменту приходилось погружаться в детали целей 13 команд, из-за чего качество обратной связи было низким.

Команды небольшие, поэтому и OKR были слабыми, ориентированными не на бизнес, часто техническими. Например, в зоне рассылок команда могла выбрать цель «обеспечить автовывод IP». Сама по себе эта фича не полезна клиентам — им не нужен IP, им нужна доставляемость писем. Автовывод IP может быть шагом в сторону доставляемости, но может и не сработать. C-level приходилось оценивать все OKR: какой вклад в новую функцию внесет конкретный OKR, какие еще OKR потребуется выполнить, чтобы пользователи получили нужную фичу.

Как Pipedrive Framework работает в Mindbox 

Pipedrive Framework предполагает работу в крупных командах — трайбах. Раньше в каждой команде у нас было максимум 10–12 человек. Мы объединили команды в трайбы по 20–30 человек. В трайбе есть три ключевые роли: продакт-менеджер отвечает за пользу для клиентов, архитектор — за надежность и масштабируемость системы, инженерный менеджер — за непрерывную поставку ценности и рост людей в команде.

Основа Pipedrive Framework — разделение работы на две составляющие: работу над фичами и поддержку продукта.

Работа над фичами проходит во время так называемых миссий. Для каждой миссии формируется небольшая команда из трех-пяти участников трайба. Эта команда несколько месяцев концентрируется исключительно на достижении цели миссии.

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

Миссия

Работа начинается с подготовки two pager. Two pager по-прежнему разрабатываем по W-фреймворку, но это не прежний документ с описанием небольшого обновления — с внедрением Pipedrive Framework команды укрупнились, а значит, цели в two pager стали масштабнее.

На достижение цели two pager есть полгода. За это время запускается и приземляется множество миссий — каждая направлена на достижение цели two pager.

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

Дальше собираем экипаж. Обычно это добровольцы, которым интересно сделать запланированную фичу и которые будут полезны в реализации: разработчики, продакт-менеджеры. Количество человек в команде зависит от миссии — в одних достаточно трех человек, в другие набираем по пять-шесть.

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

При подготовке миссии формулируем критерии приземления и готовим все необходимые артефакты для работы команды: доску в Github, канал в Slack, документируем ключевые изменения в архитектуре и составляем понедельный план поставки. Когда все готово и миссия взлетела, экипаж уходит из ланчпада, перестает реагировать на поддержку и приступает к работе.

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

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

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

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

Чтобы рассказать customer success manager и sales manager о новых доступных фичах, пишем пост в специальном канале в Slack. Также результатами делимся со стейкхолдерами на ежемесячных демо.

Ланчпад

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

Ланчпад работает по Kanban с элементами Scrum. В поддержке нет крупных целей, под которые можно было бы выделять спринты, зато есть поток задач разных классов обслуживания: баги, дефекты, алерты, небольшие бизнесовые и технические доработки продукта.

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

Опытным путем пришли к тому, что в ланчпаде одновременно должны находиться не более 30% участников трайба. Этого количества хватает, чтобы справляться с поддержкой, рефакторить и решать проблемы, из-за которых у поддержки увеличивается количество задач. Пока участники трайба находятся в ланчпаде, стараемся отправлять их в отпуск, чтобы к старту миссии они были свежими, отдохнувшими, румяными, сытыми, довольными и не выгорели в полете. 

Что изменили в классическом Pipedrive Framework

Мы не взяли из Pipedrive Framework все под копирку — некоторые подходы изменили, что-то оставили на будущее.

Например, и в Pipedrive Framework, и у нас миссии формулируют продакт-менеджеры. Отличие в том, что в классическом виде все продакт-менеджеры одновременно питчат свои миссии и набирают экипаж среди добровольцев — если миссия не заинтересовала разработчиков, она не полетит. В Mindbox такой формат невозможен: мы не можем фокусироваться на желании разработчиков внедрить фичу — у продукта есть заказчики, на чьих задачах мы концентрируемся. Периодически приходится назначать участников миссии. Думаем, это временно, и по мере привыкания к фреймворку ребята будут становиться активнее.

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

Опыт неудачного запуска миссии: ошибки и выводы

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

Первой миссией стало обновление рассылок — как раз собирались его проводить и решили опробовать новую систему. Задача была — освежить страницу настройки рассылки для демосценария. Кардинальных изменений не планировали: хотели только перенести минимальный набор старых функций на современные компоненты, попутно обновив стек. Объем работы оценили в два месяца.

Смена заказчиков миссии

Через месяц после запуска миссии заказчику пришлось переключиться на другую задачу, и он передал управление другому продакт-менеджеру. Мы оказались в ситуации, когда старый заказчик уже не занимается миссией, а новый еще не погрузился в контекст. Критерии приземления стали расплываться: если сначала планировали реализовать минимальный набор фич для демосценария, то в конце пытались внедрить абсолютно все функции. 

Когда менялись критерии приземления, мы не проводили обсуждений и повторного планирования — просто корректировали работу и продлевали миссию. Оглядываясь назад, понимаем, что нужно было сесть и заново оценить ее, набросать план. Это помогло бы увидеть, что потребуются дополнительные два-три месяца работы, которые к тому же не приблизят нас к цели из two pager.

В итоге одну из важнейших целей в изначальном two pager мы не выполнили. В OKR у нас было улучшение доставляемости рассылок, а редизайн планировался как приключение на 20 минут, которое мало влияет на основные цели команды. Однако во время полета задача по редизайну разрослась, и мы сконцентрировали все силы на ней, так и не реализовав доставляемость.

Мы сформулировали правило: если нужно сменить заказчика или лидера миссии, доводим ее до приземления со старым составом как можно скорей. Нормально, если при этом цели миссии еще не достигнуты. Это помогает избежать потерь на передачу контекста и осознанно подойти к форс-мажорной смене планов вместо того, чтобы плыть по течению.

Затянувшиеся сроки

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

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

Поздний фидбэк от клиентов

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

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

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

Эффект полугодовой работы по Pipedrive Framework

Мы уже полгода работаем по Pipedrive Framework: сформировали восемь трайбов, запустили и удачно приземлили 18 миссий. Можем подвести итоги.

Начали создавать крупные фичи

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

Планирование стало прозрачнее. Небольшие миссии теперь объединяются в крупные two pager с понятными для бизнеса целями. C-level и участникам трайба теперь не нужно погружаться в детали реализации и проработки фич, чтобы дать фидбэк — планируемые изменения можно оценить за счет здравого смысла.

Прирост toil замедлился

С переходом на Pipedrive Framework мы видим, что относительно числа разработчиков toil не растет.

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

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

Переработки выросли

С переходом на Pipedrive Framework переработки никуда не делись, даже немного выросли. HR-отдел раз в полгода проводит опрос среди сотрудников, один из вопросов касается нагрузки. По результатам мы видим, что больше разработчиков сообщают о переработках. 

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

Инженерный менеджер и HR-отдел взяли вопрос на контроль: если следующий опрос покажет тот же результат, постоянную программу борьбы с переработками и профилактики выгорания доработают.

Счастье разработчиков растет

Другой вопрос из HR-опроса касается удовлетворенности работой. Результаты по этому показателю радуют: уровень счастья разработчиков медленно, но растет. Это внушает настороженный оптимизм.

Еще один положительный эффект — с разделением работы на миссии и ланчпад график отпусков стал более понятным. Обычно разработчики уходят в отпуск на стыке миссий: до их начала или по окончании. Это может быть даже пара дней отдыха, чтобы настроиться на миссию или выдохнуть после нее. Думаем, это тоже влияет на eNPS (employee net promoter score — метод оценки лояльности сотрудников).

Разработчикам проще расти

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

Бонус: инструкции по внедрению Pipedrive Framework

Мы проанализировали наш опыт внедрения фреймворка, факапы и успешные запуски и собрали ранбук. В нем вы найдете полезную информацию по погружению в Pipedrive Framework, инструкции по запуску и приземлению миссии. Этот документ поможет быстрее разобраться с фреймворком, не пропустить основные шаги и не допустить наших ошибок.