DevOps: команды будущего или утопия?

Совсем недавно мы писали про разнообразие существующих экзаменов по DevOps. Как партнёры EXIN, мы, в первую очередь, обратили внимание на их программу сертификации. В связи с чем плюс-минус дружно погрузились в изучение мануала по подготовке и указанной в нём литературы (кто не успел это сделать раньше). Полагаю, некоторые, а, может быть, и многие из наших читателей уже изучили упомянутый мануал. Что интересно, известная книга The Phoenix Project позиционируется в нём, как "всезамещающий" источник знания. Откуда такая формулировка, хотите знать? Всё просто, в мануале есть раздел "Подготовка", в котором прямым текстом сказано следующее:

Подготовка (training) — это обязательная часть сертификации. От кандидатов ожидается значение базовых принципов DevOps, а также концепций Lean и Agile.

А вот дальше — внимание! Самое интересное!

Необходимые знания могут быть получены:

  • посредством онлайн-обучения (e-learning);
  • посредством посещения тренинга "Введение в DevOps";

ИЛИ

  • посредством прочтения книги The Phoenix Project.

Итак, первоисточником мудрости является упомянутая книга. На мой взгляд, позиционирование книги уж слижком навязчивое. Поэтому глаз невольно тянется к разделу "Список литературы", благо он, всё-таки, есть. Справедливости ради надо отметить, что "Проект Феникс" в этом списке значится в разделе "Дополнительная литература" с грифом "Highly recommended". Противоречиво всё это выглядит . Или нет?

Мы уже ранее делились с уважаемыми читателями информацией, что почитать про DevOps. Сегодня же хотелось бы затронуть некоторые аспекты "девопса", описанные в книге, не вошедшей в упомянутый список, но в мануале подготовке фигурирующей первой в списке литературы. Речь о книге "Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale". C особым интересом я заглянул в главу 3 "Collaboration: Individuals Working Together". И знаете, многие сейчас наперебой расхваливают DevOps, а меня прочтение отдельных фрагментов упомянутой книги привело в некоторое замешательство. Попробую объяснить.

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

  • цели — диктуемые руководством и персональные;
  • имеющиеся опыт и знания (background);
  • предпочитаемый стиль работы;
  • профессиональный и личностный рост;
  • стиль общения;
  • доверие и взаимопонимание в коллективе.

Слова, написанные там, конечно же правильные. Например, ни для кого не новость, что люди по-разному воспринимают свою работу. Для кого-то текущая позиция — важный этап в карьере, из которого надо выжать максимум. Для других — просто некая работа, которую надо делать в данный момент, пока не нашлось "работы мечты" или не заработал на полную мощность собственный параллельный проект. Также не секрет, что люди, которые хотят учиться и развиваться, далеко не всегда хотят этого одинаково, в одинаковом контексте. Объединённые вместе, в кросс-функциональную DevOps-команду, "разношёрстные" сотрудники начинают испытывать целый комплекс ранее не знакомых им трудностей. Имеющийся опыт не всегда является хорошим помощником в их преодолении, так как до этого люди могли работать в очень различной по структуре и масштабу среде. Например, кто-то работал в крупной компании, а кто-то поднимал стартап. И, в общем-то, понятно, что нужно как-то создать такую среду, в которой люди будут учиться друг у друга и, таким образом, развиваться. И что среда должна быть сбалансированной, и что люди с различными психотипами по-разному в эту среду встраиваются и по-разному на неё реагируют. И далее, одновременно с рекомендациями, как учесть особенности людей и создать для них комфортную среду, даётся рекомендация формировать команды из РАЗНЫХ людей. С разным опытом, разным психотипом, включая любителей работать по ночам и спать до обеда наравне с "жаворонками", новичков и товарищей с "короной". Таким образом в команде заведомо создаётся определённый конфликт, продуктом которого является более эффективная работа команды в целом. При этом, кстати, товарищи "с короной" далее относятся к не очень приятной категории людей с "закрытым сознанием", а попросту — не готовых меняться, уверенных в собственной исключительности, а потому ограниченных. Как мы знаем, очень мало кто способен всегда оставаться супер-гибким и готовым учиться новому и новому. Получается, что почти все сотрудники со временем перестают удовлетворять требованиям DevOps. А если выпал из контекста, стал слишком много о себе думать — свободен, дай место тем, кто пока ещё растёт.

Итак, похоже, что мы являемся свидетелями формирования новой элиты от ИТ — "Девопсов". Элиты, которая призвана стать сверх-гибкой, саморазвивающейся, супер-эффективной. Элиты, которая будет безжалостно сбрасывать весь "балласт", который не вписывается в контекст. Лично мне сейчас привиделась ITIL-овская "мясорубка", из которой сыпятся кости сотрудников, которые перестали меняться. DevOps-команды, видимо, должны стать чем-то вроде сверхэффективного спецназа, в который попасть можно только после жёсткого отбора. Понятно, что в нашем высоко-конкурентном мире это — правда жизни. Не можешь адаптироваться и меняться — тебе нет места под солнцем.

Всё, вроде бы, правильно. Но, как вам кажется, не похоже ли это всё на утопию?

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

Комментарии и мнения

  1. Вячеслав Алпатов

    Вот только не надо смешивать DevOps и всю ту пену, которую вокруг начали активно поднимать (вернее продавать) всякие- "тренеры, консультанты, коучи и прочие". Уж вами же и подмеченный пункт про навязчивое рекламирование книжки и курсов наводит на печальные мысли, как об "экзаменаторах", так и об "экзаменах". ITIL плохо продается? Или ЦА услуг расширяем? Вот так ценность сертификатов и дипломов аккуратно отправляется к нулю...

  2. Дмитрий Исайченко

    Итак, похоже, что мы являемся свидетелями формирования новой элиты от ИТ — "Девопсов". Элиты, которая призвана стать сверх-гибкой, саморазвивающейся, супер-эффективной. Элиты, которая будет безжалостно сбрасывать весь "балласт", который не вписывается в контекст.

    Как-то Ницше напомнило 🙂

  3. Яковлев Андрей

    За прошедший период, я сделал две вещи: 1. прочел "проект "Феникс"" (местами по диаганали, технические моменты мне были ясны, потом перевод выполнялся с технического жаргона, от чего скорее путает, дежавю полное. 2. Посмотрел на проблему взаимодействия разработки и поддержки "вблизи". Значительное количество проектов буксуют на инженерной поддержке. Особенно небольшие фирмы и проекты компаний, где DevOps — просто очередное красивое слово. Вот они точно сертификатов себе накупят (и сотрудникам), можно начинать печатать. Вкратце. Изначально упор сделан на разработку (Develpment), так как кадры решают все. Вместо сисадминов используются разработчики. И вот тут замента разница. Они лишь продвинутые пользователи, но не системные инженеры! Ладно затык обнаружен, но команда опять  полняется по критериям близости к разработке. Принципиальная нужность инженеров не очевидна. Несложно определить, требуют кучи навыков кодера и опускают азы для инженера. "Авианалет был неудачным, надо увеличить группу бомбардировщиков, поставив части из них задачу по прикрытию". Ага, за штурвалами перехватчиков ПВО  ничего никто не поменял  точно также устроят "черный вторник". Точно также проблема №2, "мифический человеко-месяц", команду наращивать перед дедлайном бесполезно. А так — еще и вредно.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
7
Учебный курс:
Основы ITIL (очно)