Wie erklärt man Entwicklern, die nicht technisch versierte Manager sind?

Ich bin total begeistert von DevOps. Ich weiß, dass DevOps die Methode ist, mit der wir eine IT-Infrastruktur aufbauen, die unser Unternehmen rationalisiert und vorantreibt.
Aber wie verkaufe ich das an meine Chefs, insbesondere an nicht-technische Chefs?

Wir werden ein Automatisierungsprojekt implementieren, das eine automatisierte Bereitstellung, eine Cloudifizierung der Infrastruktur und einen kontinuierlichen Integrationsprozess umfasst. Wir müssen unsere Chefs auf jeden Fall davon überzeugen, auf höherer Ebene in dieses Projekt zu investieren.

Hinweis : Wir haben begonnen, unseren Prozess durch die Automatisierung von Tests, Releases und Supervision zu verbessern. Dies ist ein Schritt in Richtung auf die Übernahme von devOps. Das Automatisierungsprojekt selbst ist jedoch in Bereitschaft, da wir mehr Investitionen benötigen.

Als Berater bin ich vertraglich verpflichtet zu antworten, "es kommt darauf an". Damit kann ich Ihre Frage tatsächlich beantworten.

Wovon hängt es ab? Nun, das könnte darauf hinauslaufen, was Ihr Chef über DevOps denkt:

1. Wenn Ihr Chef über die Besessenheit von CIO.com von dem Begriff gehört hat, fragen Sie ihn, was er davon hält. Ermitteln Sie von dort aus, was der Unterschied ist und ob ihre Ansicht kompatibel ist. Identifizieren Sie ein geeignetes Projekt, um DevOps zu testen, und stellen Sie es ihnen vor. Denken Sie daran, dass DevOps im Mittelpunkt der Kultur steht. Überlegen Sie also, wie dies auf ein Projekt angewendet werden kann.

2. Wenn Ihr Chef noch nie von dem Begriff gehört hat, erstellen Sie einen Business Case für DevOps. Verwenden Sie das Puppet Labs State of DevOps und Material aus Büchern wie The Phoenix Project , um den Business Case zu schreiben. Finden Sie ein Problem, das Ihr Chef und DevOps haben, und nutzen Sie es als Gesprächsstarter. Wie Kenchew bereits sagte, müssen Sie DevOps nicht erwähnen. Sie könnten beispielsweise vorschlagen, dass Operations stärker in ein Projekt eingebunden ist oder dass mehr Testautomatisierung als Teil der Projektbereitstellung geplant wird.

3. Wenn Ihr Chef der Meinung ist, dass DevOps nur ein weiteres Schlagwort ist, führen Sie einen der oben genannten Schritte aus, erwähnen Sie jedoch keinesfalls DevOps. Schauen Sie sich andere ähnliche Modelle wie Site Reliability Engineering, Platform Engineering oder Continuous Deployment an und finden Sie heraus, wie sie das Problem lösen können.

Der Schlüssel liegt darin, sich darauf zu konzentrieren, zu verstehen, wovon Ihr Chef motiviert ist, und dann ein wenig Zeit, Geld und Menschen zu investieren, um konkrete Schritte zur Lösung dieses Problems zu unternehmen.

Ich kann das Buch " To Sell Is Human" von Daniel H. Pink nur wärmstens empfehlen. Grundsätzlich spricht Daniel Pink darüber, wie sehr der Verkauf von Dingen von Menschen zu tun ist Lösung, die diese Bedürfnisse erfüllt.

Das tust du nicht.

Trotz Ihrer Begeisterung für DevOps teilen Non-Tech-Chefs Ihre Faszination für die Fachsprache nicht wirklich.

Zeigen Sie Ihren Vorgesetzten zunächst den Nutzen kleiner Pilotprojekte, die Sie durchgeführt haben. Sammeln Sie einige nützliche Datenpunkte, um Ihren Fall zu beweisen. (Diese Frage könnte hilfreich sein: Mit welchen Methoden kann der ROI für DevOps gemessen werden? )

Teilen Sie Ihren Vorgesetzten als Nächstes mit, dass Sie ein Projekt haben, das mehr Nutzen bringen könnte, aber eine kleine Investition erfordert. (Versuchen Sie, ein Projekt zu finden, bei dem Ihre Chefs nicht vom Stuhl fallen. Sie sollten ein Gefühl dafür haben, was diese Figur ist, wenn Sie eine Weile mit Ihren Chefs gearbeitet haben.)

Wenn Sie die Investition erhalten haben, leisten Sie hervorragende Arbeit, um das Ziel zu erreichen. Besser noch, übertreffen Sie es wild!

Nun, als die Chefs dich endlich fragen: "Was hast du getan, was uns so viele Vorteile gebracht hat?"

Dies ist die Zeit, die Sie verkünden:

"DevOps"

Und fordern Sie weitere Investitionen für Ihr nächstes Devops-Projekt an.

Jede Geschäftsinitiative würde einen Anreiz erhalten, wenn Sie deren Relevanz für die Unternehmensstrategie oder das Endergebnis der Organisation nachweisen.

Interne Initiativen wie Devops können sich nur auf das Endergebnis auswirken. Sie müssen die Kosten für wiederkehrende Arbeiten identifizieren, die von den einzelnen Personen ausgeführt werden, und ermitteln, wie die Automatisierung diese Ausgaben reduzieren würde.

Auch wenn Manager, die nicht technisch versiert sind, den Unterschied zwischen Chefkoch und Marionette nicht verstehen, haben sie doch ein gewisses Verständnis für Branchentrends. Sie können sie auf die Kosten von Verzögerungen aufmerksam machen, die durch nicht verfügbare Builds entstehen, auf die Kosten von Regressionsproblemen und darauf, wie Ihr Ansatz diese Kosten senken kann. Wenn Sie einen konkreten Plan zur Verbesserung des Geschäftsergebnisses vorweisen können und dieser Plan besser ist als die anderen Aktionselemente auf ihrem Teller, erhalten Sie eine Genehmigung.

Meine Argumentation für Leute, die mit dem Begriff DevOps nicht vertraut sind (oder sich nur irren), beruht darauf, dass ich "häufiger geschäftlichen Nutzen erbringe". Dies können meiner Erfahrung nach nur sehr wenige Manager beanstanden. Sie bekommen es.

Wenn sie so etwas sagen wie "Wir brauchen nur jemanden, der unsere Entwickler in Ordnung bringt, wahrscheinlich nur ein paar Wochen Arbeit. Es gibt also eine Grenze dafür, wie viel wir im Moment in Entwickler investieren werden", versuche ich nur zu erklären "Wir wollen nicht, dass unser Unternehmen zu viel Geschäftswert liefert. Wir brauchen nur ein bisschen mehr, aber das ist es."

Es ist natürlich nur Rhetorik, aber ich finde es sehr viel effektiver, als sie zu bitten, ein Buch über Toyota zu lesen.

Alles in den vorherigen Antworten ist wahr, aber ich denke, es fehlen einige Dinge, um die Zustimmung und das Engagement Ihrer Chefs zu erhalten (Übrigens: Die meisten Leute haben nur 1 Chef im Maximum ...).

Früher oder später wird Mr. Murphy mitkommen (= Alles, was schief gehen kann, wird schief gehen, und es wird schief gehen, wenn es nicht schief gehen sollte ). Und an diesem Punkt werden einige Chefs Antworten auf Fragen wie diese erhalten wollen:

Was ist wann und warum passiert und welcher autorisierte Benutzer hat es tatsächlich genehmigt ... im Voraus?

Und zu diesem Zeitpunkt erhalten Sie den realen ROI von DevOps-Praktiken, die Sie einsetzen können ... Und / oder plötzlich alle möglichen großen Budgetgenehmigungen, um das umzusetzen, wonach Sie suchen.

Selbst wenn es zu lange dauern würde, bis Murphy vorbeikommt, stößt Ihr Unternehmen möglicherweise auch auf Anforderungen wie die, die Richard in der Frage " Welche Prozesse oder Tools ermöglichen die Aufgabentrennung, wenn Ingenieure Code bereitstellen und ausführen? " Anforderungen erschrecken CxOs ...).

Aber wenn Sie jemals jemandem "DevOps" vorstellen müssen, der neu in diesem Bereich ist, kann es ihm helfen, ihn von vornherein zu "warnen", wie " OK ". Sie möchten also mit den DevOps-Übungen beginnen, großartig! Aber beachten Sie, dass dies so ist Wechsel zu einer anderen Religion ... "