Всем привет. Меня зовут Витя, я руководитель оптимизации процессов разработки и лидер профессии деливери-менеджеров.
Мы в Тинькофф исторически растем большими темпами — рост команд часто превышал 100% год к году. Но за всю более чем пятнадцатилетнюю историю у нас не было классических scrum-мастеров или agile-коучей. Расскажу, почему так получилось и как появились деливери-менеджеры в наших командах.
Как все начиналось
У нас в компании есть внутренняя культура, которая называется ДНК Тинькофф. Культура существовала с самого зарождения компании, а пару-тройку лет назад ее оцифровали и теперь она выглядит вот так:
Берем ее во внимание и переносимся в прошлое. Семь лет назад я руководил разработкой, когда появилась задача реализовать CRM на замену вендорской. Мы создали MVP и после первых успешных результатов получили благословение на масштабирование.
Сначала в команде было пять человек. Через полгода стало почти сорок. Через год мы выросли еще на 100%. И продолжали расти. Не знаю, сколько раз менялась модель управления командой, которая выросла более чем на 2000% за пару лет. Было много изменений в модели управления. Для наглядности объясню на модели Данбара.
Эту модель можно легко наложить на командообразование на то, как выстраивается разработка продуктов и уровни менеджмента.
Когда команда переросла цифру в 50 человек и мы перешли на 3 уровень, стало понятно, что часть команды не всегда знает, что делает другая часть. Это случалось даже в командах, создающих зависимые друг от друга фичи. На тот момент было уже 7—8 независимых команд, которые делали продукты в рамках одной CRM. У каждой команды своя цель, но при этом цели не всегда сонаправленны и было расхождение в коммуникации того, что уже есть, и того, что будет дальше.
Мы росли как команда, но скорость развития продукта пропорционально не прибавлялась. Потому что росло количество коммуникаций: чтобы о чем-то договориться, нужно было больше времени. Чтобы быть в контексте, нужно было все большему количеству людей собираться для обсуждений. Росла общая когнитивная нагрузка и инженерная сложность.
На старте добавить в продукт одну условную кнопку занимало 30 минут. По мере увеличения сложности экрана и продукта каждая новая кнопка обрастала дополнительными вводными, которые нужно учесть и согласовать с ответственными. Это все нас замедляло, и задача растягивалась уже на часы или дни.
Информационный рассинхрон между командами увеличивался, появились очереди блокировки друг на друга из-за общих компонент или ожидания чего-то от соседа.
Вишенкой на торте стало то, что мы за первый год запилили очень много классных пользовательских историй, которые по правилу Парето требовали мало сил, но давали много визуального эффекта и функциональности. И остались наиболее сложные задачи.
Нам взгрустнулось, потому что мы классная команда, растем, делаем все больше и больше. Но outcome не рос так сильно как output, а output рос медленнее хэдкаунта.
Сложилась среда, в которой нам нужно планировать развитие продукта дальше, но непонятно, как в таких условиях измерить скорость закрытия усложняющегося бэклога фич и что будет со скоростью дальше.
Как я надел вторую шапку
Мы поняли, что нужно системно улучшать процессы и в нашей ситуации это принесет намного больше пользы, чем добавление новых людей в текущие процессы.
Тогда я надел на себя вторую шапку: кроме классического руководства разработкой начал заниматься сбором, расчетом и улучшением метрик поставки по всем командам платформы и выравниванием их целеполагания и планирования.
Для начала я очистил все Jira-данные в отчетах от выбросов, чтобы увидеть максимально правдоподобные метрики. Это происходило не через выкидывание задач, а через эволюцию процессов работы с тикетами. Тогда у нас еще не было своего BI для процессных метрик, поэтому я собрал в Grafana дашборды с метриками и вывел их в офисе на монитор рядом с командой.
Когда люди увидели мониторе свои команды, мы пошли дальше:
Провели цикл индивидуальных улучшений процессов команд, направленных на стабилизацию поставки и улучшение предсказуемости.
Визуализировали и синхронизировали команды по ответственности за разные технические и бизнесовые модули, потому что были блокировки и зависимости из-за непрозрачной ответственности или отсутствия понятного роадмапа развития у определенных модулей.
Выровнялись по целеполаганию, потому что мы не могли ответить на вопрос «Когда какая часть нашей большой функциональности должна появиться на продакшене, чтобы быть переиспользованой другими командами?». Когда вы пилите что-то с нуля, вопрос эффективного переиспользования — один из важнейших для скорости, но может очень больно выстрелить в ногу в будущем.
В итоге мы пришли к тому, что у нас работал Канбан-метод, который мы использовали поверх наших скрамообразных процессов. Также мы добавили легковесные адаптированные практики из Scaled Agile Framework, например работу с техдолгом как работу с enabler-ами, а двухдневный PI-planning превратили в два созвона по 90 минут. После для синхронизации накрутили поверх этого еще OKR.
Как среда изменений ответила новой профессией
Через какое-то время после успеха прошлой истории у нас сформировалась и выделилась профессия по улучшению end-to-end-процессов. Мы поняли: если этим заниматься системно на фултайме, можно получить еще больше пользы, особенно в более сложных системах и продуктах. Было видно, что описанный ранее опыт востребован во многих продуктах, переступивших определенный уровень сложности или проходящих трансформации. И мы начали масштабировать такой подход на другие бизнес-линии.
Сейчас в Тинькофф около 60 деливери-менеджеров в ИТ и бизнес-линиях и еще шесть — в операционных подразделениях. Это около 1% от HQ и около 0,02% от операционки.
Важно, что деливери-менеджеры появились внутри, это не было запросом сверху вида «давайте мы проведем изменения и под это возьмем много людей, которые будут их проводить». Нет, у нас изначально была культурная среда, которая поддерживала проведение изменений, и деливери-менеджеры появились как ответ этой среды на те челленджи, которые возникли перед продуктами.
Деливери-менеджер помогает организации ускорить появление продукта или его поставку на рынок. Он делает это в условиях растущей сложности как ИТ-систем, так и продуктов, процессов и внешних ситуаций. При этом нам важно не терять в гибкости и эффективности как при масштабировании, так и при перестройке
Деливери-менеджер у нас чаще находится в IT под СТО, но есть варианты, когда он находятся ближе к бизнесу — у CPO. Этот вариант предпочтительнее, потому что дает возможность влиять на большее количество процессов. Область ответственности ДМ — это end-to-end-продукт либо, если он работает с ИТ-платформой и нельзя покрыть весь end-to-end, то те области, до которых можно дотянуться, плюс межкомандное взаимодействие там, где могут возникнуть зависимости.
У одного деливери-менеджера может быть до девяти команд с которыми он более-менее плотно работает, у лидов — больше, но с меньшей степенью погружения. Количество людей, с которыми работает деливери-менеджер, варьируется от 20 до 100 и больше. Это зависит от грейда и от сложности конкретной команды.
ДМ может как работать на базовом уровне платформенных команд разработки, так и заниматься полноценной работой со всеми, кто связан с продуктом: с бизнес-стейкхолдерами, с разными линиями поддержки и сервиса вокруг продукта и так далее.
Уровень погружения тоже варьируется: на низких уровнях зрелости команд иногда требуется погружение, которое можно сравнить с погружением скрам-мастера — много day-by-day-работы в команде. На более высоких уровнях зрелости уже не команд, а продуктов и сервисов, уровень погружения может быть сравним с agile-коучами: это не внутрикомандная работа, а скорее работа по запросу от топов или сопровождение бизнес-линии — например, через задавание неудобных, каверзных вопросов для поиска стрессоров для выхода из локального максимума к дальнейшим улучшениям.
Получается, что ДМ влияют на широкую область процессов: от самых базовых до того, как в компании начерчена оргструктура и целеполагание.
Мы умеем работаем «снизу», анализируя все, что происходит в продукте. Кейсы часто повторяются, но мы стараемся подбирать индивидуальные решения, оптимальные под конкретную бизнес-линию, в рамках рекомендуемых практик, а не копируя в лоб опыт из соседнего отдела.
Деливери-менеджмент — это не только про то, чтобы разово по запросу сверху что-то изменить. Это про то, чтобы эволюционно развивать команды и достигать максимальную business agility, которую мы можем себе позволить
Деливери-менеджер — полноценная профессия, у нас есть матрица грейдов, есть стандарты собеседования и онбординга, общий тулинг, который мы используем для визуализации, метрик и планирования.
Есть комьюнити, в котором мы обмениваемся опытом. И есть институт профессии, который помогает сотрудникам и руководителям с тем, чтобы деливери-менеджерам было комфортно работать и они приносили максимум пользы.
В заключение
Культура компании очень важна: инвестируя в нее, можно сэкономить усилия на проведении изменений и количество людей, которые понадобятся для этого.
Чем больше продукт и чем больше запрос на проведение изменений, тем оправданнее будет поддержка команде, но можно обойтись и без нее. Руководителю важно понимать, с какого момента эта поддержка становится действительно необходимой (вспоминаем Данбара). И при поиске этого момента важно смотреть на максимально большой продукт, максимально широкую область взаимодействия, чтобы не получилось так, что вы оптимизируете какой-то небольшой кусочек, а весь большой value-стрим от этого не получает видимого результата.
Как показывает практика, изменения не обязательно проводить top-down, не обязательно должен быть топ-менеджер, который их пропушивает. Начинайте с уровня, на котором есть запрос и на котором есть энергия для проведения изменений. Там, где у людей горят глаза и чешутся руки. Получив видимые результаты на этом уровне, вы сможете масштабировать их вверх или вниз по value-стриму.
Сейчас сообщество деливери-менеджеров у нас растет и развивается. Есть база знаний, где можно узнать, как стать ДМ и какие навыки стоит развивать. Еще есть пара телеграм-каналов — в одном рассказываем о жизни ИТ-команды и публикуем вакансии в формате дайджеста, в другом — коммьюнити ДМ. А в сентябре стартовала наша первая финтех-школа, где можно обучиться профессии деливери-менеджера. Заходите, мы будем вам рады!
Если интересно послушать доклад, по которому сделана расшифровка этой статьи - ловите запись на ютубе с митапа IT's Tinkoff Process Improvement.