Как я могу убедить разработчиков в моей команде принять «Вы создаете это, вы управляете этим»?

Как я могу убедить разработчиков в моей команде принять «Вы создаете это, вы запускаете это»? Я имею в виду эту цитату из Вернера Фогельса :

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

Я специально думаю о наборе разработчиков, которые:

• Были наняты на роль разработчика, практически без упоминания о задачах, связанных с операциями.
• Традиционно «бросали код через стену» в оперативную команду.
• Традиционно у них 9–5 рабочих графиков, и они активно враждебны идее «обязанности пейджера», участвуют в восстановлении после сбоев, пишут посмертно и т. Д., Особенно в нерабочее время. (Примечание: для этого у меня есть только очень редкие перебои в работе; я не предлагаю добавлять в нерабочее время поддержку клиентов в рабочую нагрузку этой группы.)
• В настоящее время не несут ответственности за написание / поддержку мониторинга или оповещения о своих приложениях.

Предположим, что есть команда, которая быстро разрабатывает новые облачные микросервисы с профилем, который становится таковым, что передача этих сервисов оперативной команде является неоптимальной, поскольку они не могут идти в ногу с получением глубоких знаний о услуги, необходимые для эффективного управления и мониторинга. «Вы создаете это, вы запускаете это» будет работать лучше для этой команды, потому что задачи могут делегироваться каждому ответственному члену команды. Таким образом, эта группа начала бы принимать участие в разработке инфраструктуры, инструментах мониторинга / оповещения для служб и (очень редко) реагировать на события сбоя.

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

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

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

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

Во-первых, начните с введения одной или двух новых задач, которые будут выполняться только в рабочее время. Им нужно научиться делать devops, что может быть довольно полезным процессом для (до этого момента) разработчика, использующего только код, и может потребовать некоторого контроля. Они также, вероятно, будут враждебно относиться к идее изменения баланса между работой и личной жизнью, поскольку вы упоминаете, что они привыкли к 9-5. На этом этапе запишите данные о новых процессах для последующего использования (пусть они напишут этот код, данные всегда полезны).

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

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

Если обратить особое внимание на DevOps, то если вы говорите о больших (безвыходных) корпоративных средах, то методология SAFe имеет довольно хороший способ поощрения такого поведения.

По сути, это сводится к нескольким ключевым этапам:

• проекты начинаются как релиз поезда. Намерение (и ожидание того, кто его финансирует) заключается в том, что оно будет долгосрочным. Я говорю долгие годы, ни одно из этого "не постоять за команду на 3 месяца, а потом зарезать их" бизнес.

• В ходе проекта поезд релиза неизбежно соберет больше людей, поскольку будет предъявляться как новые требования к проекту, основанные на недавно реализованных бизнес-возможностях, так и продолжающемся налоге на работу в стиле обслуживания.

• Я почти всегда вижу, как поезда выполняют свой первый шаг как команды, работающие над проектами / изменениями, на 2-м шаге они выделяют процент времени для выполнения работы. Менеджмент 3-го приращения понимает, что у него возникнут проблемы, и начинает добавлять команды, чтобы попытаться справиться с переполнением Run, чтобы дать их опытным разработчикам и инженерам время, чтобы продолжить работу над новыми требованиями.

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

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

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

ИМХО You build it, you run itне следует понимать буквально. Для начала - это звучит почти как наказание;)

Ни один человек или даже небольшая команда разработчиков не могут разумно поддерживать инструмент или набор инструментов, используемые в процессе разработки программного обеспечения (т.е. в производстве!) В течение длительных периодов времени. Был там, сделал это :)

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

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

Команда поддержки 1-й линии, разумеется, будет вынуждена обратиться к команде разработчиков (опять же, команде, а не к одному человеку!) Из-за проблем, которые они не могут решить напрямую. Да, поначалу это может быть сложно, но все станет лучше. Это должно быть сотрудничество - это часть DevOps.

В конечном итоге это зависит от размера и структуры компании. На самом деле ваша компания может пройти три этапа:

1. Стадия запуска (до 150 инженеров). Конечно, разработчикам нужно запускать собственное программное обеспечение. Каждый делает это в стартапе. У вас может даже не быть рабочей группы для начала, но даже если она у вас есть, она мала и скорость прогресса настолько высока, что невозможно передать знания, необходимые для ее успешного выполнения, другой команде достаточно быстро, чтобы они могли быть успешным.

2. Средний бизнес (более 150 инженеров, но одна рабочая группа). На данном этапе отток в компании становится слишком высоким, инженеры, которые создают программное обеспечение, не обязательно останавливаются и для его запуска. Вы больше не знаете всех, и трудно эффективно общаться, чтобы все работали. Это начало бы превращаться в хаос. На этом этапе вы хотите обратиться к модели Google, где каждая команда должна задействовать свое программное обеспечение, но не обязательно использовать его. Они будут работать с ним в самом начале, но большая часть создания программного обеспечения заключается в том, чтобы снизить затраты на его эксплуатацию до такой степени, что нагрузка будет достаточно мала, чтобы операционная группа могла подписать его запуск. Только тогда это считается выполненным.

3. Крупное предприятие с несколькими подразделениями (где у каждого своя операционная команда): на этом этапе вы можете вернуться к модели Amazon, где каждая команда разрабатывает и использует свои собственные сервисы. Каждое из бизнес-подразделений должно быть достаточно маленьким, чтобы все могли знать друг друга, поэтому примерно 150 инженеров, и вы работаете, по сути, как стартап. У Amazon каждый сервис AWS работает более или менее отдельно, и он работает на них.

Вы должны выяснить, на какой стадии находится ваша компания и / или перейти на нее, и действовать соответственно. Не существует единого решения для всех.

Мой взгляд на это (если бы я столкнулся с таким командованием или как бы вы это ни называли), был бы что-то вроде " What else would you expect?!?!". Потому что, случайно:

• Я бы даже не смог жить без этого, и
• Я люблю есть свою (собачью) еду.

Позвольте мне объяснить немного дальше ...

Мой бизнес / хобби / страсть - scm , более конкретно в средах мэйнфреймов . И куда бы я ни пошел (чтобы точно настроить вещи, чтобы соответствовать потребностям клиентов), самое первое требование, которое я навязываю (в своем контракте), заключается в том, что любая настройка, выполняемая для системы, которую мы внедряем, осуществляется с помощью той же самой системы. И таким образом (правда, это занимает несколько часов, скажем, максимум полдня), мы получаем следующие преимущества (неполный список):

• Я с трудом документирую все, что я сделал, чтобы система работала Если задаются какие-либо вопросы, я просто запрашиваю систему (и учу клиента, как запрашивать систему без моей помощи).
• Если мне позвонят через X месяцев / лет (чтобы перейти на новую версию?), Я хочу знать (помнить), что я делал раньше (и единственное, чему я доверяю, это то, что система говорит мне, иначе напоминает мне о).
• Мне нужно только один раз спросить клиента о том, как делать определенные вещи на его сайте (соглашения об именах трудно запомнить), или убедить их предоставить необходимые разрешения "системе" (не мне ...).
• Вы continuouslyтестируете свою собственную систему QA ... в производстве. Скорее всего, вы сами столкнетесь с ошибками, логическими ошибками или отсутствующими функциями (а что нет). И это очень мотивирует, чтобы они решались как можно скорее ... например, чтобы стать более продуктивным.
• ... и если вы хотите, я могу добавить еще дюжину причин ...

Однако, прежде чем вы попробуете это дома самостоятельно, имейте в виду некоторые подводные камни, чтобы избежать:

• Вы хотите, чтобы все вступили в партию (использовали систему), потому что только 1 «исключение» (он же менеджер / владелец компании?) может разрушить партию (вы думаете, что можете доверять своей системе, но затем кто-то что-то сделал без запроса / использования системы). Эти случаи могут стоить вам дней, чтобы обнаружить ...
• новые пользователи могут жаловаться на то, что при использовании этой (новой) системы у них уходит намного больше времени на выполнение своей работы (по сравнению с тем, что они использовали раньше). И где бы это ни имело смысл, они будут использовать это как оправдание, почему они опаздывают, чтобы закончить свою работу. В этот момент вам лучше иметь верховное руководство, охватывающее вас, потому что в противном случае ваш проект / система может получить вину.
• убедитесь, что вы знаете свою собственную систему и как ее настроить в соответствии со своими потребностями. В качестве примера (в моем случае): вы хотите настроить систему так, чтобы вы использовали операционную среду для доставки в вашу экспериментальную среду, а не наоборот ... Я видел, как это происходило в прошлом ... использование (злоупотребление) тестовой системы для доставки в высокозащищенные среды.