Совсем недавно мы писали про разнообразие существующих экзаменов по 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-команды, видимо, должны стать чем-то вроде сверхэффективного спецназа, в который попасть можно только после жёсткого отбора. Понятно, что в нашем высоко-конкурентном мире это – правда жизни. Не можешь адаптироваться и меняться – тебе нет места под солнцем.

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

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы