«Процесс разработки больших программных систем чрезвычайно сложен и непредсказуем. Программные проекты часто прерываются, выходят за рамки сроков и бюджета или приводят к некачественным результатам, отделяя технологию программирования от установившихся инженерных дисциплин» [1].

Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.

Именно скорость поставки ценности я заявляю в этой статье как критерий оптимизации производства. Другими словами, я руководствуюсь следующим принципом: если производство поставляет ценность быстро – оно эффективно. Если медленно – оно неэффективно.

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

Дополнительно к этому я хочу однозначной интерпретации слова «эффективность». Под эффективностью я имею в виду effectiveness, не путать с efficiency [2]. 

Говоря о ценности, я, пожалуй, займу позицию, подразумевающую перекладывание ответственности. Находясь в позиции руководителя производства, я не хочу решать, какая тема важнее для бизнеса. Этим занимается CEO. Или назначенный им Владелец продукта (Product Owner, PO). Я же буду исходить из того, что очередь входящих тем упорядочена по ценности, и самый первый элемент этой очереди несёт самую высокую ценность бизнесу. Разумеется, я не снимаю с себя ответственности предлагать Владельцу продукта темы, которые считаю важными, например, с точки зрения технического совершенства, быстродействия, отказоустойчивости и так далее.

Исследуя скорость поставки ценности, было бы наивно отрицать задержки, связанные с проявлением возникающих при разработке ПО технических рисков. Кони Бюрер умный дядька, и в откровенной ереси его обвинить никак нельзя. Но проблемы программной инженерии — это далеко не главное, что встаёт на пути в рамках реализации моей ответственности. И не только моей – я вижу, что происходит в индустрии в целом – то же самое. А именно:

• команды медленны, так как люди делают не то, что действительно важно

• производство (множество команд) в целом медленно, так как команды делают не то, что действительно важно. Сюда же стоит отнести ситуации, когда одна команда сделала свою часть действительно важной работы, а затем ждёт результатов другой команды, потому что у той есть дела поважнее

Важно заметить, что команды — это не только инженеры. Это могут быть юристы, службы информационной безопасности, отвечающий за контракты менеджмент… IT-проекты в бизнесе редко могут быть доставлены клиентам только за счёт инженеров. Однако не поймите меня превратно – все обозначенные проблемы актуальны и внутри IT-производства. Внешние по отношению к IT-производству участники усугубляют проблемы, но не являются единственным их источником.

А бывает ли по-другому? Бывает ли так, что команда бежит, бежит в нужную сторону и никого не ждёт? Конечно, бывает. Но редко. В моей практике было несколько раз. И эти «Конечно, бывает. Но редко» в равной мере справедливы как для финтеха, так и в целом для IT-индустрии.  

Разумеется, если такое бывает, если мы в принципе можем-умеем-практикуем выпускать быстро, выпускать нужное и при этом никого не ждать по дороге, то почему мы не делаем так всегда? Попробуем разобраться.

Скорость команды

Для измерения скорости (как командной, так и производства в целом) я буду использовать такую метрику, как время цикла (Cycle Time, CT). Это время нахождения элемента бэклога продукта (Product Backlog Item, PBI) в производстве. Время, за которое PBI прошёл весь путь от проработки требований до поставки клиенту.

Определим время цикла как

Где:

ST – это время обслуживания (Service Time), то есть время, когда над задачей работают: пишут требования, код, тесты, проводят ручное тестирование, готовят сценарии развёртывания.

QT – это время ожидания в очередях (Queue Time). PBI может ждать в очереди в следующих ситуациях:

• постановка, ожидающая спецификаций требований;

• подробные спецификации требований, ожидающие проектирования;

• проектные документы, ожидающие разработки;

• код, ожидающий тестирования;

• код, ожидающий интеграции.

Это далеко не все очереди, но я акцентирую свое внимание на этих, так как их влияние на QT и на CT существенно.

Почему PBI ждёт? Очевидно потому, что в команде, в моменте, нет свободных ресурсов, чтобы написать требования/код/тесты и так далее. А у тех, кто свободен, нет компетенций.  

Да, IT-индустрия придумала кросс-функциональные команды. То есть команды, которые включают все компетенции, необходимые для поставки ценности конечному пользователю. Но проблема в том, что в разных PBI объём работ на разных компонентах различен – где-то перекос в back-end, где-то в iOS, где-то в Android. В результате даже в кросс-функциональных командах «бутылочное горлышко» [3] гуляет от одной компетенции к другой. И менеджеры (люди, отвечающие за организацию производства) рады бы применить всю мощь теории ограничений, чтобы решительно перестроить производство, но в условиях постоянно меняющегося компонентного состава PBI это бесперспективно.

В компонентных командах все ещё хуже – для многокомпонентных PBI они ничего, кроме незавершённого производства (то есть потерь, с точки зрения бережливого производства [4]), не производят. Однако в защиту компонентных команд надо сказать, что они прекрасно себя проявляют на PBI, содержащих работы на каком-то одном компоненте. И хотя такие PBI – это частный случай, о нём стоило упомянуть.

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

Вернёмся к кросс-функциональным командам и применим такой инструмент, как диаграмма причинно-следственной связи (Causal Loop Diagram, CLD [5][6]). Я допускаю, что не все читатели могут быть знакомы с инструментом CLD, и дополнительно к приведённым источникам позволю себе процитировать определение.

Диаграмма причинно-следственной связи (CLD) – это схема, которая помогает визуализировать взаимосвязь различных переменных в системе. Схема состоит из набора узлов и рёбер. Узлы представляют собой переменные, а рёбра – это связи, которые представляют отношение между двумя переменными. Ребро без какой-либо метки указывает на положительную связь, а ребро с меткой О (opposite) указывает на отрицательную связь. Положительная причинно-следственная связь означает, что узлы изменяются в одном направлении, т.е. если узел, в котором начинается связь, уменьшается, другой узел также уменьшается. Точно так же, если узел, в котором начинается ссылка, увеличивается, другой узел также увеличивается. Отрицательная причинная связь означает, что два узла изменяются в противоположных направлениях, то есть, если узел, в котором начинается связь, увеличивается, другой узел уменьшается, и наоборот.

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

Замкнутые циклы на диаграмме – очень важные особенности CLD. Замкнутый цикл определяется как усиливающий (reinforcing, R) или балансирующий (balancing, B) контур обратной связи. Усиливающий цикл – это цикл, в котором эффект изменения любой переменной распространяется по циклу и возвращается к переменной, усиливая начальное отклонение, т.е., если переменная увеличивается в усиливающем цикле, эффект в течение цикла вернёт увеличение переменной, и наоборот. Уравновешивающий цикл – это цикл, в котором эффект изменения любой переменной распространяется по циклу и возвращает переменной отклонение, противоположное начальному, т.е., если переменная увеличивается в уравновешивающем цикле, эффект через цикл вернёт уменьшение к той же переменной, и наоборот.

Для наглядности я буду выделять на диаграммах усиливающие циклы меткой R, балансирующие циклы меткой B, а связи, образующие эти циклы, выделять цветом. Кроме того, если одна связь участвует в нескольких циклах, я буду рисовать несколько аналогичных связей, выделяя их разными цветами [6].

Визуализируем на CLD, как активности людей внутри кросс-функциональной команды могут сократить QT

Эту CLD следует читать следующим образом:

1. Чем больше у члена команды желание помочь коллеге в смежной компетенции, тем со временем у него больше возможности помочь коллеге в смежной компетенции.

2. Чем больше у члена команды возможности помочь коллеге в смежной компетенции, тем меньше очереди.

3. Чем меньше очереди, тем меньше время в очередях.

Вывод очевиден – чем больше у людей желания помогать коллегам в смежных компетенциях, тем мы быстрее выпускаем. Но желание – дело такое, непостоянное. И желания инженеров определяются не только любовью к своей компании и к своему продукту, но и рынком труда. А рынок труда можно описать вот такой CLD.

Эту CLD следует читать следующим образом:

1. Чем больше возможностей продать на рынке труда узкоспециализированные Hard Skills, тем выше у сотрудника мотивация на развитие узкоспециализированных Hard Skills в своей родной платформе.

2. Чем выше у сотрудника мотивация на развитие узкоспециализированных Hard Skills в своей родной платформе, тем больше времени он на это тратит.

3. Чем больше времени сотрудник тратит на развитие узкоспециализированных Hard Skills в своей родной платформе, тем со временем выше уровень его Hard Skills в этой платформе.

4. Чем выше уровень Hard Skills сотрудника в его родной платформе, тем выше его рыночная стоимость и тем больше у него возможностей выгодно продать свои способности на рынке труда.

Всё бы ничего, только мы имеем тут усиливающий цикл [5]. А если совместить эту CLD и CLD про сокращение QT, то картина довольно неприятная.

Мотивация на развитие узкоспециализированных Hard Skills в своей родной платформе растёт в усиливающем цикле и обратно влияет на желание помочь коллеге в смежной компетенции. Другими словами – текущее состояние рынка труда направлено на рост времени ожидания в очередях. Звучит дико, но пока в системе не будет найден баланс, ситуация не будет кардинально улучшаться. Нужно что-то, что в усиливающем цикле компенсирует запрос рынка. Например – выстраивать систему мотивации вокруг концепции T-Shape [7] или помещать мотивацию в обратную зависимость от времени цикла. Необязательно доходную – подойдёт всё, что позитивно скажется на удовлетворённости сотрудников.

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

Скорость производства

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

Принимая по внимание тот факт, что в Agile-методологиях предполагается, что команда – это 7 +- 2 инженера, как только размер вашей команды стал равен 9, вы должны планировать разделение команды на две. Это обусловлено количеством коммуникаций внутри команды, которую можно представить как полный граф [8], вершинам которого соответствуют инженеры, а рёбрам – коммуникации между инженерами. Первая ценность Agile-манифеста [9] учит нас тому, что «люди и их взаимодействие важнее, чем процессы и инструменты». Один из принципов Agile учит нас тому, что «непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Собственно, опираясь на эти тезисы Agile-манифеста, я и строю свои рассуждения. Итак, вы доросли до 10 инженеров на своём производстве. И поделили производство на две команды. В этом случае вы можете попасть в ситуацию, когда каждая из команд невероятно быстрая, но скорость производства в целом находится в районе дна Марианской впадины. Почему такое возможно? Чтобы разобраться с этим, давайте рассмотрим существующие модели масштабирования.

Модель с одним бэклогом продукта

В этой модели масштабирования мы создаём новые команды, но оставляем один бэклог продукта (Product Backlog, PBL). Подавляющее большинство команд в такой модели предполагают кросс-функциональность и способны брать в работу любой PBI. Да, мы получаем ворох проблем, связанных с обучением команд работать вместе над одним PBI и с инженерными практиками, но у нас одна входящая очередь, сквозной приоритет и мы разбираем PBI в порядке убывания приоритетов. Один PBL гарантирует, что производство занято работой над самым ценным.

Что касается обозначенных выше проблем, связанных с обучением команд умению работать вместе над одним PBI и с инженерными практиками, то влияние многих из них можно нивелировать за счёт применения шаблонов межкомандного взаимодействия [10].

Модель с множеством бэклогов продукта

В этой модели мы делаем буквальный copy-paste производства с одной командой. Мы наращиваем количество команд, но мы наращиваем и количество PBL. В индустрии на сегодняшний день превалирует именно этот сценарий, который проявляется в двух вариантах:

• команды масштабируются по областям разработки (например, по платформам);

• команды масштабируются по областям бизнеса.

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

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

Выглядит это примерно так:

Отец сказал сыновьям (пусть для простоты их будет четверо): «Идите на все четыре стороны и принесите мне золото. Чем больше – тем лучше».
Первый пошёл на север и дошёл до Северного Ледовитого океана. Сидит, строит лодку, чтоб океан переплыть. Шлёт отцу голубей с записками, чтобы еды прислал.  
Второй пошёл на восток и уткнулся в непроходимые леса. Сидит, мастерит пилу и топор из подручных материалов. Шлёт отцу голубей с записками, чтобы еды прислал. Третий пошёл на запад и наткнулся на варваров. Бьётся с ними не на жизнь, а на смерть. В перерывах шлёт отцу голубей с записками, чтобы поесть прислал и подмогу. Четвёртый пошёл на юг и нашёл золото. Да так много, что не унести. Таскает по слитку в неделю, и видит, что работы ему ещё на годы.

Ну вы поняли… Выглядит дико. Как и всё в copy-paste модели. Сыновья эти, если вернуться к теме статьи, – менеджеры очередей, которые часто называют себя Product Owner, по сути не являясь таковыми. Ответ на вопрос о том, что ими движет, я предлагаю поискать читателю самостоятельно.

Всем тем, у кого сейчас подгорело, я рекомендую познакомиться с концепцией Фокуса на продукте в целом (Whole Product Focus) [11], в которой сухо объясняется, почему бэклог команды — это очень спорная концепция. После этого обратиться к рисунку 5 и посчитать вероятность попадания первого PBI любого из трёх левых бэклогов в первые три PBI правого бэклога.  Рисунок 5 позаимствован в [12].

Графически проблему поставки не самого ценного можно показать на примере трёх бэклогов для трёх команд, поделённых по областям бизнеса и общего PBL, в которой PBI упорядочены по приоритету в глобальном смысле.

Очевидно, что чем больше бэклогов, тем меньше вероятность того, что производство занято действительно ценным. То же самое на языке CLD выглядит вот так:

Возможно, связь между узлами «Количество задач в работе» и «Cycle Time» покажется контринтуитивной. Однако теория массового обслуживания объясняет, почему данная связь верна [13].

Да, знаю, ситуации бывают разные. Есть и такие, когда мы осознанно делаем не самое ценное в некоторые моменты. Но должны быть правила, по которым мы так поступаем. И правила эти должен написать или провалидировать тот, кто владеет глобальным PBL.

Когда вас очень много

Модель с одним PBL имеет ограничение, обусловленное всё теми же тезисами Agile-манифеста. Тезисами про важность коммуникации. Когда в модели с одним PBL производство достигает уровня в 7–9 команд (примерно 50–70  инженеров), начинаются сложности с координацией – так же, как и в случае с коммуникацией между людьми внутри одной команды, коммуникация между командами проистекает в рамках модели полного графа – все общаются со всеми.

Для уменьшения количества коммуникаций применяется разделение производства на бизнес-домены или области требований [14], или трайбы [15]. Разделение по доменам можно проводить, руководствуясь такими критериями, как например:

• Рынок сбыта (например: Россия, Европа, Северная Америка и т.д.).

• Тип клиента (например: B2B2C или B2C или B2B).

• Тип услуги (например: POS-кредит, автокредит, ипотека и т.д).

В системе денежных переводов Золотая Корона, в производство которой, на сегодняшний день, вовлечено около 40 команд, мы явно выделили следующие области требований: «Займы», «B2B Денежные переводы РФ-СНГ», «B2B Денежные переводы EU», «B2B2C Денежные переводы», «Электронные платежные средства». При этом, если рассматривать продукт как сервис денежных переводов целом, то очевидно, что темы всех бизнес-доменов формируют единый PBL. Однако, введя области требований, мы ввели несколько бэклогов (применив модель copy-paste на уровне кластеров команд). А увеличение числа бэклогов, как указано выше, негативно сказывается на потоке поставляемой ценности. Чтобы нивелировать этот негатив, мы вынуждены вводить в систему производства инъекции [16]. Как минимум четыре:

1. Ограничивать количество бэклогов путём максимально широкого определения продукта (то есть применять принцип Whole Product Focus).

2. Создавать условия (мотивацию, если угодно) для помощи тем областям требований, где нужнее с точки зрения максимизации ценности.

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

4. Принимать меры по синхронизации приоритетных PBI из разных PBL, в случае невозможности – уменьшить количество PBL.

Как это выглядит на CLD:

Все инъекции, кроме первой, являются организационными дисфункциями [17], но масштаб не оставляет нам выбора. Первая инъекция – Whole Product Focus – формирует усиливающий цикл R3 с позитивным влиянием на скорость поставки ценности. Она является наиболее существенной.

Выходя за рамки производства

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

Иногда на смежников нисходит просветление, и они начитают помогать «вашему» подразделению. Тогда, о чудо, вы выпускаете проект так быстро, что потом ещё пару лет рассказываете на конференциях о том, как круто у вас в компании всё организовано. Однако начинается следующий проект, и ментальная карта в ваших головах снова становится похожа на приведённую выше картинку.

Я думаю, уже ни для кого не секрет, что происходит – в полный рост проявляет себя история с несколькими независимыми PBL. Причём в половине этих PBL той темы, которая самая приоритетная у «вашего» подразделения, просто нет. И, разумеется, смежные подразделения вовсе не лентяи. Просто люди, отвечающие за PBL, управляют подразделениями путём концентрации усилий на достижении локальной эффективности [16]. Это касается всех в равной степени – и смежников, и «вашего» подразделения.

В итоге мы вынуждены либо онбордить в своё производство нужные компетенции (юристов, безопасников, маркетинг и так далее), то есть ограничивать количество бэклогов, либо с некоторой периодичностью синхронизовать бэклоги разных подразделений. При этом решение относительно необходимости онбординга и, если таковое отвергнуто, то синхронизация бэклогов, возможно только на C-уровне (в идеале на уровне CEO). Однако, когда синхронизация состоялась, дальнейшая координация может и должна осуществляться на уровне лидирующей команды [10].

Вместо заключения

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

1. Команды медленны, так как люди делают не то, что действительно важно.

2. Производство (множество команд) в целом медленно, так как команды делают не то, что действительно важно.

И задавался вопросом – бывает ли по-другому? Бывает ли так, что команда (и производство) бежит в нужную сторону и никого не ждёт? Такое бывает. Нам удавалось быстро запускать большие интеграционные проекты. Благодаря стечению следующих обстоятельств:

• люди были замотивированы помогать друг другу внутри команд (Whole Product Focus);

• для всех участников проекта был одинаковый приоритет (Whole Product Focus);

• была хорошо сыграна роль лидирующей команды (Coordination & Integration patterns).

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

Список литературы

1. От ремесла к науке: поиск основных принципов разработки ПО.

2. Ichak Kalderon Adizes, On Effectiveness and Efficiency and Their Repercussions.

3. Элияху Голдратт, Джефф Кокс. Цель. Процесс непрерывного совершенствования

4. Масааки Имаи.  Гемба кайдзен: Путь к снижению затрат и повышению качества

5. Донелла Медоуз, Азбука системного мышления

6. Схема причинно-следственной связи - Causal loop diagram.

7. T-shaped skills.

8. Полный граф - Complete graph.

9. Agile-манифест.

10. Coordination & Integration.

11. Whole Product Focus.

12. У вас “Chief Product Owner” и Copy Paste Scrum.

13. Queueing Theory.

14. Requirement Areas.

15. Масштабирование Agile в Spotify.

16. Элияху Голдратт. Цель-2. Дело не в везении

17. Podlodka #132 —Дисфункции организаций.