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

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

Контекст

Для того, чтобы привлечение работало эффективно у вас должны быть следующие компоненты:

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

Итак в начале был …

Этап 0

Схема “тимлид один — а заказчиков много”

В этой схеме у нас есть следующие роли:

  • customer — заказчик. Количество заказчиков в системе большое, но конечное. В случае конфликтов договариваются между собой сами по поводу относительной приоритизации своих задач
  • teamlead — лидер команды разработки. В этой конфигурации в единственном числе, т.к. всего одна команда
  • team members — члены команды разработки aka разработчики и тестировщки

Здесь бедный тимлид напрямую получает ценные указания от большого количества заказчиков:) По очевидным причинам тимлиду было сложно одновременно обрабатывать запросы заказчиков и “рулить” командой разработки.

Итого:

  • есть роли customer, teamlead, team members
  • размер технической команды 4 человека

Этап 1

Схема “проджект в качестве умного роутера запросов”

Итого:

  • добавилась роль project manager’а
  • ни одна роль не исчезла
  • размер технической команды 5 человек

Этап 2

В нашем контексте мы для отдельных продуктов пришли к схеме с отдельными командами разработки… И так у нас появилось несколько продуктовых команд, которые обрабатывали запросы отдельных продакт менеджеров. Человек, который занимал роль тимлида большой команды, стал главой тимлидов и отвечал за разделение большой команды на части, нахождение тимлидов, их онбоардинг, обучение и дальнейшую помощь в процессе работы (а заодно и был тимлидом тех команд, где еще не было найдено тимлидов).

Гонимся за spotify team (версии 2014 года)

Итого:

  • добавились роли head of product, product manager, head of teamleads
  • исчезла роль project manager’а
  • размер технической команды 10 человек (2 команды)

Этап 3

Схема с выделенными процессными менеджерами (преимущественно скрам)

Итого:

  • добавилась роль process manager’а, команды преимущественно работали по скраму
  • ни одна роль не исчезла
  • размер технической команды 20 человек (4 команды)

Этап 4

Схема с выделенными процессными менеджерами (преимущественно kanban)

Итого:

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

Этап 5

Этот инструментарий разрабатывает core-команда, которая ведет несколько технических продуктов. Этой командой руководит tech program manager. Роль этого технического руководитель программ в том, чтобы развивать наши технические продукты, которые переиспользуются в продуктовых командах. В этой конфигурации основные вопросы в том, как организовать процесс разработки общего инструментария так, чтобы продуктовые команды получали больше пользы от общего инструментария, чем вреда. Найти этот баланс это искусство.

Схема с выделенным техническим менеджером на core команду

Итого:

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

Выводы

  • идеального процесса нет — любой процесс контекстно-зависим от людей, задач, ресурсов и т.д.
  • даже если вы считаете, что добились оптимума, то не стоит обольщаться — скорее всего, в нашем сумасшедшем мире это ненадолго и как сказала Черная Королева устами Льюиса Кэрола

“ Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!”

  • чтобы осмысленно улучшать процессы вы должны понимать правила игры и стратегию в общем — и здесь я опять процитирую математика, известного как Льюис Кэрол

— Скажите, пожалуйста, куда мне отсюда идти? — сказала Алиса.— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно… — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.

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

В общем, вся ваша работа с процессами будет напоминать погоню за неуловимым …

P.S.

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.