DevOps — это история про культуру, коллаборацию и общение, но многие не очень представляют, как будучи скромным исполнителем или тимлидом, повлиять на целый энтерпрайз и сдвинуть организацию в сторону DevOps.
На DevOops 2020 Moscow Барух Садогурский и Леонид Игольник рассказали, какими методами можно воспользоваться для влияния на стейкхолдеров, что кому говорить, как мотивировать и как работать с возражениями. Пожалуй, за исключением парапсихологических практик и гипноза (которые не стоит раскрывать неокрепшим умам), на этом докладе спикеры показали все способы влиять, не имея полномочий на благо наступления повсеместного DevOps в индустрии.
Под катом — расшифровка доклада, а также видео с конференции. Далее повествование ведется от лица спикеров.
Введение
Как часто происходит в наших докладах, у нас есть мифический герой, в нашем случае сегодня это Вася. Вася — системный администратор, он не DevOps-инженер. Он работает на омском свечном комбинате — очень прогрессивный software shop. Вася общается со своими разработчиками примерно вот так.
Они что-то пилят, что-то бросают Васе, говорят: «Ты же наш админ, давай деплой». А Вася страдает, он делает что-то, чтобы это изменить. Он читает много всего в интернете. И одна из вещей, которые он прочитал, — это DevOps. Вася поинтересовался, как там у DevOps с зарплатой, и выяснилось, что если у сисадминов с зарплатой вот так:
То у DevOps с зарплатой вот так: + 30%, что в общем-то понравилось Васе.
Вася — человек довольно рациональный. Естественно, он сразу начинает искать работу, видит открытую позицию в другом омском предприятии и сразу становится старшим DevOps-инженером на местном омском мясокомбинате. Придя на работу, он начинает там разводить DevOps. Вася вовсю девопсит, устанавливает Jenkins на десктоп под столом, устраивает полный DevOps у себя в отделе и становится настоящим DevOps и DevOps-инженером.
Но с таким DevOps у Васи все та же проблема. Разработчики говорят: «Вот ты у себя там девопсишь, девопсь и дальше». Только теперь у него DevOps на рубашке написано.
Вася понимает, что есть взаимодействие между Dev и Ops, все-таки что-то не работает и не сходится с тем, что он читал в книжках. И он придумывает новое взаимодействие, которое будет называться DevDevOps.
Вася продолжает читать книжки, он осознает, что что-то недопонял, потому что на мясокомбинате он не справляется. Он прочитал великолепные книжки: The Phoenix Project, DevOps Handbook, DevOps Accelerate.
Вася понимает, что DevOps все-таки не профессия, а культура, которая находится на пересечении трех дисциплин или иногда в разных местах, так называемых «трех колодцах». Это пересечение Development, Operations и QA.
Вася находит потрясающий документ, называющийся Accelerare State of DevOps 2019 года. Если вы его не читали, рекомендую посмотреть. В нем описаны категории перформеров: low, medium, high, elite. Он подробно описывает, что эти категории перформеров делают и чем отличаются.
Между 2018 и 2019 годами есть довольно хорошая разница. Ребят, которые раньше были в elite, было всего 7%, а потом — уже 20%.
Почему elite стало больше? DevOps и все, что делает бизнес, создается для клиентов. А клиенты хотят новых фич, причем «вчера», а не сейчас. И есть определенные вещи, которые поменялись, потому что мир вышел в онлайн. Мы имеем в виду security.
Security стала большой проблемой, мы сталкиваемся с этим ежедневно. Борьба занимает три этапа: обнаружить, подчинить и задеплоить в прод. Если два из них имеют отдаленное отношение к DevOps, то третье — совершенно DevOps-история. И это вторая причина, по которой elite-перформеров стало в три раза больше.
Эволюционное давление заставляет компанию двигаться вверх и разделяет elite-перформеров от medium-перформеров. Компаний и команд, которые поняли, что такое DevOps и как его делать правильно, становится больше, а те, кто не понял, начинают уходить вниз и рано или поздно просто отомрут.
Вася смог пробраться на важные митинги, где высокое начальство, понимая два главных фактора, требует релизить чаще. Подаются идеи нанять еще больше DevOps-инженеров или уволить весь QA.
И когда Вася предлагает внедрить DevOps, происходит так.
Не последняя причина, почему так происходит, заключается в следующем. Если посмотрим на типичную организационную структуру такой компании, то вспомним, что Вася в этой структуре — глубоко внизу, а товарищи, которые принимают решения, — наверху. И это разделение мешает Васе начать трансформацию снизу вверх.
Тем не менее, Вася нашел прекрасный способ, как это сделать. О нем и поговорим.
Если вы собираетесь трансформировать вашу организацию, то вот вам набор книжек, минимум для DevOps. У книги The Phoenix Project есть такая альтернативная реальность — The Unicorn Project. Site Reliability Engineering представляет некоторые основы инжиниринга, основанного на DevOps. В Accelerate расписывается методология и практика, на основе которой делается The State of DevOps Report. Также рекомендуем книгу для начальников War, Peace and IT Марка Шварца, она объясняет, почему DevOps нужен и важен, на языке, который понимают начальники. И Liquid Software, где раскрываются принципы continuous update и как ускоряться с delivery.
Не книжками едиными полон наш мир, и мы хотели бы еще упомянуть несколько полезных источников информации.
Во-первых, Барух ведет великолепный подкаст, который называется DevOps Speakeasy. Также есть подкаст DevOps’ish. И у конференции DevOops есть набор докладов с предыдущих сезонов.
Ну а для тех, кто любит пилить Jenkins, мы не можем не упомянуть инструменты для этого. И один из наших любимых — Technology Radar, его делает компания ThoughtWorks, где работают такие люди как Мартин Фаулер (Martin Fowler). Он внимательно описывает tools, frameworks и прочее, четко их исследует и дает рекомендации.
Надеемся, что со всеми этими знаниями вы готовы прийти на свою работу и, как вооруженный бронтозавр, трансформировать все в DevOps. Вы приходите к своему начальнику и рассказываете ему, что правильный DevOps — это методология, это коллаборация. А в ответ тебе так.
Скорее всего, вы будете видеть эту реакцию часто. Не всегда люди злодеи, иногда у них просто нет времени и сил вас слушать. Иногда люди будут искренне обещать вам, что они захотят что-то делать, может, даже строить планы, но в итоге отвлекутся, забудут, переключатся на что-то другое и не дойдут до выполнения обещаний, даже если они были искренними.
Иногда вы будете работать с людьми, которые будут болтать, но ничего полезного не сделают. На самом деле это часто происходит, потому что у каждой химической реакции есть активационная энергия, которую надо вложить в систему, чтобы пошла химическая реакция. И эта активационная энергия во многих организациях на любую трансформацию довольно высока. И ее вам может просто не хватить.
И все это вместе, скорее всего, будет вас демотивировать. И вам захочется сказать: «Да ну его нафиг! Чего мне больше всех надо? У меня есть работа, мне платят нормально!» И мы советуем вам не поддаваться этим пораженческим настроениям.
Но кипятить океан кипятильником — это тоже задача глупая. Надо подумать о том, что активационная энергия достаточно низка, чтобы вы действительно могли раскрутить этот маховик. И о том, как надо раскручивать маховик трансформации, и будет оставшаяся часть доклада. Мы расскажем про модель, которая была хорошо описана в книжке Influence Without Authority, то есть влияние без какого-то менеджмент-авторитета. Она описывает модель шести стадий и как повлиять на любые изменения, не имея на то управленческого права. Мы пойдем по этой модели шаг за шагом.
Influence Without Authority
Первая стадия — Assume all are potential allies
Нужно рассматривать всех в позитивном ключе и думать, как они могут тебе помочь, вместо того, чтобы рассматривать всех как противников и думать, как их победить. Это легче сказать, чем сделать: когда всех рассматриваешь как союзников, трудно понять, кто же из них действительно настоящий и полезный союзник.
Где искать таких союзников? Наверняка в вашей организации, как и в любой другой, есть команды, которые пытаются сделать что-то новое — forward-looking teams. Потенциально их считают хипстерами. Начиная коллаборацию с такой командой, значительно проще уменьшить ту самую активационную энергию, чтобы трансформация началась.
Подумайте, кто в вашей организации может быть вот такой forward-looking командой. Иногда они хорошо видны в вашей организации, это тоже очень полезно для трансформации, потому что видимая команда (highly visible team) может делать какой-то важный проект или работать над ключевым куском ПО. Работая с такими командами, потенциально можно привязать трансформацию DevOps к их успеху и их успех к трансформации DevOps.
С этим надо быть аккуратным. Вы всегда можете наткнуться на людей, которые будут много чего обещать, но на самом деле ничего делать не будут, потому что им просто интересно покататься на хайпе. С этими командами трансформацию начинать нет смысла. Поэтому возникает вопрос: как понять, где и с кем работать, а с кем не работать. Чтобы найти ответ, поболтайте на кухне, поспрашивайте у команд, что у кого происходит, кто, над чем и как работает. Это должно помочь найти ваших начальных партнеров для трансформации.
Вторая стадия — Clarify your goals and priorities
Подтвердим и поймем наши цели и приоритеты.
У Васи была проблема: он не мог нормально релизить софт, потому что у него были breaking silos, потому что разработчики перекидывали ему код, потому что он являлся bottleneck в нашем pipeline. И это самая главная причина, почему Вася решил это делать. Он понимает, что нужно что-то менять и эволюционное давление — это то, почему мы это делаем.
Эволюционным давлением является внешняя среда, где мы хотим работать. Мы проводим большую часть своего времени на работе и мы хотим работать там, где работать приятно, удобно, с интересными людьми, с правильными инструментами, а не в трущобах. Это еще одна причина, которая помогает нам изменить организацию, чтобы она от эволюционного давления не исчезла и туда было приятно ходить.
Не последним фактором в такой трансформации и в целях становится Resumé Driven Development. DevOps становится довольно стандартным подходом к разработке ПО. Соответственно, иметь какой-то качественный подтверждаемый опыт в своем резюме — это тоже очень полезно.
Если вы смотрите на другие страны, может быть, как раз на Кремниевую долину, то знание того, чем настоящий DevOps отличается от DevOps-инженеров, вам тоже очень поможет.
Третья стадия — Diagnose the world of the other person
То, что верно для вас, верно и для ваших партнеров. У них тоже есть карьерные цели, они тоже могут планировать изменения в своей карьере. И это является для них целью, которую вы можете помочь им исполнить благодаря имплементации правильного DevOps.
У нас есть прекрасные исследования, которые помогают нам узнать мотивацию людей. Это важно понимать, когда мы пытаемся их уговорить что-то сделать. И, например, в книжке Drive от Дэниела Пинка (Daniel H. Pink) описаны три основных мотивации, которые возникают после того, как решены вопросы с базовой мотивацией: autonomy, mastery и purpose, например, деньги. Эта мотивация может быть использована для того, чтобы убеждать других людей.
Кроме того, если вы люди с техническим бэкграундом, то вы привыкли к системам, у которых короткий фидбэк и детерминированное поведение. Вы написали строчку кода, скомпилировали ее, она скомпилировалась или нет. Дальше вы ее запустили, она делает то, что вы хотели или нет.
К сожалению, с людьми все не так. Люди — это то, что Дэн Ариели (Dan Ariely) называет predictably irrational (ожидаемо иррациональный). Это значит, что длина фидбэка у нас абсолютно неизвестна и система не детерминирована. Можно в этом разобраться, почитав как раз Predictably Irrational или Sway.
Sway — это тоже книжка о том, как переманивать людей на свою сторону, как уговаривать их что-то делать. Это актуально, когда мы хотим понять, что людей мотивирует и как их немного в нашу сторону подкрутить.
Чем выше мы поднимаемся по иерархии нашей организации, тем важнее для людей оставить свой след в истории компании. И успешная цифровая трансформация в DevOps — это legacy на много лет вперед, поэтому это может быть очень интересно тем людям, с кем вы говорите.
Также мы понимаем, что происходит в голове потенциального CIO. Давайте немного погрузимся в мысли ваших коллег, дабы понять, какие вы можете встретить потенциальные барьеры, связанные с их мотивацией стать вашими партнерами в той самой трансформации в DevOps. Их бывает очень много, и вам надо научиться это диагностировать индивидуально. Вот несколько примеров:
- Метрики. Вы рассказываете кому-то, как важно релизить чаще, а этого человека не оценивают по количеству релизов. Его оценивают по стабильности, и чем меньше у него всего падает, тем его больше хвалят. И зачем ему DevOps? Чем меньше шума, тем лучше у вас метрики, которые не сходятся, поэтому этот человек вряд ли захочет делать то, что вы от него хотите.
- Реакция начальства. У вашего потенциального партнера есть свои метрики, цели и свой начальник, у которого есть потенциально другие ожидания от того, чем будет заниматься его команда. И эта реакция начальника очень важна, чтобы понять мотивацию ваших коллег. Соответственно, вам нужно знать мнение и приоритеты не только ваших, но и его коллег.
- Отсутствие интереса. То что вы предлагаете сделать другому человеку, кажется ему скучным. Очень вряд ли этот человек побежит делать то, что вы от него просите.
- Карьерный рост. У этого человека может возникнуть вопрос — как это повлияет на его карьеру, то самый Resumé-Driven Development, поможет ли это нашей организации или нет. Это та ситуация, где highly visible team работает над чем-то важным и есть потенциальные плюшки в конце, если они действительно помогли организации. Аспект карьерного роста — еще один барьер, о котором стоит подумать, выбирая своих партнеров.
- Реакция коллег. Например, в отделе QA все считают, что внедрение DevOps приведет к их увольнению. Появляется у них в команде какой-то умник, который старается внедрить DevOps, а они это видят как прямую угрозу своей работе. Если человек это осознает, то опять же он вряд ли побежит делать то, что вы хотели.
- Нагрузка. Также надо понимать, какая нагрузка на вашем потенциальном партнере, что у них происходит, сколько у них работы и есть ли вообще у них время и желание думать о чем-то новом. Возможно, они захлебываются той работой, которая у них уже есть.
- Нежелание помочь. В конце концов, есть люди, которые просто не очень любят помогать другим людям. Это не в их характере. Соответственно, когда вы попросите у них что-то, скорее всего, они вам откажут.
- Другие приоритеты. Но они могут отказать вам не только потому что они не любят помогать другим, но и потому что у них в жизни есть свои другие приоритеты вне работы — такое иногда случается. Из-за того, что на сегодняшний день их приоритеты поменялись, они просто могут быть не готовы вкладывать дополнительную энергию или время в помощь с вашей трансформацией. Может, просто полночи не спали, у них новорожденный дома, им сейчас вообще не до этого.
С кем бы вы ни говорили и какой бы вопрос ни пытались обсудить, лучше это делать с помощью цифр. DevOps-трансформация не исключение. Источники цифр мы уже упоминали, это The State of DevOps Report и книга Accelerate, которые помогут вам найти performance metrics для вашей организации.
Если в вашей организации все так плохо с DevOps, как в организации Васи, то вы, скорее всего, будете среди low-перформеров. И самая главная и ощутимая плюшка, которую вы можете предложить, особенно начальству вашей организации, — это переехать из low-перформеров в elite, потому что их legacy как раз там. То есть, когда мы переезжаем, то становимся elite. Это то, что запомнится людям. Для того, чтобы эти цифры представить, нам их сначала нужно найти.
Мы довольно много говорили о диагностике мира ваших потенциальных партнеров, давайте поговорим о том, где конкретно искать информацию, при помощи которой можно диагностировать их мир.
Разные организации используют разные системы мотивации. Одна из систем называется OKRS. Наверняка у вас в компании есть свое понимание того, какие у каждой потенциальной партнерской команды есть цели на квартал, на год. Это неплохой источник для поиска мотивации ваших партнеров.
Также можно просто зайти посмотреть в Jira или в другой похожий инструмент на бэклог ваших партнеров и посмотреть, что же они планируют делать, и подумать о том, как можно улучшить то, что уже есть в их планах, или как DevOps-трансформация может помочь достичь их целей.
Многие из команд делают периодически ежеквартальные или ежемесячные презентации того, чем они занимаются. Эти презентации часто складываются на Wiki, и можно найти какую-то запись. Это поможет понять, что же все-таки движет вашими партнерами.
И, естественно, можно просто пообщаться с коллегами в курилке или за обедом и поспрашивать, что у них происходит в команде. Это тоже неплохой источник информации, который вас вооружает правильными данными и помогает понять глубокий внутренний мир и партнеров и команд.
Сейчас приведем несколько примеров того самого глубокого внутреннего мира.
Мы сделали небольшую таблицу, разделили на команды. У вас должен быть другой список или этот список, дополненный другими командами, которыми вы можете воспользоваться для вашей трансформации. А дальше создаем столбцы: те самые autonomy, mastery и purpose и добавим, чего эти команды боятся, потому что вам нужно будет их уговаривать: то, чего они боятся, при трансформации в DevOps на самом деле не страшно.
Cамоуправление разработчиков. Каждому разработчику хочется иметь самоуправление с точки зрения деплоя. Я хочу написать код, сделать code review, нажать кнопочку, хочу чтобы оно без Васи и Пети все оказалось в продакшене у клиентов, предоставило клиентам те фичи, которые они хотят еще вчера, и помогло нам пережить эволюционное давление. И желание разработки независимо от системных администраторов — это то желание самоуправления разработчиков, которым можно пользоваться для мотивации трансформации в DevOps. Потому что одно из правил, одно из желаний культуры DevOps — это автоматизировать вот такие рутинные процессы.
Чего боятся разработчики. Самая большая боязнь разработчика — это то, что теперь сисадмины собираются свалить на них свою работу, нам придется самим ручками деплоить и разбираться в Kubernetes. Это такие страхи, с которыми вам, когда будете уговаривать разработчиков, что DevOps — это не страшно, а где-то даже приятно, придется бороться.
Саморазвитие сисадминов, не в DevOps-инженеров. Для них так называемый мастеринг на сегодняшний день — это понимание, как же превратиться из простого сисадмина в так называемого Site Reliability Engineer. В этой дисциплине сейчас появляется очень много новых подходов, инструментов, например Infrastructure As Code, Terraform, observability. И, если они видят, что трансформация в DevOps (автоматизация — это один из главных столпов DevOps) помогает им развивать свою профессиональную карьеру, становиться более высокооплачиваемыми специалистами, то это та кнопка саморазвития, на которую можно давить у системных администраторов, дабы мотивировать их на партнерство с вами в вашей трансформации.
Страх сисадминов. Боятся они, естественно, потери контроля и полнейшего хаоса. Сейчас мы этим безруким разработчикам дадим доступ к продакшену, а они там всякого наделают. А кто будет отвечать? Конечно, мы, сисадмины, потому что мы отвечаем за стабильность продакшена. Опять же, это вполне обоснованное беспокойство, и с ним вам нужно будет работать для того, чтобы объяснить, как автоматизации pipeline как раз защищают сисадминов от произвола разработчиков в продакшене.
Самоуправление тестировщиков. Из моего опыта общения с командами тестировщиков, один из интересных аспектов самоуправления, которые DevOps им приносит — это варианты иметь те самые environment, instance, инструменты, которые позволяют поднять систему, сделать так называемый destructive testing, когда им надо протестить так, что систему надо перестраивать с нуля, что очень редко им в других ситуациях удается сделать. Та автоматизация, которую культура DevOps приносит нам, позволяет им иметь ту самую самоуправляемость и независимость от других команд или от команды dev или от команды ops, которая дает им возможность делать то, что им надо делать, потому что это все становится возможным с нажатием кнопочки.
Смысл работы. QA занимается тем, что помогает улучшать качество продукта и единственное качество продукта, которое важно — это то, что видят клиенты. Поэтому когда мы убираем эти silos и повышаем видимость всего для всех, то QA имеет гораздо более непосредственное влияние на конечный результат и на качество конечного результата, и поэтому для них смысл работы quality в продакшене достигается гораздо легче с помощью DevOps.
Самоуправление безопасников. Индустрия за последние 20 лет собрала много технических долгов компьютерной безопасности, и это один из потенциальных союзников, которые могут вам помочь двигаться вперед. Качественные безопасники тоже желают самоуправления, ведь им хочется найти какую-то проблему. Уже не говорю о проблеме в коде, а о старой версии библиотеки, потенциальном баге в kernel. Они хотят задеплоить это в продакшн, не стоя в очереди и не соревнуясь с программистом. Надо подумать о том, как привлечь команду безопасности в качестве фасилитатора вашей трансформации. Это значит, помочь им понять, что DevOps на самом деле им сильно помогает иметь самоуправление и позволяет фиксить быстрее.
Страх безопасников. Связан с тем, что опять же все лезут своими ручками в продакшн, делают там что хотят, открывают порты и создают дыры, деплоят непроверенные зависимости и создают кучу дыр в безопасности. А кого в итоге обвинят и уволят, когда это все всплывет? Естественно, безопасников. И с этим страхом вам тоже надо работать и бороться, но способы есть.
Смысл работы продакта. Еще один архетип, который очень часто не является сразу потенциальным союзником для вас, — это product management, потому что для них DevOps потенциально отвлекает команду от работы над самым главным — фичи. И поэтому правильно будет продемонстрировать вашему бизнесу или вашему продакт-менеджеру то, что эволюционное давление и DevOps увеличивают скорость, с которой можно проводить эксперименты или доставлять те самые фичи в продакшен. Обычно качественные продуктовики думают о бизнесе, деньгах, профите и метриках, связанных с тем, как пользователи юзают ваш продукт. Поэтому помогать им достичь цели при помощи увеличения скорости разработки или скорости предоставления, или скорости мутирования вашего ПО в продакшене — это один из подходов, который позволяет привезти с собой продуктовую команду в вашу трансформацию.
Саморазвитие продактов — это как раз о том, чтобы сделать правильный выбор в том, что клиентам нравится, а что нет. Единственный способ сделать этот выбор — эксперименты. Чем больше экспериментов продакты могут ставить, тем более вероятно, что они нащупают то правильное, что действительно нравится клиентам. И автоматизация, pipeline и DevOps позволят продактам делать эти эксперименты намного чаще: их саморазвитие, умение и возможность ставить эти эксперименты очень здорово возрастают с помощью DevOps, поэтому у вас есть возможность найти среди них союзников.
Чтобы потенциально хорошо трансформировать организацию в DevOps, мне надо понимать delivery, customers, quality, architecture, security. А работать-то когда?
Даже если будешь учить это вместо всей своей работы, тебя просто не хватит на то, чтобы знать это все. Никого не хватит. Люди, которые знают все про все, — это единороги, которых не существует. Но мы это делаем другим способом, который называется T-shaped. Это люди, которые знают очень хорошо одну тему — это их ножка. И знают много обо всем другом — это их перекладина. То есть у них ножка, как у Васи, сисадмин, значит они знают Ops, у них налево — Dev и понимают примерно, как работает ПО, а вот направо — QA и они примерно понимают, как достигается Quality Assurance.
Проблема в том что в букве T слишком мало направлений: вниз, вправо и влево. В русском языке мы не ограничены латинским алфавитом. Поэтому у нас есть прекрасная буква Ж, которая описывает shape людей гораздо лучше: вам нужно понимать все эти стороны, но не обязательно слишком глубоко. Если вы думаете, что специализация — это главное, и вы, может быть, слышали, что считаетесь специалистами только после того, как отработали 10 000 часов в какой-то отрасли, я вам очень рекомендую книжку Range от David Epstein — антитезис к книжке Outliers, которая воспевает специалистов. Книжка Range рассказывает о том, как дженералисты справляются гораздо лучше.
Обратите внимание на обложку: в английском нет буквы Ж, поэтому им приходится изгаляться при помощи связок ключей и прочего. В русском переводе, надеемся, будет та самая буква Ж.
В реальной жизни все не так просто. Если что-то квакает как утка и ходит как утка, в отличие от ПО, где duck typing очень помогает, с людьми duck typing работает хуже. Поэтому остерегайтесь делать такие предположения, основываясь на организационной структуре, и все-таки узнайте человека, перед тем как клеить на него одну из табличек, о которых мы рассказали.
Четвертая стадия — Identify relevant currencies, their, yours
Поняв мир потенциальных союзников и коллег, надо поговорить о том, чем вы можете помочь. Мы немного поговорим об обмене валюты, о бартере, о том, чем же можно помочь и какие виды валюты бывают в таком обмене без авторитета, когда вы работаете в IT с партнерами и запускаете трансформацию снизу.
Поскольку авторитет — это не ваша валюта, поговорим о других.
- Inspiration related — вы можете предложить что-то, что здорово вдохновит вашего партнера сделать то, что вам нужно.
- Task related — валюта, связанная с какой-то работой, если вы можете чем-то помочь своему потенциальному партнеру, у вас есть доступ к какому-то ресурсу. Например, кому-то нужен специализированный тестировщик, который понимает accessibility, и он у вас есть в команде. Это тот обмен, который вы можете эффективно произвести и начать партнерство.
- Position related — валюта, которая имеет отношение к месту в организационной структуре другого человека. Если то, что вы хотите от него, поможет ему продвинуться по карьерной лестнице — это отличная валюта.
- Relationship related — валюта, связанная с вашими профессиональными отношениями, потому что вашим командам приходится вести какое-то взаимодействие, и в виде него появляется валюта, которой можно обменяться.
- Person related — валюта, связанная с личностью другого человека. Звучит манипулятивно: жать на какие-то кнопки, которые найдут отклик в этом человеке. Но ничего плохого в этом нет, если в итоге мы это делаем для благих целей.
Речь идет о симбиозе, который надо искать и пытаться создать для того, чтобы найти правильных партнеров и мотивировать их на превышение барьера активационной энергии, дабы начать общую коллаборацию, и том, как эта коллаборация вам может все-таки продолжать помогать раскручивать тот самый маховик, который всегда в самом начале крутится очень медленно.
Приведем пример валюты, которая покрывает все виды валют, о которых мы говорили. Это хакатон. Он покрывает очень много видов валют, потому что на хакатоне вы собираете команду, которая умеет делать все и проводит весь продуктовый цикл от дизайна до продакшена буквально за один день. Естественно, это вызывает то самое вдохновение, когда люди говорят: «Ой, слушайте, это круто, DevOps работает». Кроме того, мы можем использовать результаты хакатона как task related валюту, то есть мы что-то сделали и это полезно кому-то, он будет нам должен и может быть, нам поможет. Также это person related, мы все работали вместе, мы теперь лучшие друзья. Вы знаете, как это бывает на хакатоне. И победители хакатона получают много почестей от самой организации — вполне возможно, это поможет им продвинуться по карьерной лестнице.
Пятая стадия — Dealing with relationships
Мы не можем точно ответить, что мотивирует вашего начальника послать вас, когда вы предлагаете DevOps, но понимание психологии в книжках, которые мы уже упоминали, поможет.
Они помогают выстраивать те отношения, после которых послать вас, когда вы приходите с какой-то идеей, будет намного сложнее.
Шестая стадия — Influence through give and take
Quid pro quo (услуга за услугу) — очень интересная вещь, которая часто была в политических новостях. Давайте поговорим, какие виды услуг и обмена бывают.
Interest alignment — когда у разных команд или коллег есть общие интересы, которые позволяют обменяться чем-то, чтобы достичь общей цели. Очень часто это происходит в том виде, который сегодня называется просто бартер. У меня есть тот самый тестировщик, который умеет accessibility или у меня есть load testing rig, который умеет несколько миллиардов транзакций в час провести, я его могу одолжить. Вот это создаёт и накапливает в копилочку обмен одолжениями, и рано или поздно в такой ситуации этими одолжениями можно обменяться и использовать как начальную энергию для раскрутки того самого маховика.
Хакатон — один из прекрасных форумов, где этот обмен можно начинать практиковать понемногу и постепенно перейти к масштабу более крупной организации.
Даже если вы выучили всю эту модель influence without authority, все прекрасно поняли, прочитали очень много книжек и пришли к своему начальству, начальник вам скажет: «Нет, мы не будем это делать».
И вот тогда мы поговорим о том, что же дальше.
Преграды для влияния
Внешние преграды
- Power differential — то самое место нахождения Васи в организационной структуре далеко внизу относительно человека, который должен принять решение. Надо думать, как правильно к нему подойти.
- Different goals — разные цели с партнерами, на которых вы пытаетесь повлиять или с которыми пытаетесь взаимодействовать.
- Incompatible measurements — несоответствие того, как вас измеряют на работе, как заплатят, как вас будут продвигать по карьерной лестнице.
- Rivalry — соперничество, которое иногда бывает довольно нездоровым и может быть серьезной преградой для вашей трансформации.
Внутренние преграды
- Lack of experience — отсутствие опыта работы с этой моделью. Мы вам представили эту модель перед тем, как вы пойдете и начнете ее использовать, имеет смысл потренироваться на кошечках. Эта модель не про внедрение DevOps, а про любое влияние, и имеет смысл попробовать это на каких-то менее важных задачах.
- Blinding attitude — «я точно знаю, что он не захочет мне помогать» и «этот человек — просто козел, даже не буду к нему обращаться» заранее ограничивают ваши возможности.
- Fear of failing — страх ошибиться.
- Fear of reaction — боязнь мести со стороны тех, кого вы пытаетесь как-то убедить.
Для того чтобы справиться с последним из них, есть способ, который называется BATNA.
Самое худшее — это вообще об этом не думать. Если начнете об этом думать — тоже нехорошо, потому что решите откатиться назад. Это будет сдерживать вас в принятии решений: осознание того, что откатить назад не получится, тоже очень стрессово, потому что вы понимаете, что, может быть, вам придется искать новую работу. Самый лучший вариант — уже это сделать. Начинать эту трансформацию, зная, что вы будете делать, если ничего не получится. Это позволит вам быть наиболее эффективным в ваших усилиях.
Иногда имеет смысл проиграть один из боев, но все-таки выиграть общую войну. Если у вас нет большого опыта в такой модели, начинайте понемногу, не бойтесь проигрывать какие-то не самые важные бои в вашей трансформации и оптимизируйте все для того, чтобы выиграть общую войну трансформации. Не забывайте, что скорее всего в любой организации без какой-то позиции авторитета есть одна так называемая «серебряная пуля», и ее надо использовать в правильный момент и с правильными партнерами.
Самые распространенные возражения
Часто говорят: «Пусть сисадмины дежурят, это их заговор, чтобы я дежурил, а я тут разработкой занимаюсь». Как вы знаете, хороший вопрос — тот, на который есть ответ. А отличный — тот, на который есть слайд. Божественный — тот, на который есть презентация. Вот доклад прошлого года, где в течение часа я разжевываю, почему разработчикам не стоит бояться того, что их посадят дежурить вместо сисадминов.
«Зачем вообще что-то менять, у нас и так все хорошо. И лучшее — враг хорошего». К сожалению, если мы не меняемся, то все плохо, потому что меняется все вокруг нас. Например, история трехлетней давности о том, как Equifax пострадал из-за дырки в безопасности настолько капитально, что CEO пришлось уволиться. Они ничего не делали, а мы не можем себе позволить ничего не делать.
«Колодцы — это хорошо, в них растят настоящих специалистов!». Проблема в том, что, когда мы оптимизируем не в нашем горлышке, то какой бы глубины ни были специалисты, они совершенно бесполезны. Если у нас есть прекрасная разработка, но страдает деплой в продакшн, то какая бы ни была разработка, она совершенно бесполезна.
Элияху Голдратт написал книгу The Goal, которая как раз про оптимизацию процессов. Она вышла в виде комикса, поэтому после того, как мы совсем устали читать 100500 книжек, полистать комикс и поучить оптимизацию очень приятно.
«Регуляции — это ого-го какой тормоз для DevOps, потому что мы не можем сейчас все автоматизировать и дать разработчикам доступ в продакшене, у нас регуляции». Если считать регуляции тем, что надо сертифицировать и проверять каждый релиз — это медленно и нудно. Но на самом деле регуляции не говорят, что надо проверять каждый релиз. Великолепно можно сертифицировать не релиз, а ваш pipeline. И ни один из регуляторов еще не говорил: «Нет, нельзя сертифицировать pipeline» и при помощи этого потерять свои регуляции. Поэтому сертифицируйте свои pipeline, и с регуляцией никаких проблем тоже не будет. А DevOps именно о pipeline и автоматизации и говорит.
«Вот эта история о том, чтобы релизить быстрее — невозможна! Потому что нам нужно гарантировать качество, безопасность и много других вещей. Это все требует времени, мы не можем просто так выкидывать всё в продакшн». Время обычно экономится при использовании какого-то робота или автоматизации. Автоматизируйте все, что надо делать. И на самом деле эта автоматизация помогает не только с тем, что времени будет хватать, а еще с тем, что ее проще будет сертифицировать.
Вася, вооруженный всеми теми знаниями, которые мы предоставили, благополучно трансформировал омский мясокомбинат и стал Chief Information Officer. А потом пошел трансформировать следующую организацию уже сверху. И у Васи дальше было все хорошо. Чего и вам желаем.
Давайте суммируем две ключевые точки доклада.
- Изучайте модель Influence Without Authority, она вам может помочь не только с DevOps-трансформацией, но и с многими другими инициативами в вашей профессиональной жизни.
- Учитесь работать с возражениями.
Это был доклад про влияние на стейкхолдеров, мотивацию и работу с возражениями. А на следующем DevOops, который пройдет 2–5 декабря, будет новая серия от Баруха и Леонида о Васе и его приключениях на мясокомбинате. Спикеры расскажут, какие проблемы безопасности стоят перед современной DevOps-организацией и как эти проблемы решить.
А еще у участников конференции будет возможность пообщаться с самим Патриком Дебуа, который ввел понятие DevOps, когда организовал в 2009 году первый DevOpsDays.
