Всем привет. Меня зовут Витя, я руководитель оптимизации процессов разработки и лидер профессии деливери-менеджеров. 

Мы в Тинькофф исторически растем большими темпами — рост команд часто превышал 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-стриму.

Сейчас сообщество деливери-менеджеров у нас растет и развивается. Есть база знаний, где можно узнать, как стать ДМ и какие навыки стоит развивать. Еще есть пара телеграм-каналов — в одном рассказываем о жизни ИТ-команды и публикуем вакансии в формате дайджеста, в другом — коммьюнити ДМ. А в сентябре стартовала наша первая финтех-школа, где можно обучиться профессии деливери-менеджера. Заходите, мы будем вам рады!