ЛОНДОН – Оказывается, инженер платформ – это профессия, связанная с продажами.
Мы много писали о том, чем отличаются роли DevOps-инженера и инженера платформы. Но в то время как команда DevOps в основном обслуживает только разработчиков и операторов, команда внутренней платформы разработчиков (IDP) обслуживает множество заинтересованных сторон. И это гораздо более хрупкое место с точки зрения сохранения бюджета.
На конференции Team Topologies Fast Flow в этом месяце Кристофер Бэти, технический директор Core Engineering Consulting Group, решил вывести разговор за рамки клиента-разработчика, который больше всего ассоциируется с IDP. В конце концов, принятие не может быть вашим единственным показателем — наличие пользователей не означает, что ваш IDP полезен или улучшает прибыль.
Вместо этого Бэти сосредоточился на том, как связаться с другими заинтересованными сторонами — высшим руководством, менеджерами по продуктам, управлением изменениями и безопасностью — чтобы продать вашу платформу внутри компании.
Не волнуйтесь, это не будет курс по продажам — по крайней мере, в явном виде. Это может быть уроком общения. Он представил советы по применению различных показателей платформы для формирования диалога со многими клиентами вашей платформы, для демонстрации вашей ценности разным аудиториям и для демонстрации того, как ваша команда разработчиков платформы (надеюсь) оказывает долгосрочное влияние на бизнес.
Почему разработка платформ требует подхода к продажам
Платформенные проекты иногда используют свое первоначальное финансирование для применения отличных технологий — и точка. Вот тогда могут начаться проблемы.
«Многие команды разработчиков платформ создают отличные платформы, но в то же время изо всех сил пытаются сохранить свое существование», — сказал Бэти. «Вы чувствуете, что проделали хорошую работу, но тогда ценность остается невидимой для руководства».
Эта дилемма означает, что 45% команд разработчиков платформ будут распущены или реструктурированы в течение 18 месяцев.
Поскольку во многих организациях разработка платформы находится на ранних стадиях, любая стратегия внутренних продаж должна быть основана на объяснении причин, а не на рассуждениях о том, что у вас есть или что вы обещаете сделать.
«Я действительно верю, что разработка платформ — это способ масштабирования DevOps», — сказал Бэти. Но «на практике, и, конечно, по моему опыту, мы все еще просим разработчиков приложений думать о слишком многом и делать слишком много».
По его словам, несмотря на то, что DevOps разрушил некоторые разрозненности, многие разработчики все еще манипулируют тремя облачными учетными записями — для разработки, пользовательского приемочного тестирования и производства — наряду с написанием Terraform или Pulumi, настройкой баз данных и облачным управлением идентификацией и доступом (IAM), а затем им приходится решать, какой из многих способов развернуть контейнер.
Эти важные, но повторяющиеся, недифференцированные отвлекающие факторы заставляют разработчиков тратить менее 30% своего времени (или, по некоторым данным, даже меньше) на создание уникальной бизнес-ценности.
«Разработка платформ, — сказал Бэти, — на самом деле позволяет инженерам приложений создавать приложения».
Сосредоточьтесь на проблемах заинтересованных сторон, а не на ваших решениях
Финансирование часто зависит от изменения способа демонстрации ценности разработки платформы заинтересованным сторонам в организации. Вот почему, как отметил Мэтью Меккес, старший специалист по контейнерам в Amazon Web Services, в другом выступлении на конференции Fast Flow Conf, командам разработчиков платформы недостаточно просто измерить пропускную способность и стабильность своей платформы. Что действительно важно, так это то, насколько быстро платформа может помочь группам разработчиков программного обеспечения доставлять программное обеспечение безопасным, надежным и надежным способом.
Бэти занимается определением влияния разработки платформ в более широком смысле.
«Я думаю, что цель разработки платформ — обеспечить быстрые изменения со встроенной безопасностью, надеюсь, при сохранении или повышении надежности», — сказал он. «Я предпочитаю это определение разработки платформ, а не «Я создаю возможности самообслуживания, чтобы позволить разработчикам работать продуктивно» и т. д., потому что оно говорит нам, почему мы занимаемся разработкой платформ, а не текущим «что такое проектирование платформ», потому что то, что всегда будет меняться».
Как только вы и ваша команда платформы поймете, почему, вы сможете перейти к пониманию различных точек зрения заинтересованных сторон и того, что означает успех для каждой из них. Отсюда вы можете создавать более значимые показатели, основанные на их потребностях.
«Мне всегда нужно напоминать себе, что эти обсуждения должны основываться на человеке, с которым я разговариваю, а не на решении, которое я хочу реализовать», — сказал Бэти. «Это заметка, которую я храню на своем мониторе для удаленных встреч, и я зачитываю ее себе пять раз, прежде чем пойти на личную встречу.
Заметка на стикере, по его словам, напоминает ему «любой ценой избегать обсуждения ваших решений с заинтересованными сторонами. Их не волнуют ваши решения. Их волнуют свои проблемы. Так что давайте попробуем их понять».
Только тогда, продолжил он, команды разработчиков платформ смогут иметь подотчетность и пользоваться уважением как проводники перемен.
«Как разработчики платформ, мы всегда должны знать, как то, что мы создаем, увеличит скорость, с которой эта компания может поставлять программное обеспечение», — подчеркнул он. «Это приведет к заметному улучшению безопасности или повышению надежности».
Определение ключевых заинтересованных сторон вашей платформы
«Инженерам платформ необходимо разговаривать со всеми, — утверждал Бэти, — потому что задача разработки платформ — собрать всех вместе, чтобы реально внести изменения в производство».
В большинстве организаций это включает, помимо прочего:
- Руководитель инженерного отдела.
- Инженеры по продукту.
- Смените менеджеров.
- Инфраструктурные команды.
- Команды безопасности.
Начните с рассмотрения того, как изменения попадают в производство. Команда платформы стремится выплатить то, что Бэти назвал «налогом на координацию» — трения, возникающие при переходе к изменениям в производстве. Просто помните, что эти шаги основаны не только на технологиях, но и включают в себя множество людей и процессов.
Для руководителей высшего звена риск, окупаемость инвестиций и скорость являются ключевыми показателями, в то время как руководитель отдела разработки продуктов заботится о предсказуемом внедрении, доставке и качестве. Обе заинтересованные стороны внимательно следят за тем, сколько времени фактически тратится на предоставление ценности конечным пользователям.
Поскольку мы знаем, что написание кода никогда не было узким местом, на оставшуюся часть жизненного цикла разработки программного обеспечения — внешний цикл — как тенденции разработки платформ, так и ИИ могут оказать наибольшее влияние. И то, и другое может помочь сократить время выпуска в производство или уменьшить трудности в других ключевых областях, таких как создание документации и повышение доступности для обнаружения.
Неудивительно, что самые большие проблемы безопасности обычно включают охват, скорость устранения проблем и количество уязвимостей конечных точек. В частности, по словам Бэти, заинтересованные стороны в сфере безопасности хотят, чтобы их привлекли раньше, чтобы действительно внедрить это в платформу.
Специалистов по управлению изменениями больше всего беспокоят изменения с высоким уровнем риска и то, как платформа может в целом обеспечить безопасное и прогнозируемое время запуска производства.
Руководитель отдела инфраструктуры заботится о внедрении, последовательности и операционном совершенстве.
Как структурировать беседы с заинтересованными сторонами
«Я инженер по натуре. По умолчанию я не являюсь прирожденным коммуникатором, и я был бы гораздо счастливее писать код, создавать функции платформы», — признал Бэти. «Единственный способ улучшить свое общение с этими людьми — это систематизировать его».
Прежде чем говорить о каких-либо решениях, он работает вместе с заинтересованными сторонами, чтобы озвучить проблему. Затем он пытается дать количественную оценку. Для каждой из этих заинтересованных сторон Бэти представил примеры проблем и способы их количественной оценки, чтобы затем измерить любые изменения.
Руководители
- Проблема: Доставка товара происходит слишком медленно.
- Количественно: Функции предоставляются ежемесячно.
Управление изменениями
- Проблема: Нет доверия к доказательствам, прилагаемым к запросам на изменение.
- Количественно: 95% запросов на изменения содержат доказательства, добавленные вручную.
Безопасность
- Проблема: Уязвимости продолжают расти.
- Количественно: 35 уязвимостей в продакшене.
руководитель инженерного отдела
- Проблема: Инженеры изо всех сил пытаются добиться цели.
- Количественно: Срок действия услуги — две недели. Объединение запросов на включение занимает в среднем три дня.
Заинтересованные стороны не всегда будут знать о проблеме, с которой они столкнулись, предупредил Бэти. Например, служба безопасности может совершенно не знать, что у каждой команды свой путь к производству. Все, что они знают, это то, что инструменты безопасности не применяются достаточно, или никто не берет на себя ответственность за исправление ошибок.
«Вы начинаете с количественной оценки количества активов, имеющих уязвимости», — предложил он. Затем вы приводите внешние доказательства того, как другие компании решили ту же проблему. Наконец, вы пытаетесь создать внутреннее доказательство с помощью краткого доказательства концепции.
Наконец, вместе вы создаете то, что Бэти называет «библиотекой иголок» или показателей, которыми вы являетесь совладельцем, делая ставку на то, что вы сможете перемещать эти иголки.
Какие показатели платформы наиболее важны для лидерства?
Ваша платформа должна демонстрировать измеримые значения скорости, производительности, безопасности и/или стоимости. Уже углубившись в обсуждение вопросов безопасности, Бэти привел несколько примеров для каждого из трех остальных.
Показатели скорости
- Время запуска продукта.
- Количество функций, ориентированных на пользователя, которые могут быть выпущены.
- Время выполнения.
- Время подготовки к изменениям.
- Частота развертывания.
- Инжиниринг для присоединения к команде и запуска в производство.
- Внедрение сервиса.
Эту скорость часто увеличивают за счет удаления ручных действий и утверждений.
Показатели надежности и производительности
- Какой процент продукта, ориентированного на пользователя, доступен? Разные девятки по функциям?
- Есть ли перебои во время ключевых событий?
- Имеются ли нарушения соглашения об уровне обслуживания?
- Цели уровня обслуживания (SLO).
- Индикаторы уровня обслуживания (SLI).
Работая напрямую с разработчиками приложений, добавил Бэти, вы также можете установить:
- Функциональное тестирование для ключевых сценариев использования в бизнесе.
- Нефункциональное тестовое покрытие.
- Покрытие испытаний на надежность.
Показатели затрат
Общая стоимость владения (TCO) и рентабельность инвестиций (ROI) — это ключевые показатели, которые должны понимать все руководители групп, особенно сейчас, когда вы спорите о своей работе. Он предложил некоторые ключевые показатели затрат:
- Стоимость услуги.
- Стоимость на одного клиента.
- Стоимость за путешествие пользователя.
- Стоимость хранения.
- Стоимость хостинга.
Практическое руководство по расстановке приоритетов метрик
По словам Бэти, самая сложная часть разработки платформы — это решить, что и в каком порядке делать, а это может означать, что команды будут измерять слишком много. Измерениям нужна иерархия, которую он обосновал практическими примерами.
Представьте, что выпуск продуктов замедляется. Руководители жалуются, что ваша организация, занимающаяся разработкой программного обеспечения, отстает от конкурентов. Но если команды попытаются ускориться, надежность пострадает из-за большего количества уязвимостей.
Его диагноз заключается в том, что ручной набор сред вызвал различия в тестировании и производстве. Разработчики пропускают автоматические тесты, и безопасность приходится развертывать по-разному для каждой среды. Решение, по его словам, которое команда разработчиков платформ должна представить руководителям, — это стандартизированный, консолидированный путь к производству ключевых сервисов с использованием согласованных, легких сред, которые автоматически создаются согласованным образом.
«Всегда начинайте с простого», — рекомендовал Бэти. «Выберите ключевой вариант использования для бизнеса, выясните, какие компоненты задействованы, и какую бы инициативу вы ни реализовали, просто убедитесь, что она приносит некоторую пользу этим ключевым пользовательским взаимодействиям».
Измерение — лучший способ оценить ценность вашей платформенной программы, основанный на понимании причин. Чтобы сделать это, начните с простого, посоветовал он, выбрав один ключевой, легко измеряемый вариант использования для бизнеса для каждой заинтересованной стороны.
Просто помните: «Цель не в том, чтобы измерить все», — сказал Бэти. «Это нужно для того, чтобы измерить правильные вещи, чтобы показать ценность функций платформы, которые вы создаете, ключевым людям».
Сюда, конечно, входят все, кто держит в руках кошельки. Но также, по его словам, «вы не хотите, чтобы люди блокировали то, что вы пытаетесь сделать».
Загрузите электронную книгу «Разработка платформ: что вам нужно знать сейчас».
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Дженнифер Риггинс — рассказчик о технологиях и журналист, ведущая мероприятий и дискуссий. Она устраняет разрыв между бизнесом, культурой и технологиями, ее работа основана на опыте разработчиков. Она работает писателем с 2003 года и живет… Подробнее от Дженнифер Риггинс.
