- Modernisierung von Legacy-Software: Da sich der gesamte Umfang vor Beginn der Arbeit nur schwer anhand der sichtbaren Informationen festlegen lässt, sollten anfängliche Schätzungen nicht als Deadline, sondern als anpassbare Grundlage behandelt werden
- Wie bei einer Autoreparatur ist anfangs eine Schätzung wie 18.000 US-Dollar·30 Tage möglich; werden nach Demontage und Prüfung jedoch verborgene Schäden sichtbar, sind eine ergänzende Schätzung und eine erneute Freigabe nötig
- Auch bei Modernisierungsprojekten zeigt sich verborgene Komplexität, etwa Integrationsfehler oder unerwartetes Verhalten; wer dann die ursprüngliche Schätzung erzwingen will, gerät in Konflikt mit der Realität
- Gesunde Führung fragt weniger „Warum haben wir das nicht gesehen?“, sondern nach Komplexität, Lösungen, Trade-offs und Workarounds – und entscheidet, ob weitergemacht oder gestoppt wird
- In komplexen Kontexten braucht es statt eines festen Regelwerks wiederholtes Ausprobieren, Experimentieren und Entdecken; Führungskräfte sollten weniger übermäßig kontrollieren, sondern eine Umgebung schaffen, in der Muster sichtbar werden
Schätzungen sind keine Deadlines, sondern Orientierungspunkte für den Fortschritt
- Wenn man Schätzungen bei komplexer Softwaremodernisierung wie verbindliche Deadlines behandelt, kollidieren sie mit der Realität, die sich während der tatsächlichen Arbeit zeigt
- Eine erste Schätzung entsteht auf Basis von außen sichtbaren Informationen und Erfahrung, doch nach Beginn der Arbeit können neue Komplexitäten sichtbar werden
- Eine „Schätzung“ ist eine Annäherung an den tatsächlichen Wert; bei komplexer Modernisierung ist es schwierig, alle Ergebnisse vor dem Start perfekt vorherzusagen
Die Autoreparatur als Analogie: unsichtbare Schäden und ergänzende Kostenvoranschläge
- Bei einer Autoreparatur reicht zunächst der Versicherungsgutachter eine Schadensschätzung bei der Werkstatt ein, und auch die Werkstatt übermittelt der Versicherung ihre eigene Schätzung
- Beispielsweise schätzt der Versicherungsgutachter den Schaden auf 15.000 US-Dollar
- Die Werkstatt schätzt den Schaden auf 18.000 US-Dollar und die Reparaturdauer auf 30 Tage
- Versicherungsgutachter und Werkstattexperten bewerten den Schaden gemeinsam; sobald die Versicherung die neue Schätzung genehmigt, beginnt die Reparatur
- Während der Reparatur können Schäden entdeckt werden, die zunächst nicht sichtbar waren
- Beim Zerlegen von Bauteilen können zusätzliche Schäden zum Vorschein kommen
- Mit einer Richtbank kann ein Schaden am unibody frame geprüft werden
- Es muss nicht nur der Aufprallpunkt geprüft werden, sondern auch, ob sich die Wirkung nach hinten in den Rahmen übertragen hat
- Wenn wegen zusätzlicher Schäden weitere 20.000 US-Dollar erforderlich sind, sendet die Werkstatt eine ergänzende Reparaturanfrage an die Versicherung, und die Versicherung entscheidet, ob weiter repariert oder das Fahrzeug als Totalschaden (total loss) behandelt wird
- Würde die Versicherung die zusätzlichen 20.000 US-Dollar allein mit der Begründung ablehnen, die ursprüngliche Schätzung habe bei 18.000 US-Dollar gelegen, entspräche das keinem realistischen Reparaturprozess
Auch bei der Legacy-Modernisierung wird verborgene Komplexität sichtbar
- Die Modernisierung von Legacy-Software gehört in den Bereich komplexer Software
- Auf Basis von Problemen, die von außen klar erscheinen, lässt sich eine erste Schätzung erstellen, doch während der tatsächlichen Arbeit wird oft deutlich mehr Komplexität sichtbar
- So wie bei einer Autoreparatur versteckte Schäden oder Rahmenschäden entdeckt werden können, können auch bei der Modernisierung Probleme auftreten, die in der ersten Schätzung nicht enthalten waren
- In solchen Situationen sollte man nicht an der ursprünglichen Schätzung festhalten, sondern über zusätzliche Freigaben und eine erneute Bewertung den nächsten Schritt bestimmen
Die Fragen, die gute Führungskräfte stellen
- In einer gesunden Softwareentwicklungsumgebung werden bei auftretenden Problemen Fragen gestellt, die eine Entscheidung ermöglichen, statt Schuld zuzuweisen
- Wie komplex ist dieses Problem?
- Welche Lösungswege gibt es?
- Welche Trade-offs haben die einzelnen Ansätze?
- Gibt es Workarounds oder alternative Lösungen?
- Wenn es dagegen in Richtung „Warum haben wir diese Komplexität nicht gesehen?“, „Warum dauert das so lange?“ oder „Warum wird die ursprüngliche Schätzung nicht eingehalten?“ geht, wird das Team an die ursprüngliche Schätzung gebunden
- Bei Modernisierungsprojekten gibt es sowohl Fälle, in denen weitergemacht wird, als auch Fälle, in denen sie gestoppt werden
- Werden Zusatzkosten genehmigt, geht es in die nächste Phase; durch Wiederholung dieses Prozesses nähert man sich dem Abschluss
- Wenn die Kosten den Wert übersteigen, kann das Projekt gestoppt werden
- Die Entscheidung zwischen Fortsetzen und Stoppen ist nicht einfach; Frameworks und Entscheidungsworkshops können genutzt werden, um die Richtung festzulegen
Der Unterschied zwischen komplizierten und komplexen Kontexten
- Im Cynefin Framework aus A Leader’s Framework for Decision Making können Autoreparatur oder Motorradwartung eher einem komplizierten Kontext (complicated context) zugeordnet werden
- Bei einer Autoreparatur hören sich Experten den Unfallhergang an und entscheiden durch Analyse und Tests mehrerer Faktoren – etwa unsichtbarer Schäden oder Rahmenschäden – über die beste Maßnahme
- In einem komplexen Kontext (complex context) lässt sich erst nach dem Ausprobieren beurteilen, was richtig oder falsch ist
- Eine Integration, von der erwartet wurde, dass sie funktioniert, kann scheitern
- Es kann nötig werden, neues, bisher unbekanntes Verhalten zu entdecken und zu berücksichtigen
- Für die Modernisierung komplexer Legacy-Systeme gibt es keinen festen Weg und kein Regelwerk, dem man einfach folgen könnte
- Modernisierung ist ein wiederholter Prozess aus Ausprobieren, Experimentieren, Entdecken, Lösen und Weitergehen zum nächsten Teil
Unerwartete Wendungen sind keine Ausnahme, sondern Realität
- Wenn Anwendungsmodernisierung zwischen complex und complicated liegt, braucht es ein passendes Dashboard, um Fortschritt und Erfolg zu beurteilen
- Einen einfachen Schätzprozess auf einen komplexen Kontext anzuwenden ist, als wolle man jede Schraube und jede Radmutter mit einem Hammer bearbeiten
- Unerwartete Wendungen in Modernisierungsprojekten sind Realität
- Nicht alle Ergebnisse lassen sich im Voraus vorhersagen
- Selbst mit noch so viel Vorabanalyse erreicht man kein perfektes Datenmodell
- In nahezu jedem Schritt entsteht neues Lernen
- Je nach entdeckter Komplexität muss sich das Datenmodell ändern
- Wenn sich Schätzungen ändern, sollte man nicht in Wut, Schuldzuweisungen oder Analysen verfallen, die den Zeitplan erzwingen sollen, sondern einen Weg nach vorn suchen
Wie Organisationskultur mit unerwarteten Wendungen umgeht
- Ron Westrums Modell der Organisationskultur unterscheidet, wie Organisationen mit Menschen umgehen, die unerwartete Wendungen melden, und wie sie mit Fehlern umgehen
- Power-Oriented Organisationen erschießen den Überbringer der schlechten Nachricht, und Fehler führen zur Suche nach Sündenböcken
- Rule-Oriented Organisationen ignorieren den Überbringer solcher Nachrichten und behandeln Fehler als Problem der Umsetzung von Definitionen
- Performance-Oriented Organisationen trainieren den Überbringer solcher Nachrichten, und Fehler führen zu Untersuchung und Lernen
- Wenn das zu lösende Problem weiterhin relevant ist und die Geschäftsanforderungen erfüllt, sollte man Schritt für Schritt vorgehen
- Das endgültige Ziel der zu modernisierenden Software sind die Nutzer
Komplexe Bereiche brauchen experimentelles Management
- Führungskräfte, die komplexe Bereiche nicht erkennen, können ungeduldig werden, wenn die angestrebten Ergebnisse nicht schnell eintreten
- In komplexen Bereichen ist die Fähigkeit wichtig, Fehler auszuhalten; Fehler sind ein notwendiger Bestandteil experimentellen Verstehens
- Wer eine Organisation übermäßig kontrolliert, verhindert Gelegenheiten, bei denen nützliche Muster sichtbar werden können
- Führungskräfte, die einem komplexen Kontext gewaltsam Ordnung aufzwingen wollen, scheitern
- Erfolgreich sein können Führungskräfte, die die Bühne bereiten, einen Schritt zurücktreten, Muster sichtbar werden lassen und beurteilen, welche Muster wünschenswert sind
1 Kommentare
Meinungen auf Hacker News
Ich habe Zeiten erlebt, in denen das Management Schätzungen wie Deadlines behandelte, die Spezifikationen ständig änderte und trotzdem überhaupt nicht hören wollte, warum sich etwas ändern könnte.
In solchen Fällen habe ich bei allem, was nicht trivial war, die Reaktion „Reh im Scheinwerferlicht“ gewählt. Wenn ich sagte: „Das könnte eine ziemlich große Sache sein. Jemand im Team sollte wohl etwa eine Stunde investieren, um sich anzusehen, was tatsächlich nötig ist“, fragte der Manager wie immer nach „wenigstens einer groben Zahl“. Dann nannte ich eine so große Zahl, dass man fast vom Stuhl aufsprang, und diese Zahl blieb im Gedächtnis. Danach machte ich eine Stunde Due Diligence und gab möglichst keine andere Zahl als diese grobe Schätzung, um am Ende „früher als geplant“ fertig zu werden und gut dazustehen.
Bei guten Managern war diese Strategie überhaupt nicht nötig, was wirklich angenehm war, aber bei Leuten, die nicht lernen wollten, wie man ihren Job kompetent macht, reagierte ich eben so. Meetings wurden dadurch auch deutlich unterhaltsamer.
Designteam, Frontendteam, Backendteam und QA-Team blähten jeweils so auf, der Projektmanager erhöhte die Summe dann noch einmal um 150–200 %, und Account Manager sowie Vertrieb legten vor der Kostenschätzung ebenfalls nochmals 150–200 % obendrauf.
Am Ende kostete die Wartung einer Website, die ein dediziertes Team aus 8–10 ordentlichen Web-/Full-Stack-Entwicklern gut hätte stemmen können, fast 1 Million Dollar pro Monat. Abgesehen vom 24-Stunden-Support hätten das vermutlich ein paar hervorragende Rails- oder Django-Entwickler geschafft, oder sogar eine Person plus ein Teilzeit-Grafikdesigner.
Ein paar Jahre später merkte der Kunde, was los war, und die Geschäftsführung des Unternehmens brachte die Sache komplett gegen die Wand; rund 100 Menschen verloren ihre Jobs und nicht ausgezahlte Ansprüche. An diesem Tag verlor ich selbst etwa 26.000 Dollar.
Wenn die Gesamtkapazität zum Beispiel 40 Punkte beträgt, verändert sie sich ein wenig, wenn Teammitglieder ausfallen oder dazukommen. Velocity ist der durchschnittliche Durchsatz in Punkten pro Personen-/Arbeitstag.
Volatility beschreibt, wie stark sich ein Sprint verändert. Ein 5-Punkte-Ticket herauszunehmen und dafür ein 3-Punkte- und ein 2-Punkte-Ticket hineinzunehmen, kann in Ordnung sein; wenn man das in einem zweiwöchigen Sprint aber zwölfmal macht, wird man den Sprint nicht abschließen, selbst wenn die Gesamtmenge bei 40 Punkten oder darunter liegt.
Wir machten täglich Snapshots des Sprints und betrachteten die Menge der hinzugefügten und entfernten Tickets. So konnten wir dem Management zeigen, dass wir bei geringer Volatilität fast immer fertig wurden, bei hoher Volatilität aber scheiterten – unabhängig davon, ob die Velocity überschritten wurde oder nicht. Der Grund ist, dass dann keine Zeit bleibt, sauber zu planen und Anforderungen zu klären. Es half bis zu einem gewissen Grad, das Produktteam dazu zu bringen, weiter als zwei Wochen vorauszuschauen.
Ingenieure, die bei einfachen Aufgaben stark überhöhte Schätzungen abgaben, waren mit höherer Wahrscheinlichkeit Low Performer. Das mag bei jemandem funktionieren, der langsame Lieferung nicht bewertet, oder bei einem Manager, der die Lage nicht kennt; ein Manager mit Kontext merkt es schnell.
Statt eines einzelnen festen Werts sollte man eine Fehlerspanne mit angeben, etwa „3 Monate, ±4 Wochen“. Die meisten Ingenieure wissen, dass ihre Schätzungen eine Fehlerspanne haben, aber irgendwie werden sie darauf konditioniert, zu vergessen, das auch zu sagen.
Auch aus Managementsicht zeigt die Größe der Fehlerspanne sofort, wie sicher die Schätzung ist, und ermöglicht Gespräche über Risiken. Dann sind Unterhaltungen möglich wie: „Aktuell haben wir 30 % Abweichung in beide Richtungen; was sind die größten Ursachen, und können wir ein paar Tage investieren, um eine oder zwei davon zu reduzieren?“
Ich verstehe nicht, wie man in einem Ingenieurberuf arbeiten kann, ohne vernünftig über Risiken, Wahrscheinlichkeiten und Konfidenzintervalle zu sprechen. Das ist auch nicht allein die Schuld des Managements.
Bei unerfahrenen Managern oder Leuten, die vorübergehend den Platz von jemand anderem ausfüllen, kann man verstehen, dass sie mit Unsicherheit nicht vertraut sind; in allen anderen Fällen gibt es keine Entschuldigung.
Dieser Artikel handelt von Modernisierungsprojekten, und solche Projekte haben lockere Deadlines, weil die bestehende Software weiterläuft, während der Ersatz entwickelt wird.
Es gibt Budgetdruck, Zusagen und Erwartungen der Nutzer an neue Funktionen, aber wenn der Ersatz einen Tag später kommt, bricht nicht gleich alles zusammen.
Anders ist es, wenn man eine Raumsonde startet und die Planetenpositionen nicht mehr für ein Gravity Assist passen – dann erreicht die Sonde ihr Ziel nicht. Wenn ein kleiner Werkzeugbauer mit 100 Millionen Dollar Jahresumsatz von Ford einen Vertrag bekommt, die Formen für die Produktionslinie des F150 von 2026 bis März zu liefern, und bei Verspätung 20.000 Dollar Strafe pro Minute zahlt, kann er im Februar nicht sagen: „Es gab eine Überraschung, das wird nichts.“ Man sollte nur unterschreiben, wenn man sicher liefern kann.
Ford oder NASA sind nicht überrascht, selbst wenn eine Angebotserstellung Zehntausende Dollar kostet. Wenn sie einen ECO erhalten und für ein Teil, das sich scheinbar in 30 Minuten von Hand herstellen ließe, drei Wochen und 8.000 Dollar angesetzt werden, wissen sie, dass darin Terminrisiken, Abnahmephasen, Prüfphasen, Notfallpläne und Ähnliches enthalten sind.
Wenn man aber in der Modernisierungsgruppe des OP sagt: „Weil die Informationen unvollständig sind, kann eine 30-Minuten-Aufgabe zum Ändern eines Button-Texts bis zu drei Wochen und 8.000 Dollar dauern“, wird man vor die Tür gesetzt. Optimistische Schätzungen werden belohnt, pessimistische Schätzungen unterdrückt, und genaue Schätzungen spielen keine Rolle mehr. Am Ende liegt man ständig hinter dem Zeitplan, und niemand ist besonders überrascht.
Dazu können Wartung für Hardwareänderungen, Betriebssystem-Upgrades oder neue Funktionen gehören. Ich habe Projekte gesehen, die auf diese Weise über mehr als zehn Jahre parallel liefen.
Im Jahr 1505 schätzte Michelangelo, dass es 5 Jahre dauern würde, das Grabmal von Papst Julius II. fertigzustellen.
Wegen kleiner Nebenjobs wie der Deckenmalerei der Sixtinischen Kapelle dauerte es tatsächlich etwa 40 Jahre.
Während die auf der Schätzung basierende Deadline verfehlt wurde, wurde der Projektumfang stark reduziert. Gründe waren, dass Papst Julius II. vor der Fertigstellung starb, Änderungswünsche des Kunden Julius und seiner Erben, Lieferkettenprobleme, Vertragsneuverhandlungen, Arbeitskonflikte, Mangel an Fachkräften und Finanzierungsengpässe aufgrund der langen Laufzeit.
Mindestens seit 1505 gibt es solche Dinge also. Das Lustige ist, dass der Papst nicht einmal in diesem Grabmal bestattet ist.
Früh in meiner Karriere habe ich etwas Wichtiges gelernt: Die zuerst genannte Zahl bleibt im Gedächtnis.
Leider ist das in der Praxis oft so, und Leute sagen immer wieder: „Hast du am Anfang nicht X gesagt?“ „Stimmt, aber wir haben neue Informationen bekommen“ funktioniert nicht immer.
Wer das weiß, vermeidet als Nebenwirkung manchmal, überhaupt Zahlen zu nennen.
Scotty: „Natürlich, Captain. Nur so kann ich meinen Ruf als Wundertäter bewahren.“
Zum Beispiel Tag→Woche, Woche→Monat, Monat→Quartal. Wenn etwas einen Tag dauern würde, sage ich 3 Wochen. Das wirkt viel, aber am Ende landet man wegen Bürokratie, Prozessen und technischer Schuld meistens ungefähr dort.
Es gibt die Passage: „Kann man sich vorstellen, dass ein Versicherer einer Werkstatt sagt, der ursprüngliche Kostenvoranschlag habe 18.000 Dollar betragen, also zahle er keine zusätzlichen 20.000 Dollar? Absurd, oder? Sehe ich auch so. Zum Glück funktioniert die Realität nicht so.“ In der Versicherungswelt passiert genau so etwas ständig.
Nicht nur bei Auto- und Wohngebäudeversicherungen, sondern auch bei der Krankenversicherung. Oft wird auf einen vernünftigen Punkt hin verhandelt, aber eben nicht immer; der selbstsichere Ton von „so funktioniert die Realität nicht“ überrascht.
Ein Totalschaden kann zwar teurer sein, aber es gibt eine klare Obergrenze und der Schadenfall lässt sich schließen. Versicherer mögen keine offenen Schadenfälle.
Letzteres, in der Kfz-Versicherung auch „Preferred Rate“ genannt, ist ein Rahmenvertrag, nach dem bestimmte Arten von Arbeiten zu einem festen ausgehandelten Satz abgerechnet werden.
Das ist etwas ganz anderes als ein verbindlicher Kostenvoranschlag. Ein verbindlicher Kostenvoranschlag ist normalerweise eine einmalige Schätzung für eine konkrete Arbeit, bei der der Schätzende das Risiko trägt und zusagt, sie zu diesem Satz fertigzustellen, selbst wenn sie viel komplexer wird als erwartet.
Ein Trick ist, wenn möglich immer nur für einen festen Scope zu schätzen und unbekannte Unbekannte auszuklammern.
Man sollte nicht „Feature X implementieren“ schätzen, sondern „Engine für Feature X“. Wenn zusätzliche Arbeit entdeckt wird, sollte man sie als entdeckte Meilensteine wie „bestehenden Code refaktorisieren“ oder „Feature X+Y integrieren“ ergänzen.
Allerdings funktionieren diese Benennung und dieses Verständnis nur, wenn sie nach oben weitergetragen werden. Wenn jemand den Meilenstein „Engine für Feature X“ bei gleicher Schätzung in „Feature X abgeschlossen“ umbenennt, ist man geliefert.
Ein verwandtes Problem habe ich ebenfalls gesehen: Führungskräfte halten Deadlines für „Motivation“. Das ist wie bei Leuten, die ein Haus auf 72F heizen wollen und den Thermostat auf 80F stellen, „damit es schneller geht“.
Einmal vergaßen die anderen Teilnehmer, dass ich als einfacher Engineer zu einem Leadership-Meeting eingeladen war. Als jemand einräumte, dass Deadline X sehr schwer zu halten sei, und fragte, ob man sie auf ein realistischeres Datum verschieben sollte, antwortete ein Senior PM: „Wir verschieben Deadlines nie! Engineering verbraucht einfach die gesamte Zeit, die man ihm gibt!“
In diesem Fall gab Engineering die Zeit zurück, indem ich das Team verließ.
Es stimmt auch, dass viele Engineering-Teams die gesamte Zeit verbrauchen, die ihnen gegeben wird.
Aber Manager sollten die Organisation auf Überschreitungen vorbereiten, statt Schätzungen und Pläne vor Engineers in starre Deadlines zu verwandeln. Wenn Entwickler erklären können, welche Teile warum länger gedauert haben, sobald der erwartete Fertigstellungstermin näher rückt, sollte das vernünftig nachvollzogen werden.
Manager sollten außerdem dafür sorgen, dass Kunden, Sales und höhere Manager den geplanten Fertigstellungstermin nicht als Deadline behandeln. Wenn Zusagen nötig sind, sollten kundenwirksame Deadlines deutlich nach dem erwarteten Fertigstellungstermin liegen.
Auch bei elektrischen Heizkörpern kann es in der Praxis funktionieren, weil sie sich nicht sofort abschalten, nur weil die Luft direkt am Heizkörper warm geworden ist.
Nachdem ich zu oft erlebt habe, dass „grob geratenen Schätzungen“ zu harten Deadlines wurden, werbe ich bei Stakeholdern für den No-Estimates-Ansatz.
Anfangs gibt es natürlich Widerstand. Um die Bedenken zu entschärfen, hilft es zu erklären, dass Schätzungen, die genau genug sind, um sie legitim für Planung zu verwenden, eigentlich nur in zwei Fällen möglich sind:
A) Wenn die verbleibende Arbeit nahezu eine Kopie früherer Arbeit ist. Zum Beispiel, wenn ein zweites Rechenzentrum für dasselbe System provisioniert wird.
B) Wenn das Team beurteilt, dass die verbleibende neue Feature-Arbeit im letzten Quartil angekommen ist und gut definiert ist, einschließlich der verbleibenden Risiken, die den Erfolg verhindern könnten.
Mikroschätzungen ermöglichen Mikromanagement. Gesunde Teams identifizieren die Aufgaben mit der höchsten Priorität anhand der Risiken für den Projekterfolg und arbeiten sie in dieser Reihenfolge ab.
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Mir fiel eine interessante Formel auf, die ich früher einmal auf HN gesehen hatte. Sie sieht ausgefeilt und cool aus, hat aber wie andere Schätzmethoden keine formale Gültigkeit und ist nur eine willkürliche Formel auf Basis persönlicher Erfahrung.
https://news.ycombinator.com/item?id=37965582
Meine Schätzmathematik: R = t × [1.1^ln(n+p) + 1.3^X]
R ist die tatsächlich benötigte Zeit, t die kürzestmögliche Zeit, wenn keine Kommunikation nötig ist, n die Zahl der am Prozess beteiligten Personen einschließlich Kunde und Entwicklungsorganisation, p die längste Kommunikationsdistanz im Projekt, X die Zahl neuer Tools, Bibliotheken und Techniken, die im Prozess verwendet werden.
Wenn zum Beispiel ein Projekt, bei dem ein einzelner Entwickler Code schreibt, 2 Wochen dauert (t=2), insgesamt 5 Personen beteiligt sind (n=5), 1 neues Tool verwendet wird (X=1) und die längste Kommunikationsdistanz 4 beträgt, ergibt 2×(1.1^ln(5+4) + 1.3^1) = 4,5 Wochen.
Man sollte die X-Anzahl nicht nur für bekannte Unbekannte, sondern auch für unbekannte Unbekannte erhöhen.
Leider sind Schätzungen Verhandlungssache. Wer zuerst eine Zahl nennt, verliert meistens wegen des „Stirnrunzelns“.
„Wie lautet die Schätzung?“ „Ich weiß es nicht genau.“ „Auch nur grob.“
„Bis wann hätten Sie es denn gern?“
Das ist die Falle, in die neue Manager jedes Mal tappen. Gibt man eine Antwort, heißt es bingo. Dann zeigen sie das „Stirnrunzeln“. Sie atmen scharf ein, verziehen das Gesicht und sagen: „Oh, das ist völlig unrealistisch. Woher kommt diese Zahl überhaupt?“ Danach nennen sie eine um ein Mehrfaches höhere Zahl oder schlagen vor, den Umfang zu reduzieren. Etwa: „Puh, in der Zeit könnten wir mit viel Glück und wenn wir Feature Y aus einem anderen Projekt streichen, nur Feature X schaffen.“
Wichtig ist, auf keinen Fall zuerst eine Zahl zu nennen. Wie beim Poker oder Autokauf dauert es etwas, ein Gefühl dafür zu entwickeln. Zeit ist auch in Großunternehmen Geld und sollte entsprechend behandelt werden. Ein Nullsummenspiel.
Dort, wo ich arbeite, werden Schätzungen im Namen der Effizienz immer weiter gedrückt, und übertragene Arbeit ist ebenfalls nicht erlaubt.
Ich war über ein Jahr lang fast durchgehend im Crunch, ohne Erholungszeit. Ich habe immer weiter gehofft, dass es besser wird, aber es scheint eher schlimmer zu werden. Außerdem werden alle ständig in andere Produktbereiche rotiert, ohne Wahlmöglichkeit. Ich laufe zwar noch weiter, fühle mich mental aber völlig ausgebrannt.