Teknik olmayan yöneticilere devops nasıl açıklanır?

DevOps için çok heyecanlıyım. DevOps'un bizi şirketimizi modernize edecek ve ileriye taşıyacak bir BT altyapısı oluşturmaya yönlendirecek bir yöntem olduğunu biliyorum.
Ama bunu patronlarıma, özellikle teknik olmayan patronlara nasıl satabilirim?

Otomatik dağıtım, altyapı bulutlaması, sürekli entegrasyon sürecini içerecek bir otomasyon projesi uygulayacağız .. patronlarımızı buna daha yüksek seviyelere yatırım yapmaya ikna etmemiz gerekiyor.

Not : Testleri, sürümleri ve denetimi otomatikleştirerek sürecimizi geliştirmeye başladık, bu devOps'u benimseme yolunda bir adım ama daha fazla yatırıma ihtiyacımız olduğu için otomasyon projesinin kendisi hazır.

Danışman olarak sözleşmeye bağlı olarak "duruma göre" yanıt vermekle yükümlüyüm. Yoldan çekildiğinde, aslında sorunuzu cevaplayabilirim.

Bu neye bağlıdır? Bu patronunuzun DevOps hakkında ne düşündüğüne inebilir:

1. Patronunuz bu terimi duymuşsa, belki CIO.com'a saplantıları yoluyla, bunun ne anlama geldiğini düşündüklerini sorun. Oradan farkın ne olduğunu ve görüşlerinin uyumlu olup olmadığını öğrenin. DevOps'u denemek ve onlara sunmak için uygun bir proje belirleyin. Temel DevOps'un kültür olduğunu unutmayın, bu yüzden bunun bir projeye nasıl uygulanabileceğini düşünün.

2. Patronunuz terimi hiç duymamışsa DevOps için bir iş vakası oluşturun. İş vakasını yazmak için Kukla Laboratuvarları DevOps Durumunu ve Phoenix Projesi gibi kitaplardan gelen materyalleri kullanın . Patronunuzun ve DevOps'un çözebileceği bir sorunu bulun ve bir konuşma başlatıcısı olarak kullanın. Kenchew'un DevOps'tan bahsetmek zorunda olmadığınızı söylediği gibi, örneğin, Operasyonların proje tesliminin bir parçası olarak planlanacak olan bir projeye daha fazla dahil olmasını veya daha fazla test otomasyonunu önerebilirsiniz.

3. Patronunuz DevOps'un başka bir vızıltı kelimesi olduğunu düşünüyorsa, yukarıdakilerden birini yapın, ancak DevOps'tan kesinlikle bahsetmeyin, Site Güvenilirlik Mühendisliği, Platform Mühendisliği veya Sürekli Dağıtım gibi diğer benzer modellere bakın ve sorunu nasıl çözebileceklerini öğrenin.

Anahtar, patronunuzun neyi motive ettiğini anlamaya odaklanmak, ardından bu sorunu çözmek için somut adımlar atmak için biraz zaman, para ve insan ayırmaktır.

Çok kitap tavsiye Daniel H. Pink tarafından Is İnsan satmak temelden nasıl bir şey yapmak çok insan şeydir satış hakkında Daniel Pink görüşmeler yapmamız gereken tüm ihtiyaçları içine musluk ve a önererek bizim "perde" align bu ihtiyaçlara hizmet eden bir çözüm.

Yapmazsın.

DevOps konusundaki hevesinize rağmen, teknoloji dışı patronlar hayranlığınızı techie lingo ile gerçekten paylaşmıyor.

İlk olarak, patronlarınıza yaptığınız küçük bir pilot projenin faydasını gösterin. Durumunuzu kanıtlamak için bazı yararlı veri noktaları toplayın. ( Yardımcı olabilecek bu soruyu buldu: DevOps için YG'yi ölçmenin bazı yöntemleri nelerdir? )

Ardından, patronlarınıza daha fazla fayda getirebilecek, ancak küçük bir yatırıma ihtiyaç duyacak bir projeniz olduğunu söyleyin. (Patronlarınızın sandalyeden düşmesine izin vermeyen bir proje bulmaya çalışın. Bir süredir patronlarınızla çalışıyorsanız bu rakamın ne olduğunu hissetmelisiniz.)

Yatırımı yaptıktan sonra, hedefe ulaşmak için mükemmel bir iş yapın. Daha da iyisi, çılgınca aş!

Şimdi, nihayet patronlar size "Peki bu bize ne kadar fayda sağladı?

Bu ilan ettiğiniz zamandır:

"DevOps"

Ve bir sonraki devops projeniz için daha fazla yatırım isteyin.

Herhangi bir iş girişimi, kuruluşun üst çizgisine veya alt çizgisine uygunluğunu gösterirseniz çekiş elde eder.

Devops gibi dahili girişimler yalnızca alt çizgiyi etkileyebilir. Bireyler tarafından tekrarlanan çalışmaların maliyetlerini ve otomasyonun bu harcamaları nasıl azaltacağını tanımlamanız gerekir.

Teknik olmayan yöneticiler, şefi kukla üzerinden seçmek arasındaki farkı anlayamasalar da, Endüstri eğilimlerini biraz anlamışlardır. Yapıların mevcut olmaması nedeniyle gecikme maliyetleri, regresyon sorunları ve yaklaşımınızın bu maliyetleri nasıl azaltabileceği konusunda onları bilgilendirebilirsiniz. Alt satırda iyileştirme için somut bir plan gösterebilirseniz ve plakalarındaki diğer eylem öğelerinden daha iyiyse, devam edersiniz.

DevOps kaynamaları hakkında bilinmeyen (veya sadece yanılmış) insanlar için akıl yürütme çizgim, "iş değerini daha sık sunmaktır". Bu, benim tecrübelerime göre, çok az yöneticinin itiraz edebileceği bir şey. Anlıyorlar.

Eğer "sadece adanmışlarımızı düzeltmek için birine ihtiyacımız var, muhtemelen sadece birkaç haftalık bir çalışma derlerse, şu anda adanmışlara ne kadar yatırım yapacağımızın bir sınırı var" diyorum ki, "Şirketimizin çok fazla iş değeri sağlamasını istemiyoruz. Sadece biraz daha fazlasına ihtiyacımız var, ama hepsi bu".

Tabii ki sadece retorik, ama Toyota hakkında bir kitap okumalarını söylemekten çok daha etkili olduğunu düşünüyorum.

Önceki cevaplardaki her şey doğrudur, ancak patronlarınızın onayını ve taahhüdünü almak için eksik olan bazı şeyler olduğunu düşünüyorum (BTW: çoğu insanın en fazla 1 patronu var ...).

Er ya da geç Bay Murphy gelecektir (= Yanlış gidebilecek, yanlış gidecek ve yanlış gitmemesi durumunda yanlış gidecek ). Ve bu noktada bazı patron (lar) böyle sorulara cevap almak isteyecektir:

Ne zaman ve neden oldu ve hangi yetkili kullanıcı bunu gerçekten onayladı ...

Ve bu noktada gerçek YG'yi, uygulayacağınız DevOps uygulamalarından alacaksınız ... Ve / veya aradığınız şeyi uygulamak için aniden her türlü büyük bütçe onayını alın.

Murphy'nin gelmesi çok uzun sürse bile, şirketiniz Richard'ın " Mühendisler hem kodu dağıtıp çalıştırdığında ne gibi işlemler veya araçlar Görevleri Ayırmayı mümkün kılıyor? " (Bu tür gereksinimler CxO'ları korkutur ...).

Ancak, yeni olan birine "DevOps" tanıtmak zorunda kalırsanız, onları " Tamam " gibi "uyarma" konusunda yardımcı olabilir , bu yüzden DevOps uygulamalarına başlamak istiyorsunuz, harika! başka bir dine geçiyoruz ... "