Масштабирование без кросс-функциональных команд

Перевод доклада Mike Burrows Scaling without cross-functional teams с конференции Øredev 2016 выполнен с разрешения автора.

Введение

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

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

В рассказе Майка минимум философии — максимум практичности.

Поехали!

Пример 1 — Ранний рост

В тот момент, когда Майк подключился к проекту, была одна команда — команда VBA (Visual Basic Application). Она разрабатывала настольное приложение для управления рисками на рынке бондов.

Владельцы бизнеса решили, что нужно больше разработчиков для ускорения, и была создана новая команда — Web. Часть людей перешли из команды VBA в Web, часть была нанята извне. Люди из команды VBA отлично знали предметную область, так как пришли из операционной части бизнеса. Это здорово помогало команде развивать продукт.

Роль Майка была в управлении поставкой обеих команд, официально роль называлась CTO.

Команда VBA была частично зависима от команды Web с точки зрения данных: веб-сервисы команды Web были источником данных для настольного приложения команды VBA.

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

В какой-то момент решили нанять инженера технической поддержки (Tech Support), который работал на обе команды и мог поддерживать одновременно настольное приложение и серверную часть. Команды стали разбирать только сложные запросы на поддержку, которые инженер технической поддержки не мог выполнить сам.

Ключевая проблема была в том, что релиз новых версий продукта «разрушительно» влиял на работу бизнес-процессов компании. Для исправления ситуации в команду добавили владельца продукта (Product Owner, PO) и бизнес-аналитика (Business Analyst, BA). Над командами образовалась управленческая тройка: СТО, PO и BA. Они решали, в какую команду лучше отдать задачу в зависимости от того, с какой скоростью нужно было ее сделать и как долго потом поддерживать.

Что получилось в итоге:

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

В качестве вывода можно процитировать закон Галла:

«Любая работающая сложная система развивается на базе простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире. Вам придется начать заново с простой работающей системы».

Пример 2 — Глобальный департамент

Второй пример описывает более сложную структуру, в которой работали 120 человек. Официальная картинка организационной структуры была такой:

Майк был в роли GDM (Global Delivery Manager).

В каждую региональную команду (столбики на диаграмме выше) входили:

• Бизнес-аналитик (BA) и проектный менеджер (Project Manager, PM).
• Разработчики (Dev).
• Техническая поддержка (Technical Support, TS).

Так выглядела идеальная «маркетинговая» картинка. В действительности же было несколько по другому:

• в одной локации не было команды разработки;
• в одной локации не было BA/PM;
• в двух самых больших локациях были подкоманды тестировщиков (Quality Assurance, QA);
• в одной самой большой были компонентные команды разработки (на графике ниже обозначены буквами С, то есть Component).

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

Реальная организационная структура была такой:

Поставка бизнес-ценности требовала совместной работы региональных команд (на картинке ниже обозначены буквой R, то есть Regional) и компонентных команд  (на картинке ниже обозначены буквой С). Поддержка нужна была с обеих сторон:

Также требовалось взаимодействие с технической поддержкой:

Для полноты картины рассмотрим, как выглядел процесс релизов:

Планирование, разработка, тестирование и развертывание были разнесены по итерациям.

Идея простая и заманчивая, но по факту отвратительная:

• из-за высокой стоимости синхронизации между релизами;
• из-за высокого Cycle Time задачи от 4-6 недель.

Сейчас стараются сделать все активности по разработке, тестированию и развертыванию в одной итерации.

Еще один более яркий пример высокой стоимости синхронизации — это архитектурное взаимодействие между компонентами. Так выглядела высокоуровневая архитектура банковского приложения:

Было много мелких изменений множества Front-систем и гораздо более редкие изменения нескольких Backend-систем. Синхронизация всех 3 слоев систем по релизам в такой структуре может быть настоящим адом.

Решение, которое было реализовано — это асинхронное общение между системами через подписки. Сейчас это довольно частая практика:

В итоге каждый компонент может релизиться независимо. Мы выпускали большие кросс-компонентные изменения без лишней синхронизации и иерархии в виде программных/проектных менеджеров. Все работало. Люди просто говорили между собой и делали дело.

Пример 3 — Переход от внешнего подряда к более интегрированной модели с внутренней разработкой

Забавный факт: в Великобритании большая часть Agile-коучей работает в проектах для правительства страны. Майк работал в одном из них, предметной областью которого была социальная поддержка. Это был проект в программе Government Digital Services (GDS — это аналог Госуслуги России). Мантрой людей, которые работали в проекте, была: «Начинайте с реальных потребностей. Потребностей вашего пользователя, а не правительства».

Если Вам интересно углубиться в этот подход к проектированию сервисом, вы можете прочитать эту статью.

Поток инициатив в проекте был следующим:

При беглом ознакомлении подход похож на водопад, но в действительно им не является.

Шаг 1 “Discovery” — понять, что действительно нужно людям? Как люди будут пользоваться сервисом? Есть ли у людей доступ к технологиям? Что если у них нет доступа? Что если у них ограниченные возможности?

Шаг 2 “Alpha” — быстрое прототипирование. Если не можем создать прототип в виде программного продукта, то делаем его на бумаге. Тестируем сервис с внутренними пользователями. Вырабатываем перечень функциональности для бета-версии, первой версии для внешних пользователей.

Шаг 3 “Beta” — тестирование с людьми с улицы. Итоговая цель — наладить стабильную работу сервиса. Это сложно, но это ключевой шаг для перехода дальше. Без плана по стабильности проект не мог запуститься.

Шаг 4 “Live” — система переходим в промышленную эксплуатацию, начинаются поэтапные улучшения.

Перейдем к ролям в проекте:

• Service manager — отвечает не только за доставку ПО, но и за сервис целиком (включая работу службы поддержки, внутренних обеспечивающих подразделений и прочего).
• Часто его дополняли Product Owner и Project Manager (иногда эти роли совмещались). Project Manager — удобный прокси для другой части организации (обеспечение согласований, утверждение бюджетов и прочее).
• User Research/Experience — тестирование системы с пользователями и проектирование интерфейса.
• Delivery Manager — отвечает за программную часть сервиса (поставку ПО), в этой роли был Майк.
• Название остальных ролей говорит само за себя.

Очень важно понимать, что это роли, а не отдельные люди! Не надо на каждую проблему нанимать «менеджера проблемы». Совмещайте роли, если это возможно.

Будьте осторожны: если не хотите разрыва между ожиданиями и реальностью, начинайте с тех областей, где можно получить быструю обратную связь (к примеру, мобильная и веб-разработка). Сложные внутренние системы оставьте на потом.

Финальный совет: Визуализируйте зависимости с другими командами и педантично управляйте ими. Смотрите, какие могут быть зависимости в ближайшее время, будьте проактивны в их разрешении. Не начинайте то, что не может быть завершено из-за зависимости. Возвращайте работу в бэклог и приступайте к ней снова, когда зависимость разрешилась.

Пример доски для отслеживания зависимостей:

Принципы масштабирования без кросс-функциональности команд

Люди и их навыки важнее, чем роли и организационная структура

1. Роли заставляют человека думать в рамках ограничений, акцент на роли блокирует выполнение работы, которую человек реально может сделать!
2. Организационная структура является затруднением, если люди думают только о ней. Правила коммуникаций в компаниях зачастую не требуют соблюдения иерархии. Это ограничение заложено в головах людей. Его нужно снимать.
3. Начинайте с того, что у вас есть сейчас и что реально работает.
4. Пусть реальные потребности приводят к развитию навыков и возможностей. Задайте себе вопросы: какие есть пробелы в текущей команде сейчас? Что нужно будет в будущем?

T-shaped или узкие специалисты — у вас есть место для всех

1. Если у вас 1 разработчик может взять задачу и реализовать ее на всех уровнях, проверить и выпустить ее — это очень круто!
2. Если у вас есть 1 человек может написать лучшие скрипты развертывания — это тоже круто! Доверьте это ему.
3. Помните и цените узких специалистов, их уход будет вам очень дорого стоить.

Сплоченность крайне важна

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

Частая поставка творит чудеса

1. Начните там, где можно быстро поставлять (к примеру, веб и мобильная разработка)
2. НО у вас должна быть стратегия расширения на другие части системы.

Об авторе Mike Burrows Владелец компании AgendaShift, которая фокусируется на Lean-Agile трансформациях и Agile-коучинге. Майк — автор книг о Kanban-методе.Он работал в роли GDM (Global Delivery Manager), CTO (Chief Technical Officer) в крупных проектах по разработке ПО, в том числе на правительство Великобритании.

О переводчике Константин Хохрин 15 лет в разработке программных продуктов, 10 лет в роли лидера, 7 лет в Agile. Работал в компаниях Yota, i-Free, IQ Option, нескольких стартапах.Специализируется на масштабировании Agile и OKR.Закончил физический факультет СПБГУ. Начинал свой путь разработчиком.