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

Готов ли бизнес к DevOps?

В недавно вышедшей статье Олега Скрынника «The biggest problem with DevOps is the name» изложено несколько хороших идей, и об одной из них я хотел бы поговорить более подробно.

Идея эта состоит в том, что почти все триггеры и события, связанные с развитием и/или эксплуатацией услуги, такие как инциденты, запросы на изменение, рождаются в бизнесе. Результаты реакции на эти события со стороны управляющего ИТ-подразделения потребляются им же, что, в свою очередь, порождает новый набор событий, образуя цикл. Бизнес живет, изменяется и, тем самым, формирует неудовлетворенный спрос на организационно-технические решения, которые позволяли бы ему расти с наибольшей скоростью.

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

Такая идиллическая картина мира не становится для бизнеса тотальной катастрофой только по причине нескольких сочетающихся факторов:

  1. Бизнес, на самом деле, достаточно живуч и неплохо приспосабливается почти ко всему. Со временем он научился опосредованно управлять этим черным для него ИТ-ящиком через финансовое подкрепление: если ИТ недостаточно хорошо удовлетворяет бизнес, то бизнес, в свою очередь, перебрасывает за стену меньшее количество денежных знаков.
  2. ИТ-блок, опасаясь недополучить средств к существованию, пробуривает в стене небольшие переговорные отверстия и прорубает одно или несколько окон стандартных форм, через которые общается с бизнесом силами бизнес-аналитиков и сотрудников Service Desk.

Ситуация может быть визуально осложнена тем, что ИТ-блок имеет собственный бюджет, и сам финансирует из него реализацию пожеланий и потребностей бизнеса. На самом деле, это не переворачивает ситуацию с ног на голову, так как средства ИТ-бюджета все равно кто-то должен заработать, и этот кто-то — это бизнес, но возможности прямого управления финансированием отдельных инициатив бизнес в этой ситуации лишается.

Чем такая расстановка чаще всего характерна?

  • Бизнес (и заказчик и пользователи), взаимодействуя с ИТ, чаще выступают единым фронтом, даже если их интересы не синхронизированы между собой. Один за всех! Все за одного!
  • Бизнес стремится отказаться от ответственности по владению и управлению данными, ключевыми информационными ресурсами/инструментами, аргументируя это словами: «Управлять этим — ваша ответственность. Мы за что вам платим?».
  • Бизнес стремится отказаться от оперативного управления ИТ-бюджетом в рамках которого реализуются его потребности! Так как это требует от бизнеса принятия ответственных решений в слабо понятной для него области.

Если вы скажете, что в данной позиции отдельные бизнес-подразделения могут вести себя как маленькие дети, то вы не будете далеки от истины.

Один хитовый философ 19 века и, по совместительству, автор мировых бестселлеров озвучил идею о том, что бытие определяет сознание. А для нашего кейса эта идея означает, что для того, чтобы не препятствовать органическому росту бизнеса, мы должны снести эту многострадальную стену, разрушив границу между бизнес-подразделением и ИТ.

Теперь бизнес не только будет оказывать услуги и общаться со своим покупателем, но и будет полноправно владеть всеми своими инструментами и технологиями. Теперь ИТ-подразделение будет выступать не в роли «фейкового» субъекта фальшивых взаимоотношений с бизнесом, а в роли объекта: надежного ресурса и качественного профессионального инструмента.

  • Кто отвечает за выручку? — Бизнес.
  • Кто отвечает за затраты? — Бизнес.
  • Кто отвечает за коммуникации? — Бизнес.
  • Кто управляет рисками? — Бизнес.
  • Кто владеет данными? — Бизнес.
  • Кто владеет информационными системами и инструментами? — Бизнес.
  • Кто отвечает за информационную безопасность? — Бизнес.
  • Кто принимает финансовые решения? — Бизнес.

Только бизнес является истинным действующим субъектом.

Как он будет оперировать новыми для него ИТ-сущностями? Он будет управлять ими нашими руками: c помощью наших ИТ-знаний, умений и навыков.

Именно этому, кроме прочего, и учит нас DevOps, а не только тому, кто будет разрабатывать продукты, кто сопровождать их, и почему это должно стать потоком ценности.

Уверен, что, если в вашей организации еще остались такие стены, то ваш бизнес уже готов к их демонтажу. В отличие от вас самих.

Никогда не недооценивайте его живую волю и самостоятельность.

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

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

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

  • Рубрики

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

    • Работать меньше, чтобы сделать больше
      Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, …
    • Это же не наш профиль…
      Не смотр на то, что на нашем портале мы обсуждаем вопросы ITSM, я хотел бы затронуть тему “котиков”. Многие наверняка скажут: “Причем здесь котики? Это же не ваш профиль”. А какой …
    • Кто такие агенты изменений в продуктовой команде?
      Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не …
    • Обновление Scrum Guide
      18 ноября 2020 года отцы-основатели Scrum Кен Швабер (Ken Schwaber) и Джеф Сазерлэнд (Jeff Sutherland) опубликовали новую версию руководства Scrum (Scrum Guide). Это особенно …
    • Где в ITIL можно почитать про управление техническим долгом?
      Во время вебинара нам поступил вопрос: Есть ли в практиках ITIL разделы\главы, в которых уделяется внимание управлению техдолга? (чтобы почитать)…
    • Технический долг: как бороться с невидимым врагом
      Зачастую о техническом долге говорят, как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Он и тебя посчитал
      В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной …
    • «DevOps Handboek» — «DevOps для ИТ-менеджеров» на голландском
      Книга Олега Скрынника «DevOps для ИТ-менеджеров» — лучший выбор для тех, кто хочет разобраться в том, что такое DevOps, — вышла на голландском …
    • Диагностика продуктовых команд как поток
      Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что …
    • Учёт доступности? А можно как-то попроще?
      На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: «а можно как-то попроще?». Вопрос, в общем-то, …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT