Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

«Я очень хорошо знала это приложение, раньше я занималась поддержкой этой технологической команды. Почти десять лет в ходе каждого ежегодного цикла планирования по программам мы обсуждали, как перенести это приложение с мейнфрейма на другую платформу. Разумеется, как и в большинстве организаций, даже при наличии полной поддержки руководства мы никогда не могли выкроить время.

Моя команда хотела провести отображение потока создания ценности, чтобы определить, действительно ли приложение на COBOL создает проблему, или, возможно, существует более масштабная проблема, и ее нам необходимо выявить. Провели совещание. Собрали всех, кто имел хотя бы какое-то отношение к доставке продукта внутренним клиентам и партнерам по бизнесу, — членов группы обслуживания мейнфрейма, группы общей поддержки и т. д.

Обнаружили, что, когда менеджеры отдела отправляли форму запроса “назначение исполнителя на линию продукции”, а мы запрашивали его табельный номер, им неизвестный, они либо оставляли соответствующее поле пустым, либо вводили в него текст наподобие “я не знаю”. Что еще хуже, для заполнения формы менеджерам надо было идти из складского помещения в офис, где стояли компьютеры. В результате получалась напрасная трата времени, а запрос несколько раз перебрасывался туда-сюда».

В ходе совещания участники провели несколько экспериментов, в том числе исключили поле с номером сотрудника в форме и позволили другому отделу получать информацию с более низкого уровня. Эксперименты, проведенные при помощи менеджеров соответствующего отдела, показали: время обработки запроса сократилось на четыре дня. Группа позднее заменила приложение для ПК приложением для iPad, что дало возможность менеджерам передавать необходимую информацию, не покидая складское помещение, а время обработки было позднее уменьшено до секунд.

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

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

Определение всех команд, обеспечивающих поток создания ценности

Пример компании Nordstrom показывает: как бы ни был сложен поток создания ценности, ни один человек не знает всего списка задач, решаемых в ходе создания ценности для клиента, особенно если необходимая работа выполняется различными командами, нередко разделенными организационным устройством компании, географическим фактором или методами стимулирования.

В результате после выбора приложения или сервиса для преобразований DevOps мы должны определить всех участников потока создания ценности, несущих ответственность за совместно создаваемую ценность для клиентов. В общем случае в этот список входят:

• владелец продукта. Представитель компании, определяющий набор функциональности в следующей версии продукта;

• разработчики. Команда, ответственная за разработку функциональности продукта;