Wie Unbehagen uns hilft, den Entwicklungsprozess zu verbessern.

Ich bin ein Teamleiter und meine Aufgabe ist es, die produktive Arbeit des Teams sicherzustellen. Dies ist nicht einfach, da es kein fertiges Erfolgsrezept gibt. Natürlich gibt es anerkannte Methoden: Agile , Lean , Value Stream Mapping . Sie geben gemeinsame Richtlinien und Werte, was bereits gut ist, aber dies sind nur Richtlinien. Und mit spezifischen Lösungen, seien Sie freundlich, drehen Sie sich. Deshalb Sie und Teamleiter.

In dem Artikel werde ich erzählen, wie sich das Team und ich schrittweise gebildet haben und nun regelmäßig den Ansatz für effektive Arbeit verfeinern. Der entscheidende Punkt ist, dass die ausgewählten Tools vom gesamten Team wirklich akzeptiert werden und Wurzeln in der Arbeit haben. Dies gibt Hoffnung, dass der Ansatz nützlich ist.

Ein bisschen Kontext

Bei True Engineering beschäftigen wir uns mit Unternehmensentwicklung. Wir stellen ein riesiges, mehrjähriges Produkt her, an dem viele Teams teilnehmen. Insbesondere besteht unser Team aus sieben Personen: vier Entwicklern, einem Team-Tech-Leiter (schreibt Code und viel), einer Qualitätssicherung und einer PM. Das Produkt, an dem das Team arbeitet, ist zwei Jahre alt. Der technische Zustand - durch die Bemühungen des gesamten Teams - ist nahezu vorbildlich.

Beschwerden als Diagnosewerkzeug

Um Probleme im Team zu finden und zu erkennen, verwenden wir ein ziemlich einfaches Werkzeug - das Unbehagen der Teilnehmer.

Hier geht es natürlich nicht um eine Situation, in der eine Person klimatisiert und eine andere heiß ist. Ich spreche von Fehlern im normalen Arbeitsfluss.

Zum Beispiel war die Veröffentlichung schief, obwohl jeder seine Arbeit gut gemacht hat. Oder die Stabilisierung dauert seit zwei Wochen an und das Team reißt, obwohl wir selbst Schätzungen vorgenommen haben und niemand uns gestört hat, es gut zu machen. Oder das Geschäft hat nicht das bekommen, was es erwartet hatte.

Wie man in einer ähnlichen Situation handelt:

1. Stoppen Sie die Panik und erkennen Sie, warum wir uns gerade unwohl fühlen.
2. Gehen Sie der Grundursache auf den Grund. Zum Beispiel mit der Five Why- Technik oder einfach nur mit gesundem Menschenverstand.
3. Entscheiden Sie, wie das Problem behandelt werden soll. Richtlinien für die Auswahl der richtigen Lösung werden am Ende des Artikels erläutert. Hier stelle ich einen grundlegend wichtigen Punkt fest: Wir verwenden Unbehagen, um Probleme zu diagnostizieren, aber dies bedeutet nicht, dass die Richtlinie für die Auswahl von Lösungen darin besteht, Komfort zu erreichen. Denken Sie daran, dass der Hauptgrund, warum Sie als Team existieren, der geschäftliche Wert ist. Niemand braucht ein glückliches Team, das keine Ergebnisse bringt.
4. Führen Sie nach einer Weile eine Retrospektive durch. Wenn die Entscheidung nicht geholfen hat, kehren wir mit einem neuen Verständnis zu Absatz 1 zurück. Wenn es hilft, automatisieren wir die Liste der Prinzipien für zukünftige Anfänger oder ergänzen sie. Es ist keine Kontrolle mehr erforderlich, die Teilnehmer selbst werden den Arbeitsansatz wählen, wenn er wirklich gut ist.

Der beschriebene Algorithmus ist einfach, aber die Einzelheiten reichen nicht aus. Als nächstes werde ich die Prinzipien beschreiben, die wir mit diesem Ansatz abgeleitet haben. Damit der Artikel nicht zu einer Erinnerung wird, beschreibe ich nur das erzielte Ergebnis und nicht die ganze Geschichte vom Schmerzbewusstsein bis zu seiner Beseitigung.

Die Prinzipien, auf denen wir den Prozess aufbauen

1. Wir erstellen und verkürzen ständig Rückkopplungsschleifen

Jede menschliche Interaktion mit der Außenwelt basiert auf Rückmeldungen, ohne die es unmöglich ist, die Richtigkeit der durchgeführten Aktion zu überprüfen. Stellen Sie sich vor, wie unser Leben aussehen würde, wenn wir keinen Schmerz spüren würden, der aus einer Höhe von vier Metern springt oder eine glühende Teekanne greift.

In der Entwicklung kann die Code-Vervollständigung als Beispiel für eine gute, kurze Rückkopplungsschleife dienen - sie gibt Auskunft über die Richtigkeit der Aktion zum Zeitpunkt der Code-Eingabe.

Ein Beispiel für das Fehlen einer Rückkopplungsschleife: Wir kennen das Problem mit den Benutzern, können es jedoch nicht reproduzieren. Wir haben keine Protokolle. Es gibt keine Möglichkeit, das Update schnell einzuführen, und wir wissen nicht einmal, welche Version derzeit auf dem Produkt ist. Du wirst den Feind nicht wünschen.

Jede Aktion im Entwicklungsprozess kann und sollte Feedback geben: Erstellen, Flusen, bestandene Selbsttests, durchgeführte Tests, Testsitzung mit dem Unternehmen, erfolgreiche Bereitstellung, Überwachung des Produkts - all dies sind Möglichkeiten, Fehler zu erkennen und ihre weiteren Aktionen anzupassen.

Es ist auch erwähnenswert, dass die Kosten für Fehler steigen, wenn Sie vorwärts gehen. Wenn wir einen Produktionsfehler in der Produktion veröffentlicht haben, der die Daten verdirbt, besteht die Aufgabe nicht nur darin, ihn zu beheben, sondern die Daten wiederherzustellen (wenn überhaupt möglich). Die Kosten für die verspätete Beseitigung eines solchen Fehlers sind sehr hoch, ganz zu schweigen von den Konsequenzen für das Unternehmen.

Daher ist das Vorhandensein einer großen Anzahl schneller und informativer Rückkopplungsschleifen von entscheidender Bedeutung.

Nachfolgend finden Sie die Schleifen, die wir bewusst unterstützen und wenn möglich verkürzen. Ich denke, die meisten von euch wissen es. Aber hast du sie wirklich und arbeitest?

• Die Möglichkeit, ein Projekt lokal auszuführen.
• Entwickelt, um schnell zu versagen .
• Schneller, informativer CI-Build.
• Ständige Codeüberprüfung und Arbeiten mit Code über Pull-Anforderungen.
• Verfügbarkeit von Autotests. Tests sind schnelle, stabile und informative Fehlermeldungen.
• Automatische Bereitstellung, da die manuelle Bereitstellung seltener durchgeführt wird.
• Häufige Releases, anstatt eine Woche nach Abschluss der Aufgaben eine Version zu akkumulieren und freizugeben.
• Informative Protokolle, Überwachung, Diagnosetools. Zugriff auf sie vom gesamten Team.
• Die Fähigkeit zum Filtern und grafischen Visualisieren von Protokollen.
• Kontinuierliche Überwachung der technischen und funktionalen Indikatoren des Systems im Rahmen der täglichen Arbeit.
• Empirische Untersuchung des Systems - Google Analytics, Analyse der im System gesammelten Daten.
• Speichern des Datenänderungsverlaufs anstelle des Endzustands, falls zutreffend.
• Enge, gemeinsame Arbeit von Dev, Ops, QA, Business, anstatt die Ergebnisse der vorherigen Phase „über den Zaun zu werfen“.
• Durchführung regelmäßiger Rückblicke sowohl im Team als auch im Unternehmen.
• Regelmäßiges Feedback aus dem Geschäft. Noch besser ist das Feedback des Endbenutzers.
• Die Fähigkeit, die Arbeit der Benutzer "auf den Feldern" zu beobachten.
• Die Fähigkeit, den Benutzer zu beobachten, der Ihr System zum ersten Mal sieht.

Im Allgemeinen muss das Feedback selbst ein Blickfang sein. Wie zum Beispiel ein kaputter Build.

Bemerkenswert ist, dass manchmal eine sehr kleine Änderung für eine radikale Verbesserung ausreicht.

Beispielsweise schreiben Sie Protokolle in ELK . Sie sind strukturiert, analysiert, öffentlich zugänglich - alles ist in Ordnung. Aber wie oft kommt der Entwickler beim Debuggen vorbei? Höchstwahrscheinlich nicht.

Wenn Meldungen mit Warnstufe und höher direkt in der IDE angezeigt werden, besteht die Möglichkeit, dass beispielsweise die Ausführungszeit der Abfrage abfällt. Auch wenn es nicht mit der aktuellen Aufgabe zusammenhängt. Es besteht die Möglichkeit, das Problem früher zu bemerken, und die Kosten für die Behebung sind geringer.

2. Jede Aktivität hinterlässt öffentliche Artefakte

Artefakte sollten genau öffentlich sein. Und nützlich.

Dank dieses Prinzips minimieren wir den Busfaktor, sorgen für ein einheitliches Verständnis der Situation, arbeiten (und fakapim) bewusst und ziehen ständig Schlussfolgerungen.

Einige Praktiken sind offensichtlich und allgemein anerkannt: informative Meldungen von Commits, Verknüpfung von Commits mit Aufgaben, Beschreibung des Testverfahrens, Definition von Done.

Es gibt weniger offensichtliche Punkte:

• Sie können es nicht "nur vermasseln", der Fehler muss erkannt werden. Wenn die Analyse schlecht durchdachte Anforderungen aufdeckt, wird die bewusste Verfeinerung zu einem Artefakt für alle. Wenn das Problem in der Architektur des Systems liegt, ist das Artefakt die beschriebene technische Aufgabe mit einem klaren Begriff für die Aufnahme in die Arbeit.
• Die Menge an Wissen in der Post, Instant Messenger, Köpfe sollte minimal sein. Alle Verfeinerungen spiegeln sich in der Wissensdatenbank oder im Task-Tracker wider. Wenn der Tester die Aufgabe annimmt, sind die sich ändernden Anforderungen für ihn keine Neuigkeit. Wenn ein Unternehmen ein Ergebnis akzeptiert, versteht jeder, was er bekommen sollte. Dieser Zustand verwandelt die Arbeit in einen kontinuierlichen Strom. Stellen Sie es bereit (Details herausfinden, Wissensdatenbank aktualisieren und Aufgabenbeschreibung) - die Aufgabe jedes Teilnehmers am Prozess.
• Die Testergebnisse sind nicht nur "Ich habe geprüft, alles ist in Ordnung", sondern eine öffentlich zugängliche Liste bestandener Testfälle, die vor und nicht während oder nach dem Test zusammengestellt und diskutiert wurde. Die Liste kann von jedem Teilnehmer des Prozesses studiert und ergänzt werden.

3. Wir respektieren das Recht des anderen auf konzentrierte Arbeit

Die Bedeutung der Arbeit im Strom und die Folgen einer Unterbrechung sind meines Erachtens bereits bekannt. Daher werde ich nicht im Detail auf das Problem eingehen, sondern mich sofort unseren Praktiken zuwenden.

• Kopfhörer werden nur empfohlen.
• Die Arbeitskommunikation ist asynchron. Lenken Sie Ihren Kollegen nicht mit einer kleinen Frage ab, sondern stellen Sie ihn im Task-Tracker (siehe Abschnitt über öffentlich verfügbare Artefakte).
• Manchmal passieren Dinge, die den normalen Betriebsmodus unterbrechen: ein Unfall am Stoß, unverständliche Anforderungen an eine bereits in Arbeit genommene Aufgabe. Ein Signal kann eine laute Diskussion im Büro sein, an der drei oder mehr Personen teilnehmen. Wenn diese Situation nicht in wenigen Minuten behoben ist, werde ich eine Person ernennen, um die Details zu klären. Der Rest kehrt zum normalen Betrieb zurück, bis die verantwortliche Person Informationen für die weitere Analyse bereitstellt.

4. Wir vermeiden Multitasking

Weil Multitasking nicht funktioniert . Sie erschöpft nur, sprüht Aufmerksamkeit und verschiebt den Erhalt des Ergebnisses.

Welche Praktiken helfen:

• Work In Progress Limit.
• Konzentration auf den Wertefluss, nicht auf Ressourcen. Zum Beispiel kann der erste Entwickler die Aufgabe an einem Tag erledigen, der zweite in drei. Aber der erste wird erst nach einer Woche veröffentlicht. Der zweite übernimmt also die Aufgabe zu arbeiten. Wir werden mehr Zeit für die Implementierung aufwenden, aber das Ergebnis schneller liefern (drei Tage statt einer Woche und einen Tag) und mit der nächsten Aufgabe fortfahren. Gleichzeitig versuchen wir nicht, das Nicht-Pushable an den ersten Entwickler zu „schieben“ und lassen uns nicht von Arbeiten ablenken, die in ihrer Erwartung „hängen“.
• Wenn mehrere Personen an einer Aufgabe beteiligt sind und die Arbeit zu 90% abgeschlossen ist, besteht das Hauptziel des Teams darin, alles zu tun, um die letzten 10% zu erledigen. Erst danach gehen wir weiter.

5. Wir treffen architektonische Entscheidungen so spät wie möglich

Dies ist nicht unser Know-how, sondern eines der Grundprinzipien von Lean Manufacturing .

Die getroffene und umgesetzte Entscheidung schränkt die Möglichkeit weiterer Änderungen ein. Und wenn die Entscheidung unter Bedingungen unvollständiger Informationen getroffen wird (und dies ist fast immer der Fall), sind die Chancen, eine falsche Entscheidung zu treffen, erheblich höher.

Wenn das Versäumnis, eine Entscheidung zu treffen, die Arbeit nicht blockiert und nicht zu einem exponentiellen Wachstum der technischen Verschuldung führt, sollte dies verschoben werden, sodass das System für zukünftige Entscheidungen bereit bleibt, wenn wir weitere Informationen haben.

Dies ist die Basis der Entwicklung - wir bauen keine „großen“ Architekturen vor Projektbeginn. Stattdessen machen wir den Refactoring-Prozess sicher (siehe Abschnitt über Rückkopplungsschleifen) und machen ihn zu einem natürlichen Teil des Prozesses.

Ebenso versuchen wir nicht, die zukünftigen Anforderungen an das System zu erraten oder eine universelle Lösung zu entwickeln. Die Fähigkeit zur sicheren Umgestaltung ist universeller, da Änderungen in der Zukunft möglich sind.

6. Der Code ist jederzeit betriebsbereit.

Natürlich ist dieser Zustand absolut nicht erreichbar, das System fällt nach Änderungen regelmäßig aus. Dies bedeutet jedoch nicht, dass dieses Merkmal nicht gesucht werden sollte.

Wenn ein Zusammenbruch eine abnormale Situation und keine Lebensnorm ist, sind seine Ursachen leicht zu finden. Dies ist normalerweise das letzte Commit. Daher ist die verantwortliche Person verständlich, die zu eliminierenden Schritte sind verständlich, es ist klar, wenn wir in einen stabilen Zustand zurückkehren.

Das daraus resultierende Vertrauen in den Betrieb des Systems bietet eine wertvolle Gelegenheit, es jederzeit freizugeben.

Der zweite Wert ist, dass wir zuversichtlicher sind, Verfügbarkeitsversprechen zu machen. Wenn wir die Arbeit in zwei Phasen unterteilen: "Entwicklung" und "Stabilisierung", ist es schwierig, ein konkretes Versprechen zu geben, da "Stabilisierung" Arbeit mit Problemen ist, die wir noch nicht kennen. Daher können wir sie nicht genau bewerten.

Wenn die Stabilisierung untrennbar mit der Entwicklung einhergeht und dafür alle notwendigen Instrumente vorhanden sind, ist die Situation vorhersehbarer.

Wie wir die kontinuierliche Leistung aufrechterhalten:

• Offensichtlich: Codeüberprüfung, Autotests, Feature-Flags.
• Alle Änderungen werden sofort in der Testumgebung bereitgestellt. Wenn es defekt ist, können Sie es später nicht reparieren - die Qualitätssicherung ist blockiert.
• Testen in einem kontinuierlichen Ablauf unmittelbar nach Abschluss der Aufgaben, während sich der Entwickler die Aufgabe und den Code merkt und schnell Korrekturen vornimmt.
• Wir machen die Arbeit nicht in Teilen. Wenn zwei Personen für die Implementierung benötigt werden, arbeiten sie paarweise in einem Zweig. Laden Sie den Code in den Hauptzweig hoch, wenn er vollständig fertig ist und in Tests behandelt wird.
• Lieferautomatisierung und feste Lieferartefakte, die nicht manuell „beendet“ werden müssen.
• Jedes Teammitglied kennt Diagnosetools, weiß, wie man mit ihnen arbeitet und wie man Releases erstellt.

7. Wir sind ein Team, keine Entwicklungsgruppe.

Was bedeutet "Team":

• Der gesamte Code wird von mindestens einer Person überprüft. Wenn ein ernstes Problem entdeckt wird, werden sie aufgefordert, zusammenzusitzen und Paarprogramme durchzuführen. Es ist von unschätzbarem Wert, ein Buch, einen Artikel oder eine ausführliche Erklärung zu teilen, anstatt persönliche Meinungen zu verbreiten.
• Anstatt uns in Stücken mit anschließender schmerzhafter Integration des Ergebnisses zu entwickeln, arbeiten wir bei Bedarf paarweise eng zusammen.
• Wir machen den Prüfer nicht zu einem Werkzeug zum Überprüfen von Tippfehlern, sondern bringen saubere, kleine Pull-Anfragen in die Prüfung ein.
• Wir werfen keine Aufgaben „durch den Zaun“, sondern übergeben die Arbeit der Qualitätssicherung sorgfältig und überprüfen den glücklichen Weg selbst. Wir helfen der Qualitätssicherung zu verstehen, was und wie zu testen ist, und helfen bei der Übergabe von Grenzszenarien (z. B. künstliches Brechen des Systems).
• Die Qualitätssicherung wiederum untersucht die interne Struktur des Systems, weiß, wie alle erforderlichen Details (Protokolle, Datenstatus) erfasst werden, und erhält einen äußerst informativen Fehler.

8. Wir hacken Schwänze

Um die Effizienz und Konzentration der aktuellen Arbeit zu maximieren, beseitigen wir die "Schulden", die mit der bereits geleisteten Arbeit verbunden sind:

• Aufgaben werden so schnell wie möglich zum Verkauf gebracht. Erst danach betrachten wir sie als erledigt.
• Wir beseitigen ständig technische Schulden, damit die hohen Reparaturkosten (eine Woche) nicht steigen und die Arbeit nicht blockiert wird, was die Pläne für die Bereitstellung von Geschäftsfunktionen ruiniert.
• Wir starten keine Aufgaben, die wir „eines Tages“ erledigen werden, aber wir löschen langlebige Aufgaben. Ein Unternehmen wird sicherlich für eine Aufgabe kommen, wenn (wenn) die Zeit dafür wirklich kommt. Und nur für den Fall, dass Sie im Task-Tracker die gelöschte Aufgabe wiederherstellen können. Diese Funktion war für uns jedoch nie nützlich.
• Langlebige Zweige, auskommentierter Code, To-do-shki - all dies ist ein toter Code, dessen Platz im Korb liegt.
• Instabile Tests werden sofort behoben oder gelöscht und durch niedrigere ersetzt.
• Wir verfolgen "schleichende" Aufgaben.

Der letzte Punkt ist eine gesonderte Erklärung wert.

Ich meine "schleichende" Aufgaben mit anfänglich geringen Arbeitskosten, die aber mehrere Tage oder Wochen in Bearbeitung bleiben.

Warum kann das sein:

1. Die Aufgabe war anfangs schlecht konzipiert, es waren bereits viele Verfeinerungen erforderlich, Klarstellungen sind widersprüchlich oder unvollständig. Also verschwenden wir keine Zeit mehr, hören auf, an der Aufgabe zu arbeiten, und kehren zur Aussage zurück.
2. Die Aufgabe wartet auf ein Ergebnis von jemandem. Zum Beispiel ein Service von einem anderen Team oder eine Verfeinerung von einem Unternehmen. Wir halten solche Aufgaben auf einem Bleistift und lassen sie nicht alleine gehen.

Es ist schwierig, diesen Punkt einzuhalten. Zunächst muss „Kriechen“ realisiert werden. Dann müssen Sie eine willensstarke Entscheidung treffen und einen Schritt zurück ins Detail gehen. Dies ist für den Entwickler schwierig, da bereits Zeit aufgewendet wurde. Und natürlich wird eine solche Entscheidung auf den Widerstand des Unternehmens stoßen. Die Praxis zeigt jedoch, dass dies die Chancen verringert, ein Ergebnis zu erzielen, mit dem weder das Team noch das Unternehmen oder die Benutzer zufrieden sind.

Das Zykluszeitdiagramm hilft bei der Suche nach solchen Aufgaben. Es zeigt die Zeit vom Moment der Arbeit bis zur Fertigstellung. Wenn die Aufgabe "nicht in der Menge" ist, ist dies ein Kandidat für eine genaue Prüfung.

So wählen Sie nützliche Lösungen

Leider habe ich kein sofort einsatzbereites Rezept. Teameffektivität ist eine heuristische Aufgabe, dh es gibt keine garantierten Lösungen.

Aber es gibt noch eine Checkliste. Da ist er:

• Ich habe am Anfang des Artikels darüber geschrieben und wiederhole hier: Die Tatsache, dass wir Unbehagen zur Diagnose von Problemen verwenden, bedeutet nicht, dass wir bei Entscheidungen nach Komfort streben. Denken Sie an das Hauptziel - Wertsteigerung für das Unternehmen.
• Denken Sie bei der Analyse von Problemen daran, dass alle Teilnehmer gute Absichten haben . Wenn Ihr Denken auf einer paranoiden Überzeugung beruht, dass Ihnen jemand absichtlich Schaden zufügt, ist es sehr schwierig, eine gute Entscheidung zu treffen.
• Versuchen Sie nicht, alles zu zerbrechen und wieder aufzubauen. Bewegen Sie sich in kleinen Schritten und nehmen Sie die Änderungen schrittweise vor. Warten Sie, bis die vorgenommenen Änderungen Ergebnisse bringen, und führen Sie erst dann neue ein.
• Wenn es keine klare Lösung gibt, gehen Sie in kleinen Schritten vor, bewerten Sie das Ergebnis ständig und probieren Sie verschiedene Optionen aus. Eine klare Rückkopplungsschleife und ständige Reflexion sind ein unerschöpfliches Entwicklungswerkzeug für Sie und das Team.
• Schmiede das Eisen, solange es heiß ist. Verschieben Sie die Analyse nicht nachträglich - das Team wird bereits vergessen, was passiert ist. Es ist besser, zu einer Retrospektive mit einem bereits erkannten Problem und vorgefertigten Lösungen zu kommen, die noch mit dem Team abgewogen werden müssen, um die besten auszuwählen.
• Die Entscheidung muss vom gesamten Team getroffen werden. Kein Pflanzen von oben wird funktionieren, und Kontrollversuche sind nur eine Illusion.
• Machen Sie den Menschen keine Aufgaben, die für ihre täglichen Aktivitäten untypisch sind. Sie werden auf tausend plausible Erklärungen stoßen, warum das Versprechen nicht gegeben wurde, aber Sie werden das Ergebnis nicht erhalten.
• Die Wirkung der Entscheidung muss greifbar sein. Es wird Ihnen selten gelingen, eine Entscheidung über die Eigenschaften von SMART zu treffen, aber es muss eine bewusste Methode zur Bewertung des Ergebnisses geben. Zumindest auf der Grundlage von "jetzt passiert das seltener".
• Versuchen Sie regelmäßig aufzuzeichnen, was jetzt am meisten weh tut. Wenn Sie nach einem halben Jahr die Aufnahmen mit einem Lächeln erneut lesen und denken, es gäbe eine Dose, dann sind Sie auf dem richtigen Weg.

Fazit

Lassen Sie uns abschließend die Schwächen des Ansatzes diskutieren.

Zunächst wird mit diesem Ansatz nach lokalen Optimierungen gesucht, mit denen keine Entwicklungsstrategie für das Produkt und das gesamte Unternehmen erstellt werden kann. Natürlich ist das Bewusstsein für Probleme besser als unbewusstes Scheißen und Brennen bei der Arbeit, aber dies ist nur der erste Schritt.

Ich bitte Sie auch, keine vorgefertigte Liste von Prinzipien zu erstellen, sondern das Werkzeug zu verwenden, mit dem es erstellt wurde. Deshalb:

Unsere Liste ist nicht vollständig. Es enthält nur das, was wir bereits in unserer täglichen Arbeit umgesetzt haben.
Das Team nimmt keine Grundprinzipien an, deren Wichtigkeit sie selbst nicht erkannt hat, durch den Schmerz ihrer Abwesenheit. Anstatt Ideen zu arbeiten, bekommen Sie einen Trottel, den jeder für einige Zeit im Büro herumträgt und dann Staub in eine Ecke legt.

Unsere Liste ist spezifisch. Wenn beispielsweise die technische Verschuldung des Projekts seit fünf Jahren ignoriert wird und mit der öffentlichen Verschuldung der USA vergleichbar ist, ist es sehr schwierig, das Prinzip der ständigen Ausrottung der technischen Verschuldung in Anspruch zu nehmen. Es ist fair zuzugeben: Eine Schuld dieser Größe wird niemals zurückgezahlt. Und konzentrieren Sie sich auf Lösungen, die wirklich dazu beitragen, die Situation zu verbessern.
Wie verbessern Sie den Prozess? Und welche Grundsätze haben Sie bereits in Ihre Arbeit übernommen?