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

Блеск и нищета автономных команд

Неоднократно упоминавшийся на нашем портале Чарльз Бетц (Charles Betz, среди прочего автор «Digital Practitioner Body of Knowledge (DPBoK)», являющейся базой для соответствующей сертификации от The Open Group, консорциума, разработавшего TOGAF, IT4IT, к которым, кстати, Чарльз тоже приложил руку) опубликовал на прошедшей неделе любопытный фрагмент своей беседы с Agile-классиком Доном Райнерстеном (Don Reinertsen). Дон — автор книг «Разработка продуктов за половину времени» («Developing Products in Half the Time»), «Управление дизайн-фабрикой» («Managing the Design Factory»), «Принципы потока продуктовой разработки» («The Principles of Product Development Flow: Second Generation Lean Product Development»).

В интервью эксперты рассуждают о недостатке автономных (читай «продуктовых») команд – сложности накопления и доступа к экспертизе по сравнению с командами/специалистами с узкой специализацией, привлекаемыми для решения различных задач.

В этом небольшом тексте есть хорошая формулировка проблемы, описанной автором теории ограничений Э.Голдраттом.
«Люди просто не понимают, как измерять производительность общей сервисы {shared service – службы/команды, которые могут быть задействованы в решения различных задач, например, в разработке и поддержке различных продуктов; классический сценарий для функциональной организационной структуры}. Они наивно полагают, что, поскольку они тратят деньги на производство продукции, они должны измерять затраты на единицу продукции. Что ж, если вы измеряете общие сервисы по стоимости на единицу продукции, вы приходите к минимизации времени простоя в сервисе {команде, каждой команде}, поэтому вы переходите к более высоким уровням утилизации. К сожалению, сочетание высокой утилизации и колеблющегося спроса создаёт серьезные проблемы с очередями, которые затем приведут к длительному и непредсказуемому времени отклика.»

Также Дон интересно описывает заблуждение некоторых управленцев.
«Да, люди продолжают приходить ко мне и говорить, что для достижения желаемого результата их программы им нужен прямой контроль над всеми, кто влияет на этот результат. Они говорят: «Мне нужно, чтобы моя команда занималась закупками; мне нужно, чтобы в моей команде были инженеры-технологи; мне нужны QA в моей команде».
Я спрашиваю их: «А зачем они вам?» Они говорят: «Потому что их работа важна и влияет на мою способность добиваться хороших результатов». Затем я говорю: «Вам нужна команда расчета заработной платы в вашей команде?» Они говорят: «Нет, зачем мне это?» Я говорю: «Ну разве зарплата не важна? Разве люди не любят получать чеки вовремя?» И они говорят: «Да, это важно, но бухгалтерия делает свою работу — они делают то, что должны делать».
И я говорю: «Получается, вам не нужна дюжина дополнительных наборов навыков, которыми вы сможете управлять в своей команде. Вам нужно сделать так, чтобы эти общие ресурсы соответствовали тому, что вам действительно нужно. Когда вы работаете с общими ресурсами, которые реагируют на запросы и соответствуют вашим ожиданиям, и ваш реальный уровень обслуживания удовлетворяется, тогда у вас нет желания испытывать дополнительную головную боль, связанную с управлением ещё одной группой специалистов. Вам нужно сосредоточиться на том, как вы измеряете производительность ваших общих ресурсов и как дать людям возможность достичь этой производительности. Решите эту проблему, и вам не будет интересно привлекать их к себе в команду».

Любопытно, означает ли это, что, по мнению эксперта, можно полностью отказаться от автономных команд? Shared services ничуть не хуже. «Вы просто не умеете их готовить»©. Нужно лишь определить правильную систему измерения.
И хотя с последним тезисом в общем трудно поспорить (система измерения действительно должна быть правильной), с таким лёгким отказом от продуктовых команд согласиться сложно.

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

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

  • Лилия Арсентьева

    Интересно.

    Обычно очень сложно сформулировать эти самые требования к конкретному «Shared service», поэтому проще забрать к себе спецов и ими типа управлять.

    Но любая специализация всегда будет эффективнее универсалов.


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

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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как 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 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT