54. Проблемы синхронных процессов

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

Итерации

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

У итераций есть определенные проблемы. Они плохо работают в условиях непредсказуемости окружающей среды (чуваки, срочно надо вот эту стори сделать для Siemens, бросайте все и переключайтесь на нее). Они плохо справляются со сложными задачами, требующими глубокого исследования. Они стремятся превратиться в мини-водопад с прудиком и тиной. Они выматывают команду своей монотонностью. Все эти проблемы можно попытаться решить, но процесс становится сложнее. К примеру, для срочных задач можно ввести дежурство. Глубокое исследование оформлять как юзер стори в одной итерации. Водопад можно взорвать динамитом кросс-функциональных команд и жесткой дисциплиной. Монотонность можно разбивать творческими паузами без особого фокуса и цели.

У итераций есть несомненные плюсы. Они объединяют людей единым контекстом и дают четкий дедлайн. Как показывает практика, разработка без дедлайнов требует неимоверного внутреннего профессионализма и самоконтроля. Подавляющее большинство разработчиков нуждается во внешних ограничениях, чтобы получить хороший результат за разумное время. Иначе ребята стремятся или сделать отличный результат за неразумное время, или посредственный результат за неразумное время. В первом случае с помощью дедлайнов мы осознанно идем на приемлемый технический долг, а во втором — минимизируем издержки от неверных решений (все равно переделывать придется, так лучше уж понять это пораньше).

Мета-итерации

Можно сказать, что итерации более-менее работают на уровне отдельной команды. Что сделали создатели SAFe? Они взяли концепцию итераций и распространили ее на десятки команд и сотни человек. Эта мета-итерация называется Program Increment, ее планирование занимает два дня и в нем участвует около 150 человек. Фишка в том, что все команды внутри этой мета-итерации должны работать синхронно по своим итерациям. Например, у нас есть 12 команд, значит все эти 12 команд начинают итерацию в среду, и заканчивают во вторник через 2 недели.

Зачем все это надо? Общий Program Increment (PI) дает командам шанс обнаружить зависимости между своей работой, обсудить их и скорректировать планы. Это на самом деле очень полезная практика. Часто зависимости становятся видны слишком поздно и с ними сложно что-то сделать. Все заняты, и отвлечь, скажем, команду ядра для помощи команде внедрения может просто не получиться в разумные сроки. В результате либо работа команды внедрения ставится на паузу (а паузы в разработке фич очень вредны), либо команда ядра отвлекается и ставит свою фичу на паузу (а паузы в разработке фич очень вредны). Планирование PI может заранее выявить такие проблемы, и команда ядра подстроит свои планы под команду внедрения.

Вторая цель — общий контекст. На все эти 12 команд сверху спускается набор бизнес-задач и фич. Команды разбирают фичи, обсуждают детали реализации и более-менее понимают, зачем все это надо.

Кажется, вполне себе благородные цели. И это на самом деле так. Но не слишком ли много усилий тратиться на их достижение? По моим подсчетам, в SAFe люди тратят на собрания около 20% рабочего времени. Синхронизация — очень дорогое удовольствие и источник очередей. Можно ли решить проблемы единого контекста и зависимостей через just in time взаимодействие?

Управление зависимостями

Ответ положительный. Но для реализации нужны более глубокие структурные изменения, чем просто набор одинаковых команд. Управление зависимостями — очень сложная область в любой организации, поэтому в первую очередь это должно решаться структурой самой организации. Худший вариант, когда у вас 12 равнозначных команд и зависимости могут быть между любыми командами. Это ад. Идеальный вариант, когда зависимостей между командами нет вообще. Это рай. У меня есть несколько рецептов по пути в рай:

• Кросс-функциональные команды. У вас вообще нет шансов убрать зависимости в функциональных командах (by design).
• Юниты-слои, задающие направление зависимостей. Например, вы можете создать юнит, который занимается платформой (P), и юнит, который занимается реализацией функциональных требований (F). В каждом юните несколько кросс-функциональных команд. Тогда зависимости почти всегда будут возникать в одну стороны, F зависят от P (и никогда наоборот). Также вы можете свести к минимуму зависимости между командами в F.
• Согласование планов юнита F с юнитом P. За 1–2 месяца до начала какой-то фичи в юните F, об этом надо дать знать P. Тогда они успеют подстроить свои планы под функциональные требования. Проблема зависимостей будет обнаружена тогда, когда надо, и решена just it time.

Каждый кружок — отдельная команда. Стрелочки — зависимости между задачами команд.

Такой подход гораздо менее затратен с точки зрения собраний и (вероятнее всего) ничуть не менее эффективен. Важна сама идея — минимизация зависимостей через структуру организации.

Общий бизнес-контекст

Вторая проблема — создание общего контекста. Нужны ли нам синхронизации целей каждые 3 месяца? Очевидно, можно обойтись без этого. Задача руководства — все время генерировать электромагнитное поле, которе будет направлять заряженные частицы-команды. Это поле нельзя включать на пару дней раз в 3 месяца, оно должно включаться гораздо чаще через публичные посты, беседы и открытые дискуссии, ежемесячные собрания на часик-другой. Создание общего контекста — непрерывный процесс.

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

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

Фундаментальная ремарка вместо логичного окончания

Синхронные процессы может быть проще создавать и поддерживать, но их производительность будет ниже, чем у асинхронных процессов. Спросите у программистов.