- Ein großes Kundenprojekt bei einem Fortune-500-Unternehmen begann mit der Abhängigkeit von einem Vendor-Produkt, entpuppte sich tatsächlich aber als Software, die eher ein halbfertiges Produkt war und umfangreiche Anpassungen benötigte
- Die Vendor-Integration vereinte die Nachteile eines unflexiblen Pakets und individueller Entwicklung und führte nach der Übergabe im August zu einem Integrations-Deathmarch, um den Launch im Oktober zu schaffen
- Ein Design, das alle Kundentransaktionen in einem einzigen riesigen JSON-Dokument speicherte, verursachte Performance-Probleme; das damalige 16-MB-Limit pro Dokument in MongoDB erwies sich bei der realen Datenmigration als fatale Grenze
- Das Unternehmen verbarg das Problem vor Kunde und Vendor, ging einen Monat verspätet live und setzte innerhalb von etwa zwei Monaten ein Skunkworks-Rewrite mit einem dreiköpfigen internen Team um, um die Vendor-Integration zu ersetzen
- Als der CTO kurz vor Weihnachten Feiertagsarbeit anordnete, berichtete der Teamleiter bereits erledigte Arbeit jeden Tag so, als sei sie gerade in Arbeit, ließ die Entwickler pausieren, und das Team hielt den Testtermin im Januar sowie den Launch ein
Der Fehlentwurf, der mit einem Vendor-Produkt begann
- In einem Fortune-500-Unternehmen versprach der CTO die Lieferung eines großen Projekts für einen wichtigen Kunden, zu dem er persönliche Kontakte hatte
- Der Kernbereich wurde an einen großen Technologiedienstleister ausgelagert, und der Vendor behauptete, ein Produkt zu haben, das den Großteil der schweren Arbeit übernehmen könne
- Das tatsächliche Produkt passte nur grob zu den Anforderungen; um das benötigte Verhalten zu erreichen, waren umfangreiche Anpassungen nötig
- Dadurch entstanden zugleich die Nachteile von Vendor-Software und individueller Software
- Es wurde zu einem unflexiblen Paket, das mit Gewalt dazu gebracht werden musste, etwas zu tun, wofür es ursprünglich nicht entworfen war
- Es wurde von der Haupt-Codebasis des Vendors geforkt, wodurch die Wartungskosten stiegen und die Möglichkeit entstand, dass der Support irgendwann enden würde
- Die Projektbeteiligten hielten diesen Ansatz für schlecht, doch in einer Situation, in der sich die direkte Berichtskette zum CTO häufig änderte, liefen Statusmeetings nach dem Muster „Gute Idee, Boss“ ab
Terminverzug und eine fatale Datenstruktur
- Das interne Entwicklungsteam baute andere Teile des Projekts selbst, während der Vendor den ganzen Sommer über versprach, das Produkt werde bald integrationsbereit sein
- Als das Vendor-Produkt im August geliefert wurde, begann ein Integrations-Deathmarch mit dem Ziel eines Launches im Oktober
- Im September traten Bugs zutage, die den Launch blockieren konnten
- Das Vendor-Produkt speicherte alle Kundentransaktionen als JSON-Records in einem einzigen riesigen JSON-Dokument
- Je mehr Testdaten sich ansammelten, desto langsamer wurde die Performance
- Bei jeder neuen Transaktion wurde das gesamte JSON-Dokument aus der Datenbank gelesen und am Ende ein neuer Record angehängt
- Der Vendor sagte, man könne das beheben, indem man Indizes auf Transaktionsfelder hinzufüge, und diese Methode schien vorübergehend zu helfen
Das 16-MB-Limit von MongoDB und der versteckte Rewrite
- Das größere Problem war, dass der Vendor als Datenbank MongoDB gewählt hatte und MongoDB damals ein 16-MB-Limit pro Dokument hatte
- Als das Migrationsteam im Oktober begann, echte Kundendaten einzuspielen, stieß es zunehmend an das 16-MB-Limit
- Das Unternehmen verbarg diese Grenze vor dem Kunden und beschloss, den Betrieb einen Monat verspätet aufzunehmen
- Gleichzeitig startete es ein Skunkworks-Projekt, das die Vendor-Integration ersetzen sollte
- Auch dem Vendor wurde dies nicht mitgeteilt
- Damit wurde der Kern der Lage sowohl vor dem Kunden als auch vor dem Technologiepartner verborgen
- Auf Vendor-Seite waren ursprünglich etwa 70 Personen im Einsatz, doch für die interne Ersatzlösung wurden nur 3 Personen abgestellt
- 1 Person für das Datenbankdesign
- 1 Person für den Aufbau des Backends, das mit der Datenbank interagierte
- 1 Person für den Aufbau der Business-Logik und der Webservices
Die Entscheidung kurz vor dem Feiertags-Deathmarch
- Dem Kunden wurde mitgeteilt, dass er im Januar eine neue Version zum Testen erhalten werde, die die kritischsten Mängel beheben sollte, die beim ursprünglichen Go-live in Kauf genommen worden waren
- Dem Kunden wurde jedoch nicht gesagt, dass das gesamte Kernsystem in etwa zwei Monaten neu geschrieben wurde
- Das ursprüngliche Projekt hatte bis zum Launch über ein Jahr gedauert, doch der Rewrite musste von 3 Personen inklusive der Feiertagszeit umgesetzt werden
- Etwa Mitte Dezember wurde den Projektbeteiligten Feiertagsarbeit nicht als Bitte, sondern als Anweisung mitgeteilt
- Die meisten Teammitglieder hatten bereits 6 Monate lang 60 bis 80 Stunden pro Woche gearbeitet und waren im Burnout
- Ein Software-Launch erzeugt ähnlichen Druck und ähnliche Belohnungen wie eine Bühnenaufführung
- Das Ergebnis von Monaten oder Jahren Vorbereitung erreicht am Launch-Tag echte Nutzer
- Entwickler gewinnen aus dem Gefühl „Ich habe es geschafft“ und aus den Reaktionen der Nutzer ein starkes Erfolgserlebnis
- Ein Software-Launch kann sich wie eine Live-Performance für Introvertierte anfühlen
Die Woche, in der der CTO belogen wurde und das Team Pause machte
- Als Weihnachten näher rückte, hatte das dreiköpfige Team die Ersatzsoftware in einem Monat fast fertiggestellt
- Es gab noch Funktionen aufzuräumen, aber wenn das Team nicht ausbrannte, konnte es den Testtermin im Januar schaffen
- Als der CTO die Streichung der Feiertage anordnete, antwortete der Teamleiter nach außen hin mit „OK“
- Tatsächlich sagte er den 3 Entwicklern: „Nehmt euch eine Woche frei. Ich kümmere mich darum.“
- Der Teamleiter nahm jeden Morgen am obligatorischen Statusmeeting teil und berichtete dem CTO bereits im Vormonat erledigte Arbeit so, als sei sie gerade in Arbeit
- „Das Team arbeitet hart. Heute haben wir Integrations-Meilenstein Nr. 73 erreicht“
- „Gestern hat das Team gute Fortschritte gemacht und einen weiteren Webservice abgeschlossen“
- Die Entwickler kamen nach einer Woche erholt zurück
- Das Team hielt den Januar-Termin ein, lieferte einen guten Launch ab und fühlte sich für kurze Zeit wie Rockstars
- Rückblickend war dieses Gefühl eher Herman’s Hermits als The Beatles, aber trotzdem war es gut
1 Kommentare
Hacker-News-Kommentare
Wenn jemand seinen Urlaub streicht und weiterarbeitet, weil es „deadlinegetrieben“ sei, möchte ich aus eigener Erfahrung sagen: Hör auf, so dumm zu sein.
Es ist besonders schwer aufzuhören, wenn man Anerkennung dafür bekommt, hart gearbeitet zu haben, aber am Ende bereut man all diese Zeit.
Wenn ein Unternehmen selbstverständlich die Feiertage und Urlaubstage seiner Mitarbeiter heranzieht, um sein Produkt verkaufen zu können, trägt es dazu bei, die problematische Welt zu schaffen, in der wir heute leben.
Wenn viele Leute das tun, müssen noch mehr Leute es tun. Wenn niemand es tut und sich alle so verhalten, als sei schon die Forderung an sich absurd, wird das Unternehmen realistische Schätzungen abgeben, auch wenn es dem CEO im Portemonnaie wehtut.
Man kündigt seinen Urlaub an, organisiert Vertretung, trägt ihn in den Teamkalender ein, übergibt die Aufgaben und nimmt sich dann einfach frei.
Projekte kommen und gehen, und Zeitpläne verschieben sich auch von selbst.
Wenn man anfängt, seinen Urlaub an Projekttermine anzupassen, macht man sein Leben lang keinen Urlaub mehr.
Ausnahmen wären allenfalls Rollen, in denen klar bekannte Hochphasen wie Jahresende, Quartalsende oder Steuersaison existieren und es unangemessen wäre, genau dann zu verschwinden.
Mein Cousin hat von September 2023 bis Januar 2024 fast jeden Tag bis 1 Uhr nachts gearbeitet, um ein katastrophal gemanagtes Projekt fertigzubekommen, und nur an Weihnachten freigenommen; selbst das hatte der Director nur erlaubt, weil es ein religiöser Feiertag war und er Angst hatte, die Mitarbeiter könnten klagen.
Er verpasste wichtige Dinge und verlor durch den Stress etwa 20 Pfund.
Das Unternehmen hatte eine knappe Deadline für die Migration auf ein neues System, wusste seit fünf Jahren davon und hatte trotzdem erst im Vorjahr damit angefangen.
Wenn die Frist verpasst worden wäre, hätten außerplanmäßige Kosten in Millionenhöhe gedroht. Am Ende schaffte das Team die Deadline, doch die Belohnung war ein paar Wochen später die Entlassung mit der Begründung, seine Stelle sei weggefallen.
Jetzt sucht er mit über 50 in der denkbar schlechtesten Phase nach einem Job.
Sie sind süchtig danach, sich wertvoll und wichtig zu fühlen, und haben nach Feierabend sonst nichts zu tun.
In einigen Fällen trugen die ausgezeichneten Mitarbeiter sogar eine Mitschuld an diesem Chaos.
Erst nach der vierten Geschichte begriffen die Führungskräfte im Raum, dass das Unternehmen ein strukturelles Problem hatte.
Falls jüngere Leute das hier lesen: Dass solche Geschichten so ausgehen, hängt sehr stark vom Unternehmen und vom Glück ab.
In einem gesunden Unternehmen wäre es vermutlich gar nicht erst zu dieser Art von ausgelagerter Umsetzung gekommen.
Das ist nämlich ein derart offensichtliches Scheitermuster, dass erfahrene Leute den Ausgang schon vor dem Start hätten absehen können.
Schon früher hätten die Leute dem CTO nicht vorgelogen, es laufe gut, sondern gesagt, dass es nicht funktioniert.
Wenn es einen klügeren oder kreativeren Weg gebraucht hätte, um das Projekt zu retten, hätte man das gemeinsam mit dem CTO, vielleicht sogar mit dem Kunden, neu abgestimmt.
Auch hätte man ein Team, das bereits im Burnout steckt, nicht über einen Feiertag hinweg zu langen Arbeitszeiten getrieben.
Manager oder Leads hätten sich für den Projekterfolg und die Gesundheit des Teams gegen die höhere Ebene gestellt und, falls nötig, darauf bestanden, dass das Team an Feiertagen frei hat.
In einer „halbwegs gesunden“ Organisation kann es vorkommen, dass ein Manager absichtlich vage bleibt oder Informationen weglässt; ob das gut oder schlecht ist, hängt von der Situation ab.
Aber wenn ein Manager oder Lead wie in dieser Geschichte wiederholt und offen die Befehlskette nach oben belügt, wird das normalerweise als sehr schlimm angesehen, egal ob das Unternehmen gesund ist oder nicht.
Natürlich ist es im Nachhinein viel einfacher, solche Situationen mit verschränkten Armen zu bewerten.
In schwierigen Positionen oder im Zustand der Überarbeitung kann jeder Fehler machen, aber es ist sinnvoll, solche Szenarien anzuschauen und daraus zu lernen, damit man besser reagieren kann, wenn man wieder in eine ähnlich üble Lage gerät.
Wenn du in so einem Unternehmen bist, solltest du anfangen, dir einen neuen Job zu suchen.
Korruption auf dieser Ebene ist nicht zu beheben, und sie werden dich auch nicht zum CTO machen.
In den letzten 25 Jahren Berufstätigkeit habe ich so etwas kein einziges Mal gesehen.
Die Reparatur dauerte anderthalb Jahre, und in der Zwischenzeit konnten wir Verkäufe nicht rückgängig machen, weil angeblich „Unterwäsche“ verschickt worden war.
Tatsächlich verkauften wir gar keine Unterwäsche, sondern nur Netzwerkdienste; trotzdem konnten wir Kunden erst helfen, nachdem wir gewartet hatten, bis das System den Bestellprozess abgeschlossen hatte.
Dieses Board-Mitglied ging ein Jahr später, und ich vermute, er war ziemlich zufrieden damit, den dummen CEO hereingelegt zu haben.
Ich wurde dort schließlich entlassen und habe keinerlei Mitleid mit diesem herumstümpernden Unternehmen.
Das waren Idioten, die eine „Lösung“ outsourcen wollten und damit nur allen noch mehr Schmerzen bereiteten.
Es gibt durchaus Probleme, die wirklich gelöst werden müssen, aber die Hälfte davon ist nur Müll, damit man sich gut fühlen kann, weil man „es nicht intern baut und Geld spart“.
Am Ende muss man weiter Vertragskosten zahlen, um den Müll zu warten, den man ursprünglich gar nicht selbst gebaut hat.
Damit meine ich, Probleme nicht zu verstecken, sondern die Fakten auszusprechen; das ist wirklich selten.
Man muss sich nur die Microsoft-Sicherheitsnotizen ansehen.
Dass es an Feiertagen keinen Death March gibt, stimmt bis zu einem gewissen Grad, wenn man bei einer Bank oder bei FAANG arbeitet.
Wenn es ein Unternehmen mit „Startup-Kultur“ ist, kann man das vergessen.
Tatsächlich ändert sich die Einstellung zur Arbeit ziemlich schnell, sobald die eigenen Interessen auf dem Spiel stehen, aber es gibt nicht viele Unternehmen, in denen man eine solche Gelegenheit bekommt und das beobachten kann.
Ich habe oft mitten in der Nacht unbemerkt Regeln gebogen, um das Nötige zu erledigen, und viele fähige Leute sind denselben Weg gegangen.
Sogar in Banken habe ich so etwas gesehen.
Solange man keine finanziellen Wetten eingeht, die größer sind als der Wert des Unternehmens oder Teams, kann vieles einfach durchgehen.
Entweder man liefert ab und wird befördert, oder man hat seine Beförderungschancen selbst verringert und sucht sich eben einen neuen Job.
Die Passage, dass „das Vendor-Produkt alle Kundentransaktionen als JSON-Records innerhalb eines riesigen JSON-Dokuments speicherte und man zum Hinzufügen einer neuen Transaktion erst das komplette JSON-Dokument aus der Datenbank lesen und dann den neuen Record ans Ende anhängen musste“, sollte völlig verrückt klingen
Ähnlich habe ich einmal bei einer Technical Due Diligence zu einem potenziellen Investmentziel eines Fonds geholfen; in der User-Tabelle dieses Startups standen auch Ticket-/Reservierungsdaten
Ein Ticket war eine Spalte, deshalb brauchte der aktivste Nutzer, wenn er in seiner gesamten Historie 5 Tickets hatte, 5 Spalten
Als ich es prüfte, gab es bereits über 500 Spalten, und sie suchten nach Investment für „Skalierung“
Natürlich ist das ein lösbares Problem, aber wie zu erwarten war alles auf völlig verdrehte Weise designt, und das war der offensichtlichste „Was ist das denn?“-Moment
Das Investment bekamen sie nicht
Die gesamte Kunden- und Produktdatenbank lag zusammen mit Passwörtern im Klartext in einer öffentlichen, mehrere Megabyte großen einzelnen
.js-Datei, und bei den Internetgeschwindigkeiten der frühen 2000er musste die App diese Datei komplett laden, bevor sie irgendetwas tun konnteAußerdem war die App eine einzige riesige Datei, und im Verzeichnis lagen massenhaft Dateien mit Namen wie
index.1.js,index.final.js,index.newest.js,index.45.jsIch hatte genug Erfahrung, um Best Practices zu kennen, ging also zum CEO, brachte ihn dazu, den CTO zu feuern, und begann, das Ganze mit
git,mysql, serverseitiger Logik und echter Struktur neu aufzubauenDanach wurde der Windows-Server, auf dem das alles lief, gehackt und zu einem Porno-Server umfunktioniert; ich hatte diesen Server nie gesehen und hatte keine Adminrechte, aber aus irgendeinem Grund war es meine Schuld
Die ersten Jobs waren wirklich lehrreich
Ein Senior Engineer, der damit prahlte, aus Stanford zu kommen, hatte das System entworfen
Ich habe mit echten Produktionsdaten lange argumentiert, dass es nach dem Launch nicht skalieren würde, aber niemand hörte zu, und wenige Wochen nach dem Launch brach es zusammen
Kurz darauf wechselte ich das Team, und das Schlimmste war, dass dieser Senior Engineer am Ende befördert wurde und das System einem komplett neuen Team übergeben wurde, das sich dann damit herumschlagen durfte
Das gesamte Systemdesign war furchtbar, und man kann sich wohl denken, warum
Die Führungskräfte mit schicken Abendessen und Reisen einwickeln, ein vermurkstes Produkt abliefern und dafür sorgen, dass man auch künftig weiter gebraucht wird
In der Geschichte selbst hatte der CTO von nichts eine Ahnung
Aus seiner Sicht sah am Ende alles so aus, als wäre es gut gelaufen
Ein Gewinn für alle, außer für die Entwickler, die 80 Stunden pro Woche gearbeitet haben
An dieser Geschichte ist alles kaputt, einschließlich des Vorgehens des Protagonisten
Dass ein Teamleiter Leuten Urlaub gibt und das mit einer Lüge verheimlicht, ist völlig inakzeptabel und ziemlich klar etwas, wofür ein Unternehmen einen entlassen könnte
Im Grunde wirkt sogar eine fristlose Kündigung aus wichtigem Grund möglich
Allerdings scheint die Führungsebene so sehr aus der Spur zu sein, dass er wahrscheinlich damit durchkommt und sogar Lob bekommt
Es wirkt zwar wie ein Verhalten, das zu seiner Umgebung passt
Mein Rat an neue Team Leads wäre aber: Darauf gibt es nichts, worauf man stolz sein sollte; die bessere Option ist, laut zum Problem zu machen, dass die Leute Überstunden machen, und zu verlangen, dass der Vendor an normale Standards gehalten wird oder dass der Projektumfang auf eine normale Arbeitswoche angepasst neu bewertet wird
Wenn man solche Situationen irgendwie am Laufen hält, bringt das niemandem etwas, außer dass Leute ausbrennen oder gefeuert werden können
Wenn man nicht wirklich verzweifelt ist, weil man eine Familie ernähren muss, hat ein Team Lead die Verantwortung, die vernünftigen Arbeitszeiten seines Teams vor irrsinnigen Forderungen zu schützen
Das ist ein Hügel, auf dem man bereit sein sollte, gefeuert zu werden, nicht ein Hügel, auf dem man lügen sollte
Wenn es die Ergebnisse also nicht beeinträchtigt hat, ist es völlig akzeptabel, dass der Teamleiter den Leuten Urlaub gibt und sogar lügt
Was hätte das Management getan, wenn man es geteilt hätte? Es hätte das Projekt weiter vorgezogen
Leuten, die andere für ihren eigenen Ruhm härter arbeiten lassen wollen, muss man eins auswischen
Wessen Tag wurde hier eigentlich gerettet?
Der miese Vendor, der Schrott geliefert hat?
Der CTO, der sich mit Ja-Sagern umgibt und offensichtlich keine Ahnung hat, was im Unternehmen passiert?
Die Entwickler, die bis auf die Knochen geschuftet haben, aber dann hieß es: „Schon okay, ich habe euch doch eine Woche freigegeben“?
Der Protagonist, der alle angelogen hat, um einen willkürlichen Termin eines Unternehmens einzuhalten, dem seine Mitarbeiter egal sind?
Bei dieser Geschichte hat es mich in jedem Moment geschüttelt
Ich arbeite durchaus hart und habe gelegentlich Mehrarbeit gemacht, um einen Launch für Kunden reibungslos zu machen, aber diese Geschichte ist pure Verrücktheit
Hin und wieder mehr Zeit zu investieren, funktioniert nur, wenn es eine Vertrauensbeziehung zum Vorgesetzten gibt und man weiß, dass man immer die Wahrheit sagen kann
Genau das ist im Grunde der Kern einer blameless culture, und es funktioniert nur, wenn alle die Wahrheit sagen
Wie verrückt zu lügen, um die Deadline eines dummen CTO einzuhalten, ist buchstäblich nicht normal
Wenn du in so einer Situation bist, solltest du sofort raus und dir einen besseren Job suchen
„Stolz und Erfolgserlebnis“ und Burnout?
Das „wir“ in der Passage „Wir haben auch den Januar-Termin geschafft, großartig gelauncht und waren kurz Rockstars“ bedeutet ganz offensichtlich ich
Vielleicht hatte ich einfach Glück, aber ich wurde nie entlassen, weil ich die Wahrheit gesagt habe, und mit der Wahrheit ließ sich leichter arbeiten.
Etwa so: „In einer Third-Party-Bibliothek auf dem kritischen Pfad steckt ein Bug. Wir können es schwerer machen, in diesen Bug zu laufen, aber beheben können wir ihn nicht, bevor der Vendor ihn fixt“, oder: „Durch das Nutzerwachstum sind Performance-Probleme schneller sichtbar geworden als gedacht. Während wir zwei Monate für die Behebung brauchen, können wir zur Abmilderung das Dreifache für Infrastruktur ausgeben oder Kunden wegen der Performance verlieren“, oder: „Unser größter Kunde hat erst nach der ersten Iteration verstanden, was er eigentlich will. Es ist etwas völlig anderes als das, von dem wir dachten, dass wir es bauen würden. Wir können das bauen und damit Geld verdienen, oder einem Traum hinterherlaufen und sterben.“
Noch einmal: Vielleicht hatte ich Glück, aber Ehrlichkeit hat für mich gut funktioniert.
Deshalb macht man es, wie andere schon sagten: Man sagt, man werde es „prüfen“, und schiebt es dann langsam zur Seite oder setzt die Person auf Kleinkram an.
Die zweite Option ist, den Mund zu halten und zuzusehen, wie sie lange kämpfen und dann scheitern.
Normalerweise dauert das etwa ein Jahr, aber ich habe auch gesehen, dass es nach zwei bis drei Monaten eingestampft wurde und die Führung im nächsten Quartal praktisch abserviert war.
Wenn jemand nach deiner Meinung fragt, kannst du deine Bedenken diplomatisch erklären; wenn niemand fragt, kannst du auch still bleiben.
Der entscheidende Punkt ist, ob du aktiv auf Probleme in einem Plan hinweist, mit dem jemand über dir die Lorbeeren einstreichen will.
In dem Moment, in dem du es aussprichst, haben sie das Gefühl, ihr Urteilsvermögen werde infrage gestellt, und nehmen es als persönlichen Angriff.
Das zu tun, ohne sich Feinde zu machen, ist extrem schwierig; Feinde bleiben lange, und den Schaden durch einen einzigen Feind können selbst mehrere Freunde kaum ausgleichen.
Deshalb muss man das Spiel mitspielen.
Dass der Protagonist über bereits erledigte Arbeit gelogen hat, ist ein wirklich wichtiges Detail.
Jeden Morgen ging er in das verpflichtende Death-March-Statusmeeting mit dem CTO und sagte: „Das Team arbeitet hart“, „Heute haben wir Integrationspunkt Nr. 73 des Meilensteins erreicht“, „Gestern gab es guten Fortschritt, und wir haben einen weiteren Webservice fertiggestellt“ – tatsächlich waren das aber Dinge, die schon im Vormonat erledigt worden waren.
Aus einem bestimmten Blickwinkel wirkt das wie underpromise and overdeliver.
Hätte er gelogen und behauptet, nicht erledigte Arbeit sei erledigt, hätte sich das deutlich schlechter angefühlt.
Das wäre definitiv riskanter gewesen, und wenn das Team zurückgekommen wäre und er gesagt hätte: „Hier sind die Tickets, aber ich habe dem CTO schon gesagt, dass sie erledigt sind, also beeilt euch“, wäre das aus Sicht des Teams auch nicht gut gewesen.
Die Interaktion zwischen Entwicklern und Management leidet stark unter Informationsasymmetrie und mangelndem Vertrauen.
Ich arbeite gerade an einem Projekt, bei dem eine Codebasis modernisiert wird, die auf einem sehr alten Compiler läuft.
Wir arbeiten seit einem Jahr daran, und große Teile des Systems sind fertig, aber ein ziemlich wichtiger Teil fehlt noch.
Das Management versteht den Prozess nicht und hat auch keine Gewissheit, dass das Projekt am Ende erfolgreich sein wird.
Softwareprojekte, insbesondere Migrationsarbeiten, haben eine lange Geschichte des Scheiterns, daher mache ich ihnen ihre Nervosität nicht zum Vorwurf.
Früher hatten wir wöchentliche Fortschrittsmeetings, jetzt sind es zwei pro Woche; offenbar glauben sie, dass es dadurch schneller geht.
Meist nehmen sie nicht selbst teil, sondern ein mittlerer Manager spielt den Boten.
Aus Entwicklersicht ist natürlich klar, dass das funktionieren wird, und persönlich habe ich nie am Erfolg gezweifelt.
Nur ist das System groß und alt, deshalb ist der Zeitrahmen unsicher.
Es bleiben Monate, nicht Jahre, und ich kenne die 80/20-Regel, aber wir sind schon tief in diesen 20 % drin.
Für das Management ist es nur ein binärer Zustand aus fertig/nicht fertig, daher ist der Fortschritt schwer einzuschätzen, und in dem, was wir sagen, steckt für sie kein „Vertrauen“.
Das kann ich nachvollziehen.
Selbst wenn wir ein Jahr lang nichts getan und nur Meetings abgehalten hätten, hätten sie es nicht gewusst.
Es ist ein Festpreisvertrag, also haben wir keinen Grund, es in die Länge zu ziehen, aber das Risiko liegt vollständig bei ihnen.
Sie haben schon viel Geld ausgegeben und sind nervös.
Auf Basis des Rats externer Technikexperten haben sie gute technische Entscheidungen getroffen, aber es fehlt ihnen weiterhin an Gewissheit.
Wenn das Projekt am Ende scheitert, trifft es schließlich sie, nicht uns im gleichen Maß.
Es gibt keine einfache Lösung.
Man kann nicht einfach sagen, Manager müssten technisch sein, und diese Technik ist auch nicht ihr Kerngeschäft.
Mehr Consultants zu holen, wird ihnen auch kein warmes Gefühl geben.
Das Beste, was wir tun können, ist weitermachen und liefern.
Auch Monatsblöcke sind in Ordnung: einfach weiter herunterbrechen und alles in Teilaufgaben aufteilen.
Es muss nicht perfekt sein, und grobe Kanten sind okay.
Ich empfehle, jedem Block einen freundlichen, unterhaltsamen Namen zu geben.
Zum Beispiel eignen sich klassische Tanznamen wie Tango, Cha-Cha oder Walzer.
Dann setzt man Meetings mit den Managern an, bezieht auch höhere Manager ein und bittet die mittleren Manager, bei den täglichen Stand-ups zuzuhören.
Alle sollten stehen, damit die Meetings kurz bleiben, und der Fortschritt gegenüber den Aufgaben auf der Liste sollte nachverfolgt werden.
Wenn eine Aufgabe dazukommt oder sich etwas leicht verzögert, überrascht das niemanden, solange ihr insgesamt nahe am Plan bleibt.
Wir wissen beide, dass das tatsächliche Deployment die große Hürde ist, aber das muss man ihnen erst sagen, wenn man dafür bereit ist.
Verzögerungen machen das Management nervös, und das ist verständlich, aber mehr Meetings machen es nicht schneller.
Es hilft nicht, wenn ein PM jeden Tag 30 Minuten eincheckt und sagt, er werde „unterstützen und alles bereitstellen, was nötig ist, um das Projekt wieder auf Kurs zu bringen“.
Was nötig ist, sind einfach weniger Meetings.
Das einzige Hindernis ist Zeit, und der Grund, warum Zeit ein Hindernis ist, liegt darin, dass die obere Ebene von Anfang an auf einem unrealistischen Zeitplan bestanden hat.
Indem sie zeigen, dass sie den Entwicklern nicht vertrauen, zeigen sie am Ende auch, dass sie ihrer eigenen Managementfähigkeit nicht vertrauen, die richtigen Entwickler eingestellt zu haben.
Sie machen einen zentralen Teil ihrer eigenen Arbeit sehr schlecht.
Ein Einjahresprojekt sollte kein binärer Zustand aus fertig/nicht fertig sein.
Es muss Fortschrittsmetriken geben, mit denen man arbeiten kann.
Das Topmanagement muss nicht technisch sein, aber irgendwo in der Hierarchie muss es unbedingt jemanden geben, der den Fortschritt in eine verständliche Form übersetzen kann.
Zwei Dinge an dem Anbieter sind schwer zu verzeihen, wenn man sie sicher weiß:
Zum einen hat er die Kernlogik davon abhängig gemacht, Mongo-Records endlos wachsen zu lassen; zum anderen konnten drei etwas überdurchschnittliche Leute ihn mit gezieltem Einsatz in etwa drei Monaten ersetzen.
Dass dieser Anbieter es bis zu Fortune-500-Kunden geschafft hatte, zeigt, wie hilflos sich Organisationen wie dieser Kunde selbst vor gar nicht so großen Softwareaufgaben fühlen.
Tatsächlich wirkt der Projektumfang so, als könnten einige hier ihn sogar als Hobbyprojekt stemmen.
Deshalb verstehe ich auch, warum Retool bei Tech-Leadern beliebt ist, bei Engineers aber nicht unbedingt.
Ich frage mich, welche anderen Produktansätze dieselbe Lücke schließen könnten.
Dank Tabellenkalkulationen konnte praktisch jede Person auf niedriger Ebene innerhalb weniger Tage einen groben, fast funktionierenden Prototyp eines Tools bauen, ohne mit irgendjemand anderem in der Organisation zu tun zu haben.
Vor Tabellenkalkulationen musste man Vorgesetzte überzeugen, damit die IT-Abteilung die Anfrage übernahm, und allein dieser Prozess dauerte mindestens drei Monate.
Danach hätte man noch ein paar Quartale warten müssen, bis man eine grobe, fast funktionierende Implementierung in etwas wie Cobol oder C bekommen hätte, die nicht zu den Anforderungen passte.
Ein paar Entwickler und ein paar Supportleute fuhren zu den Nutzern, und die Entwickler hatten sechs Monate lang an einem neuen Tool gearbeitet, das ein großes Problem lösen sollte.
Aber dieser Tag war der erste, an dem die Endnutzer es überhaupt zu sehen bekamen.
Kurz darauf fuhren wir wieder über die Staatsgrenze zurück, und die Entwickler waren ziemlich kleinlaut.
Soweit ich weiß, wurde dieses Projekt nie wieder von irgendjemandem erwähnt.
Die lassen Juniors die ganze Arbeit machen und rechnen sie zum Stundensatz von Senior-Entwicklern ab.
Ich wünschte, die Leute würden aufhören, KI-generierte Headerbilder zu verwenden.
Das reißt einen gleich am Anfang aus der Konzentration.
Ist der Code da hinter dem Monitor?
Und ist auf der Rückenlehne des Stuhls hinten auch Code? Oder sitzt da jemand auf einem riesigen iPad?
Wenn man schon KI-Bilder verwendet, sollte man sich wenigstens bemühen, dass sie nicht völlig seltsam und verrückt aussehen.
Solche Bilder sind buchstäblich in Sekunden generiert; war das wirklich das beste aus der Auswahl?