Jak wyjaśnić devops menedżerom nietechnicznym?

Jestem całkowicie podekscytowany DevOps. Wiem, że DevOps to metodologia, która przeniesie nas do budowy infrastruktury IT, która usprawni i przyspieszy rozwój naszej firmy.
Ale jak sprzedać to moim szefom, zwłaszcza nietechnicznym?

Zamierzamy wdrożyć projekt automatyzacji, który obejmie: automatyczne wdrożenie, chmurę infrastruktury, proces ciągłej integracji. Zdecydowanie musimy przekonać naszych szefów do inwestowania w to na wyższych poziomach.

Uwaga : zaczęliśmy ulepszać nasz proces poprzez automatyzację testów, wydań i nadzoru, jest to krok w kierunku przyjęcia devOps, ale sam projekt automatyzacji jest w gotowości, ponieważ potrzebujemy więcej inwestycji.

Jako konsultant jestem umownie zobowiązany do udzielenia odpowiedzi „to zależy”. Dzięki temu mogę odpowiedzieć na twoje pytanie.

Od czego to zależy? To może sprowadzać się do tego, co twój szef myśli o DevOps:

1. Jeśli twój szef słyszał o tym terminie, może przez swoją obsesję na punkcie CIO.com , zapytaj go, co według niego oznacza. Następnie sprawdź, jaka jest różnica i czy ich widok jest zgodny. Znajdź odpowiedni projekt do wypróbowania DevOps i przekaż mu go. Pamiętaj, że u podstaw DevOps leży kultura, więc zastanów się, jak można to zastosować w projekcie.

2. Jeśli twój szef nigdy nie słyszał o tym terminie, zbuduj uzasadnienie biznesowe dla DevOps. Skorzystaj ze Stanu DevOps Puppet Labs i materiałów z książek takich jak The Phoenix Project, aby napisać uzasadnienie biznesowe. Znajdź problem, który ma twój szef, a DevOps może go rozwiązać i wykorzystaj go jako początek rozmowy. Ponieważ kenchew powiedział, że nie musisz wspominać o DevOps, możesz na przykład zasugerować, że Operacje będą bardziej zaangażowane w projekt lub więcej automatyzacji testów, które zostaną zaplanowane w ramach realizacji projektu.

3. Jeśli twój szef uważa, że ​​DevOps to tylko kolejne modne słowo, zrób jedno z powyższych, ale absolutnie nie wspominaj o DevOps, spójrz na inne podobne modele, takie jak Inżynieria niezawodności witryny, Inżynieria platformy lub Ciągłe wdrażanie i dowiedz się, jak mogą rozwiązać problem.

Kluczem jest skupienie się na zrozumieniu motywacji twojego szefa, a następnie poświęcenie odrobiny czasu, pieniędzy i ludzi na podjęcie konkretnych kroków w celu rozwiązania tego problemu.

Bardzo polecam książkę „ Sprzedać to człowiek” Daniela H. Pink , zasadniczo Daniel Pink opowiada o tym, jak sprzedaż czegoś jest rzeczą bardzo ludzką, wystarczy, że skorzystamy z potrzeb i dostosujemy naszą „ofertę”, proponując rozwiązanie, które spełnia te potrzeby.

Ty nie.

Pomimo twojego entuzjazmu wobec DevOps, szefowie nietechniczni tak naprawdę nie dzielą twojej fascynacji żargonem technicznym.

Po pierwsze, pokaż swoim szefom korzyści płynące z niewielkich projektów pilotażowych, które wykonałeś. Zbierz kilka użytecznych punktów danych, aby udowodnić swoją sprawę. (Znalazłem to pytanie, które może pomóc: Jakie są metody pomiaru ROI dla DevOps? )

Następnie powiedz swoim szefom, że masz projekt, który może przynieść więcej korzyści, ale wymaga niewielkiej inwestycji. (Spróbuj wymyślić projekt, który nie pozwoli twoim szefom spaść z krzesła. Powinieneś poczuć, co to za postać, jeśli pracujesz ze swoimi szefami przez jakiś czas.)

Po uzyskaniu inwestycji wykonaj doskonałą robotę, aby osiągnąć cel. Jeszcze lepiej, gwałtownie go przekraczaj!

Teraz, kiedy w końcu szefowie pytają: „Więc co zrobiłeś, to przyniosło nam tak wiele korzyści?”

Oto czas, który ogłaszacie:

„DevOps”

I poproś o więcej inwestycji na następny projekt devops.

Każda inicjatywa biznesowa zyska na popularności, jeśli wykażesz, że ma ona znaczenie dla górnej lub dolnej linii organizacji.

Inicjatywy wewnętrzne, takie jak devops, mogą mieć wpływ tylko na wynik finansowy. Musisz określić koszty powtarzalnej pracy wykonywanej przez poszczególne osoby oraz sposób, w jaki automatyzacja ograniczy te wydatki.

Mimo że menedżerowie bez wiedzy technicznej mogą nie rozumieć różnicy między wyborem szefa kuchni a marionetką, rozumieją trendy w branży. Możesz uświadomić im koszty opóźnień z powodu niedostępności kompilacji, koszty problemów z regresją oraz sposób, w jaki twoje podejście może zmniejszyć te koszty. Jeśli potrafisz pokazać namacalny plan poprawy w dolnej linii, a jeśli jest lepszy niż inne przedmioty akcji na ich talerzu, uzyskasz zielone światło.

Moje ogólne rozumowanie ludzi, którzy nie są zaznajomieni (lub po prostu mylą się) na temat terminu „DevOps”, sprowadza się do „częstszego dostarczania wartości biznesowej”. Z mojego doświadczenia wynika, że ​​bardzo niewielu menedżerów jest w stanie sprzeciwić się. Oni to rozumieją.

Jeśli powie coś w stylu „potrzebujemy kogoś, kto wyprostuje naszych programistów, prawdopodobnie tylko kilka tygodni pracy; więc jest limit na to, ile teraz zainwestujemy w programistów”. Próbuję wyjaśnić, że to tak, jakby powiedzieć „Nie chcemy, aby nasza firma zapewniała zbyt dużą wartość biznesową. Potrzebujemy tylko trochę więcej, ale to wszystko”.

To oczywiście tylko retoryka, ale uważam, że jest skuteczna, o wiele bardziej niż zachęcanie ich do przeczytania książki o Toyocie.

Wszystko w poprzednich odpowiedziach jest prawdą, ale myślę, że brakuje pewnych rzeczy, aby uzyskać aprobatę i zaangażowanie od swoich szefów (BTW: większość ludzi ma tylko 1 szefa maksymalnie ...).

Wcześniej czy później przyjdzie pan Murphy (= Wszystko, co może pójść nie tak, pójdzie nie tak i pójdzie źle, gdy nie powinno się nie udać ). I w tym momencie niektórzy szefowie będą chcieli uzyskać odpowiedzi na pytania takie jak to:

Co się stało, kiedy i dlaczego, i który autoryzowany użytkownik faktycznie zatwierdził ... z góry?

I w tym momencie uzyskasz prawdziwy ROI z praktyk DevOps, które masz na miejscu ... i / lub nagle otrzymujesz różnego rodzaju ogromne zatwierdzenia budżetu, aby wdrożyć to, czego szukasz.

Nawet jeśli zajęłoby to zbyt wiele czasu Murphy'emu, Twoja firma mogłaby również napotkać takie wymagania, jak Richard opisany w pytaniu „ Jakie procesy lub narzędzia umożliwiają Podział obowiązków, gdy inżynierowie wdrażają i uruchamiają kod? ” (Tego rodzaju wymagania przestraszą CxO ...).

Ale jeśli kiedykolwiek będziesz musiał przedstawić „DevOps” komuś, kto jest nowy, może pomóc mu „ostrzec” go z góry jak „ OK, więc chcesz zacząć praktyki DevOps, świetnie! Ale pamiętaj, że to jest jak przejście na inną religię ... ”