Bagaimana cara menjelaskan devops kepada manajer non-techy?

Saya benar-benar bersemangat tentang DevOps. Saya tahu bahwa DevOps adalah metodologi yang akan menggerakkan kami untuk membangun infrastruktur TI yang akan merampingkan dan memajukan perusahaan kami.
Tetapi bagaimana saya menjual ini kepada bos saya, terutama bos non-teknis?

Kami akan mengimplementasikan proyek otomasi yang akan mencakup, penyebaran otomatis, cloudifikasi infrastruktur, proses integrasi berkelanjutan .. kami pasti perlu membujuk bos kami untuk berinvestasi di level yang lebih tinggi dalam hal ini.

Catatan : kami mulai meningkatkan proses kami dengan mengotomatisasi pengujian, rilis, dan pengawasan, ini adalah langkah menuju adopsi devOps tetapi proyek otomasi itu sendiri siap karena kami membutuhkan lebih banyak investasi.

Menjadi konsultan saya secara kontrak wajib menjawab, "itu tergantung". Dengan itu, saya benar-benar dapat menjawab pertanyaan Anda.

Apa itu tergantung? Nah, itu bisa sampai pada apa yang bos Anda pikirkan tentang DevOps:

1. Jika atasan Anda pernah mendengar istilah tersebut, melalui obsesi mereka terhadap CIO.com mungkin, maka tanyakan kepada mereka apa yang menurut mereka artinya. Dari sana cari tahu apa perbedaannya dan apakah pandangan mereka kompatibel. Identifikasi proyek yang sesuai untuk mengadili DevOps dan berikan kepada mereka. Ingat bahwa pada intinya DevOps adalah budaya jadi pertimbangkan bagaimana hal itu dapat diterapkan pada suatu proyek.

2. Jika atasan Anda belum pernah mendengar istilah tersebut, buat kasus bisnis untuk DevOps. Gunakan State of DevOps dan bahan Puppet Labs dari buku-buku seperti The Phoenix Project untuk menulis kasus bisnis. Temukan masalah yang dimiliki bos Anda dan DevOps dapat menyelesaikannya dan menggunakannya sebagai starter percakapan. Seperti yang dikatakan kenchew, Anda tidak harus menyebutkan DevOps, Anda mungkin, misalnya, menyarankan agar Operasi lebih terlibat dalam proyek atau otomatisasi pengujian yang akan direncanakan sebagai bagian dari pengiriman proyek.

3. Jika bos Anda menganggap DevOps hanyalah kata buzz lainnya, maka lakukan salah satu di atas tetapi sama sekali tidak menyebutkan DevOps, lihat model serupa lainnya seperti Rekayasa Keandalan Situs, Rekayasa Platform atau Penyebaran Berkelanjutan, dan cari tahu bagaimana mereka dapat menyelesaikan masalah.

Kuncinya adalah fokus pada memahami apa yang termotivasi oleh atasan Anda, kemudian mengukir sedikit waktu, uang dan orang-orang untuk mengambil langkah nyata untuk menyelesaikan masalah itu.

Saya sangat merekomendasikan buku To Sell Is Human oleh Daniel H. Pink , pada dasarnya Daniel Pink berbicara tentang bagaimana menjual sesuatu adalah hal yang sangat manusiawi untuk dilakukan, yang perlu kita lakukan hanyalah memanfaatkan kebutuhan dan menyelaraskan "nada" kita dengan mengusulkan solusi yang melayani kebutuhan tersebut.

Kamu tidak.

Terlepas dari antusiasme Anda tentang DevOps, bos non-teknologi tidak benar-benar berbagi ketertarikan Anda dengan istilah techie.

Pertama, tunjukkan kepada atasan Anda manfaat dari proyek percontohan kecil yang telah Anda lakukan. Kumpulkan beberapa poin data yang berguna untuk membuktikan kasus Anda. (Menemukan pertanyaan ini yang dapat membantu: Apa beberapa metode untuk mengukur ROI untuk DevOps? )

Selanjutnya, beri tahu atasan Anda bahwa Anda memiliki proyek yang dapat membawa lebih banyak manfaat tetapi perlu investasi kecil. (Cobalah untuk mencari tahu proyek yang tidak membiarkan bos Anda jatuh dari kursi. Anda harus memiliki perasaan tentang angka ini jika Anda telah bekerja dengan bos Anda untuk sementara waktu.)

Setelah Anda mendapatkan investasi, lakukan pekerjaan yang sangat baik untuk mencapai tujuan. Lebih baik lagi, jauh melebihi itu!

Sekarang, ketika akhirnya para bos bertanya kepada Anda, "Jadi apa yang Anda lakukan yang memberi kami banyak manfaat?"

Ini adalah waktu yang Anda nyatakan:

"DevOps"

Dan minta lebih banyak investasi untuk proyek devops Anda berikutnya.

Setiap inisiatif bisnis akan mendapat daya tarik jika Anda menunjukkan relevansinya dengan topline atau bottomline organisasi.

Inisiatif internal seperti devops hanya dapat mempengaruhi bottomline. Anda perlu mengidentifikasi biaya pekerjaan berulang yang dilakukan oleh individu dan bagaimana otomatisasi akan mengurangi pengeluaran itu.

Meskipun manajer non-teknologi mungkin tidak memahami perbedaan antara memilih koki daripada boneka, mereka memiliki beberapa pemahaman tentang tren Industri. Anda dapat membuat mereka sadar akan biaya keterlambatan karena bangunan tidak tersedia, biaya masalah regresi dan bagaimana pendekatan Anda dapat mengurangi biaya tersebut. Jika Anda dapat menunjukkan rencana nyata untuk peningkatan di bottomline, dan jika itu lebih baik daripada item tindakan lainnya di piring mereka, Anda akan mendapatkan lampu hijau.

Alasan saya masuk ke orang-orang yang tidak terbiasa (atau hanya keliru) tentang istilah DevOps bisul adalah untuk "memberikan nilai bisnis lebih sering". Ini, dalam pengalaman saya, adalah sesuatu yang sangat sedikit yang bisa keberatan manajer. Mereka mengerti.

Jika mereka mengatakan sesuatu seperti "kita hanya butuh seseorang untuk meluruskan para devosan kita, mungkin hanya beberapa minggu kerja; jadi ada batasan berapa banyak kita akan berinvestasi dalam devops sekarang" Saya hanya mencoba menjelaskan itu seperti mengatakan "Kami tidak ingin perusahaan kami memberikan nilai bisnis terlalu banyak. Kami hanya perlu sedikit lagi, tapi hanya itu".

Itu hanya retorika, tentu saja, tetapi saya merasa ini efektif, lebih daripada memberitahu mereka untuk membaca buku tentang Toyota.

Segala sesuatu dalam jawaban sebelumnya adalah benar, tetapi saya pikir ada beberapa hal yang hilang untuk benar-benar mendapatkan persetujuan dan komitmen dari bos Anda (BTW: kebanyakan orang hanya memiliki 1 bos pada maks ...).

Cepat atau lambat Tn. Murphy akan ikut (= Apa pun yang bisa salah, akan salah, dan itu akan salah saat tidak seharusnya salah ). Dan pada saat itu beberapa atasan ingin mendapatkan jawaban atas pertanyaan seperti ini:

Apa yang terjadi kapan dan mengapa, dan pengguna resmi mana yang benar-benar menyetujuinya ... dimuka?

Dan pada saat itu Anda akan mendapatkan ROI nyata dari DevOps-praktik yang akan Anda miliki ... Dan / atau tiba-tiba mendapatkan segala macam persetujuan anggaran besar untuk mengimplementasikan apa yang tampaknya Anda cari.

Bahkan jika itu akan memakan waktu terlalu lama bagi Murphy untuk datang, perusahaan Anda mungkin juga mengalami persyaratan seperti apa yang dijelaskan Richard dalam pertanyaan " Proses atau alat apa yang memungkinkan Pemisahan Tugas ketika para insinyur baik menyebarkan dan menjalankan kode? " (Jenis persyaratan menakut-nakuti CxO ...).

Tetapi, jika Anda harus memperkenalkan "DevOps" kepada seseorang yang baru mengenalnya, mungkin membantu mereka untuk "memperingatkan" mereka di muka seperti " OK, jadi Anda ingin memulai praktik DevOps, hebat! Tapi ketahuilah bahwa itu seperti beralih ke agama lain ... "