Как в Тинькофф появились деливери-менеджеры и чем они занимаются

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

Мы в Тинькофф исторически растем большими темпами — рост команд часто превышал 100% год к году. Но за всю более чем пятнадцатилетнюю историю у нас не было классических scrum-мастеров или agile-коучей. Расскажу, почему так получилось и как появились деливери-менеджеры в наших командах.

Как все начиналось

У нас в компании есть внутренняя культура, которая называется ДНК Тинькофф. Культура существовала с самого зарождения компании, а пару-тройку лет назад ее оцифровали и теперь она выглядит вот так:

Берем ее во внимание и переносимся в прошлое. Семь лет назад я руководил разработкой, когда появилась задача реализовать CRM на замену вендорской. Мы создали MVP и после первых успешных результатов получили благословение на масштабирование.

Сначала в команде было пять человек. Через полгода стало почти сорок. Через год мы выросли еще на 100%. И продолжали расти. Не знаю, сколько раз менялась модель управления командой, которая выросла более чем на 2000% за пару лет. Было много изменений в модели управления. Для наглядности объясню на модели Данбара.

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

Когда команда переросла цифру в 50 человек и мы перешли на 3 уровень, стало понятно, что часть команды не всегда знает, что делает другая часть. Это случалось даже в командах, создающих зависимые друг от друга фичи. На тот момент было уже 7—8 независимых команд, которые делали продукты в рамках одной CRM. У каждой команды своя цель, но при этом цели не всегда сонаправленны и было расхождение в коммуникации того, что уже есть, и того, что будет дальше.

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

На старте добавить в продукт одну условную кнопку занимало 30 минут. По мере увеличения сложности экрана и продукта каждая новая кнопка обрастала дополнительными вводными, которые нужно учесть и согласовать с ответственными. Это все нас замедляло, и задача растягивалась уже на часы или дни.

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

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

Нам взгрустнулось, потому что мы классная команда, растем, делаем все больше и больше. Но

Как среда изменений ответила новой профессией

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

Сейчас в Тинькофф около 60 деливери-менеджеров в ИТ и бизнес-линиях и еще шесть — в операционных подразделениях. Это около 1% от HQ и около 0,02% от операционки.

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

Деливери-менеджер помогает организации ускорить появление продукта или его поставку на рынок. Он делает это в условиях растущей сложности как ИТ-систем, так и продуктов, процессов и внешних ситуаций. При этом нам важно не терять в гибкости и эффективности как при масштабировании, так и при перестройке

Деливери-менеджер у нас чаще находится в IT под СТО, но есть варианты, когда он находятся ближе к бизнесу — у CPO. Этот вариант предпочтительнее, потому что дает возможность влиять на большее количество процессов. Область ответственности ДМ — это end-to-end-продукт либо, если он работает с ИТ-платформой и нельзя покрыть весь end-to-end, то те области, до которых можно дотянуться, плюс межкомандное взаимодействие там, где могут возникнуть зависимости.

У одного деливери-менеджера может быть до девяти команд с которыми он более-менее плотно работает, у лидов — больше, но с меньшей степенью погружения. Количество людей, с которыми работает деливери-менеджер, варьируется от 20 до 100 и больше. Это зависит от грейда и от сложности конкретной команды.

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

Уровень погружения тоже варьируется: на низких уровнях зрелости команд иногда требуется погружение, которое можно сравнить с погружением скрам-мастера — много day-by-day-работы в команде. На более высоких уровнях зрелости уже не команд, а продуктов и сервисов, уровень погружения может быть сравним с agile-коучами: это не внутрикомандная работа, а скорее работа по запросу от топов или сопровождение бизнес-линии — например, через задавание неудобных, каверзных вопросов для поиска стрессоров для выхода из локального максимума к дальнейшим улучшениям.

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

Если интересно послушать доклад, по которому сделана расшифровка этой статьи — ловите запись на ютубе с митапа IT’s Tinkoff Process Improvement.