Продолжаем тему масштабирования организаций и сегодня поговори | xpinjection

Продолжаем тему масштабирования организаций и сегодня поговорим о платформенных командах. Это популярное название, которое дают выделенной команде, занимающейся разработкой единой платформы или ядра продукта. Очевидно, что эта команда является компонентной и очень редко может реализовывать end-to-end ценность в одном из потоков. Обычно она делает что-то для других команд. В результате, для данной команды актуальны стандартные проблемы компонентных команд. Когда же это оправдано?

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

2. Создание API платформы поверх существующих legacy систем. В этом случае очень важно централизованное видение, стандарты и практики. Команде важно работать сфокусировано с очень тесной коммуникацией.

3. Поддержка одной из сложных legacy систем. Многие legacy системы разработаны в очень специфичном технологическом стеке и требуют узких доменных знаний. Например, огромная core banking system на Cobol.

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

1. Минимизировать количество таких команд в организации. Тогда будет проще упорядочить ее работу и построить подходящий процесс разработки.

2. Команда должна иметь стратегическую цель максимально перейти на self-service модель работы с другими командами. Это значит, что продуктовые команды должны иметь возможность большую часть типовых задач решать самостоятельно по проработанным и детально описанным подходам. Принцип internal open source в действии.

3. Важно выбрать подходящий процесс разработки в зависимости от специфики команды и решаемых задач. Если задачи от продуктовых команд обычно небольшие и разнородные, то может лучше подойти Kanban. Если нужна сфокусированная среднесрочная работа, то лучше может подойти Scrum. Причём, желательно присоединяться на время работы к продуктовым командам для многокомандной работы над единой целью.

4. Нужно четко определиться с подходом для управления приоритетами. Для этого должен быть строго один принимающий решения человек. Сложно назвать его полноценным Product Owner в данном случае, так как компонентная команда не делает продукт, но чаще всего выделяют именно эту роль.

5. Если большая часть задач этой командой делается для определенной продуктовой команды, то можно присоединить ее туда. Это поможет интегрироваться плотнее в бизнес цели и приоритеты, а также избежать дублирования командных функций и ролей как people management, ScrumMaster, HR, поддержка и т.д.

Компонентные команды явно не идеальны, но имеют место быть во многих контекстах. Ведь теория и реальная жизнь всегда расходятся. :)

#менеджмент #масштабирование #разработка