Produktmanager in einer DevOps-Welt sein
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 verstehen, welche Auswirkungen ihre Entscheidungen auf die Funktionsfähigkeit der Software haben, 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 der Erstellung, Auslieferung und dem Betrieb von Software bei PagerDuty verwenden, und wie sie unserem Produktteam helfen, den Kunden einen Mehrwert zu bieten.
Schnelle, häufige und stabile Bereitstellungen
Die meisten unserer Github-Repos sind für die kontinuierliche Integration oder Bereitstellung eingerichtet. Wenn Sie eine Pull-Anfrage öffnen, wird Ihr Code wie von Zauberhand in die Cloud geladen, eine Reihe von Tests werden ausgeführt und wenn alle erfolgreich sind, erhalten Sie ein großes grünes Häkchen mit der Aufschrift „Sicher zur Bereitstellung“.
Wir haben auch ChatOps-Bereitstellung. Es gibt einen Kanal in Locker Hier können Sie einen Bot bitten, jeden Zweig eines beliebigen Repositorys in jede beliebige Umgebung, einschließlich der Produktion, zu werfen. Dies erleichtert auch die Untersuchung und das Zurücksetzen fehlerhafter Bereitstellungen und hilft im Allgemeinen dabei, Einblick in das zu gewinnen, was in unserer Infrastruktur vor sich geht.
Nachdem ich diese Magie erlebt habe, kann ich mir nicht vorstellen, in eine Welt zurückzukehren, in der Entwicklung und Bereitstellung erfordern, dass die Site für Wartungsarbeiten heruntergefahren wird oder ein separates Team damit beauftragt wird. Produktmanager leben und sterben von der Feedbackschleife – je länger Sie kein Live-Produkt sehen und daraus lernen, desto größer ist das Risiko, das Sie eingehen.
Gezielter Fehler
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, die möchten, in einem Raum und wir bauen einen Teil unserer Infrastruktur ab. Das Ziel ist dreifach:
- Setzen Sie die Erwartung, dass Sie bei der Einrichtung eines Dienstes bei PagerDuty diesen mit Scheitern im Sinn . Sie sollten damit rechnen, dass jederzeit verrückte Dinge passieren können und Sie wach bleiben müssen.
- Identifizieren Sie in einer kontrollierten Umgebung Bereiche, in denen unsere Systeme nicht robust sind, sodass wir diese Probleme beheben können, lange bevor Kunden davon betroffen sind.
- Ü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 ist auf dem Weg zum Erfolg mit vielen Risiken und Misserfolgen verbunden. Da dies in unserer Kultur verankert ist, ist es einfach, teamübergreifende Gespräche über diese Themen zu führen.
Ich habe auch viel aus der Praxis des inszenierten Scheiterns, der schuldlosen Nachbesprechungen und des systemischen Denkens gelernt. Ich habe gelernt, sowohl Scheitern als auch Erfolg nicht als einer einzelnen Entscheidung oder einer einzelnen Person zuzuschreiben, sondern als Wechselwirkungen mehrerer Überzeugungen und Umstände. Ich habe gelernt, einen Arbeitsrückstand aufzubauen, der keine Domino-Reaktion im Wasserfallstil erfordert, um erfolgreich zu sein, sondern der Unsicherheit Rechnung trägt 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.
Als Produktmanager ist das manchmal etwas frustrierend, denn es bedeutet, dass Ihr Fahrplan für neue Funktionen durch technische Schulden oder Betriebsprobleme durcheinander geraten kann. Dies sollte man eher im Hinterkopf behalten, wenn man die Arbeit plant und ein Team leitet.
Doch auf lange Sicht hilft die Eigenverantwortungskultur den Mitarbeitern nicht nur dabei, die richtigen Entscheidungen für das aktuelle Projekt zu treffen, sondern auch langfristig die richtigen Entscheidungen für ihr Team und die gesamte Organisation.
Bei DevOps sind Ihr Entwicklungsbudget und Ihr Betriebsbudget dasselbe Budget. Ihre Mitarbeiter sind dieselben Mitarbeiter. Wenn Sie wackeligen Code ausliefern oder Ihr Team über seine nachhaltigen 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
Es ist nicht immer einfach, Produkt und Technik auf einen gemeinsamen Nenner zu bringen. Die Leute müssen lernen, dieselbe 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. Das kann ein wenig holprig sein, und bei jeder Veröffentlichung blicken wir zurück und sehen, wo wir es hätten besser machen können.
Aber ich denke, es lohnt sich. Jedes Mal, wenn ich sehe, wie die Kluft zwischen Entscheidungen und Konsequenzen kleiner wird, jedes Mal, wenn wir Teams mehr Verantwortung für ihren Code geben können, liefern wir häufiger bessere Software aus und machen unsere Kunden zufriedener. Es kann anfangs eine Menge sein, an die man sich gewöhnen muss, aber ich kann mir kein besseres Modell als DevOps für ein großartiges Produktmanagement vorstellen.