Отрицательная скорость: как повысить предел сложности

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

Самым очевидным признаком того, что команда достигла предела сложности, является то, что на преодоление организационной сложности она тратит больше времени, чем на решение непростых проблем, на которых ей следует сосредоточиться. Такие показатели DORA, как время выполнения для изменений (скорость) и частота сбоев при внесении изменений (качество), показывают, замедляются команды с течением времени или ускоряются. На эти показатели влияют и другие факторы, но в целом это хороший индикатор эффективности команды.

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

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

Самым очевидным признаком того, что команда достигла предела сложности, является то, что на преодоление организационной сложности она тратит больше времени, чем на решение непростых проблем, на которых ей следует сосредоточиться. Такие показатели DORA, как время выполнения для изменений (скорость) и частота сбоев при внесении изменений (качество), показывают, замедляются команды с течением времени или ускоряются. На эти показатели влияют и другие факторы, но в целом это хороший индикатор эффективности команды.

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

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

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

Проекты по упрощению обычно включают переработку организационной структуры для устранения сложности в потоке коммуникации. Наименее сложные организационные структуры включают большие иерархические команды, в которых сотрудники работают в одном помещении. Самые сложные организационные структуры включают небольшие, распределенные и автономные команды. Закон Конвея демонстрирует, что большие иерархические команды, скорее всего, будут создавать монолитные приложения, тогда как небольшие распределенные команды, скорее всего, будут создавать приложения с использованием модульных архитектур, таких как микрослужбы. Быстрое создание качественного программного обеспечения становится возможным благодаря шаблонам модульной архитектуры, таким как архитектура микрослужб, а это означает, что более сложная организационная структура с большей вероятностью приведет к успеху. Хотя «упрощение» организационной структуры облегчает ее понимание, оно контрпродуктивно в отношении конечной цели проекта по упрощению.

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

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

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