Эффективное взаимодействие продуктовых и платформенных команд разработки или “давайте жить дружно” © Леопольд

В данной статье я попробую раскрыть свои мысли относительно совместной работы продуктовых и платформенных команд. Для того, чтобы был понятен обсуждаемый контекст, я рекомендую посмотреть предыдущую статью посвященную “эволюции процессов в фронтовых командах привлечения Tinkoff”. В упомянутой выше статье мы остновились на командной конфигурации, изображенной на рисунке 1

Рис.1 “Конфигурация с продуктовыми и платформенной командой”

В этой статье мы рассмотрем как сделать так, чтобы все они следовали заветам Леопольда aka “ребята, давайте жить дружно”. Ну поехали …

С чего начать

Как и в любой деятельность стоит начать с целевого состояния системы. В нашем случае кажется, что наша идеальная картина выглядит следующим образом:

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

Для того, чтобы жить дружно надо предотвратить конфликты, которые могут возникнуть из-за ряда причин, например

  • недопонимания
  • пересечения зон ответственности разных людей
  • провисания ответственности, когда работа должна быть сделана, а ответственный не зафиксирован

Самый простой способ — это нарисовать заинтересованных людей и прописать их мотивации, а дальше от этого плясать. В нашем случае это выглядит как-то так

Рис. 2 “Схема с 4-мя заинтересованными лицами и их интересами”

В этой схеме у нас есть 4 основные роли:

  • Chief Product Owner — главный за бизнес-продукты
  • Head of feature teams — главный за работу фичевых команд
  • Head of technical products— главный за технические продукты
  • Chief Technical Officer — главный за IT в общем

Chief Product Owner нужен поток создания фич в его продукты с достаточной скоростью и качеством. Для этого он при помощи своих product manager’ов загружает беклог фичевых команд, за эффективность которых отвечает Head of feature teams. Для того, чтобы фичевые команды могли быть эффективными им требуется набор технических инструментов, которые со своей платформенной командой развивает Head of technical products. Большая часть функциональных требований и некоторая доля нефункциональных приезжает в платформенную команду от фичевых команд в общем и от Head of feature teams в частности. В то же время Head of technical products продает и подталкивает фичевые команды к использованию новых и функциональных инструментов.

В этой схеме Chief Technical Officer стоит чуток сбоку, но и у него есть определенные требования к обоим head’ам, а именно:

  • от Head of feature teams он ждет того, чтобы процессы внутри фичевых команд были выстроены, команды укомплектованы, тимлиды обучены. Важно, чтобы у каждой такой команды был roadmap развития их продукта как бизнесовый, так и технический. Из этой дорожной карты появляется потребность в новых технических фичах от платформенной команды, ориентированных на помощь в решении бизнес задач
  • от Head of tech products он ждет, чтобы технические продукты развивались консистентно. Для этого должен быть составлен roadmap по техническим продуктам, в котором будут сбалансированы технические усилия с учетом важности и приоритета бизнес-потребностей, ради которых создаются инструменты. Также важно, чтобы были выстроены процессы разработки внутри платформенной команды, т.к. иначе эффективность ее деятельности будет не слишком высокой

Пример реализации

Давайте теперь разберем на примере взаимодействие продуктовых и core-команд привлечения Tinkoff. В данном случае мы будем рассматривать деятельность наших фронтовых команд.

Если вы бывали на сайте tinkoff.ru, то вы точно взаимодействовали с результатами работы этих команд. Например так выглядит страница одного их продуктов, которые развивают наши продуктовые команды.

Рис. 3 “Страница продукта Tinkoff Black”

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

Рис. 4 “Декомпозиция фронтового приложения на составляющие”

На приведенном выше рисунке

  • слева размещена зона ответственности продуктовой команды
  • справа — core-команды
  • а узкая полоска посередине представляет собой граничную зону
  • стрелками указаны зависимости между объектами

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

  • продуктовых форм, которые разрабатывает она же, которые в свою очередь зависят от движка форм, за развитие которого отвечает core команда
  • движка для рендера страниц и блоков, которые используются в нем как строительные блоки. Причем за развитие движка рендера страниц отвечает core-команда, а вот создавать блоки может как core-команда, так и сама продуктовая команда, если блоки нужны только им или им важно сделать их “здесь и сейчас”
  • библиотек для трекинга и аналитики — наши продуктовые заказчики трепетно относятся к собираемым данным, т.к. именно на их основе они принимают решения о развитии продуктов. Поэтому core-команда постоянно допиливает этот инструментарий, который используют продуктовые команды
  • и последним в списке, но близко к началу списка по значению, идет наш фреймворк для фронтовых приложений. Этот фреймворк позволяет легко стартануть новое приложение, а главное интегрировать туда все остальные части так, чтобы они не казались инородными частями:) За развитие фреймворка отвечает core команда

Выводы

Чтобы ваши продуктовые и core команды жили в согласии вам надо:

  • подходить к развитию инструментов, создаваемых core командой, с точки зрения продукта. А значит нам нужен сбор требований и обратной связи от пользователей, внятная приоритизация и общедостуный roadmap, высокое качество инструментов (документация, тесты, …), возможность для продуктовых команд участвовать в их развитии, …
  • продуктовые команды, для которых готовиться инструмент, должны иметь схожие потребности и профиль. В противном случае у вас не получится свести требования к инструментарию и получится что-то неудобоваримое
  • продуктовые команды должна иметь внятное планирование и бизнесовые roadmaps. В этом случае эти планы могут быть правильно учтены в дорожной карте развития технических продуктов, а не впиливаться в adhoc режиме с помощью костылей и изоленты

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

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

P.S.

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

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store