Эволюция процессов в фронтовых командах привлечения Tinkoff

Процессы разработки ПО— это основые бизнес-процессы в it’шных компаниях, которые должны наносить непоправимую пользу клиентам. В этих процессах задействована большая часть сотрудников, которые исполняют различные роли, зависящие от принятых в компании подходов к организации труда it’шников. Учитывая важность этого вопроса, возникает вопрос “Почему так часто эти процессы кардинально отличаются от тех идеальных процессов, которые зачастую есть в наших представлениях?”. В этой статье я попробую ответить на этот вопрос, вооружившись своим опытом и рассказав про эволюцию в менеджменте фронтовых команд Tinkoff за последние 3 года.

Контекст

Сначала я задам контекст и расскажу про то, что такое Привлечение Tinkoff и за что отвечают наши фронтовые команды. Привлечение — это такое управление в нашей компании, которое помогает всем нашим бизнесовым линиям и обеспечивает беспрерывный поток новых клиентов на все продукты компании от Tinkoff Black до Tinkoff Travel:)

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

Этап 0

Схема работы нашей команды фронтов выглядела следующим образом

Схема “тимлид один — а заказчиков много”
  • teamlead — лидер команды разработки. В этой конфигурации в единственном числе, т.к. всего одна команда
  • team members — члены команды разработки aka разработчики и тестировщки
  • размер технической команды 4 человека

Этап 1

На первом этапе мы добавили еще одну роль project manager’а. Человек, исполняющий эту роль, выступал в качестве умного “роутера” запросов, т.е. его роль была в том, чтобы валидировать входящие запросы от Customer’ов на структурированность и достаточность постановок, а также управлять относительными приоритетами. Кроме этого он помог в коммуникациях со связанными техническими отделами (эксплуатации, тестирования, …).
В итоге, это изменение сняло поток бизнесовых запросов с команды разработки, что повысило эффективность системы.

Схема “проджект в качестве умного роутера запросов”
  • ни одна роль не исчезла
  • размер технической команды 5 человек

Этап 2

По мере роста наша команда разработки увеличивалась и увеличивалось количество фич, которые генерировали заказчики. В итоге, главный заказчик выступил в роли head of product, объединив под собой product manager’ов, которые стали отвечать за отдельные направления (банк для физлиц, страховая, банк для юрлиц, виртуальный оператор и т.д.). В свете этих изменений мы решили попробовать модель Spotify teams версии 2014 года (подробнее смотри 1, 2)

Гонимся за spotify team (версии 2014 года)
  • исчезла роль project manager’а
  • размер технической команды 10 человек (2 команды)

Этап 3

Spotify teams оказалось интересной моделью, но годной далеко не для всех:) В нашем случае часть новоиспеченных product manager’ов были готовы наполнять беклог, но не плотно работать с командой разработки. Им оказались нужны process managers, которые возьмут на себя вопросы доведения фичей до готовности и финальных релизов. Так у нас появились процессные менеджеры, которых я благоразумно назвал релиз-менеджерами. Хотя изначально команды работали по скраму и эти люди частично исполняли еще и роль скрам-мастеров.

Схема с выделенными процессными менеджерами (преимущественно скрам)
  • ни одна роль не исчезла
  • размер технической команды 20 человек (4 команды)

Этап 4

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

Схема с выделенными процессными менеджерами (преимущественно kanban)
  • ни одна роль не исчезла
  • размер технической команды 35 человек (7 команд)

Этап 5

На четрветом этапе было все хорошо и мы успешно справлялись с продуктовыми задачами. Это делали отдельные команды, которым задачи поставлялись продуктовыми менеджерами. В каждой такой команде есть teamlead, которому помогает с техническими сложностями его технический руководитель (head of teamleads), а также с процессами process manager, но … чего-то все-таки не хватает. Все дело в том, что в нашем случае все команды сидят на одном стеке и используют плюс-минус один инструментарий (конструктор форм, конструктор страниц, блоки страниц, библиотеки трекинга, работы с внешними api и т.д.)

Схема с выделенным техническим менеджером на core команду
  • на этом шаге я рассказал про techlead’ов, которые были и раньше и отвечали за развитие наших инструментов, но отчасти децентрализованно
  • ни одна роль не исчезла
  • размер технической команды 55 человек (больше 10 команд)

Выводы

Я обещал в самом начале ответить на вопрос “Почему так часто эти процессы кардинально отличаются от тех идеальных процессов?” и мой ответ в том, что

  • даже если вы считаете, что добились оптимума, то не стоит обольщаться — скорее всего, в нашем сумасшедшем мире это ненадолго и как сказала Черная Королева устами Льюиса Кэрола
  • процессы в командах точно будут разными если у вас всего 5, 15, 50 или 150 человек — это не плохо и не хорошо, это просто есть. И с этим вам придется работать:)

P.S.

Я уже рассказывал о росте наших фронтовых команд, соответствующем изменении процессов, а также изменении роли тимлида в них на прошлогоднем Teamlead Conf в Питере. Ниже добавил ссылку на этот доклад

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.