Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 3

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

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

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

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

  • Яковлев Андрей

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT