Wie kann ich Entwickler in meinem Team davon überzeugen, "Sie bauen es, Sie leiten es" zu akzeptieren?

Wie kann ich Entwickler in meinem Team davon überzeugen, "Sie bauen es, Sie leiten es" zu akzeptieren? Dabei denke ich an dieses Zitat von Werner Vogels :

Die Übernahme der operativen Verantwortung der Entwickler hat die Qualität der Services sowohl aus Kunden- als auch aus technologischer Sicht erheblich verbessert. Das traditionelle Modell ist, dass Sie Ihre Software an die Wand bringen, die Entwicklung und Betrieb voneinander trennt, sie wegwerfen und dann vergessen. Nicht bei Amazon. Sie bauen es, Sie leiten es. Dies bringt Entwickler in Kontakt mit dem täglichen Betrieb ihrer Software. Es bringt sie auch in den täglichen Kontakt mit dem Kunden. Diese Kundenfeedbackschleife ist für die Verbesserung der Servicequalität von entscheidender Bedeutung.

Ich denke speziell an eine Reihe von Entwicklern, die:

• Wurden in eine Entwicklerrolle eingestellt, mit wenig / keiner Erwähnung von ops-bezogenen Aufgaben.
• Habe einem Ops-Team traditionell "Code über die Wand geworfen".
• Herkömmlicherweise haben sie einen 9-5-Arbeitszeitplan und sind aktiv gegen die Idee der "Pager-Pflicht", die Teilnahme an der Notfallwiederherstellung, das Verfassen von Obduktionen usw., insbesondere außerhalb der normalen Geschäftszeiten. (Hinweis: Ich habe diesbezüglich nur sehr selten Ausfälle im Auge. Ich schlage nicht vor, dass wir die Arbeitsbelastung dieses Teams um Kundensupport außerhalb der Geschäftszeiten erweitern.)
• Sie sind derzeit nicht dafür verantwortlich, Überwachungen oder Warnungen für ihre Anwendungen zu schreiben / zu unterstützen.

Angenommen, es gibt ein Team, das rasch neue Cloud-Mikroservices mit einem Profil entwickelt, das derart wird, dass die Weitergabe dieser Services an ein Ops-Team nicht optimal ist, weil es nicht mithalten kann, um tiefgreifende Kenntnisse zu erlangen die Dienste, die erforderlich sind, um sie effektiv zu verwalten und zu überwachen. "Sie bauen es, Sie führen es aus" würde für dieses Team besser funktionieren, da Aufgaben an jedes verantwortliche Teammitglied delegiert werden könnten. Daher begann dieses Team mit dem Entwerfen der Infrastruktur, dem Überwachen / Warnen von Tools für die Dienste und (sehr selten) dem Reagieren auf Ausfallereignisse.

Ich interessiere mich speziell für Methoden, die durch Beispiele aus der Praxis untermauert werden. Wie wurde dies an anderen Arbeitsplätzen erfolgreich umgesetzt, und ob dabei kanonische Schritte zu befolgen sind? Alle Links zu Aufzeichnungen, die Antworten unterstützen können, wären sehr hilfreich.

Ich denke, der einfachste Weg ist, ihre Leistungsziele zu ändern, damit sie sowohl auf Zuverlässigkeit als auch auf der Bereitstellung von Code basieren. Verkaufen Sie es, da das Unternehmen ohne beides nicht erfolgreich sein kann. Warum sollten die Entwickler nur an einem gemessen werden? Der beste Weg für sie, ihre Leistungsziele zu erreichen, besteht darin, in den Betrieb einbezogen zu werden.

Letztendlich müssen Sie sie davon überzeugen, dass dies der beste Weg für das Unternehmen und damit für sie ist. Das ist schwer und man kann nicht erwarten, dass sie von Anfang an an Bord sind. Sie müssen auch auf den Wert verkauft werden.

Wenn es darum geht, die Unternehmenskultur zu beeinflussen, geht der beste Weg wahrscheinlich über die bekannte "Boil the Frog" -Methode. Sie müssen diese Aufgaben den Entwicklern langsam vorstellen, weil ich weiß, dass ich selbst (als Entwickler) es ablehnen würde, all diese neuen Aufgaben auf einmal zu übernehmen.

Stellen Sie zunächst ein oder zwei neue Aufgaben vor, die nur während der normalen Geschäftszeiten ausgeführt werden sollen. Sie müssen lernen, wie man Devops macht, was durchaus der Lernprozess für einen (bis zu diesem Punkt) Code-only-Entwickler sein kann und eine gewisse Supervision erfordert. Wahrscheinlich stehen sie auch der Idee einer Änderung der Work-Life-Balance ablehnend gegenüber, da Sie erwähnen, dass sie an 9-5 gewöhnt sind. Zeichnen Sie zu diesem Zeitpunkt Daten zu den neuen Prozessen auf, die später verwendet werden sollen (lassen Sie sie diesen Code schreiben, Daten sind immer nützlich).

Später, wenn Ihnen die neuen Aufgaben zur Einführung ausgehen (so dass der erste, zweite und vierte Aufzählungspunkt fast abgeschlossen sind), müssen Sie die ersten Aufgaben, die Sie als Kandidaten eingeführt haben, außerhalb der normalen Arbeitszeiten ausführen . Es kann sein, dass Sie eine gewisse Gegenreaktion bemerken und sogar eine gewisse Abnutzung, je nachdem, wie stark Sie dies vorantreiben und wie stark die Kultur des Work-Ends-at-Five-Ansatzes verankert ist. Um sich dagegen zu wehren, unterstützen Ihre Daten hoffentlich die Idee, dass Arbeiten außerhalb der normalen Geschäftszeiten selten sind, nur in Extremsituationen auftreten und sowohl dem Unternehmen als auch dem Kunden große Vorteile bringen. Wenn Ihre Daten dies nicht unterstützen, sollten Sie besser bereit sein, sich mit den Konsequenzen dieser Wahl zu befassen.

Auch mit Daten, kann es noch einfacher sein , die Entwickler die Überwachung schreiben haben / Code Alarmierung (so werden sie dev ops aber nach wie vor hauptsächlich dev) und halten Sie die alternative ops Team als Front-Line - Support (wie ein paar andere haben vorgeschlagen). Wie gesagt, kleine Änderungen sind wichtig, um Spiel zu vermeiden. Die Integration von Arbeit für Entwickler über die normalen Arbeitszeiten hinaus wird eine Herausforderung sein, da sie möglicherweise wissen, dass sie anderswo nach Arbeit suchen können, wenn sie es nicht mögen, da der Markt für Entwickler derzeit stark ist, insbesondere wenn sie bereits über Fähigkeiten für Entwickler verfügen. Vorbehalt Emptor!

Wenn Sie außerhalb von DevOps über große (ish) Unternehmensumgebungen sprechen, bietet die SAFe- Methode eine gute Möglichkeit, diese Art von Verhalten zu fördern.

Im Wesentlichen handelt es sich um einige Schlüsselschritte:

• Projekte beginnen als Auslösezüge. Die Absicht (und die Erwartung derjenigen, die es finanzieren) ist, dass es langfristig sein wird. Ich spreche jahrelang, nichts davon "Steh ein Team für 3 Monate auf, dann steh sie nieder".

• im laufe eines projekts wird der release train zwangsläufig mehr menschen anhäufen, da sowohl neue projektanforderungen aufgrund neu realisierter geschäftschancen als auch die laufende steuer für wartungsarbeiten eine wichtige rolle spielen.

• Ich sehe fast immer, dass die Züge ihr erstes Inkrement als 100% -Projekt- / Änderungsteams ausführen, das zweite Inkrement einen bestimmten Prozentsatz der Zeit für die Ausführung der Arbeit verwenden. Das 3rd-Increment-Management stellt fest, dass es bald ein Problem gibt, und fängt an, Teams hinzuzufügen, um den Run-Überlauf zu bewältigen, damit die erfahrenen Entwickler und Ingenieure Zeit haben, weiter an neuen Anforderungen zu arbeiten.

• Wenn die richtige Balance gefunden wird, wenn Projektteams in der Lage sind, weiterhin Projektergebnisse zu liefern, ohne dass die Wartungsarbeiten zu langwierig werden, und wenn neue Teams in den Zug einsteigen, ist nicht sofort zu erwarten, dass es sich nur um 100% ige Supportteams handelt, sondern um ein Team ein angemessener Teil der Änderungsarbeit, die erledigt werden sollte, dann landet man bei Auslieferungsteams, die die Produkte besitzen, die sie standardmäßig bauen. Es muss nicht sofort geschehen, dass sie jetzt ein Run-Team sind. Stattdessen integriert es sich nur langsam in ihre täglichen Aktivitäten.

Wo dieses Modell offensichtlich einige Schwächen aufweist, liegt die Preisgestaltung für ein Unternehmen. Im Allgemeinen würde ich davon ausgehen, dass Sie für eine Änderungsressource viel mehr bezahlen als für eine laufende Ressource. In der Regel sind laufende Verträge mit großen Anbietern Festpreise und die Absicht ist, dass sie ihr Geld für kontinuierliche Verbesserungen und damit Kosteneinsparungen verdienen.

Abgesehen davon ist es nicht allzu schwierig, die Change-Teams als Teil eines Release-Zugs zu betrachten, um einfach kontinuierliche Verbesserungen zu liefern. Wenn sie etwas aufbauen oder tun können, das ihre Fähigkeit verbessert, sich auf neue Projektlieferungen zu konzentrieren und sich weniger mit der Arbeit "business as usual" zu befassen, sollte dies auf der Grundlage des wahrgenommenen Nutzens durch denjenigen, der das Geld für das Projekt besitzt, zurückgestellt und priorisiert werden Zug loslassen.

IMHO You build it, you run itsollte nicht wörtlich genommen werden. Zu Beginn - es klingt fast wie eine Bestrafung;)

Keine einzelne Person oder auch nur ein kleines Entwicklerteam kann ein Tool oder ein Toolset, das im Softwareentwicklungsprozess (dh in der Produktion!) Verwendet wird, für längere Zeit angemessen unterstützen. Kenne ich schon :)

Die Support-Aufgaben werden tendenziell erweitert, wenn der Kundenstamm der Tools (Sets) wächst. Wenn das Entwicklerteam ausschließlich diese Aufgaben übernimmt, kann es am Ende vor allem Unterstützung leisten, und es bleibt nur wenig / keine Zeit mehr für die weitere Entwicklung. Eigentlich eine Sackgasse - wie viele Entwickler möchten in einem solchen Umfeld bleiben?

Ein professionelles Support-Team der ersten Reihe ist von entscheidender Bedeutung, um Frustrationen, Stress und andere Auswirkungen einer langfristigen Belastung der Mitglieder Ihres Entwicklerteams durch Support-Pflichten zu vermeiden.

Das 1st-Line-Support-Team würde natürlich auf das Entwicklerteam zurückgreifen (wieder Team, nicht Einzelperson!), Wenn Probleme auftreten, die nicht direkt behandelt werden können. Ja, es mag anfangs schwierig sein, aber es wird besser. Es sollte eine Zusammenarbeit sein - das ist ein Teil dessen, worum es bei DevOps geht.

Dies hängt letztendlich von der Größe und Struktur des Unternehmens ab. Es gibt drei Phasen, in denen sich Ihr Unternehmen befinden kann:

1. Die Startphase (unter 150 Ingenieuren). Natürlich müssen die Entwickler ihre eigene Software ausführen. Jeder tut dies in einem Startup. Sie haben vielleicht noch nicht einmal ein Betriebsteam, aber selbst wenn Sie dies tun, ist es klein und die Geschwindigkeit des Fortschritts ist so hoch, dass es nicht möglich ist, das Wissen, das für die erfolgreiche Ausführung erforderlich ist, schnell genug an ein anderes Team weiterzugeben erfolgreich sein.

2. Das mittelständische Unternehmen (über 150 Ingenieure, aber ein einziges Betriebsteam). Zu diesem Zeitpunkt ist die Abwanderung im Unternehmen zu hoch, und die Ingenieure, die Software entwickeln, müssen nicht unbedingt mitarbeiten, um sie auszuführen. Sie kennen nicht mehr alle und es ist schwierig, effektiv zu kommunizieren, damit alle im Einsatz sind. Es würde anfangen, sich in Chaos zu verwandeln. Zu diesem Zeitpunkt möchten Sie sich dem Google-Modell zuwenden, bei dem jedes Team seine Software operationalisieren muss, diese jedoch nicht unbedingt ausführen muss. Sie werden es zu Beginn betreiben, aber ein großer Teil der Erstellung von Software besteht darin, die Betriebskosten auf einen Punkt zu senken, an dem die Last so gering ist, dass das Betriebsteam sich anmelden kann, um es auszuführen. Erst dann gilt es als erledigt.

3. Großes Unternehmen mit mehreren Geschäftsbereichen (in denen jeder ein eigenes Betriebsteam hat): In dieser Phase können Sie auf das Amazon-Modell zurückgreifen, in dem jedes Team, das wesentlich ist, seine eigenen Dienste entwickelt und betreibt. Jeder Geschäftsbereich muss klein genug sein, damit sich alle kennen. Unter 150 Ingenieuren agieren Sie also im Wesentlichen als Start-up. Bei Amazon wird jeder AWS-Dienst mehr oder weniger separat ausgeführt und funktioniert für sie.

Sie müssen herausfinden, in welcher Phase sich Ihr Unternehmen befindet und / oder sich in dieser befindet, und entsprechend handeln. Es gibt keine "Einheitsgröße" -Lösung.

Meine Einstellung dazu (wenn ich mit einem solchen Gebot konfrontiert wäre oder wie auch immer Sie es nennen würden) wäre so etwas wie " What else would you expect?!?!". Weil aus Versehen:

• Ich würde nicht einmal in der Lage sein, ohne es zu leben, und
• Ich esse sehr gerne mein eigenes (Hunde-) Essen.

Lassen Sie mich noch etwas näher erläutern ...

Mein Geschäft / Hobby / Leidenschaft ist scm , genauer gesagt in Mainframe- Umgebungen. Und wo immer ich mich befinde (um das Material auf die Bedürfnisse des Kunden abzustimmen), besteht die allererste Anforderung, die ich (in meinem Vertrag) auferlege , darin, dass jede Abstimmung des von uns implementierten Systems über dasselbe System erfolgt. Und wenn wir dies tun (das dauert ein paar Stunden, etwa einen halben Tag, bis es soweit ist), erhalten wir die folgenden Vorteile (unvollständige Liste):

• Ich dokumentiere kaum etwas, was ich getan habe, um das System zum Laufen zu bringen. Wenn irgendwelche Fragen gestellt werden, frage ich einfach das System ab (und bringe dem Kunden bei, wie man das System ohne meine Hilfe abfragt).
• Wenn ich in X Monaten / Jahren dazu aufgefordert werde (um auf ein neues Release aufzurüsten?), Möchte ich wissen (erinnern), was "ich" zuvor getan habe (und das einzige, dem ich vertraue, ist das, was mir das System sagt, auch bekannt als erinnert mich an).
• Ich muss den Kunden nur einmal fragen, wie er bestimmte Dinge auf seiner Website tun soll (Namenskonventionen sind schwer zu merken), oder ihn davon überzeugen, die erforderlichen Berechtigungen für "das System" zu erteilen (nicht für mich ...).
• Sie continuouslytesten Ihr eigenes System für die Qualitätssicherung ... in der Produktion. Möglicherweise treten Fehler, logische Fehler oder fehlende Funktionen (und was nicht) auf. Und diese sind äußerst motivierend, sie so schnell wie möglich anzusprechen ... z. B. um produktiver zu werden.
• ... und wenn Sie möchten, kann ich noch ein Dutzend Gründe hinzufügen ...

Bevor Sie dies jedoch zu Hause ausprobieren, sollten Sie sich einiger Gefahren bewusst sein, um Folgendes zu vermeiden:

• Sie möchten, dass alle an der Party teilnehmen (das System verwenden), da nur eine "Ausnahme" (auch bekannt als Manager / Eigentümer des Unternehmens) die Party ruinieren kann (Sie würden meinen, Sie können Ihrem System vertrauen, aber dann hat jemand etwas getan) ohne das System zu fragen / zu benutzen). Dieser Fall kann Tage kosten, um zu entdecken ...
• Neue Benutzer könnten sich darüber beschweren, dass es mit diesem (neuen) System viel länger dauert, bis sie ihre Arbeit erledigt haben (im Vergleich zu dem, was sie zuvor verwendet haben). Und wo immer es Sinn macht, werden sie das als Entschuldigung dafür benutzen, warum sie zu spät kommen, um ihre Arbeit zu erledigen. Zu diesem Zeitpunkt sollten Sie besser vom oberen Management abgedeckt werden, da sonst möglicherweise Ihr Projekt / System die Schuld trägt.
• Stellen Sie sicher, dass Sie Ihr eigenes System kennen und wissen, wie es an Ihre Anforderungen angepasst werden kann. Beispiel (in meinem Fall): Sie möchten das System so konfigurieren, dass Sie die Betriebsumgebung für die Bereitstellung in Ihrer experimentellen Umgebung verwenden und nicht umgekehrt. Ich habe gesehen, dass dies in der Vergangenheit passiert ist. Verwendung (Missbrauch) des Testsystems zur Bereitstellung in hochsicheren Umgebungen.