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

DevOps: неудобные вопросы про начальников

Я не знаю примеров создания крупных компаний в несколько тысяч сотрудников с нуля – когда собрались инвесторы, сказали друг другу: “Отличная идея, сделаем на ней бизнес!” – и сразу план по найму в сотни и тысячи позиций. В мире всякое бывает, и такое возможно, просто мне не встречалось.

Все компании, которые мне известны, создавались, развивались и росли постепенно. Какие-то быстрее, какие-то медленнее. Как это обычно происходит с точки зрения ИТ-сотрудников? Упрощённо картина выглядит так: у некого бизнеса возникает потребность в информационных технологиях, как правило – на очень ранней стадии. Появляются специальные ребята, айтишники. Среди них есть несколько программистов, несколько администраторов, и один из них становится к тому же руководителем этого отдела (в своём резюме он потом напишет: “возглавил вновь созданное структурное подразделение“). Заметим, что все эти айтишники занимаются непосредственными обязанностями по нанесению пользы. Не пишут бумажки, не рисуют планы, не согласовывают стратегии, а делают дело. Включая начальника.

Компания растёт. Ребята не справляются, не успевают, поэтому нанимают новых, дополнительных. Есть поверие, что эффективно управлять более чем семью сотрудниками невозможно, поэтому ресурсы (простите за цинизм) объединяются в небольшие группы, у каждой из которых возникает выделенный или не очень руководитель, подчиняющийся вышестоящему, который подчиняется ещё выше, и так далее. Уровней управления в среднего размера компании может быть до пяти-семи: департамент, служба, управление, отдел, группа, я даже встречал термин “бюро”. Выкручиваемся как можем.

Чем выше по уровню иерархии, тем меньше руководитель вовлечён непосредственно в создание ценности (если вы понимаете, о чём я), тем менее компетентным он должен быть. Однако размер оплаты труда меняется в противоположную сторону: чем выше, тем дороже для компании обходится начальник. Возможно, это связано с увеличением зоны ответственности, но не везде.

Теперь же мы говорим про DevOps. Давайте искать новые способы получения пользы от информационных технологий! Вроде, можно быть устроенными иначе, и давать результат не хуже. Что это такое – быть устроенными иначе? Среди всех аспектов применения DevOps одна из самых больших перестроек происходит именно в группировке и организации ресурсов, создаются самоорганизующиеся продуктовые команды. Им начальник (в теории) не нужен, тим-лид ни к чему, координатор не требуется и супервайзор не является необходимым.

И вот тут возникают неудобные вопросы. Например, правда ли можно работать без начальников? Те, кто служил в армии, понимают, что такого не бывает. Но служили-то не все, поэтому есть сомневающиеся – а вдруг, и правда можно? Как узнать, как понять? Какой должна быть команда, чтобы работать самостоятельно? Что уметь? Как думать? Нужен ли переходный период – первые полгода, так уж и быть, с начальником, а уж дальше сами?

Второй неудобный вопрос – предположим, мы хотим сохранить руководителей в командах, пусть на время. Откуда их взять? Понятно же, что просто назначить бывших руководителей отделов на роли тим-лидов – тупиковая ветка, от них теперь требуются другие знания, другие умения, готовность экспериментировать, осознание временности своей роли, создание новой культуры выполнения работ и так далее. Назначить тех же бывших начальников – такое же зло и глупость, как переквалифицировать бывших руководителей проектов в скрам-мастеров (чем все вокруг занимаются, похоже).

Следующий неудобный вопрос – куда девать армию бывших начальников? Они все появились в компании не просто так. Каждый когда-то был нужен и важен. Многие очень хорошо знают предметную область, особенности организации, да и даже особенности отдельных личностей – как исполнителей, так и смежников, сотрудников бизнес-подразделений. Терять такое знание (недокументированное нигде) никак не хочется, но и создавать искусственные должности для тех, кто теперь не особо нужен, также странно. Ведь за это придётся кому-то заплатить, и, вспоминая уровень зарплат и бонусов, заплатить немало.

И последний неприятный вопрос. Как теперь первому лицу в ИТ (CIO, либо ИТ-директору – в зависимости от компании понимание первого лица разнится) обеспечить управляемость конструкции? Более того, как эта конструкция будет выглядеть? Нам всем понятна и привычна иерархия – все компании вокруг устроены именно так, наши и нанимаемые сотрудники мыслят в терминах подчинённости и орг.структуры. А вот что такое сеть, или холакратия, нам известно только из литературы, даже пример в дикой природе толком не найти.

Я не случайно назвал свою заметку “Неудобные вопросы” – ответов я давать не предполагал, так как по многим пунктам у меня пока есть только соображения, но не опыт. Сейчас мне важно и интересно, что вы думаете по данной теме. Актуальны ли эти вопросы? Есть ли на них ответы? Есть ли у вас опыт перестройки от иерархии в новую прекрасную реальность? Существует ли она больше, чем в чьём-то воображении?

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

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

  • Максим

    Когда ответы то будут? 🙂 Хоть мысли, да ещё бы с примерами.

    Вопросы у всех есть, это легко.

    • Постановка проблемы – первый шаг к решению. Без понимания задачи решения не найти 🙂

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

    Олег, а вот не к началькам. Люди есть люди. У Вас DevOps в вакууме , без интриганов, зависников. Я лично считаю самоорганизацию возможной, но организация…. DevOps часто трещит из-за того, что ценность производят Dev

    • Андрей, вопросы отдельных личностей никуда не деваются, их придётся решать. Но в этом аспекте организация DevOps не имеет специфики, и ответы есть в известной области управления организационными изменениями. Повторюсь, это не уменьшает значимости вопросов, но мне сейчас интересны особенности именно DevOps.

  • Ivan

    «Есть ли у вас опыт перестройки от иерархии в новую прекрасную реальность? Существует ли она больше, чем в чьём-то воображении?»
    Есть классические примеры Buurtzorg, Zappos, Morning Star, Patagonia.
    Из российских экспериментируют Mindbox, Semrush, Scrumtrek, 2ГИС.
    Чем дальше, тем с ирерархией сложнее https://www.youtube.com/watch?v=vc9IX1M48Gc

    «Правда ли можно работать без начальников?»
    А что даёт начальник? Не идеальный из книжек, а тот с которым работают команды каждый день. Можно ли ценные функции разнести по команде?

    «предположим, мы хотим сохранить руководителей в командах, пусть на время. Откуда их взять?»
    Обучить. Привлечь со стороны.
    Смешать подходы.

    «Какой должна быть команда, чтобы работать самостоятельно?»
    Например, находиться на стадии Performing по Такману.
    Можно взять другие модели.

    «Куда девать армию бывших начальников? »
    Предложить роли в новой структуре. Как показывает опыт, несогласные уходят.

  • Андрей, другой

    Выскажусь. Зачем нужен начальник? – можете называть его как хотите(начальник, руководитель, team leader (или Gruppen Führer по-немецки:) )), но во всех процессах должен быть человек, который скажет: мы тут все обсудили и Я (именно Я) решил. Т.е. нужен человек, который будет брать на себя риски по принятию решений (к стати, именно по этой причине у него и оплата выше). Самое неприятное состоит в том, что не всем это дано. Человек должен быть начальником по своему мировоззрению, а не по назначению приказом. Ну и квалификация тоже должна быть ого-го, иначе будет просто самодурство. Самый яркий для меня пример такого руководителя – финансовый директор FIAT в конце 90-х. Еще есть проблема с переходом от штатной структуры(когда люди привязаны к должностям и не понятно, чем именно они занимаются) к ролевой модели(когда люди привязаны к конкретным операциям, но не понятно, кому они подчиняются). К стати, у меня есть негативный пример про матричную модель. В одной очень крупной западной ИТ компании парень на почве стресса от развода “забил” на работу и неделю ходил играть в гольф. Каково же был его изумление, что по его возвращении его отсутствия так никто и не заметил. Руководитель одного проекта считал, что он занят на другом, и наоборот.
    Но руководитель на каждом уровне нужен, иначе будут совещания, обсуждения и бесконечное хождение по кругу. Таких примеров у меня завались, особенно сейчас.

  • Алексей Глушаков

    В названии статьи легкая провокация 🙂 Эти вопросы не неудобные, а неизбежные. И радует, что все приходят к одним и тем же вопросам. А вот ответы, с ними сложно.
    В статье упущен один важный момент, это собственно переход от одной модели к другой. Есть организация, в которой и руководители и работники живут в рамках знакомой и устоявшейся модели, и невозможен сразу переход к принципиально иной модели. Прежде все потому, что в головах еще долго будет оставаться старая модель. Отсюда появляется желание на переход оставить старых начальников. Но это тупик, это именно те люди, которые всеми силами будут защищать старую модель. По сути, паразитная активность обеспечена. Из работников вытягивать тим-лидов тоже проблематично, работник он ведь тоже “старовер” и не понимает, что от него хотят, “нового”.
    Попытка донести светлое сразу всей компании у нас провалилась, со старта стало понятно, что это “не понятно”, а значит “не нужно”. А дальше множество доводов почему нет, сложные модели взаимодействия, управления ресурсами. В итоге пришли к тому. что надо сначала создать культуру, чтобы каждый пришел к мысли что как то оно не удобно работать в старой модели, долго, дорого. малоэффективно, хочется по другому. По пути отсеются те, кто не хочется меняться, не хочет быть частью новой культуры. И тогда есть шанс что изменение произойдет изнутри, а не снаружи.

    • Алексей, в точку!
      Про переходный период в заметке акцентировать не стал, хотя понятно, что тут есть над чем подумать.
      Меня смущает Ваш вывод. Ждать изменения культуры можно бесконечно долго, особенно при условии, что нынешних начальников всё устраивает, а в новой схеме им места может и не найтись. Ну или им работать придётся, а не руками водить 🙂

      • Алексей Глушаков

        А я про начальников ничего не писал. 🙂 Даже из вашей статьи понятно, что начальники “старой формации” не приживутся и абсолютно не эффективны в новых реалиях. Ценность смогут приносить только те, кто способен осознавать изменения и перестраиваться в работе. Поэтому вообще не вижу смысла тратить время на тех, кто гарантированно “потеряется” по дороге.
        Речь шла про специалистов, из которых и будут собираться те самые самоорганизующиеся команды. У них в головах должно провернуться, чтобы пришло осознание, что изменения нужны и неизбежны. Тогда они все сделают сами.
        Мы сейчас собираем маленькие команды на небольшие цели (до месяца работы команды) и участвующие сами осознают, насколько это удобно прежде всего им. И в следующий раз люди идут в такую команду сами, потому что знают что там “хорошо”. Правда сейчас со старта в команде нужен координатор(это не начальник в привычном понимании), людям сложно выстраивать взаимодействие между собой. Сильна привычка “моя хата с краю”, и постоянно ищут указующий перст руководителя. Ну и противостояние Dev и Ops никто не отменял. Поэтому координатор строит те самые линия взаимодействия внутри команды, а дальше команда работает сама.

  • Leonid

    Мне кажется, что проблема несколько надумана, если коротко, «начальник» вовлечен в создание ценности через обеспечение работоспособности команды, условно говоря, КПД команды разработчиков без начальника 10%, а с начальником 90%.

    • Леонид, я не согласен.
      Держать начальника в каждой команде из 5-9 человек – дорого, особенно если толком непонятно чем он должен заниматься, какую давать ценность, кроме слов “руководить”, “отвечать”, “контролировать” и “подписывать зарплату” (я утрирую, но именно такие “функции” зачастую приписывают руководителям).
      И более серьёзный аргумент: скорость работы команды без начальника может быть сильно выше, чем с таковым. Потому что руководитель, не создавая ценности, создаёт видимость работы через обсуждения, совещания, разборы, согласования и утверждения “решений”. И выделение/перераспределение ресурсов, которого можно избежать.

      • Leonid

        Про затраты:
        В общем случае «начальник» должен распределять задачи и контролировать их выполнение, но этим ведь его обязанности не ограничиваются. В ИТ «начальники», от старшего группы, до руководителя отдела, обычно являются и хорошими специалистами в своей области и вносят значительный вклад в «создании ценности», при этом, их ЗП не на много выше, чем у остальных сотрудников. Так что я не могу согласится с тем, что «начальники», даже в небольших командах, это «дорого», конечно, если не давать каждому кабинет и секретаршу.
        Про скорость:
        Да, бывают случаи, когда «начальником» оказывается настоящий вредитель, но это несчастные случаи. В норме же «начальник» всегда повышает КПД подчиненных. Именно разность КПД команды с начальником и без него и определяет ценность «начальника».

  • Алексей

    Не вызовет ли ставка на самоорганизацию команды удорожания процесса набора специалистов? Есть ощущение, что такая вероятность есть, т.к. к оценке технических качеств специалиста добавляется нормальные такие пороги по совместимости с командами. Т.е. нельзя будет взять человека, который только частично стыкуется с командой, он должен подходить к команде идеально. Иначе возникнет вероятность, что самоорганизация не сработает, а точки принятия решений, которая могла бы обозначить правила игры и заставить им следовать, тоже не будет.
    Опять же, я пока не могу сообразить, как при таком подходе без лидеров будут обеспечиваться следование стратегическим целям. Ну не верю я что вся команда из 5-9 человек будет хорошо ими владеть, чтобы на их основе коллективно принимать решения. Таким образом наиболее вероятным будет ситуация, при которой выделится человек, который будет выполнять роль лидера. Либо на такие команды будут прилетать уже задачи декомпозированные до уровня, где эти самые решения принимать не нужно будет.

  • Виталий

    Здравствуйте, Олег!
    Вопросы действительно не удобные.
    Моё мнение.

    1. Термин Начальник возможно не совсем подходит. От него веет СССР и зоной, стереотипом из прошлого. Чем-то авторитарным. Это уже впечатано в подсознание общества. Поэтому люди на него так холодно реагируют. В современных реалиях я бы использовал термин Лидер или Руководитель. Он правильнее отражает суть этой роли.

    2. Без Лидера ничего не будет работать. Законы природы никто не отменял. Везде есть Альфы, Беты, Прайды и т.п. Иерархия основанная на роли. Даже в группе из 2х человек всегда выявляется Лидер. Работа условно без Лидера в некоторой степени возможна только от рождения до младенчества организации.

    3. Роль Лидера отлично разъяснена Питером Друкером. Если команда готова самостоятельно решать эти задачи, уж не знаю как, то наверное без Лидера можно обойтись. Но я считаю, что команда просто зайдёт в коллапс.

    4. Искать новых руководителей только в своём “котле”. В книге “От хорошего к великому” эта тема раскрыта. В 10 из 11 Великих компаний лидерами были люди из этих же компаний. Тогда как их конкуренты нанимали людей со стороны. И проигрывали.

    5. Руководителям старой формации: тех кто способен измениться, кто понимает вектор давать этот шанс, давать другие задачи, новые направления. Кто не способен, убирать.

    6. Только так можно обеспечить управляемость, в том числе для CIO.

  • Алексей

    Наша компания прошла этап формирования DevOps команд. проблема начальников, на мой взгляд, несколько раздута и надуманна.
    Роль начальника (руководителя, лидера и т.п) в любом случае нужна. Всегда должен быть человек, который отвечает за результат, за направление, выбирает что именно делать из вороха нагенерированных командой идей и в какой последовательности. У любой команды, формирующей ценность, вокруг всегда другие люди, не входящие в команду, но имеющие потребность взаимодействовать с командой, например, подразделение отвечающее за поддержку продукта (ценность=продукт), за взаимодействие с клиентами и т.д. Точкой входа для них так же должен быть кто-то один, отвечающий за распределение задач внутри команды.
    У нас для каждого продукта (aka ценности, создаваемой командой) есть Бизнес Владелец Продукта (больше человек Бизнеса, который знает стратегические планы компании и участвует в их разработке) + Технический владелец (условный Технический Директор Продукта, отвечает за выбор технологий, которые используются для разработки продукта).
    И, да, они изнутри компании, давно работают, имеют колоссальный опыт и знания, не стоят на месте и всячески развивают как себя так и свои команды. Со стороны на эти роли очень сложно найти человека, у них прежде всего должен быть авторитет внутри самой же команды, иначе ломается коммуникация внутри команды.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM