Публикации 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?