Планирование и приоритет

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

Определение целей и ключевых сценариев

Чтобы приступить к работе, сначала оцените, где сегодня находится ваша организация с помощью модели возможностей разработки платформы. Используйте модель, чтобы определить, где ваша организация находится по шести основным направлениям инженерии платформ: инвестиции, внедрение, управление, обеспечение и управление, интерфейсы, а также измерение и обратная связь. Все организации более продвинуты в некоторых возможностях, чем в других. Как только вы знаете, где стоит ваша организация сегодня, вы можете выбрать возможности, которые вы хотите увеличить. Дополнительные сведения см. в статье "Оценка текущих методик" и установка будущих целей.

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

Как однажды сказал руководитель по платформенной инженерии: "Я не занимаюсь разработкой платформы, пока не получу какую-либо выгоду от этого." – Питер, руководитель по платформенной инженерии, многонациональная технологическая компания.

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

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

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

Еще лучше, когда вы договариваетесь о целях и ключевых результатах (OKRs) с вашим руководством и внутренними партнерами, это помогает установить измеримые цели для текущего этапа ваших инвестиций. (Другие подходы планирования имеют аналогичные понятия, если ваша организация использует что-то другое.) Лучшие ОКR — это те, которые можно задать на основе конкретной меры, так как она удаляет субъективность.

Сценарии и задания, которые необходимо выполнить

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

Сценарий. Начало создания нового приложения

• Понимать и применять лучшие практики и политики организации
• Создание нового репозитория
• Инструменты предоставления
• Подготовка общей инфраструктуры
• Предоставление участникам команды доступа
• Установка конвейеров CI/CD
• Подготовка инфраструктуры разработки
• Начальное развертывание для тестирования "каналов"

Сценарий. Добавление или удаление нового члена в существующую команду

• Обновление доступа к средствам и службам
• Настройка компьютера разработчика
• Обучайте участников команды работать с приложениями
• Создание среды песочницы приложения
• Создайте и проверьте первый pull request

Сценарий. Добавление или обновление инфраструктуры для существующего приложения

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

Сценарий. Добавление или обновление средства для существующей команды

• Понимание лучших практик организации, доступных вариантов
• Запрос использования нового средства
• Обновление доступа участника группы к средствам
• (Если применимо) Интегрируйте инструмент в клиентские системы или конвейеры CI/CD

Сценарий. Поиск или повторное использование существующего API, пакета SDK или службы

• Обнаружение доступных API, пакета SDK или служб
• Оценка того, соответствует ли она потребностям
• Свяжитесь с командой владельца по любым вопросам
• Принятие для использования в приложении

Сценарий: реагирование на инцидент операционных процессов

• Уведомление о проблеме
• Оцените, связано ли это с кодом приложения, инфраструктурой или обоими.
• Создание среды песочницы, которая отражает prod (если отличается)
• Внесение изменений, тестирование, внеполосный выпуск

Сценарий. Быстрое исправление инцидента безопасности

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

Сценарий: устаревший инструмент

• Общие сведения об использовании инструментов
• Уведомить пользователей об устаревании
• (Необязательно) Координация миграции пользователей в новое средство

Сценарий: Развертывание новой модели архитектуры приложений

• Пилотная предлагаемая архитектура
• Настройка на основе результатов пилотного проекта
• Обновление документации по передовым практикам
• Создание шаблонов, обновление автоматизации, политик и управления

Аудит соответствия приложений (GDPR, специальные возможности, стандарты инфраструктуры)

• Общие сведения о текущих правилах соответствия
• Проверка соответствия приложений правилам
• Установление крайнего срока для исправления отклонений
• Внесение изменений, тестирование, выпуск

Многие сценарии относятся к нескольким ролям. Подумайте о метриках, чтобы оценить улучшение.

От проблем до концепций

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

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

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

Обоснуйте ваши первоначальные инвестиции

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

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

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

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

Измерение успешности и подтверждения значения

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

Например, может быть трудно обеспечить финансирование или взаимопомощь для усилий по соблюдению требований, поскольку они могут рассматриваться как дополнительные расходы для команд разработчиков, которые обеспечивают бизнес-ценность. Менталитет продукта может изменить это восприятие. С продуктовым мышлением вы пытаетесь убедиться, что клиенты вашей внутренней платформы для разработчиков довольны и что бизнес-цели заинтересованных сторон достигнуты. Метрики позволяют использовать факты, чтобы доказать, что вы предоставляете бизнес-ценность. Настройка ОКR может помочь, особенно если у вас есть метрики, которые можно использовать для удаления субъективной предвзятости. Даже если вы ничего не оцениваете сегодня, вы можете установить учебный OKR, чтобы задать базовый уровень, который будете уточнять после его определения.

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

• Скорость и время для бизнеса: медианное количество дней, чтобы завершить первый запрос на вытягивание (внедрение), медианное количество минут для процессов сборки и тестирования (например, CI), медианное время для слияния запроса на вытягивание.
• Качество программного обеспечения: инциденты (проблемы), созданные в месяц на каждого разработчика (количество нормализовано относительно числа разработчиков), среднее время восстановления (MTTR), среднее время для изучения и исправления проблем безопасности.
• Простота использования платформы: индекс удовлетворенности пользователей (NSAT)
• Процветающая экосистема: Средняя оценка для каждого из следующих опрошенных вопросов: "Я могу сделать свою лучшую работу", "большинство дней я энергичен работой, которую я делаю", "работа, которую я делаю, имеет смысл для меня".

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

Другие метрики, которые вы или ваши спонсоры могут быть заинтересованы в измерении, включают:

Area	Примеры метрик
Производительность доставки программного обеспечения	DevOps Research and Assessment (DORA): время выполнения изменений, частота развертывания, коэффициент отказа изменений, время восстановления сервиса (MTTR)
Operations	DORA (MTTR), среднее время между отказами (MTBF), среднее время для подтверждения, доступность для конечных клиентов, метрики задержек, пропускная способность, затраты на команду, затраты на развертывание
Метрики внедрения возможностей платформы	Количество команд или разработчиков, использующих инструмент или функцию с течением времени, процент репозиториев, использующих платформу, наиболее популярные шаблоны, конвейеры и т. д.

Сбор метрик требует времени и усилий, поэтому важно сосредоточиться на критически важных метриках для основных целей, которые вы определили, особенно те, которые позволяют использовать ОКR. Продукты на основе OpenTelemetry, такие как Application Insights, могут помочь.

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

Другие советы

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

план изменений

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

Проверка идей с помощью новых приложений

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

Сосредоточьтесь на существующих центрах тяжести для взаимодействия с пользователем перед созданием новых

Разработчики, скорее всего, будут применять и придерживаться новых возможностей, когда они появляются в чем-то, что они уже любят и используют. При оценке концепций для предоставления новых возможностей обязательно изучите варианты, которые расширяют существующие центры тяжести. Например, редакторы и IDE (Visual Studio, VS Code), наборы DevOps (GitHub, Azure DevOps), существующие CLI или существующий внутренний портал могут быть более эффективными, чем совершенно новый портал или другой UX. Дополнительные сведения см. в разделе "Взаимодействие с пользователями".

Предположим, принцип наименьших привилегий

Предположим, что разработчики имеют ограниченный доступ к взаимосвязанным системам для таких задач, как обеспечение инфраструктуры. Вам потребуется управляемый способ включения этого доступа для самообслуживания.

Планирование управляемого эксперимента

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

Минимизация настройки платформы приложений

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

Связанный контент

• Применение систем проектирования программного обеспечения