Bei Geschwindigkeit Santa Clara Dieses Jahr hielt ich einen Vortrag über das Zusammenspiel zwischen DevOps Bewegung und Produktmanagement. Ich denke, es ist wichtig, dass Produktmanager die Auswirkungen ihrer Entscheidungen auf die Softwarefunktionalität verstehen, und dass Entwicklungsteams – ob DevOps oder andere – verstehen, wie sich ihre Entscheidungen auf das Produkt auswirken.

Ich möchte drei Vorgehensweisen hervorheben, die wir bei PagerDuty zum Erstellen, Versenden und Betreiben von Software verwenden, und wie sie unserem Produktteam dabei helfen, den Kunden einen Mehrwert zu bieten.

Schnelle, häufige und stabile Bereitstellungen

Die meisten unserer Github-Repositories verfügen über Continuous Integration oder Continuous Deployment. Wenn Sie einen Pull Request öffnen, wird Ihr Code wie von Zauberhand in die Cloud hochgeladen, eine Reihe von Tests werden ausgeführt, und wenn alle erfolgreich sind, erhalten Sie ein großes grünes Häkchen für „Sicher zum Deployen“.

Wir haben auch ChatOps-Implementierung. Es gibt einen Kanal in Locker Hier können Sie einen Bot bitten, jeden Zweig eines beliebigen Repositorys in jeder Umgebung, einschließlich der Produktionsumgebung, zu platzieren. Dies erleichtert auch die Untersuchung und das Zurücksetzen fehlerhafter Bereitstellungen und hilft generell dabei, die Vorgänge in unserer Infrastruktur transparent zu machen.

Nachdem ich diese Magie erlebt habe, kann ich mir nicht vorstellen, in eine Welt zurückzukehren, in der Entwicklung und Bereitstellung eine Abschaltung der Website für Wartungsarbeiten oder die Zusammenarbeit mit einem separaten Team erfordern. Produktmanager leben und sterben von der Feedbackschleife – je länger man kein Live-Produkt sieht und daraus lernt, desto größer ist das Risiko.

Konstruiertes Versagen

Inspiriert von Netflix' Simian Army injizieren wir regelmäßig kontrollierte und überwachter Ausfall in die Systeme von PagerDuty, um sicherzustellen, dass wir immer auf das Unerwartete vorbereitet sind.

Jeden Freitag um 11 Uhr pazifischer Zeit treffen sich Entwickler, Betriebsteams und alle anderen Interessierten in einem Raum, und wir bauen einen Teil unserer Infrastruktur ab. Das Ziel ist dreifach:

1. Setzen Sie die Erwartung, dass Sie bei der Einrichtung eines Dienstes bei PagerDuty diesen mit Versagen im Kopf . Sie sollten damit rechnen, dass jederzeit verrückte Dinge passieren können und Sie wach bleiben müssen.
2. Identifizieren Sie in einer kontrollierten Umgebung Bereiche, in denen unsere Systeme nicht robust sind, damit wir diese Probleme beheben können, lange bevor Kunden davon betroffen sind.
3. Üben Sie unsere Techniken zum Vorfallmanagement, damit wir im Falle eines Black-Swan-Ereignisses geübt und automatisch reagieren können.

Ich liebe es, Produktmanager in einer Kultur zu sein, in der Misserfolge als Lernmöglichkeit betrachtet werden. Produktmanagement birgt auf dem Weg zum Erfolg viele Risiken und Misserfolge. Da dies in unserer Kultur verankert ist, ist es leicht, teamübergreifend über diese Themen zu sprechen.

Ich habe auch viel aus der Praxis des konstruierten Scheiterns, der schuldlosen Post-Mortem-Analyse und des systemischen Denkens gelernt. Ich habe gelernt, Misserfolg und Erfolg nicht als Folge einer einzelnen Entscheidung oder einer einzelnen Person zu betrachten, sondern als Wechselwirkungen verschiedener Überzeugungen und Umstände. Dadurch konnte ich einen Arbeitsvorrat aufbauen, der keine Domino-Wasserfall-Reaktion erfordert, um erfolgreich zu sein, sondern Unsicherheiten berücksichtigt und die Chancen zu unseren Gunsten erhöht.

Bauen Sie es, versenden Sie es, besitzen Sie es

Was mir an DevOps bei PagerDuty jedoch am besten gefällt, ist die Kultur des Softwareeigentums. Unsere Teams setzen den Code ein, den sie schreiben, und übernehmen Verantwortung für die Software, die sie veröffentlichen.

Für Produktmanager ist das manchmal etwas frustrierend, da es bedeutet, dass Ihr Plan für neue Funktionen durch technische Schulden oder betriebliche Probleme durcheinander geraten kann. Dies sollte bei der Arbeitsplanung und der Leitung eines Teams berücksichtigt werden.

Doch auf lange Sicht hilft die Kultur der Eigenverantwortung den Mitarbeitern nicht nur dabei, die richtigen Entscheidungen für das Projekt zu treffen, an dem sie gerade arbeiten, sondern auch, die richtigen langfristigen Entscheidungen für ihr Team und die gesamte Organisation zu treffen.

Bei DevOps sind Ihr Entwicklungsbudget und Ihr Betriebsbudget identisch. Ihre Mitarbeiter bleiben dieselben. Wenn Sie fehlerhaften Code ausliefern oder Ihr Team über seine Grenzen hinaus treiben, leidet Ihre eigene zukünftige Geschwindigkeit. Mit den Worten von Jez Humble „Schlechtes Verhalten entsteht, wenn man die Leute von den Konsequenzen ihres Handelns ablenkt.“ Ich denke, dass die enge Beziehung zwischen Produkt und Entwicklung das richtige Verhalten und die richtigen Kompromisse fördert.

Herausforderungen

Produkt und Entwicklung auf einen gemeinsamen Nenner zu bringen, ist nicht immer einfach. Die Beteiligten müssen lernen, die gleiche Sprache zu sprechen, einen gemeinsamen Kontext und ein gemeinsames Verständnis aufzubauen und darüber nachzudenken, wie sich unterschiedliche Arbeitsabläufe auf ein gemeinsames Ziel auswirken. Es kann etwas holprig werden, und bei jeder Veröffentlichung blicken wir zurück und sehen, wo wir noch hätten besser werden können.

Aber ich denke, es lohnt sich. Jedes Mal, wenn die Kluft zwischen Entscheidungen und Konsequenzen kleiner wird und wir Teams mehr Verantwortung für ihren Code übertragen können, liefern wir häufiger bessere Software aus und sorgen für zufriedenere Kunden. Anfangs ist es vielleicht gewöhnungsbedürftig, aber ich kann mir kein besseres Modell als DevOps für gutes Produktmanagement vorstellen.