von Doug Needham, DataOps.live von Doug Needham, DataOps.live Technische Schulden sind eine Herausforderung für jedes digitale Team. Vorschläge, um es zu vermeiden, werden übertrieben oder ignoriert, und es ist ein seltener Trick, die Dinge zu beheben, die wir wissen, dass sie repariert werden müssen. Wir haben verstanden, was wir wissen – wie erschreckend technische Schulden wirklich sind – vielleicht würden sie weniger zurückstoßen, wenn wir kämpfen, um die Dinge auf die richtige Weise zu bauen. Datenbesitzer Datenbesitzer Ich glaube, ich habe einen Weg gefunden, sie zu erzählen. Märchen, Gleichnisse und Geschichten, die unsere Großeltern erzählen, sind möglicherweise nicht faktisch, aber sie sind "wahr". Das gefährliche Rennen Sie wollten Ihr Auto in Eile bauen, und hier ist es – oh, aber zwölf Schrauben blieben übrig, nachdem wir es zusammengestellt hatten. Die Projektmanager haben darauf bestanden, dass diese bestimmten Schrauben auf das nächste Wartungsfenster warten können. Das Verkaufsteam versichert Ihnen, dass diese Schrauben nicht notwendig sind. Das Ingenieurteam weiß, was diese Schrauben zusammenhalten werden.Sie empfehlen, sich die Zeit zu nehmen, um die Schrauben anzuwenden. Das Rennen beginnt bald. Die Uhr tickte. Du bist der Fahrer. Sie werden Entscheidungen über Leben oder Tod mit hoher Geschwindigkeit auf einer Rennstrecke treffen, die entwickelt wurde, um die Fähigkeiten Ihres Autos zu demonstrieren. Auf der Startlinie befinden sich 39 weitere Fahrzeuge, die jeweils ihre eigenen Engineering-, Vertriebs- und Projektmanagementteams haben. Haben sie alle Teile ihres Autos zusammen gehalten? Welche Teile Ihres Autos halten Sie nicht so gut wie möglich zusammen? Wenn du dieses Auto benutzt und es bis zur Grenze drückst, wirst du das Rennen gewinnen, oder wirst du in der 3. Runde ein Puddle bekommen? Moral der Geschichte Dies ist eine technische Verschuldung: eine hochrisikoreiche Situation, die leicht vermieden werden könnte, wenn man auf die Experten hört. Wenn Sie eine schnellere Analogie benötigen, ist es wie russisches Roulette, nur Sie wissen nicht die Anzahl der Kammern, den Kaliber der Kugel, wie viele Kugeln geladen sind oder in welche Richtung die Waffe gerichtet ist. Nicht-technische Stakeholder verwechseln manchmal Refactoring für technische Schulden.Es ist sicherlich wahr, dass es Zeiten gibt, in denen Architekten und Ingenieure bessere Wege lernen, etwas zu bauen, nachdem es gebaut wurde. In beiden Fällen sollten diejenigen, die die Implementierungen tatsächlich durchführen, in der Lage sein, zu entscheiden, was getan werden muss. Wenn Ihr PM oder Dateninhaber Sie bitten, die Ecken zu schneiden, erinnern Sie sie an diese Geschichte. Wenn ja, dann lassen Sie sie." Pflicht zu warnen Sie wissen nicht, wie wichtig der richtige Treiber ist, strukturierte SQL, das Aktualisieren der Subroutinen, das Hinzufügen eines Knoten zum Cluster oder das Aktualisieren auf das aktuelle Patch-Niveau und das Erhalten eines sauberen Neustarts. Sie bauten ihnen ein wunderbares Auto, aber sie diktierten ein paar Kurven, von denen Sie wussten, dass sie später repariert werden mussten, nur später kam es nie. Da wir die Risiken der technischen Schulden kennen, haben wir die Verantwortung, den Alarm zu erheben. Erzähle ihnen die Geschichte des Rennens. Erinnere sie daran, dass sie in diesem Auto sitzen. Ich hoffe, dass diese Geschichte ein Pfeil in Ihrem Quiver wird, wenn ein Business-Benutzer oder Projektmanager versucht, Sie zu überwältigen Architekten und Ingenieure, die wissen, dass etwas getan werden muss, und es muss richtig gemacht werden. Die Wahl der Werkzeuge, die wir verwenden, um das technische Schuldenrisiko zu mildern, ist eine Entscheidung, die immer noch in unseren Händen liegt. eine kodifizierte Architektur, die sicherstellen soll, dass Sie können auf den Schultern dieses Teams stehen und sich nachts leicht ausruhen oder die Drehung 3 mit voller Geschwindigkeit nehmen! DataOps.live Datenmanagement wird geregelt von DataOps.live Datenmanagement wird geregelt
