Привет, Хабр! Меня зовут Елизавета, я скрам-мастер стрима ДБО (веб-версия дистанционного банковского обслуживания) для банков в команде РСХБ.Цифра. Выстраиваю процессы на основе человекоцентричного подхода, помогаю команде раскрывать потенциал. В этом материале хочу поделиться с вами историей о том, как мы превратили обычную задачу по формированию команд в приятный процесс. Да, это возможно! Расскажу не только о методиках, но и человеческих взаимоотношениях, где психология — лучший друг программистов и тимлидов, которые объединяются ради создания продукта в финтехе.

Вызов по Agile

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

Именно поэтому к командам, которые должны работать над банковским приложением, предъявлялись высокие требования. Они должны были работать с безупречной точностью — цена промаха исчислялась миллионами рублей. Система обязана функционировать без перебоев 24 часа в сутки 7 дней в неделю. Интерфейс должен быть настолько простым, чтобы разобраться в нём мог даже человек, далёкий от технологий. И ни в коем случае нельзя допускать задержек в обработке транзакций. 

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

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

Согласно рекомендациям методологии Safe (Scalable Agile Framework), оптимальная численность команды должна составлять от 4 до 7 человек, поэтому мы решили разбивать команду из 20 человек на 3. 

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

Для подбора «команды мечты» мы начали с проверенных психологических методик — модели DISC и теста «Командные роли» Р. М. Белбина. И если первая сработала как точные часы, то со второй всё оказалось куда сложнее.

Модель DISC чётко разделила команду на четыре типа. «D» (Доминирование) — это те, кто сразу берётся за решение проблемы, не боится сложных вызовов. «I» (Влияние) — настоящие зажигалки, которые заряжают всех энергией и поддерживают боевой дух. «S» (Стабильность) — надёжные опоры, методично выполняющие задачи. «C» (Соответствие) — бдительные стражи качества, замечающие малейшие недочёты. Методика дала нам чёткий ориентир для стартовой расстановки сил.

Корректируем план

Но с тестом Белбина всё пошло не по плану. Мы точно знали: в оригинальной версии методики выделяется 9 ролей. Однако, обратившись к русскоязычным источникам, обнаружили лишь 8 ролей. Что ещё хуже — смыслы оказались искажены. Пропала роль «Специалист» (Plant) — генератор нестандартных, порой кажущихся безумными идей. Смешались функции «Мотиватора» (Shaper), который подстёгивает команду, и «Координатора» (Coordinator), организующего процесс. Исчезла роль «Работник компании» (Company Worker) — невидимый клей, скрепляющий команду воедино. 

Мы как будто готовились к сложному походу с подробной картой, а затем обнаружили, что у нас в руках лишь её обрывок. Как сопоставить ожидаемую девятиролевую модель с реально доступной восьмиролевой? Как избежать потери важных аспектов командной динамики из‑за расхождений в интерпретации? Решили разобраться до конца.

Следующие недели превратились в настоящее расследование. Мы раскладывали перед собой оригинал теста Белбина и его русскоязычные адаптации, внимательно сверяя каждое описание, выискивая расхождения и пытаясь понять логику преобразований. Экспериментировали с формулировками, пытаясь адаптировать иностранные термины к российскому контексту: «Company Worker» стал «Связующим звеном», а «Plant» — «Генератором прорывов».

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

В процессе работы мы постепенно пришли к трём ключевым принципам, которые полностью изменили наше мышление.

Во‑первых, мы поняли: тест — не приговор, а лишь подсказка. Его результаты важны, но только как отправная точка для диалога. Мы начали задавать людям вопросы: «В каких ситуациях вы чувствуете максимальный драйв?», «Когда вам говорят „Ты сделал это круто!“, о чём идёт речь?». Ответы часто расходились с результатами тестов, но открывали истинные сильные стороны каждого.

Во‑вторых, мы осознали, что культурный контекст кардинально меняет правила. То, что в Британии называют «Company Worker», в России может проявляться как «Старший товарищ» или «Хранитель атмосферы». Мы перестали зацикливаться на точной терминологии и сосредоточились на сути — на том, как именно человек вносит вклад в команду.

В‑третьих, мы приняли, что идеала не существует, а настоящая сила — в синергии. Никто не вписывается идеально в одну роль. Например, программист может быть одновременно и «Аналитиком», и «Генератором идей», если дать ему пространство для проявления разных граней таланта.

Что изменилось?

Ключевым организационным изменением стало перераспределение Agile‑церемоний (дейли, уточнение бэклога, ретроспектива спринта, демо, PI-планирование, Inspect&Adapt) по командам. Раньше ежедневный дейли проводился для всех 20 человек одновременно — это снижало фокусировку и затягивало обсуждение. Теперь у каждой команды КФК (кросс-функциональной команды) есть собственный дейлик: встречи стали короче, конкретнее и эффективнее, поскольку обсуждаются только релевантные для группы задачи. Аналогичная трансформация произошла и с другими мероприятиями — планированием спринтов, ретроспективами и обзорными сессиями: каждая команда проводит их автономно, адаптируя формат под свои потребности.

 При формировании команд мы придерживались принципа сбалансированной экспертизы. В каждой группе работают по 2 бэкенд‑разработчика, при этом мы сознательно выстраиваем пары «мидл + джун». Такой подход даёт двойной эффект:

джуниор получает постоянную поддержку и возможность расти под руководством опытного коллеги;

мидл избегает дублирования функций с другим мидлом, фокусируясь на наставничестве и решении задач своего уровня. 

Каждая команда стала по‑настоящему автономной: она самостоятельно планирует работу, принимает решения и несёт ответственность за свой участок разработки.

Скорость разработки выросла на 40 % — теперь роли не дублировались, каждый знал свою зону ответственности (скорость разработки считаем по переходу фичи из одного статуса в другой в жире по waterfall).  Количество критических ошибок снизилось на 65 %, ведь каждый участник отвечал за свой фронт работ, тщательно проверяя свою часть. За полгода ни один ключевой специалист не покинул компанию. 

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

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

 Жёсткие роли — это скорее ограничение, чем помощь. Поэтому стали создавать гибкие, «дышащие» позиции, позволяя людям проявлять себя в разных амплуа. Название роли перестало быть догмой — важнее стало то, какую реальную ценность человек приносит команде. Например, «Связующее звено» звучало куда понятнее и ближе нашим сотрудникам, чем оригинальный «Работник компании».

И самое главное — мы научились праздновать различия. Поняли, что команда из 20 «идеальных исполнителей» обречена на посредственность. Настоящий прорыв возможен только там, где есть баланс: генераторы идей, которые толкают вперёд; критики, которые проверяют реальность; реализаторы, которые воплощают задуманное; хранители, которые обеспечивают стабильность.