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

Стандартизованный инструмент управления работами?

Публикации DevOps Forum – огромный вклад в свод знаний о DevOps. Я всегда многому у них учусь. Но с последним выпуском я не могу согласиться. Это Преодоление неэффективности в системах управления работами. Я не согласен с тем, что внедрение стандартизованной системы управления работами необходимо для визуализации.

Мы рекомендуем выбрать один инструмент, что противоречит распространённому принципу, согласно которому команды должны иметь возможность выбирать свои собственные инструменты. Гибкость важна для команд, но есть ряд ключевых областей, в которых стандартизация приносит больше пользы, чем возможность для команд использовать различные инструменты. К ним, в частности, относится система управления работами, обеспечивающая удобство визуализации для тех, чьей обязанностью является контроль выполнения этих работ.

Я могу согласиться с этим при одном условии: речь идёт об одном потоке создания ценности.

IT4IT – это лучшая из известных мне моделей, описывающая фундаментальные потоки ценности в ИТ. В ней описаны четыре потока: Strategy to Portfolio, Require to Deploy, Request to Fulfill и Detect to Correct. Преимущества от использования единого инструмента в пределах любого из потоков создания ценности, чтобы упростить визуализацию, очевидны. Но пользы от попыток заставить людей во всех потоках использовать один и тот же инструмент визуализации, на мой взгляд, немного.

Если бы написанное в этой статье было ограничено рамками потока создания ценности Require-to-Deploy – привычного контекста DevOps – у меня не было бы вопросов. Но в ней говориться об ИТ в целом. На мой взгляд, в этой статье сделано опасное утверждение, которое может привести к войнам между системами управления разработкой ПО, такими как Jira, и операционными инструментами, такими как Servicenow и Remedy.

Ключевое слово в DevOps-автоматизации – цепочка инструментов. Неотъемлемое условие заключается в том, чтобы работа проходила через каждый поток создания ценности и, при необходимости, передавалась между ними. Конечно, каждая группа людей должна быть свободна в выборе инструментов, наиболее подходящих для их потока создания ценности, и я смею вас заверить, что Jira не является лучшим инструментом для управления потоками Request to Fulfill или Detect to Correct. Кроме того, есть ещё поддерживающие функции, такие как сети, безопасность и эксплуатация, которые не будут рады вашим попыткам стандартизации на базе систем управления разработкой ПО.

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

Даже в рамках одного потока создания ценности идея стандартизации инструментов для поддержки централизованной отчетности вместо наделения команд правом самим управлять потоком работ звучит для меня очень не по Agile. Руководство всегда должно быть вторичным, помогая обеспечить выполнение работы. Найдите способ консолидировать представления, а не навязывать инструменты.

Или я неправильно понял статью?

Оригинал: A standardised work management tool?

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

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

Ваш адрес 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