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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сценарий: нерекомендуемая программа

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

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

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

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

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

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

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

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

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

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

Сделайте дело для ваших первоначальных инвестиций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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