Як пояснити девіз неметеджним менеджерам?

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

Ми будемо реалізовувати проект автоматизації, який буде включати в себе автоматизоване розгортання, клоудифікацію інфраструктури, безперервний процес інтеграції.

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

Будучи консультантом, я за контрактом зобов'язаний відповісти, "це залежить". З цим не виходить, я можу реально відповісти на ваше запитання.

Від чого це залежить? Що ж, це може звестись до того, що думає ваш шеф про DevOps:

1. Якщо ваш начальник почув цей термін, можливо, через його одержимість CIO.com , то запитайте їх, що вони думають, що це означає. З цього моменту з’ясуйте, в чому різниця, і чи їхній погляд сумісний. Визначте підходящий проект для випробування DevOps та націліть його на них. Пам'ятайте, що основою DevOps є культура, тому подумайте, як це можна застосувати до проекту.

2. Якщо ваш начальник ніколи не чув про цей термін, тоді будуйте бізнес-справу для DevOps. Використовуйте штат DevOps Puppet Labs та матеріали з книг, таких як Проект Phoenix, для написання ділової справи. Знайдіть проблему, яку має ваш начальник, і DevOps міг би її вирішити і використовувати її як стартову розмову. Як Кенчев сказав, що вам не потрібно згадувати DevOps, ви, наприклад, можете запропонувати Операції брати більше участі в проекті або в більшій кількості автоматизованих тестів, які плануються в рамках реалізації проекту.

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

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

Я настійно рекомендую книгу « Продати є людиною» Даніель Х. Рожевий , принципово Даніель Пінк розповідає про те, як продати щось дуже людська справа. Все, що нам потрібно зробити, це скористатися потребами та вирівняти наш «крок», запропонувавши рішення, яке відповідає цим потребам.

Ви цього не робите.

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

По-перше, покажіть вашим начальникам перевагу невеликих пілотних проектів, які ви зробили. Зберіть кілька корисних точок даних, щоб довести свою справу. (Знайдено це питання, яке може допомогти. Які існують методи вимірювання рентабельності інвестицій для DevOps? )

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

Отримавши інвестиції, зробіть чудову роботу щодо досягнення мети. А ще краще, дико перевищуйте це!

Тепер, коли нарешті начальники запитують вас: "Так що ви зробили, що принесло нам стільки користі?"

Це час, який ви проголошуєте:

"DevOps"

І попросіть більше інвестицій для наступного проекту devops.

Будь-яка ділова ініціатива отримає силу, якщо виявить її відповідність як верхній, так і нижній лінії організації.

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

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

Моя основна міркування для людей, які незнайомі (або просто помиляються) про термін DevOps кипить, зводиться до "частішого надання ділової цінності". На мій досвід, це дуже мало менеджерів, які можуть заперечити. Вони це отримують.

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

Це, звичайно, лише риторика, але я вважаю, що це ефективно, набагато більше, ніж як казати їм читати книгу про Toyota.

Все в попередніх відповідях відповідає дійсності, але я думаю, що деякі речі відсутні, щоб насправді отримати схвалення та зобов’язання від ваших начальників (BTW: у більшості людей є лише 1 начальник на максимум ...).

Рано чи пізно містер Мерфі зійде (= Все, що може піти не так, піде не так, і піде не так, коли не повинно піти не так ). І в цей момент деякі начальники захочуть отримати відповіді на такі питання:

Що сталося, коли і чому, і який авторизований користувач насправді це схвалив ... наперед?

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

Навіть якщо для Мерфі пройде занадто багато часу, ваша компанія може також зіткнутися з такими вимогами, як, наприклад, описаний Річард у питанні " Які процеси або інструменти дозволяють розділити обов'язки, коли інженери розгортають і запускають код? " ( Такі вимоги лякають CxO ...).

Але якщо вам коли-небудь доведеться представити "DevOps" кому-небудь новачеві, це може допомогти їм "попередити" їх вперед на зразок " Добре, тож ви хочете почати практику DevOps, чудово! Але майте на увазі, що це як перехід на іншу релігію ... "