Портал №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 не будет опубликован.

  • Рубрики

  •  
  • Авторы

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

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT