Verschiedene Organisationen verfolgen unterschiedliche Ansätze bei der Softwareentwicklung. Und je nachdem, in welcher Phase sich die Organisation befindet, kann ein Ansatz den anderen überwiegen.

Beginnen wir mit einer Geschichte.

Kürzlich bin ich auf ein Projekt gestoßen, das an einem Scheideweg stand und wir uns zwischen Skaleneffekten und schneller Markteinführung entscheiden mussten. Ich beschloss, die Angebote des internen Teams weiter zu nutzen, um die langfristigen Unternehmensziele zu erreichen und technische Schulden zu minimieren.

Nun ja ... das ist fehlgeschlagen und es hat mich und mein Team wieder getroffen. Unabhängig vom Ergebnis habe ich mir beim Nachdenken über dieses Projekt ein paar Gedanken zur Bewertung genau dieses Themas gemacht, von denen ich hoffe, dass sie Ihnen (und meinem zukünftigen Ich) bei der Wahl zwischen Skaleneffekten und dem Build-it-Prinzip helfen werden -Selbst-Ansatz.

Die Skaleneffekte ermöglichen es Teams, sich auf einen bestimmten Bereich zu spezialisieren.

Was dich hierher gebracht hat, wird dich nicht dorthin bringen. Mit der Skalierung einer Organisation wächst auch die Fachkompetenz, die ein Team behalten muss. Dies ist der Hauptgrund, warum Teams aufgeteilt und Missionen gebildet werden: um atomare Probleme zu lösen.

Durch die Spezialisierung auf eine Domäne kann das Team tief in einen Bereich vordringen und sich den Code, den Betrieb und die Sicherheitsaspekte des Dienstes aneignen. Die Erwartung, dass Ingenieure die gesamte Organisation verstehen und mit allem umgehen können, führt oft zu Ineffizienzen.

Es kann äußerst kostspielig sein, vom gesamten Unternehmen zu erwarten, dass es alle Compliance-Vorgaben versteht, die mit der Verwaltung von Daten wie PCI/PII/HIPAA einhergehen. Hier hat das spezialisierte Team einen Vorteil; Sie werden zu Experten auf diesem Gebiet, und ihre Kunden nutzen einfach ihre Angebote und vertrauen darauf, dass diese entsprechend gehandhabt werden.

Das alles gibt es natürlich nicht umsonst. Die versteckten Kosten können dazu führen, dass Sie sich für die Option entscheiden, Software selbst zu erstellen.

Wenn Sie anfangen zu arbeiten und auf andere Teams angewiesen sind, wird die Ausrichtung der Prioritäten von entscheidender Bedeutung. Was Ihnen wichtig ist, ist für sie nicht immer wichtig. Sie müssen sie davon überzeugen, ebenfalls investiert zu werden. Bestehende Plattformen und Dienste funktionieren basierend auf ihrer Dokumentation (falls vorhanden) nicht immer. Es besteht immer eine hohe Wahrscheinlichkeit, dass die APIs scheinbar funktionieren, aber nicht funktionieren. Seien Sie bereit und puffern Sie diese.

Der Release-Zeitplan ist nicht mehr unabhängig. Sie können kein Produkt veröffentlichen, bei dem Ihre kritische Abhängigkeit nicht live geht. Es ist mehr Koordination erforderlich, und hier ist die Einbeziehung einer starken Führung von entscheidender Bedeutung.

Auch Fehler und Mängel können problematisch sein und dazu führen, dass man „die heiße Kartoffel wegwirft“, anstatt sich mit den Schwachstellen und Beschwerden des Kunden zu befassen.

Erkenntnisse

Auf Makroebene glaube ich, dass die Nutzung interner Teams, die sich auf eine Domäne spezialisiert haben, wichtiger ist als die Neuerfindung des Rades. Dadurch entsteht eine langfristige Hebelwirkung. Eine leichte Verzögerung eines Projekts im Gegenzug zum Aufbau eines funktionierenden Mechanismus führt auf lange Sicht zu einem weitaus besseren Ergebnis.

Jedoch…

Es gibt noch ein paar Dinge zu beurteilen:

1. Legt Ihr Unternehmen Wert darauf, es richtig oder schnell zu machen?
2. Versteht das Team den Vorteil von Skaleneffekten?
3. Ist die Kultur bereit, auf dieses spezielle Modell umzusteigen?

Einer der Abschiedsgedanken, die ich mit Ihnen teilen möchte, ist, den Mut zu haben, Ihre Verluste zu begrenzen. Im obigen Beispiel hätten wir die Verluste reduzieren und es selbst aufbauen sollen, da die Organisation offensichtlich noch nicht bereit war. Obwohl das Projekt scheiterte, gelang es uns, den Reifegrad der Organisation zu ermitteln.

Ich hoffe, dass dies hilfreich war, um einige meiner eigenen Gedanken zur Bewertung von Kompromissen darzulegen.