Um Wachstum, Innovation und Kundenzufriedenheit voranzutreiben, verlassen sich Unternehmen heute in hohem Maße auf Technologie. Für diejenigen, die online arbeiten, wird DevOps früher oder später unverzichtbar.
A QUICK SUMMARY – FOR THE BUSY ONES
TABLE OF CONTENTS
Wenn es richtig umgesetzt wird, kann es die Lücke zwischen den Geschäftserwartungen und der Arbeit der Entwicklungsteams schließen. Dies kann natürlich einige Herausforderungen mit sich bringen — insbesondere, wenn Sie keine Erfahrung mit der Umsetzung einer DevOps-Strategie haben.
Wenn es das ist, womit Sie derzeit in Ihrem Unternehmen konfrontiert sind, dann sind hier meine Empfehlungen als DevOps-Leiter.
Die Rolle von DevOps besteht darin, Softwareentwicklung und IT-Betrieb zu integrieren, um schnellere Lieferzyklen, bessere Softwarequalität und Zuverlässigkeit zu erreichen. Diese „technischen“ Ergebnisse wirken sich direkt auf Geschäftsziele wie eine schnellere Markteinführung, eine höhere Kundenzufriedenheit und eine verbesserte betriebliche Effizienz aus.
Eine gut ausgearbeitete DevOps-Strategie sollte perfekt auf die Unternehmensziele abgestimmt sein. Hier sind ein paar Tipps, wie das geht:
Der erste Schritt besteht darin, klare, messbare Ziele zu setzen. Meiner Erfahrung nach besteht der schwierigste Teil darin, zu definieren, was „klar“ eigentlich bedeutet. Die Stakeholder im Unternehmen haben eine Vorstellung davon, was sie erreichen möchten, aber — da viele keinen technischen Hintergrund haben — verfügen sie nicht über die Mittel, um ihre Vision in konkrete IT-Ergebnisse umzusetzen.
Also, wie kannst du das angehen? Ich empfehle, groß angelegte Geschäftsziele in kleinere technische Kennzahlen zu unterteilen. Stellen Sie sicher, dass sie numerisch gemessen werden können, da die IT-Abteilung so viel besser verstehen kann, was genau bewertet wird.
Dazu könnten beispielsweise „Erhöhung der Seitenladezeit um X%“ oder „Erhöhung der Anwendungsverfügbarkeit auf 99,99%“ gehören.
Zum Ausrichten DevOps-Strategie mit Geschäftszielen Es ist wichtig, ein robustes Framework zur Erfolgsmessung zu entwickeln. Das beinhaltet Metriken und KPIs. Das Tech-Team definiert normalerweise Ersteres, während letztere aus dem Geschäft stammen.
Tal Holtzer, CEO von VPS-Server, teilt diese Perspektive. Er erzählte mir, dass ein entscheidender Moment für ihre DevOps-Effizienz die Entwicklung eines KPI war, der einen Zusammenhang zwischen der Häufigkeit der Bereitstellung und dem Grad der Kundenzufriedenheit herstellte.
„Wir konnten unsere DevOps- und Geschäftsteams zu einer effektiveren Interaktion ermutigen, indem wir die Geschwindigkeit, mit der wir Updates veröffentlichen, evaluierten und sicherstellten, dass diese Updates zu Verbesserungen sowohl der Verfügbarkeit als auch der Leistung führen.
Das Endergebnis? Neben einer höheren Kundenbindung stieg auch die Bereitstellungseffizienz um 25% „, so Holtzer.
Denken Sie daran, dass Kennzahlen die KPIs beeinflussen. Hier sind ein paar Typen, die du in Betracht ziehen kannst — sie sind allgemein bekannt als DORA-Metriken:
Wenn Teams diese Kennzahlen zusammen mit den Geschäftsergebnissen verfolgen, können sie besser verstehen, wie sich ihre Arbeit auf die Unternehmensziele auswirkt.
Gal Cohen, Leiter der Geschäftsentwicklung und Außendienstleiter bei JDM Schiebetüren, gab ein gutes Beispiel dafür, wie das in der Praxis funktionieren kann. Indem man dem DevOps-Team die Verantwortung für die „Zeit bis zur Problemlösung“ und nicht „nur“ für die Systemverfügbarkeit zuwies, verstand es seine umfassendere Rolle im Unternehmen. Er sagt, das Unternehmen sei sich bewusst geworden, dass es bei der Neustrukturierung seines Planungssystems die falschen Kennzahlen verfolgt habe.
„Wir hatten gelegentlich Synchronisierungsfehler, bei denen die Aufgabendetails überhaupt nicht aktualisiert wurden, was dazu führte, dass Techniker ohne die richtigen Informationen zu Terminen erschienen. Da es sich nicht um einen technischen Ausfall handelte, konnten herkömmliche Verfügbarkeitskennzahlen dies nicht kennzeichnen. Für unser Unternehmen war das ein echtes Problem. Nachdem wir die Verantwortung für DevOps auf die „Zeit bis zur Lösung“ verlagert hatten, begannen sie, diese Probleme als Umsatzblocker und nicht nur als kleine Störungen zu behandeln „, sagte Cohen. Nachdem dies ans Licht kam, automatisierte das Unternehmen Selbstheilungsskripte, um Synchronisierungsfehler zu erkennen und zu beheben — noch bevor ein Techniker merkte, dass ein Problem vorlag.
Das Aufbrechen von Silos ist eines der wichtigsten Prinzipien hinter DevOps. Unternehmen müssen sicherstellen, dass es über die verschiedenen Mitglieder des Produktentwicklungsteams hinausgeht und auch Perspektiven aus Marketing, Vertrieb und Kundensupport einbezieht.
Diese Stakeholder sind bei der Gestaltung Ihrer DevOps-Strategie so wichtig, weil sie Feedback-Schleifen von Kunden und anderen Abteilungen bereitstellen können.
Dies bringt mich zu einem wichtigen Punkt — wen wir als „Kunden“ definieren, hängt weitgehend von der Größe unseres Unternehmens ab. In kleinen und mittleren Unternehmen wie Brainhub sind Kunden die Endbenutzer einer Anwendung oder eines Produkts.
Diese Personen können — mehr oder weniger anonymisiert — ihre Meinung dazu äußern, was ihrer Meinung nach gut funktioniert und was verbessert werden muss und warum. Wenn Sie jedoch in einem großen Unternehmen arbeiten, sind Ihre Kunden möglicherweise tatsächlich die internen Abteilungen Ihres Unternehmens.
Wie Sie sich vorstellen können, wird die funktionsübergreifende Zusammenarbeit zwischen kleinen Unternehmen und Unternehmen unterschiedlich sein. Bei ersteren wird es wahrscheinlich um eine unkomplizierte Beziehung zwischen Unternehmen und Kunden gehen, während bei letzteren komplexe interne und externe Strukturen bestehen werden. Wenn Sie diese Unterschiede erkennen, können Sie besser verstehen, wo, wann und von wem Sie überhaupt Feedback einholen müssen.
Lassen Sie mich Ihnen ein Beispiel dafür geben, wie wir unsere Entwicklungs-Roadmaps bei Brainhub an der Marktnachfrage ausrichten.
Wie mein Kollege Mateusz Konieczny in unserem Bericht erklärt“Von der Vision zum Code“, „Unsere Technologieentscheidungen bei Brainhub sind grundsätzlich geschäftsorientiert. Wir konzentrieren uns immer auf das WARUM hinter jeder Entscheidung und legen sorgfältig fest, WIE diese umgesetzt werden soll“.
Um sicherzustellen, dass alles, was wir entscheiden, zur umfassenderen Unternehmensstrategie passt (nicht „nur“ zu technischen Zielen), greifen wir auf strukturierte Frameworks wie Entscheidungsmatrizen und Tech Radar zurück. Wir greifen auch ständig auf die Proof-of-Concept-Dokumente unseres Forschungs- und Entwicklungsteams zurück.
Dies hilft uns, ein klares Bild von den Zielen zu behalten, sodass wir die Arbeit jedes Teams im Hinblick auf Skalierbarkeit, Geschwindigkeit und Produktivität optimieren können.
Jedes Unternehmen wird natürlich seine eigenen „Go-to“ -Techniken haben. Um Ihnen ein weiteres Beispiel zu geben, Robbert Bink von Krypto erholt sich hat mir gesagt, dass das, was außergewöhnlich gut funktioniert, um DevOps und Business auf derselben Wellenlänge zu halten, gemeinsame Dashboards sind. Es ermöglicht beiden Seiten, wichtige Leistungskennzahlen in Echtzeit zu verfolgen und so die oft vorhandenen Kommunikationssilos aufzubrechen.
„Zum Beispiel richten wir Kennzahlen wie Bereitstellungshäufigkeit und Vorlaufzeit für Änderungen ein — wichtige DevOps-KPIs — sowie geschäftsorientierte Kennzahlen wie Kundenabwanderungsrate und Akzeptanz von Funktionen. Ein konkreter Fall, in dem sich dies als unschätzbar erwies, war die Einführung eines neuen Wiederherstellungstools für Krypto-Wallets. Als beide Teams sahen, wie sich schnellere Implementierungen direkt auf das Feedback der Nutzer und die Akzeptanz von Funktionen auswirkten, waren beide Teams motiviert, effektiver zusammenzuarbeiten, was letztendlich zu einer erfolgreichen und gut angenommenen Markteinführung führte „, so Bink.
Automatisierung kann in DevOps ein großer Vorteil sein, da sie die Konsistenz und Geschwindigkeit der Arbeit ermöglicht.
In einer Umfrage, die wir für den Bericht „From Vision to Code“ durchgeführt haben, fanden wir heraus, dass 78% der Unternehmen, die sich in hohem Maße für DevOps engagieren, auch angeben, dass Automatisierung eine große Rolle spielt.
Durch die Automatisierung von Test- und Bereitstellungspipelines können Sie beispielsweise Ziele wie schnellere Feature-Rollouts erreichen und Ihrem Team den manuellen Aufwand ersparen.
Allerdings möchte ich betonen, dass es gewisse Grenzen gibt, wann Automatisierung noch hilfreich ist und wo sie selbst zur Belastung werden kann. Wenn Sie für die Erledigung einer Aufgabe buchstäblich ein oder zwei Minuten benötigen, ist der Versuch, sie zu automatisieren, Ihre Zeit und Mühe nicht wert.
Bestimmte Aufgaben können schneller und kostengünstiger erledigt werden, indem sie weiterhin manuell ausgeführt werden. Was Sie automatisieren sollten, sind komplexe Prozesse, bei denen Sie deutlich erkennen können, welche Produktivitätsvorteile Sie erzielen werden.
Wenn Sie also an Ihrer DevOps-Strategie arbeiten, empfehle ich Ihnen dringend, zu überprüfen, ob Sie keine Prozesse automatisieren, die sie nicht wirklich benötigen.
DevOps-Praktiken sind auf kontinuierliche Verbesserungen ausgerichtet und eignen sich daher perfekt für die sich ändernden Geschäftsstrategien. Regelmäßige Rückblicke und datengestützte Anpassungen stellen sicher, dass sich Teams schnell an sich ändernde Geschäftsprioritäten anpassen, Ineffizienzen umgehend beheben und Prozesse für langfristigen Erfolg verfeinern.
Bevor ich auf jeden Punkt näher eingehe, möchte ich erklären, was ich mit datengesteuerten Anpassungen meine.
Ich stoße oft auf Unternehmen, die all ihre Daten verwenden, nur um datengesteuert zu arbeiten. Sie denken kaum darüber nach, was jedes Datenelement bedeutet, woher es stammt und ob es sich um echte Daten handelt. Entscheidungen auf der Grundlage von Daten zu treffen, die nicht verifiziert und zuverlässig sind, kann schwerwiegende Folgen haben.
Die Anpassung an sich ändernde Geschäftsprioritäten erklärt sich von selbst, und agile Teams sollten mit solchen Anpassungen keine Probleme haben. Um Ineffizienzen umgehend zu beheben, ist es wichtig, zunächst genau zu definieren, was eine Ineffizienz ist.
DevOps-Teams erhalten in der Regel viele Benachrichtigungen, um auf dem Laufenden zu bleiben, was mit einem System passiert. Wenn jede Woche dieselbe Warnung erscheint, ist dies ein deutliches Zeichen dafür, dass das System ineffizient ist. Diese muss zuerst behoben werden, bevor neue Funktionen bereitgestellt werden.
Meiner Erfahrung nach ist es besser, zu Beginn des Projekts zwei zusätzliche Tage damit zu verbringen, bestimmte Probleme zu lösen, anstatt sie auf einen späteren Zeitpunkt zu verschieben, da dies nur zu mehr technischen Schulden führt. Es ist oft besser, Prozesse von Anfang an zu verfeinern, als neue Funktionen mit unausgegorenen Prozessen bereitzustellen. Langfristig wird dies zu schnelleren Bereitstellungen und einer höheren Zuverlässigkeit führen.
Der ultimative Schritt, um die DevOps-Strategie an den Geschäftszielen auszurichten, besteht darin, kundenorientiert zu bleiben. DevOps-Teams sind zwar normalerweise nicht dafür verantwortlich, Feedback einzuholen, da dies die Aufgabe des Marketings und des Kundensupports ist, aber sie müssen es analysieren. Nur dann können sie sicherstellen, dass neue Funktionen oder Korrekturen den Kundenbedürfnissen entsprechen.
Die Aufrechterhaltung einer hohen Kundenzufriedenheit ist ein Geschäftsziel, aber es kann nicht erreicht werden, ohne das System voll funktionsfähig zu halten — und das ist die Domäne von DevOps.
Diese Liste wäre natürlich nicht vollständig, ohne die agilen Prinzipien zu erwähnen. Die DORA-Metriken, auf die ich zuvor Bezug genommen habe, wären unmöglich zu erreichen, ohne Ihre Arbeit auf einer agilen Methodik aufzubauen. Teams, die Agile in ihre Arbeitsabläufe integrieren, können:
Nur wenn Metriken und KPIs vollständig aufeinander abgestimmt sind, können DevOps und Unternehmen auf dasselbe Ziel hinarbeiten. Um dies effektiv zu erreichen, müssen Sie eine Strategie entwickeln und sicherstellen, dass alle kontinuierlich miteinander kommunizieren. Es ist auch äußerst wichtig, dass jeder weiß, wofür er verantwortlich ist und wo sich seine Arbeit mit der anderer im Team überschneidet.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Read next
Popular this month