ЛОНДОН – Последний принят на работу, первый уволен – таков закон страны. Для команд разработчиков платформ, большинство из которых менее 5 лет, это тоже может быть справедливо. Многие изо всех сил пытаются доказать свою правоту.
Команды, занимающиеся разработкой платформ, чувствуют необходимость связать свою техническую поставку с бизнес-целями, но большинство из них измеряют неправильные вещи, если вообще что-то делают. При этом от 60 до 70% проектов платформ не приносят результатов, при этом почти половина команд платформ расформирована или реструктурирована в течение 18 месяцев.
Большая часть конференции Fast Flow Conf в этом году, флагманского мероприятия Team Topologies, была посвящена внедрению платформы и тому, почему внедрение — не единственное, на чем должны сосредоточиться инженеры платформ.
Мэтью Мекес, старший специалист по контейнерам в Amazon Web Services (AWS), в этом месяце рассказал на Fast Flow о том, как измерить зрелость вашей платформы, чтобы в нее можно было инвестировать сверху вниз. Он объяснил, как предоставить внутренним командам разработчиков платформ метрики, которые могут спасти их рабочие места.
Что сдерживает команды платформы?
Несмотря на то, что пока это работает не очень хорошо, нельзя отрицать, что разработка платформ следует своим предшественникам — Agile, DevOps и облачным технологиям — как в том, чтобы стать стандартом технологической отрасли, так и в борьбе за широкое распространение после многих лет попыток.
Gartner прогнозирует, что к 2026 году 80% крупных организаций, занимающихся разработкой программного обеспечения, будут иметь команды по разработке платформ, по сравнению с 45% четырьмя годами ранее. Но технологической отрасли не нужны дополнительные 18-месячные инвестиции, которые в конечном итоге будут сокращены. Платформенные команды должны найти способ оказать долгосрочное влияние в краткосрочной перспективе.
Почему команды платформы терпят неудачу? По словам Меккеса, обычно это смесь:
- Отсутствие продуктового мышления: Отношение к внутренним платформам разработки (IDP) как к техническим артефактам, а не к услугам, которые могут потреблять клиенты-разработчики.
- Чрезмерное усложнение вещей: Противоположность предыдущему пункту — говорить всему «да» и пытаться поддерживать каждую рабочую нагрузку, вместо того, чтобы сосредотачиваться на том, что приносит пользу 80% инженерных команд.
- Несогласованность с заинтересованными сторонами: Разработчики платформ, которые думают, что знают, что лучше для разработчиков, а затем полностью игнорируют менеджеров по продуктам и руководство.
- Культурные и организационные барьеры: Неспособность обеспечить постоянное улучшение и добавленную стоимость на рынке для стимулирования внедрения платформы.
- Плохие показатели: Возможно, команда использует метрики DORA для обеспечения пропускной способности и стабильности, но не может связать их с бизнес-целями.
Но, по словам Мекеса, если вы недостаточно зрелы в своем путешествии по платформе, вы не сможете выпускать релизы быстрее, сохраняя при этом стабильность. Он процитировал Дэйва Фарли, соавтора книги «Непрерывная доставка»: «Между скоростью и качеством не может быть компромисса. Если вам нужны высококачественные системы, вы должны создавать их быстро».
Важность быстрого цикла обратной связи и итераций
Как и командам разработчиков, которым они служат, командам платформ необходим цикл небольших релизов и более быстрая обратная связь. Так как же сократить время, чтобы стать зрелой командой разработчиков платформ? Нет, сказал Мекес, повторяя одни и те же ошибки.
«Мы можем совершать совершенно новые, новые ошибки, которые могут быть действительно захватывающими, но, будем надеяться, мы не будем повторять те же ошибки, которые видим снова и снова», — сказал он.
«Если у нас действительно хорошие основы платформы и посмотрите, насколько хороша наша работа, но она по-прежнему влияет только на одну или две рабочие нагрузки внутри организации», — добавил он, ваш IDP может быть хорош на бумаге, но это не продукт, имеющий пользователей. Другими словами, это пустая трата.
По его словам, чтобы найти точку, в которой внутренние клиенты привлекаются к платформе, а не подталкиваются к ней, команды платформы должны по-настоящему придерживаться модели «платформа как продукт» и уделять приоритетное внимание отзывам всех заинтересованных сторон.
«Нам необходимо создать систему измерения, соответствующую ключевым показателям эффективности бизнеса, чтобы мы могли продолжать оправдывать повторные инвестиции», — сказал Мекес. «И мы действительно очень сосредоточены на опыте разработчиков».
Это означает, например, что в крупной организации, предоставляющей финансовые услуги, не может быть только одной команды платформы, обслуживающей всех.
«Нам действительно нужно выделить пару бизнес-подразделений, которые действительно собираются инвестировать в современную, непрерывную доставку и создать что-то, что будет соответствовать их сценарию использования, что мы действительно сможем продемонстрировать, что мы можем затем масштабировать по всему остальному миру».
Как измерить зрелость вашей платформы
Аксиома науки (а инженерия — это наука) заключается в том, что нельзя улучшить то, что не измеряешь.
Вот почему рабочая группа по разработке приложений Cloud Native Computing Foundation создала Модель зрелости платформы, охватывающую пять областей инвестиций в платформу:
- Команда: Кто входит в команду платформы и как она финансируется.
- Принятие: Онбординг пользователей и внутренний маркетинг.
- Интерфейсы: API, инструменты, чат-боты, порталы.
- Операции: Управление жизненным циклом, включая вывод из эксплуатации функций.
- Измерение: О ценности программы-платформы.
«Как мы можем измерить ценность так, чтобы это действительно интересовало бизнес, и чтобы мы могли сообщить об этом?» — сказал Мекес. «Таким образом, мы можем просить больше денег, больше персонала, больше инвестиций год за годом, поскольку мы начинаем извлекать выгоду из нашей расширяющейся платформы».
Четыре уровня зрелости платформы:
Понимание модели зрелости платформы CNCF
Рабочая группа по разработке приложений CNCF только что выпустила пилотную версию модели зрелости разработки платформ, чтобы помочь организациям задуматься над этими показателями. Хотя это быстрая онлайн-викторина, вы можете распечатать ее, обсудить и сделать заметки — ответы могут быть не такими простыми, как «да» или «нет». Используйте его, чтобы создать артефакт, который объясняет и измеряет вашу команду платформы.
Меккес рекомендует выделить несколько часов на первую оценку, но как только вы это сделаете, последующие оценки должны занять около часа. Надеемся, что с помощью этого упражнения вы сможете построить достижимую дорожную карту на следующий квартал или два.
Реальные примеры оценки зрелости платформы
Он привел пару примеров того, как команды платформы показали зрелость в одних областях, но ей не хватало в других.
Пример 1: Достаточно предварительный
Измерение показателей DORA для команды платформы, а не для команды разработчиков, которую вы обслуживаете. Следующие шаги заключались в следующем:
- Развивайте операционное совершенство, чтобы убедиться, что платформа лучше, чем то, что было у разработчиков раньше.
- Установите измерения, привязанные к организационным ключевым показателям эффективности, чтобы оправдать повторные инвестиции.
- Сосредоточьтесь на опыте разработчиков, инструментах самообслуживания и инвестициях в бизнес-подразделения, которые хотят осуществлять современную непрерывную доставку.
Пример 2: более сложный
Эта компания уже пару лет занимается разработкой платформы и создала надежную экосистему Kubernetes с комплексной системой измерения. Однако только 20% рабочих нагрузок было перенесено на IDP. Как сказал Мекес: «У них есть эта потрясающая вещь, но она не получает поддержки».
В результате этой оценки команда поняла, что ей нужен выделенный менеджер по продукту и более централизованный процесс адаптации новых пользователей. Пришлось также учитывать ограниченную интеграцию с остальным жизненным циклом разработки программного обеспечения.
«Для них речь идет о том: «Как нам построить этот замкнутый цикл обратной связи, чтобы мы могли совершенствовать возможности самообслуживания, начать привлекать сообщество и стимулировать внедрение за пределы тех, кто первым внедрил его?» — сказал Меккес.
Стимулирование внедрения и обеспечение инвестиций сверху вниз
Ключ, по его словам, к нисходящим инвестициям и коммуникациям: «Мы хотим пойти и сделать вот что: пойти и получить максимальную отдачу от облака. Затем перейти к построению операций: как мы можем построить устойчивую автоматизацию процессов? И тогда это начинает вызывать затруднения».
Потому что, утверждал он, независимо от того, насколько хороша ваша деятельность, она никогда не будет стимулировать внедрение в одиночку. Команды платформы должны поддерживать адаптивные изменения.
«Как нам решать эти сложные, неоднозначные проблемы? Как мы помогаем людям учиться?» — спросил Мекес. «Именно здесь мы собираемся подумать об адаптации нашей платформенной культуры, переходе к мышлению DevOps и, наконец, собираемся объединить разработчиков и операторов для сотрудничества, создавая ориентированные на разработчиков организации, в которых наши разработчики близки к продукту».
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Дженнифер Риггинс — рассказчик о технологиях и журналист, ведущая мероприятий и дискуссий. Она устраняет разрыв между бизнесом, культурой и технологиями, ее работа основана на опыте разработчиков. Она работает писателем с 2003 года и живет… Подробнее от Дженнифер Риггинс.
