Отрицательная скорость: как повысить предел сложности
Как понять, что организационная сложность мешает вашей команде разработчиков, и как это исправить
Эндрю Бояги
Старший евангелист
Одна из самых распространенных целей организации по разработке — быстрая поставка качественного программного обеспечения.
Прочитайте программное заявление своего ИТ-директора или технического директора и послушайте их выступления. Скорее всего, они преследуют какую-то из разновидностей этой цели. Но хотя цель популярна, успешность ее реализации сильно разнится — от команд, достигших этой нирваны, до команд, застрявших в чистилище поставки программного обеспечения. Одни постоянно выпускают новый код в рабочую среду с минимальным количеством инцидентов и негативных последствий для клиентов, в то время как другие испытывают трудности с выпуском ежеквартальных релизов.
В чем причина такого разброса в производительности?
Сложность поставки программного обеспечения — это разница между быстрой поставкой качественного программного обеспечения и… ее отсутствием. Это разница между звоном в победный колокол после успешного еженедельного релиза и разобщенной командой по поставке программного обеспечения, раздосадованной тем, что месяцы работы над последней версией привели к шести новым багам и откату.
Сравните скорость и качество поставки новых продуктов и функций в стартапах со скоростью и качеством устоявшейся крупной организации. Например, стартапы в области финансовых технологий за последнее десятилетие захватили значительную рыночную долю крупных банков, давно присутствующих на рынке. Банки часто ссылаются на несправедливые преимущества стартапов: они работают в условиях меньшего контроля со стороны регулирующих органов и не имеют устаревших монолитных приложений, которые требуется обслуживать. Меньший размер команд обеспечивает большую гибкость и возможность адаптироваться к потребностям клиентов. По сути, стартапы в области финансовых технологий не несут того же груза сложности, что традиционные банки, и это позволяет им работать быстрее и с меньшими рисками. Но хотя из-за сложности работа команд разработчиков ПО может замедлиться, сама по себе сложность — не всегда плохо.
Связанные материалы
Укротите бесконтрольный рост программного обеспечения
СМ. РЕШЕНИЕ
Управление компонентами с помощью Compass
Сложность в сфере поставки программного обеспечения
Сложность может приносить пользу — решать сложные задачи чрезвычайно интересно. Это мотивирует команды справляться с проблемами, находить решения в непростых ситуациях и привносить инновации в отрасль. Однако в определенный момент сложность перестает означать решение сложных проблем и начинает оказывать негативное влияние на команды разработчиков ПО.
Организационная сложность играет ключевую роль в снижении эффективности команд разработчиков ПО. В словаре Collins определение сложности дается как «состояние наличия множества различных частей, сложным образом соединенных или взаимосвязанных друг с другом». На практике организационная сложность — это совокупность информации, зависимостей, изменений, других команд, инструментов и запросов, с которыми командам разработчиков ПО приходится сталкиваться при взаимодействии с остальными подразделениями организации.
Более высокий уровень организационной сложности, естественно, затрудняет быструю разработку качественного программного обеспечения, поскольку команды тратят больше времени на взаимодействие с организацией, чем на решение сложных проблем. Растущие организации быстро обнаруживают, что команды разработчиков ПО достигли предела сложности — количества сложностей, с которыми команды могут справляться, прежде чем это начнет сказываться на удовлетворенности работой, качестве создаваемого программного обеспечения и скорости его создания. В таком случае может показаться логичным, что снижение организационной сложности позволит командам сосредоточиться на решении сложных проблем, повышении качества и скорости поставки программного обеспечения. Давайте посмотрим, почему это не обязательно так.
Влияние сложности на команду разработчиков ПО
Внедрение архитектуры микрослужб — хороший пример влияния сложности на команды разработчиков ПО. Определение сложности — «состояние наличия множества различных частей, сложным образом соединенных или взаимосвязанных друг с другом», — также является идеальным описанием архитектуры микрослужб. Действительно, микрослужбы позволяют командам работать независимо, быстрее поставлять продукты и безопасно масштабировать системы — я люблю микрослужбы! — однако они, несомненно, значительно повышают сложность.
Давайте рассмотрим эффективность команд разработчиков ПО в компании Atlassian на многолетнем пути внедрения архитектуры микрослужб.
В начале внедрения микрослужб в Atlassian показатели DORA были замечательными! Небольшие фрагменты кода упростили тестирование и развертывание, что позволило командам смело работать быстрее, а удовлетворенность работой была на высоком уровне. На этом этапе мы пожинали ожидаемые преимущества архитектуры микрослужб. Несмотря на повышение сложности, негативного влияния на команды не наблюдалось.
Рис. 1. Начало использования микрослужб
Учитывая преимущества, внедрение архитектуры микрослужб постепенно охватывало все большую часть организации, что, естественно, приводило к повышению организационной сложности. Автономных команд становилось все больше, требовалось расширять совместную работу, а большее количество микрослужб означало больше зависимостей. Темпы изменений резко возросли — все это признаки разрастания программного обеспечения. Возросшая сложность привела к снижению эффективности команд разработчиков ПО, о чем свидетельствовало снижение скорости изменений, а также умственная нагрузка, ставшая проблемой для команд разработчиков ПО.
Рис. 2: эффективность команды перестает расти, когда сложность приближается к пределу
Без вмешательства организация в конечном итоге достигла предела сложности, а эффективность команды разработчиков снизилась. Преимущества в скорости, автономности и качестве, которые ощущались в начале перехода на микрослужбы, сошли на нет, поэтому разработчики стали открыто выражать недовольство. Все это говорит о том, что организация достигла предела сложности. Команде разработчиков совсем не хочется, чтобы участники тратили силы на преодоление организационных препятствий вместо решения сложных проблем.
Рис. 3: эффективность команды падает, когда организация достигает предела сложности
Как определить, что вы приближаетесь к пределу сложности
Достижение предела сложности может казаться неизбежным, но есть некоторые признаки того, что команды к нему приближаются. Сразу скажу, что абсолютного показателя, позволяющего определить, насколько близко вы подошли к пределу сложности, не существует, но есть некоторые признаки.
Самым очевидным признаком того, что команда достигла предела сложности, является то, что на преодоление организационной сложности она тратит больше времени, чем на решение непростых проблем, на которых ей следует сосредоточиться. Такие показатели DORA, как время выполнения для изменений (скорость) и частота сбоев при внесении изменений (качество), показывают, замедляются команды с течением времени или ускоряются. На эти показатели влияют и другие факторы, но в целом это хороший индикатор эффективности команды.
Удовлетворенность разработчиков ПО — еще один показатель уровня организационной сложности, с которой приходится справляться командам. Разработчики больше, чем представители любой другой роли, любят решать сложные проблемы и ненавидят ненужные задачи, которые мешают работе. Низкая степень удовлетворенности разработчиков ПО — явный признак того, что организационная сложность стала проблемой для команды.
Упрощение — проигрышная стратегия
Обнаружив, что команды утопают в сложности, компании часто запускают «проект по упрощению», направленный на восстановление простоты в организации. Однако упрощение — проигрышная стратегия по двум причинам: сложность среды возрастает быстрее, чем любая организация способна ее упростить, а «проекты по упрощению» работают в той самой сложной среде, на упрощение которой направлены.
Популярной отправной точкой для упрощения является сокращение количества приложений путем консолидации (где возможно) или вывода из эксплуатации. Вывод приложения из эксплуатации требует, чтобы команда понимала все вышестоящие и нижестоящие зависимости, кто использует приложение, как заменить его функции, куда и как данные будут архивированы или перенесены, а также множество других сложностей, возникающих при выполнении такого рода работ. К сожалению, значительные усилия, необходимые для достижения этой цели, не окупаются столь же значительным снижением сложности. Количество приложений, которые компания может вывести из эксплуатации без ущерба для основной деятельности или удобства пользователей, ограничено, а количество новых программных компонентов, которые могут создать разработчики, безгранично. За 12 месяцев, необходимых для вывода из эксплуатации одного приложения, с большой вероятностью будут созданы сотни новых микрослужб. Поскольку здоровая технологическая среда со временем разрастается, для снижения сложности нецелесообразно ограничивать ее фиксированным количеством приложений или программных компонентов.
Проекты по упрощению обычно включают переработку организационной структуры для устранения сложности в потоке коммуникации. Наименее сложные организационные структуры включают большие иерархические команды, в которых сотрудники работают в одном помещении. Самые сложные организационные структуры включают небольшие, распределенные и автономные команды. Закон Конвея демонстрирует, что большие иерархические команды, скорее всего, будут создавать монолитные приложения, тогда как небольшие распределенные команды, скорее всего, будут создавать приложения с использованием модульных архитектур, таких как микрослужбы. Быстрое создание качественного программного обеспечения становится возможным благодаря шаблонам модульной архитектуры, таким как архитектура микрослужб, а это означает, что более сложная организационная структура с большей вероятностью приведет к успеху. Хотя «упрощение» организационной структуры облегчает ее понимание, оно контрпродуктивно в отношении конечной цели проекта по упрощению.
Упрощение важно и полезно, но лучше всего сделать его частью непрерывного совершенствования команд разработчиков ПО (и групп команд), а не одноразовой акцией. Упрощение может задержать достижение предела сложности, но оно не вернет организации свободу и скорость уровня стартапов.
Повышение предела сложности
Чтобы вернуть команде разработчиков ПО эффективность, организациям необходимо повысить предел сложности. Повышение предела сложности означает увеличение объема организационной сложности, с которой могут справляться команды, прежде чем это начнет сказываться на удовлетворенности работой, качестве и скорости поставки программного обеспечения.
Разработка платформы — важная концепция для повышения предела сложности в организации. Сильные команды разработки платформ сосредоточены на снижении умственной нагрузки команд разработчиков ПО путем абстрагирования организационной сложности от повседневной работы. При правильной реализации разработка платформы позволяет командам сосредоточить большую часть усилий на решении сложных проблем и сократить время, затрачиваемое на преодоление организационной сложности.
Рис. 4: снятие существующего ограничения по сложности
Именно по этой причине компания Atlassian создала платформу для разработчиков Compass. Compass позволяет повысить предел сложности, помогая командам разработчиков ПО ориентироваться в организационной сложности с помощью каталога компонентов, показателей и карт оценки и сосредоточиться на создании здоровой культуры разработки. Суть в том, что организационная сложность в компании Atlassian не уменьшилась. На самом деле, она продолжала расти по мере перехода все большей части организации на архитектуру микрослужб. Мы сократили время, затрачиваемое командами разработчиков ПО на навигацию в рамках этой сложности, в чем и состоит разница между проектом по упрощению и повышением предела сложности.
В Atlassian занято более 10 000 сотрудников и используется более 17 000 программных компонентов, но наши команды разработчиков работают по большей части так же свободно, как и стартапы, быстро поставляя качественное программное обеспечение. В чем наш ключ к успеху? В повышении предела сложности для увеличения эффективности команд разработчиков ПО.
Вот два действия, которые помогут вам начать повышать предел сложности.
- Отслеживайте и оценивайте показатели DORA. Как выглядят показатели DORA вашей команды? Если вы еще не отслеживаете их, показатели DORA по умолчанию доступны в Compass.
- Определяйте и оценивайте степень удовлетворенности разработчиков. Как разработчики ПО чувствуют себя в ваших командах? Большинство организаций проводит опросы для оценки удовлетворенности сотрудников. Запросите результаты с разбивкой по функциональным областям, чтобы получить представление об удовлетворенности разработчиков. Ключевые вопросы касаются оценки следующих утверждений:
- Я горжусь тем, что поставляю.
- Уровень стресса на моей работе приемлемый.
- Я понимаю, как моя работа способствует достижению целей компании.
Кроме того, Compass собирает эту информацию во время ритуала CheckOps, где команды делятся своими впечатлениями о прошлой неделе и рассказывают о том, что могло бы быть лучше.
Для повышения предела сложности требуется сочетание инструментов, процессов и ритуалов. Платформа для разработчиков, такая как Compass, поможет вам понять состояние системы, составить карту зависимостей и создать постоянные ритуалы, что позволит повысить предел сложности и раскрыть потенциал команд по поставке программного обеспечения в вашей организации.
Попробуйте Compass бесплатно уже сегодня.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Сообщество Compass
Обучающее руководство: создание компонента
