Як змінити існуючу політику в організації?

Я припускаю, що організація, яка бажає зробити трансформацію DevOps, має деякі проблеми та політику, яку вона зацікавлена ​​в зміні. Цей інтерес може виникнути від топ-менеджерів, середніх менеджерів або навіть знизу вгору. Одним з найбільших факторів, що перешкоджає цим змінам, є змушення інших людей купувати зміни.

Наприклад, у багатьох випадках висунення «нових» ідей, таких як Agile, часто не вдається. Люди чинять опір змінам, і це здається стіною, яка зупиняє хороші речі. І все ж є мандат на те, щоб відбуватися хороші речі.

Які методи можна використовувати для впливу на працівників в організації, яка починає трансформацію DevOps? Особливо специфічні прийоми та способи роботи. Конкретна додаткова інженерія, менше махає рукою.

Ви повинні розуміти, що процеси змінюють людей, які слідують за ними. Коли люди навчаються, інтерналізуються та вдосконалюються в процесі, це змінює те, як вони вчаться вирішувати певну проблему. Набір подібних процесів зміцнює один одного у мисленні, який людина використовує для вирішення категорії проблем і врешті формує набір цінностей, які керують рішеннями та новими рішеннями нових проблем.

Навіть якщо ви зміните процес, без зміни настрою та ще більш важливого значення для цінностей, людина просто адаптуватиме новий процес відповідно до тих же цінностей, того ж розуму чи навіть того ж рішення, що і в оригінальному процесі. У певний момент неможливо розлучитися з цією людиною на цій посаді від набутого мислення або змінити основні цінності.

Для внесення змін у вас є два варіанти:

1. Зверніться до людини, яка вже матиме правильні цінності та настрій та в кращому випадку зрозумійте процес, якого потрібно дотримуватися без вашої допомоги.
2. Запровадьте нового працівника, або найняли нещодавно найманого працівника, або наймайте його з іншого колективу в організацію та навчіть його в новому процесі, сподіваючись прищепити нове мислення, сподіваючись, що з'явиться новий набір цінностей.

Якщо зміна є локальною, ви можете скористатися внутрішньою передачею, оскільки ця людина вже поділить загальносвітові цінності компанії, які ви хочете зберегти. У разі більшої зміни вам потрібно залучити когось іззовні, щоб мати свіжу перспективу і не ділитися цінностями компанії, які ви могли б намагатися змінити.

Важлива частина полягає в наданні можливості особі, колективу чи діловому підрозділу слідкувати за процесами та ізолювати їх від старої команди, інших команд або решти компанії відповідно, яка все ще може слідувати старій сукупності процесів. Оскільки дуже важко ізолювати такого агента змін від управління вище, якщо зміна має бути більшою, йому часто потрібно дотримуватися весь шлях по ланцюгу управління або проходити цілком зверху.

Примітка . Важко запровадити зміни не лише до вашої команди без підтримки керівництва. Навіть всередині вашої команди це важко, якщо інші вже налаштовані на свій шлях. Для нової команди в новій компанії успішний євангеліст часто може впливати на формувальну політику навіть без підтримки керівництва, просто будучи лідером або створюючи шлях найменшого опору для наслідування. Але у створеній компанії див. Вище.

Зламати свою команду

Домогтися змін у вашій організації важко. У людей є звички, вони чинять опір змінам, і їм часто подобається статус-кво. Щоб внести зміни в жодному конкретному порядку, ось кілька інструментів, якими ви можете скористатися.

1. Змушуйте інших відчувати проблему, яку вирішує DevOps. Багато разів переваги DevOps розуміє лише на теоретичному рівні ваша команда. Більшість проблем, які трапляються під час розгортання, сподіваються і рідко відчувають решта команди розробників або керівництва. Щоб виправити це, переконайтеся, що ви озвучуєте проблеми, коли вони виникають, і вкажіть, як ця проблема не сталася б, якби команда використовувала рішення безперервної інтеграції. Інша можливість полягає в тому, щоб ви попросили розробників виправити проблеми, викликані їх кодом під час розгортання, а не виправляти їх самостійно.

2. Знайдіть лідерів . Люди звичайно слідкують за лідерами, будь то керівництво чи просто найпопулярніша / командуюча особа в групі. Отримайте цих лідерів на борту зі своїм бажанням перейти до культури DevOps та розробити загальнодоступні способи, як їх можна побачити, використовуючи чи відстоюючи кращі практики.

3. Побудувати довіру . Ми з більшою ймовірністю погоджуємось на речі людей, після того, як ми з ними вже домовились один-два рази. В ідеалі ви можете знайти невеликі вдосконалення, які можна внести без змін культури і на цьому розвивати успіх. Однак якщо це не варіант, задайте їм прості запитання та запропонуйте прості пропозиції, щоб вони звикли говорити так чи погоджуватися з вами.

4. Не соромтесь повторити себе. Повторення працює і врешті-решт занурюється. Коли це можливо, згадуйте, які чудові речі були б, якби команда використовувала DevOps. Однак це працює лише в тому випадку, якщо ви спочатку побудували довіру до своєї команди.

5. Зробіть це приємно . Якщо вам дозволено скласти доказ концепції для вашої ситуації з DevOps, використовуйте милі смайлики та веселі кольори у звітах та повідомленнях. Опублікувати смішні gif, коли збірка не вдається. Переконайтеся, що ви не дратуєте своїми оновленнями.