DevOps — не волшебная палочка, которая может улучшить работу компании. Лидер в любом случае необходим. В этой статье Anton Weiss рассказывает историю DevOps, о том, какие качества должен иметь хороший лидер и как менеджерам вести компанию к успешному будущему.
Несколько лет назад, когда DevOps-конференции только получили свое развитие, было много разговоров о том, как привлечь руководство к нашей новой замечательной парадигме. Инженеры из разных организаций выходили на сцену и рассказывали истории побед, чтобы доказать, что DevOps просто необходим для построения бизнеса.
Озираясь на прошлое, мы осознаем, что ситуация кардинально изменилась. Теперь менеджеры приходят к консультантам DevOps и говорят: «Мы хотим внедрить DevOps. Как нам привлечь инженеров?»
DevOps родился как движение. Как и всякая революция, все началось с разгорающегося огня в стоге отчаяния от неэффективности старых способов работы и искры творчества. Именно эта искра сподвигла лучшие умы переосмыслить наш modus operandi и понять, что есть лучший способ управления.
DevOps and Agile — две революции
Когда речь идет о DevOps, часто возникает вопрос о его отношениях с Agile. Некоторые говорят, что DevOps — продолжение Agile, но Agile «не принимал во внимание многие операции, именно поэтому был создан DevOps». Agile был революцией с манифестом и идеями сотрудничества, коммуникации и гуманности.
Как это случается со всеми революционными идеями, Agile утвердился, официально оформился и превратился в широко известную методологию, такую как Scrum, LESS, SAFE и их вариации. Менеджеры увидели потенциал Agile в создании более продуктивной и гибкой организации. Сейчас существует структура, которая позволяет внедрить Agile в несколько простых шагов.
Однако Agile был неоднозначным благом. Во-первых, в действительности все было не так просто: не существует универсального для всех организаций метода управления. Во-вторых, как это бывает с институционализацией, внедрение — всего лишь формальность. Процесс был воспринят людьми весьма отрицательно. Backlog grooming стал важнее, чем работающее программное обеспечение.
Довольно много инженеров выразили искреннее недоверие к практике Agile. Они заявили, что это бессмысленная игра или, что еще хуже, механизм манипуляции, призванный сделать сотрудников беспомощными, подчинить их волю и профессиональное мнение ради достижения краткосрочных финансовых целей.
Читайте: «Мы хотим внедрить DevOps. Как привлечь инженеров?»
Костер DevOps разгорелся так сильно, что Agile потерял свое преимущество, потому что больше не соответствует целям. Несчастные инженеры пишут код и перестают заботиться о системах, которыми управляют. В результате страдают клиенты, страдает бизнес, все остаются ни с чем.
DevOps можно рассматривать как расширение Agile, но это не одно и то же. Во-первых, DevOps не имеет структуры. Есть некоторые методологии и инструменты: непрерывная доставка, инфраструктура как код, контейнеры, комплексный мониторинг. Также существуют архитектурные модели, такие как микросервисы, feature toggles, слабая связанность (loose coupling). Но это только инструменты.
Если вы читали о DevOps, то, скорее всего, слышали о CALMS. Расшифровывается название так:
Culture (Культура);
Automation (Автоматизация);
Lean practices (Оптимизация);
Measurement and (Система мер);
Sharing (Обмен опытом).
CALMS можно рассматривать как краеугольный камень DevOps. Аббревиатура была придумана John Willis and Damon Edwards, а затем разработана Jez Humble. Поэтому если мы вернемся к инструментам и методологиям, то поймем, что они только способствуют автоматизации, системе измерений и в какой-то мере рационализации. Они не организуют ни обмен опытом, ни культуру.
Аббревиатуры дают нам только ALM. В каком-то смысле это интересно, поскольку это совершенно иная аббревиатура, расшифровывающаяся как Application Lifecycle Management. Реализуем мы только ALM. В противном случае мы рискуем попасть в ту же ловушку формальной реализации, как это случается с Agile-инициативами.
Избегая ловушки
Предположим, вы менеджер, который хочет внедрить DevOps в свою организацию. Вы знаете, что структуры нет, а есть простые принципы, которым нужно следовать. Но где-то установлена ловушка (вы либо уже попадали в нее, либо слышали о ней от знакомых). И вы знаете, как избежать этой ловушки: убедиться, что в компании царят культура и обмен опытом, коммуникация и сотрудничество, сочувствие и творчество. Но разве кто-то об этом заботится?
Можете ли вы заставить разработчиков, тестировщиков и администраторов сотрудничать, сопереживать и быть новаторами? Было бы великолепно, если бы вы только сказали сотрудничать, и работники сразу начали бы действовать.
К сожалению, это непросто. Сотрудничество и обмен опытом не основаны на механических действиях. Они управляются эмоциями, а эмоции не активизируются при обучении.
Читайте: «В GitHub мы сотрудничаем гораздо больше, чем между Devs и Ops»
Возникает вопрос: как мы влияем на эмоции? Как вдохновляем и мотивируем? Можем ли мы больше платить менеджерам за то, что они сотрудничают, или уволить за то, что они недостаточно сострадательны? Нужно ли поощрять тех администраторов, которые сопереживают, или разработчиков, которые не боятся экспериментировать? Как мы активируем культуру обмена информацией и экспериментирования? Третьим методом по Gene Kim?
Как вы уже догадались, всего можно достичь с помощью лидерства.
Хотите знать, как начать что-то, так же не поддающееся описанию, как и культура? Лидерство — решение, трудно поддающееся определению. David Wheeler сказал: «Все проблемы информатики могут быть решены другой косвенной адресацией (за исключением, конечно, проблемы слишком большого числа направлений).
Я считаю, что в период крупных организационных преобразований лидерство является средством построения корпоративной культуры. И вы знаете, что лидерство действительно может быть проще, чем кажется. Социологи изучают этот вопрос в течение многих лет!
На самом деле мы можем изложить все основные теории лидерства менее чем за 5 минут. И как сказал Kurt Lewin, известный психолог и исследователь, «нет ничего практичнее хорошей идеи». Так что потерпите, пока я быстро пройдусь по всем теориям, а затем мы посмотрим, как все это связано с трансформацией IT-организаций.
Краткое изложение теорий лидерства
Первые попытки определения того, что позволяет некоторым людям лидировать и что заставляет остальных следовать им, были предприняты несколько веков назад. Все началось с так называемой «The Great Man Theory.» Согласно этой теории лидером нужно родиться. Человеку либо дано быть лидером, либо нет. И если нет, вы не можете стать Александром Македонским. Эта теория была настолько непрактичной, что исследователи (или, скорее, философы) пытались создать список качеств, которыми должны обладать прирожденные лидеры.
Так появилась вторая теория — «The Trait Theory of Leadership». Это была серия исследований, в которых рассматривались индивидуальные характеристики лидера. Теория была более практична: нужно иметь лидерские качества, и люди пойдут за тобой. Отрицательной стороной теории стал слишком длинный список предполагаемых лидерских качеств, при этом ни один набор не мог быть идеальным для всех обстоятельств. Теория была значительно лучше предыдущей, но все еще неприменимой.
Поиск чего-то более практичного привел к созданию «The Skills Theory of Leadership», согласно которой существует набор лидерских качеств (как во второй теории), но преимущество отдается практическим качествам. Суть в следующем: если хочешь, чтобы люди доверяли и следовали за тобой, нужно обладать техническими навыками в своей области. Такие человеческие качества, как убедительность, дипломатичность и учтивость, и концептуальные навыки — способность видеть общую картину и думать стратегически просто необходимы. Это уже то, с чем мы можем работать!
Читайте: «Понимание корпоративной культуры в SoundCloud»
Следующая теория — «Leadership style theory». Согласно ей ваш стиль лидерства — ключ к успеху. В теории рассматриваются разные стили. Например, «инициативный и демократичный лидер» или «сторонний наблюдатель».
Вероятно, самая известная теория, основанная на стилях, — «The Managerial Grid». Теория гласит, что лидер должен придерживаться стиля, который позволяет быть дружелюбным, но в то же время и бескомпромиссным. Эта теория имеет достаточно прочную основу. Но откуда тогда взялись другие?
Теория «Situational Leadership» утверждает, что не существует шаблонной модели. В разных ситуациях требуются разные черты, навыки и стили, поэтому лидер должен адаптироваться к ситуации. Если применить теорию к нашей сфере, то внедрение DevOps в быстрорастущий стартап требует другого подхода, нежели внедрение в крупный корпоративный гигант. Одни и те же цели в одном случае требуют больше дисциплинарных знаний, а в другом случае — вдохновительного подхода.
Похожая теория называется «The Contingency Theory of Leadership». В то время как предыдущий подход предполагает, что ситуация статична и лидер должен адаптироваться к ней, «The Contingency Theory of Leadership» гласит, что стиль лидера фиксирован. Может быть так, что лидер больше ориентирован на задачи, чем на людей. Таким образом, лидеру достаточно сложно соответствовать ситуации. Итог — лидерство зависит от соответствия стиля лидера условиям. Приняв во внимание особенности IT-сферы, можно заключить, что тот, кто успешно возглавляет реализацию DevOps, не обязательно подходит для преобразования в корпоративных условиях.
Читайте: «DevOps может испытать кризис среднего возраста в ближайшие 10 лет».
Следующие две теории противоположны. «Transactional Leadership»основана на принципе взаимности. Люди будут следовать за лидером, если будут получать что-то взамен. Поэтому лидер должен создать систему вознаграждений и наказаний и внимательно следить за тем, что происходит.
«Transformational Leadership», напротив, гласит, что лидеры добиваются личной заинтересованности и приверженности сотрудников, а не используют подход «услуга за услугу». Иначе говоря, они добиваются результатов путем активных преобразований в корпоративной среде.
«Servant Leadership Theory» представляет собой смесь двух предыдущих теорий. Если лидер ставит в приоритет потребности сотрудников, прислуживая, а не обслуживаясь, то тем самым создает доверительную и партнерскую среду и добивается более высокой производительности. Теория была популяризирована многими исследователями в последние десятилетия, но ее корни намного глубже. Например, сила Иисуса была и остается результатом сострадания, служения и жертвы. Людям нужны любовь и сострадание, а не принуждение и страх.
Четыре задачи лидерства DevOps
В каждой из рассмотренных 10 теорий своя истина. Но более важным является вопрос их применения в DevOps, ведь мы — разработчики DevOps, а не теоретики.
Итак, чтобы дать некоторые практические советы, мы создали короткий список под названием «Четыре задачи лидерства DevOps».
Задача 1. Расскажите историю
Обращаясь к списку теорий, я убедился, что самый важный урок можно извлечь из «The situational leadership theory». Мы должны начинать с оценки ситуации. Для нового проекта с участием небольшой многофункциональной группы «a skill-based leadership» всегда работает лучше всего. Мелкомасштабная и относительно низкая сложность позволяет квалифицированному руководителю контролировать техническую реализацию, человеческие отношения и стратегическое видение.
Фактическое преимущество DevOps наиболее очевидно в больших сложных средах. Среды, которые изначально не были построены с учетом принципов DevOps нуждаются в трансформации. И для трансформации нам нужна, как вы догадались, transformational leadership.
Нам необходимы реформаторы, которые могут объяснить, почему DevOps, и создать лучшее видение мира, который может вдохновлять и мотивировать сотрудников. Нужно быть строителем корпоративной культуры. Это легче, чем кажется. Культура — это просто история, которую вы рассказываете. Но это должна быть подлинная история, и лидерство должно быть частью этой истории.
Итак, первая задача — расскажи историю! Если вы менеджер, занимающийся внедрением DevOps, вам нужно либо стать рассказчиком DevOps самостоятельно, либо найти того, кто станет этим рассказчиком.
Задача 2. Будьте охранником
Как только вы заставили сотрудников поверить в вашу историю, нужно подготовить почву для экспериментов. Дорога к совершенствованию — не прямой путь. Главная причина, по которой мы так неохотно делаем шаг, — страх споткнуться. Нам нужен лидер, чтобы поддержать в случае падения. Это «the servant leader», который готов жертвовать не сотрудниками, а ради сотрудников.
В прошлом году у нас было несколько клиентов, которые пришли с вопросом: «Сколько людей я могу уволить, если реализую DevOps?» Я всегда говорю: «Если вам нужно их уволить, увольняйте сейчас, потому что не сможете наладить сотрудничество под угрозой сокращения численности персонала».С другой стороны, в то время как нехватка ресурсов является сложной задачей, она также может обеспечить гораздо больший вклад в творчество и воображение инженера.
Задача 3. Создайте Kernel team
«Transformational leadership» и «servant leadership» необходимы, но недостаточны. В DevOps работа осуществляется в независимых самоорганизующихся командах. Мы считаем, что они такие же гибкие и динамичные, как и лучшие стартап-компании. В противном случае стартап-компания сперва завоюет ваших разработчиков, а затем и бизнес.
Таким образом, нам нужны «the skill-based leaders», чтобы тренировать и координировать действия своих команд.
Задача 3 ориентирована на группу квалифицированных лидеров для поддержки трансформации. «The transformational leader» будет стимулировать их сотрудничать. Взамен они будут эскалировать общую картину направлений организации. Мне нравится называть это Kernel team, однако в теории управления эта концепция известна как Synerteam, или целевая группа, ориентированная на анализ проблем и обеспечение бесперебойного взаимодействия всех бизнес-единиц.
Задача 4. Будьте стимулятором общения
Говоря о четвертой задаче, я хотел бы упомянуть Martin Luther. Лютер не был первым реформатором, который заставлял католическую церковь идти по неправильному пути. Но он определенно стал самой значительной фигурой в протестантской реформации, и причиной было массовое общение.
Самой важной работой Лютера было Ninety-Five Theses, где он четко изложил практики католического духовенства. Он утверждал: чтобы быть хорошим христианином, не нужно покупать индульгенции. Достаточно верить в Бога. Опять же, Лютер не был первым, кто об этом подумал. Но он первым воспользовался новой технологией — печатной машиной Gutenberg. Его идеи были напечатаны, распространены по всей Европе, способствовали установлению лютеранства и имели не только богословские, но и социальные последствия.
Чтобы что-то изменилось, необходимо сообщить об изменениях. Мы все слышали о влиянии социальных сетей на the Arab Spring. Если хотите, чтобы в вашей компании царила весна, организуйте открытое общение в той форме, которая кажется самой естественной для современных инженеров, будь то Slack, Yammer, Riot, Confluence или Bitrix. GitLab-команды называют это «Conversational Development». Идея ChatOps, популяризированная Github, тоже очень востребована.
Marshall McLuhan сказал: «The medium becomes the message». Если хотите сообщить об изменении, измените каналы связи. И не ждите, что это произойдет в тот же миг. Так же, как правительство несет ответственность за поддержание состояния дорог и электрических линий, руководители организации ответственны за создание, продвижение и поддержание корпоративных каналов связи. Сделайте работу видимой.
Заключение
Конечной целью DevOps-трансформации является создание самоорганизующейся системы, в которой все команды активно взаимодействуют просто потому, что доверяют и уважают друг друга. Это прекрасный образ, как образ кодовой базы с нулевыми ошибками.
Однако второй закон термодинамики ясно показывает, что в изолированной системе всегда будут возрастать энтропия и беспорядок. Порядок не может существовать без внешних отношений. Это означает, что по мере того, как DevOps становится реальностью, роль руководства должна изменяться. Роль органа формирования и управления меняется на роль канала, соединяющего организацию с внешним миром.
Удачи во внедрении DevOps. Чем дальше вы зайдете, тем больше вам будет нравиться то, что вы делаете.