Один из моих проектов проходит активную фазу роста, из команды в 3 человека мы выросли в 2 команды по 9 человек. За 6 месяцев мы набили достаточно шишек и вот этим опытом я и хочу поделиться.

Краткая предыстория

Мы начали с дискавери фазы: аналитик, архитектор и ваш покорный слуга. Затем добавили 3 разработчиков и еще одного технического консультанта. Затем добавили еще аналитика и еще одного разработчика. Паралельно с этим, мы добавили в проект команду со стороны клиента. Плюс, с нами работает команда тестировщиков-консультантов и один разработчик от другого юнита тоже со стороны клиента. Цели, задачи, процессы, атмосфера и культура у всех разная, но бизнес стейкхолдеры – одни. И гордые лычки project manager ношу только я и мой визави со стороны клиента. Так что мы на двоих выгребаем все происходящее.

— И сколько же у тебя людей-то в подчинении?
— Почти 3 тысячи.
— Батюшки! Как же ты с ними справляешься? Трудно, небось?
— Трудно с тремя, а когда трёх научишься организовывать, дальше число уже не имеет значения.

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

Если очень кратко сформулировать вывод, что меняется при скейле, то я напишу:

А вот про детали и что делать, я и хочу поговорить.

Коммуникация

Мы все работаем распределенно. Разработчики одной команды сидят в другой локации, со мной рядом только аналитики и еще один разработчик. Вторая команда работает тоже порознь. Третья команда на стороне клиента также распределена. Ремоут создает свои трудности, но с ними можно жить, хоть мы и страдаем от skype for business.
Но вот возросшее кол-во цепочек коммуникации для банальной синхронизации, кол-во новых ивентов в календаре, кол-во синхронной и ассинхронной коммуникации, вот оно действительно стало мешать и замедлять процесс разработки. Историю скейла можно проиллюстрировать следющей последовательностью графиков:

Buy-in

Что делать, если вы работаете над разными вещами совершенно с разных сторон, и люди не являются частью одной организации? С расширением команды я столкнулся и с ростом зависимостей. Там где раньше мы зависели от одного странного чувака, теперь у меня 4 группы лиц, которые вставляют палки в колеса. Мало того, что каждая команда внутри моего проекта привнесла такие зависимости, так они привнесли интерзависимости!

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

Функциональщина

Лонг стори шорт, мы пришли к функциональной структуре. Хотя на бумаге и в отчетах у нас конечно же скрамбан. Но команды имеют ограниченную функциональную ориентацию с рядом блокирующих друг-друга зависимостей. Это появилось не от хорошей жизни, а потому что бизнесу надо срочно и мы брали готовые команды, которые занимались другими задачами и ставили их на горячее направление. Более того, сама орг.структура клиента выстроена по определенному функциональному типу.

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

Что можно сделать?

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

Цели и что такое Хорошо

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

Какие могут быть цели? Не открою Америку, если скажу:

Предположение #1 – обеспечить стабильность совместного релиза всех 3-х команда для поставки одного пакета функционала, чтобы бизнес мог сделать end-to-end.

Предположение #2 – снизить влияние зависимостей на релиз, чтобы поставка была ну точно стабильной.

Что можно поменять?

• Оптимизировать орг-структуру и поменять местами людей, для обеспечения кросс-функциональности. Люди, работающие над одними и теми же бизнес-задачами не будут зависеть от людей с теми же задачами в других команда. Чтобы
• Убрать кол-во интерзависимостей и цепочек коммуникации между командами. Меньше пустого общения, больше фокуса на работу. Чтобы
• Синхронизировать цикл поставки. Бизнесу не нужно пушить деливери, а нужно пулить готовые задачи. Чтобы
• Бизнес имел одно окно UAT тестирования в стабильные и предсказуемые отрезки времени.

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

Приглашаю к дискуссии всех менеджеров, поделиться своим опытом скейла.