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

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

3. Выявите уклоняющихся. «Уклоняющиеся» — высококлассные и авторитетные специалисты, но они будут, скорее всего, противостоять нашим усилиям (возможно, даже саботировать их). В целом мы обращаемся к этой группе только после того, как привлекли на свою сторону молчаливое большинство, когда в достаточной степени достигли успеха и можем хорошо выступить в защиту нашей инициативы.

Расширение DevOps на всю организацию — непростая задача. Оно может вызвать нежелательные последствия для отдельных сотрудников, отделов и даже для организации в целом. Но, как говорит Рон Ван Кеменад, директор по информационным технологиям компании ING, преобразовавший свою компанию в одну из наиболее популярных организаций в области технологий, «лидерство в изменениях требует мужества, особенно в корпоративных средах, где сотрудники боятся изменений и будут противостоять им. Но если вы начнете с малого, то вам действительно нечего бояться. Любой лидер должен быть достаточно смел, чтобы выделить команды на решение задач, связанных с риском, хотя и предусмотренным».

Заключение

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

Глава 6. Основные сведения о работе в потоке создания ценности, превращении его в прозрачный и расширении на всю организацию

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

В предыдущей главе мы рассказали о проведенных компанией Nordstrom преобразованиях DevOps под руководством Кортни Кисслер и ее группы. В процессе многолетней работы они выяснили: один из наиболее эффективных способов начать улучшение любого потока создания ценности — провести рабочее совещание с основными заинтересованными сторонами и выполнить упражнения по отображению потока создания ценности. Этот процесс описан в данной главе. Он поможет зафиксировать все шаги создания ценности.

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

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

Кисслер объясняла: