Serverlose Architekturen wirken sich grundlegend auf die begrenzenden Faktoren aus, die die Produktentwicklung einschränken.Produktmanager in der Organisation agieren in verschiedenen Rollen. Manchmal werden sie als "Kundenstimme" bezeichnet, manchmal spielen sie die Rolle der
"Corporate Cat-Hazard" . Sie sind fetthäutige Brüder, Menschen, die Sie unaufhaltsam dazu bringen, das Produkt zu liefern, trotz jeglicher Ethik oder Ausreden. Ein guter Produktmanager wird selten zum Vorbild eines anderen, aber dank der Arbeit solcher Menschen sind die meisten der technologischen Lösungen, die Sie jemals verwendet haben, verkörpert.
PM ist immer auf der Suche nach Werkzeugen von höchster Qualität, um das Problem zu lösen. Wir wissen, dass Wettbewerber ständig auf den Fersen sind, die Kunden es satt haben zu warten, deshalb müssen wir ständig intelligenter, schneller und effizienter handeln. Mit dem Aufkommen serverloser Technologien war nicht sofort klar, wie sie in die Wunschliste des Produktmanagements passen würden. Nachdem ich ein Jahr lang mit diesen Technologien gearbeitet habe, sehe ich jedoch, dass sie einige Probleme der Softwareentwicklung lösen, die uns für immer erschienen.
Paradox: Teamgröße und Leistung
Die erste Regel des Produktmanagements lautet: Der Arbeitsaufwand wächst ständig. Der Rückstand schwillt weiter an und fällt nur in einem Fall auf Null: wenn das Produkt eliminiert wird. Am schwierigsten ist es, die wichtigsten Elemente Ihres Auftragsbestands in ein Produkt zu verwandeln, das zur Auslieferung bereit ist. Wenn alle anderen Dinge gleich sind, wird angenommen, dass die folgende Beziehung eingehalten werden sollte:
Wenn ein Bagger 1 Tonne Erde pro Tag recyceln kann, wird davon ausgegangen, dass 10 Bagger 10 Tonnen recyceln können. In der Regel basiert das Ressourcenmanagement in Unternehmen auf diesem Prinzip: Wenn Sie den Umsatz steigern möchten, stellen Sie mehr Vertriebsmitarbeiter ein. Wenn bei der Entwicklung von Software der Rückstand wächst, besteht die Versuchung darin, einfach das Team zu vergrößern. In Fällen mit komplexen Produkten und Dienstleistungen zeichnet sich jedoch im Laufe der Zeit normalerweise ungefähr der folgende Zeitplan ab:
Es ist selten zu sehen, wie ein riesiges Team im Stachanow-Tempo arbeitet. Aber es kommt oft vor, dass ein kleines Team mit beneidenswerter Konstanz sprunghaft Fortschritte macht.
Viele Startups haben diese Art von Fehler: Sobald das Produkt erfolgreich ist, werden mehr neue Entwickler und Manager zu den Mitarbeitern hinzugefügt. Bald stellt sich plötzlich heraus, dass die Geschwindigkeit zu sinken beginnt. Was ist los? Dass die ersten Entwickler talentierter waren, dass die Bürokratie im Unternehmen wuchs und wie die Architektur geplant war?
Ich denke, all dies sind nur Symptome, nicht die Wurzel des Problems. Das Problem selbst beruht auf dem Zusammenspiel von drei kritischen Faktoren, von denen nur zwei direkt gesteuert werden können:
- Fragilität ist der Effekt neuer Veränderungen. Wenn eine neue Funktion nur einen Teil der Maschine betrifft, ist sie einfach zu testen und zu implementieren. Wenn alle Elemente der Maschine betroffen sind, wird das Testen schwieriger und gleichzeitig wichtiger, und die Implementierung erfordert eine Größenordnung mehr Zeit.
- Das Arbeitsvolumen ist die kleinste Arbeit, die von einem Team ausgeführt werden kann, und bietet eine produktive Funktion am Ausgang. Das Ergebnis ist beispielsweise "Bezahlen mit Alexa" und nicht "Zusammenkommen und diskutieren, wie Zahlungen mit Alexa getätigt werden".
- Komplexität - wie viel Wissen erforderlich ist, um eine Funktion zu implementieren. Ist ein Entwickler, der weiß, wie man eine Funktion schreibt, in der Lage, dasselbe innerhalb des Unternehmens zu tun? Welche zusätzlichen Änderungen müssen vorgenommen werden, damit sich der Fortschritt allmählich verlangsamt und das Produkt nicht mehr mit Funktionen wächst, die aus Sicht des Kunden wertvoll sind?
Mich interessiert besonders, warum all diese Faktoren zu Beginn der Existenz optimal ausgewogen sind: Es gibt nichts Fragiles, der Arbeitsaufwand ist nicht besonders groß (und Sie können dem Kunden normalerweise zustimmen) und die Komplexität fehlt praktisch. Wenn ein Team eine GDPR-konforme Site erstellen muss, hat es Zeit, dieses Problem zu untersuchen. Eine Entscheidung wird schnell getroffen, und das Team kann sicher sein, dass die Site genau wie geplant funktioniert.
In größeren Unternehmen werden diese Faktoren kombiniert, was zu einer wachsenden Teamgröße führt, und das Arbeitsvolumen wird reduziert. Um eine GDPR-kompatible Website in einem solchen Unternehmen zu erstellen, benötigen Sie die Unterschrift eines Anwalts, die Genehmigung der Vermarkter, die Genehmigung des Projekts auf der Ebene des Verwaltungsrates, die A / B-Prüfung der am wenigsten störenden Implementierung, die Koordination von Entwicklungsunterbrechungen mit dem Admins-Team und die Koordination mit den von anderen Teams verabschiedeten Bereitstellungsplänen - Die Liste geht weiter. Trotz dieser Kontrolle und der Anzahl der Prozesse ist das Team aufgrund der Fragilität des gesamten Systems und vieler Unbekannter im Ökosystem viel weniger zuversichtlich, dass es erfolgreich sein wird.
Wenn Sie dieses Beispiel auf die Größe eines realen Projekts erweitern, in dem es möglicherweise Dutzende von Funktionen und Hunderte von Änderungen gibt, ist es leicht zu verstehen, wie sich aufgrund des Einflusses dieser Faktoren das Diagramm des Verhältnisses „Teamgröße / Arbeitsvolumen“ vom ersten zum zweiten ändert. Wenn das Team wächst, sind Sie dazu verdammt, weniger Arbeit pro Zeiteinheit zu erledigen, unabhängig davon, wie Sie versuchen, den Organisationskoloss zu überlisten. Oder scheint es einfach so - aber was ist dann zu tun?
Wie man alle drei Faktoren hackt
Dieses Problem verfolgt mich seit vielen Jahren, was mich dazu veranlasste, die möglichen Ursachen zu untersuchen. Können Startups schnell Fortschritte machen? Für eine Weile dachte ich nur, angesichts der Schwierigkeiten des Produktmanagements in großen Organisationen. Dann habe ich mir jedoch alle drei Faktoren genauer angesehen.
Zerbrechlichkeit ist immer zu Ihrem Nachteil - sie führt bei jedem Projekt jeder Größe zu einer ständig wachsenden technischen Verschuldung. Die Situation erinnert an die „Halbwertszeit im Gegenteil“: Jedes Element des Programms wächst mit der Zeit und wird dadurch (während der Entwicklung) fragiler, und all dies wird mit jeder neuen Codezeile zusammengesetzt.
Der Arbeitsaufwand hängt nicht mit einem bestimmten Merkmal des Produkts zusammen („Pay with Alexa“), sondern mit Unterschieden in den Umrissen der Infrastruktur, wenn wir die Zustände „vorher“ und „nachher“ vergleichen. Je schwieriger das „Nachher“ wird, desto mehr Arbeit wird reduziert. Aus diesem Grund wird in vielen Unternehmen bei der Planung von Arbeiten der Schwerpunkt von den Bedürfnissen des Kunden („Pay with Alexa“) auf die Bedürfnisse des Unternehmens verlagert („Treffen und diskutieren Sie, wer an der Implementierung der Funktion„ Pay with Alexa “beteiligt sein sollte).
Komplexität ist eine Kombination aus sozialen, organisatorischen und technischen Faktoren, die sich direkt auf die Dauer der Suche nach einem geeigneten Entwickler auswirkt. Die Fähigkeit, Programmierer als Multitasking-Mitarbeiter zu behandeln, die mit jedem Job betraut werden können. Darüber hinaus ist es Komplexität - genau der Aspekt, der wahrscheinlich unsichtbar, undokumentiert und missverstanden bleibt. Ein Entwickler kann eine React-Anwendung zu Hause schreiben und selbst freigeben. In der Organisation muss er jedoch ein Dutzend zusätzliche Schritte ausführen, die seine Zeit in Anspruch nehmen, und die für den Benutzer interessanten Funktionen ändern sich überhaupt nicht. Der Programmierer wird den größten Teil des Tages mit ihnen verbringen.
Zusammen bilden diese drei Faktoren einen Teufelskreis, so dass der Arbeitsaufwand abnimmt, die Fragilität zunimmt, der Entwickler immer weniger Funktionen ausführt und Ihr Produkt als unsichtbarer Schlamm mit Komplexität bewachsen ist. Folglich hilft das Wachstum des Teams nicht, und die Geschwindigkeit kann nur durch List mit Zahlen und Indikatoren bewusst gesteigert werden. Ein klassisches Symptom: Die Position „Besprechung abgehalten“ wird in Sprintberichten angezeigt.
In großen Unternehmen musste ich einige fehlerhafte Ansätze beobachten, um diesen Kreislauf zu durchbrechen. Das erste ist „Large-Scale Agile“, was zu großen Meetings führt, an denen absolut alle Teilnehmer an der Entwicklung eines bestimmten Features teilnehmen und versucht wird, die Arbeit zu koordinieren. Versuchen Sie also, die Arbeit zu koordinieren und die Komplexität zu verstehen. Ein solcher Ansatz ist gut für Lebensmittelvertriebsunternehmen, die bezaubernde Mittagessen anbieten, aber in unserem Fall funktioniert er nicht. Tatsache ist, dass die Größe der Gruppe vorrangiger Projekte immer größer wird und sie selbst abnimmt. Daher ist es nicht möglich, die Probleme der Fragilität und Komplexität grundlegend zu lösen. Im Laufe der Zeit bietet Agile in großem Maßstab eine taktische Liste von Aufgaben, die einer Einkaufsliste ähnelt und immer weniger einem ganzheitlichen Weg von einem durchdachten Feature zum anderen ähnelt.
Zweitens versuchen unternehmensinterne „Innovationsgruppen“ häufig, periphere Veränderungen voranzutreiben, in der Hoffnung, dass diese Arbeit in einer fragilen Maschine Fuß fasst und sich die gesamte Struktur zum Besseren ändert. Dieser Ansatz hat einen bizarren Nebeneffekt: Die Überzeugung wird gefestigt, dass nur solche „Gruppen von Innovatoren“ das Recht haben, Änderungen am Prozess vorzunehmen. Daher löst eine ähnliche Methode auch keine Probleme mit der organisatorischen Komplexität.
Nachdem ich viele Jahre lang verschiedene Fehler gesehen hatte, kam ich zu dem Schluss, dass es notwendig ist, alle drei Faktoren zu hacken, um ihre kombinierte Wirkung auf die geleistete Arbeit zu verhindern und mit Trägheit umzugehen:
- Die Fragilität sollte in zukünftigen Versionen oder mit zunehmendem Alter des Produkts nicht zunehmen.
- Die Arbeit sollte nicht geringer sein als das, was erforderlich ist, um ein Merkmal zu erstellen, das aus Sicht des Benutzers von Bedeutung ist.
- Die Komplexität sollte die Arbeit eines einzelnen Entwicklers nicht beeinträchtigen.
Wenn es Ihnen gelingt, diese Ideen zu übernehmen, sind Sie vor Stein geschützt, der alle Softwareprodukte in der Geschichte der Menschheit verfolgt. Es klingt großartig, aber wie kann dies erreicht werden?
Wenn es Ihnen gelingt, diese Ideen zu übernehmen, sind Sie vor Stein geschützt, der alle Softwareprodukte in der Geschichte der Menschheit verfolgt. Es klingt großartig, aber wie kann dies erreicht werden?
Serverless Technologies brechen Einschränkungen
Dank des Aufkommens der Cloud-Technologie war es möglich, wichtige Wege in einen neuen „gehackten“ Zustand zu ebnen. Im Allgemeinen wurde mit dem Aufkommen der Clouds der Prozess der Bereitstellung eines Softwareprodukts kompakter, da ein Anbieter begann, viele Routinetätigkeiten für Sie zu erledigen. Bevor die Clouds angezeigt wurden, mussten Sie, wenn Sie eine neue Benutzerfunktion implementieren mussten, einen Server bestellen, Geräte auf Racks installieren, Netzwerke in einem Rechenzentrum verlegen und diese Geräte dann warten, die sich mit der Zeit abnutzen. In der Cloud kann all dies gemietet werden, wodurch Dutzende von Organisationselementen beseitigt und ganze Monate gespart werden.
Darüber hinaus reduzieren wir die Fragilität und Komplexität, da keine Geräte in einem Rechenzentrum aktualisiert werden müssen und bei Bedarf Zugriff auf Hardware bereitgestellt wird. Die Verwendung von Programmen ist viel einfacher als früher. Im Laufe der Zeit hat der Aufwand für die Verwaltung einer umfangreichen virtuellen Infrastruktur jedoch erheblich zugenommen, und viele veraltete Bereitstellungsmethoden sind unverändert geblieben. Mithilfe der Clouds kann das Team erheblich vergrößert werden, bevor sich die Arbeit verlangsamt - es verlangsamt sich jedoch auf die eine oder andere Weise.
Serverlose Technologien verändern diese Dynamik radikal. Die serverlose Anwendung besteht aus kleinen Codeteilen, die von Ihrem Team geschrieben wurden (der sogenannte „Kleber“), und funktionalen „Black Boxes“, die vom Cloud-Anbieter verwaltet werden. Die Black Box akzeptiert einfach eine Konfiguration und reagiert auf Änderungen. In einer Anwendung mit einer hochwertigen Architektur fällt ein Standardteil der mit dem Betrieb der Anwendung verbundenen Betriebsarbeit auf die Standard-Blackboxen. Die Anwendung selbst ist keine monolithische Funktion mehr, sondern eine föderale Struktur von Funktionen und Black Boxes.
In der Praxis wirkt sich dies dramatisch auf die drei oben genannten Faktoren aus:
- Die Fragilität wird aufgrund der Nullkosten für das Infrastrukturmanagement und der schwachen Bindung verringert. In unseren eigenen Projekten wurde beobachtet, dass die Codebasis infolge solcher Änderungen manchmal verzehnfacht werden kann.
- Die Größe des „Werkstücks“ ist normalerweise mit den Kosten für die Erstellung eines neuen Features vergleichbar, da es trivial wird, neue Versionen von Funktionen oder völlig neue Funktionen zu erstellen, die zuvor nicht benötigt wurden.
- Die Komplexität wirkt sich nicht auf den Entwickler aus. Wenn er eine Funktion schreiben kann, die Kreditkartenzahlungen verarbeitet, gibt es in der serverlosen Anwendung praktisch nichts zu tun, zusätzlich zu diesem Code, keine organisatorischen Wrapper und keine Berücksichtigung des Ökosystems, wodurch die Arbeit verlangsamt werden könnte.
Bei der Verwaltung auch sehr großer Anwendungen ohne Server kann der Produktmanager die wenigen Elemente, die von den vorgenommenen Änderungen betroffen waren, leicht genauer betrachten. Darüber hinaus ist es einfach, zwei Versionen wettbewerbsfähig zu starten, indem Flaggen von Funktionen platziert werden. Darüber hinaus ist es normalerweise nicht einmal notwendig, alte Codeversionen abzureißen.
In Anwendungen ohne Server wird die Infrastruktur immer auf der Peripherie aufgebaut, und Sie schreiben nur den erforderlichen Mindestcode, der vollständig verwaltete Dienste kombiniert. Sie müssen nie aus betrieblicher Sicht darüber nachdenken. Wir versuchen nicht, den Monolithen zu kontrollieren, den alten Code zu bereinigen oder das gesamte System aus der Vogelperspektive zu betrachten.
Warum ist es immens wichtig
Mit zunehmendem Tempo des Wandels wird es immer schwieriger vorherzusagen, wie Ihr Programm in Zukunft aussehen wird oder was Benutzer von Ihnen erwarten. Daher werden Versuche, Code „seit Jahrhunderten“ so zu schreiben, dass er in Zukunft trotz aller Änderungen funktionieren muss, immer vergeblicher. Wir haben gesehen, wie schlecht die Wiederverwendung von Code in den meisten Unternehmen ist und wie die Einhaltung veralteter Plattformen den Fortschritt verlangsamt.
Jetzt ist alles so angeordnet, dass das alte System so lange wie möglich entwickelt und gewartet wird, bis seine Unterstützung dem Programmierer fast immer wieder abnimmt. Danach beginnt das Unternehmen erneut mit dem neuen System und verspricht feierlich, die Fehler des alten Systems nicht zu wiederholen. Wenn drei Faktoren früher oder später das neue System erwürgen, kommt es zu einem technologischen „Waldbrand“, nach dem Sie erneut von vorne beginnen müssen.
Wir wenden uns dem Kampf gegen die Symptome der Komplexität zu, weshalb so viele Paradigmen kommen und gehen und keine wesentlichen Spuren in der Geschichte des Produktmanagements hinterlassen. Die serverlose Entwicklung wiederum ermöglicht es dem Team, die zunehmende Komplexität zu minimieren und weiterhin ein wertvolles Produkt in einem ziemlich gleichmäßigen Tempo zu liefern, ohne in klassische Fallen zu geraten, die seit Jahrzehnten die Geißel jeder Softwareentwicklung sind.
Das serverlose Paradigma beginnt sich gerade zu entwickeln, scheint aber bereits äußerst vielversprechend. In einer Zeit, in der der Kunde neue Funktionen wie nie zuvor benötigt, können Produktmanager endlich eine Plattform erwerben, auf der Sie anhand der Vorbereitung neuer Funktionen präzise denken können. Dieser Prozess wird nicht durch die zunehmende Komplexität der Organisation behindert und hört auch nicht aufgrund übermäßiger Fragilität auf.