Читать книгу Projekt Unicorn - Gene Kim - Страница 14
KAPITEL 3 Montag, 8. September
ОглавлениеNach dem Townhall-Meeting kehrt Maxine an ihren Schreibtisch zurück. Sie schaut auf ihren Kalender. Es ist der vierte Tag ihrer Gefangenschaft und ihrer Mission, einen Phönix-Build zu erstellen, aber es fühlt sich an, als wäre bereits ein ganzes Jahr vergangen. Die Stunden ziehen sich zäh wie Melasse.
Sie erhält eine Benachrichtigung auf ihrem Telefon, die sie aufrüttelt und in die Realität zurückholt:
Phoenix-Projekt: Stakeholder-Status-Update (beginnt in 15 Minuten)
Dieses Meeting kennt sie noch nicht. Um ihre Mission voranzutreiben, hat sie alle gebeten, sie zu jedem einzelnen Treffen einzuladen. Das ist besser, als am Schreibtisch zu sitzen, zumal sie immer noch versucht, die Lage vollständig zu verstehen. Sie hofft, jemanden zu finden, der ihr einige der Dinge, die sie braucht, besorgen kann. Sie hat darauf geachtet, dass ihr keine Action-Items zugewiesen werden, und sie hat sich auch nicht freiwillig für die Arbeit an irgendwelchen spaßig klingenden Features zur Verfügung gestellt – sie will sich nicht vom Phoenix-Build ablenken lassen.
Jeder hier glaubt, dass Features wichtig seien, weil sie in einer App, auf der Webseite oder in der API landen. Aber niemand scheint zu erkennen, wie wichtig der Build-Prozess ist. Entwickler können ohne einen vernünftigen Build-, Integrations- und Testprozess nicht produktiv sein.
Sie kommt früh an und ist überrascht, dass nur noch ganz hinten ein wenig Platz ist. Sie steht mit fünf anderen Personen an der Wand. Als sie sich umsieht, staunt sie nicht schlecht – alle Entscheidungsträger der Firma sind hier. Maxine lächelt, als sie sieht, dass Kirsten Fingle, die Leiterin des Project Management Office, die Sitzung leitet. Maxine hatte es genossen, mit ihr zusammenzuarbeiten, als sie ein großes Programm unterstützte, dem mehrere von Kirstens Projektleiter-Ninjas zugeteilt wurden – die Ninjas sind normalerweise für die wichtigsten Projekte vorgesehen, in denen viele Gruppen innerhalb des Unternehmens koordiniert werden müssen. Das sind richtige Asse, wenn es darum geht, Dinge zu bewegen. Sie können Probleme schnell eskalieren und lösen – oft mit einer einzigen Textnachricht.
Vorne im Raum steht Chris, der ihr kurz zunickt – er managt über 200 Entwickler und QA-Leute, deren Arbeit hauptsächlich durch das Phoenix-Projekt bestimmt wird. Chris starrt jemanden auf der anderen Seite des Tischs an, der wie Ed Harris in Apollo 13 aussieht. Als sie ihren Nachbarn leise fragt, wer das sei, antwortet dieser: »Bill Palmer, der neue VP of IT Operations. Ist letzte Woche nach der großen Säuberungsaktion in der Führungsriege befördert worden.«
Großartig, denkt Maxine. Aber sie freut sich, dass diese Menschenansammlung bereits ein paar Dienstjahre hinter sich hat. Es ist, als stünde man auf der Brücke der Enterprise und würde den Sternenflottenoffizieren bei der Arbeit zuschauen.
Sie genießt die ersten 15 Minuten der Sitzung. Es ist ein Chaos. Alle rätseln herum, was genau Sarah im Townhall-Meeting meinte, als sie davon sprach, der Phoenix-Launch fände »später in diesem Monat« statt. Kirsten erklärt mit Nachdruck: »Das Datum wird noch verhandelt, und mir wurde bisher nichts Konkretes mitgeteilt.« Könnte es wirklich ein weiterer Fehlalarm sein?, fragt sich Maxine ungläubig.
Sie spürt die besondere Dringlichkeit, mit der über Geschäftsprioritäten und die wichtigsten zu eskalierenden und zu behandelnden Themen gesprochen wird sowie über solche, bei denen aktuelle Konflikte gelöst werden müssen. Sie weiß nicht, was all die Akronyme bedeuten, aber sie fügt die, die sie für wichtig hält, ihrer Liste hinzu und ignoriert die fade, unternehmensinterne Kabbelei.
Ganz allmählich stellt sich bei ihr, ganz gegen ihre eigene Erwartung, Langeweile ein, während das Treffen weiter vor sich hin plätschert und sich der Fokus auf bedeutungslose Details richtet, die leidenschaftlich vorgetragen werden von … wem auch immer – sie hat ehrlich gesagt keine Ahnung. Steht OEP für »Order Entry Protocol« oder »Order Entry Program«? Oder haben sie wieder über OPA gesprochen? Oder ist das vielleicht das Gleiche? Interessiert mich das wirklich?
40 Minuten später – ihre Augen werden schon glasig – beginnt die »Task-Status-Phase« des Meetings, und Maxine verliert endgültig jegliches Interesse. Hätte sie noch etwas anderes zu tun, wäre sie schon längst weg.
Ihre Füße schmerzen vom langen Stehen, und sie überlegt gerade, ob sie die Sitzung verlassen soll, als sie hört, wie sich jemand darüber beschwert, wie lange er schon auf etwas wartet, das er dringend braucht. Sie schmunzelt, als sie denkt: Willkommen im Klub. Genau damit verbringe ich den lieben langen Tag.
Einer der Dev-Manager aus der Riege der jüngeren Mitarbeiter antwortet. »Ja, wir sind definitiv im Rückstand, aber wir haben ein paar neue Entwickler, die diese Woche anfangen, um in einer oder zwei Wochen auf dem Laufenden zu sein und produktiv mithelfen zu können.«
Ha. Ich kenne mich wirklich gut aus und habe dennoch fast keine Fortschritte gemacht, denkt sie, während sie zu Boden schaut. Sie schmunzelt vor sich hin. Viel Glück, ihr Dummköpfe.
Es setzt eine lange, unbehagliche Stille ein. Maxine schaut auf. Zu ihrem Entsetzen sehen alle sie an – ihr wird klar, dass sie etwas laut gesagt haben muss.
Sie schaut Chris an, der fassungslos dreinblickt und ihr mit wild gestikulierenden Händen eine Art »Nein, nein, nein!« herüberschickt.
Von ganz vorne meldet sich schnell Kirsten: »Schön, Sie zu sehen, Maxine! Ich wusste gar nicht, dass Sie bei Phoenix sind. Wir freuen uns, dass jemand mit Ihrer Erfahrung bei unseren Bemühungen helfen wird – Sie hätten zu keinem besseren Zeitpunkt auftauchen können!«
Chris vergräbt sein Gesicht in den Händen. Wenn Maxine nicht schon an der Wand stünde, würde sie zurückweichen. Sie ahmt Chris nach und wedelt mit ihren Hände hin und her. »Nein, nein, nein … Tut mir leid, ich bin erst seit ein paar Tagen hier. Sie alle leisten erstaunliche Arbeit. Bitte fahren Sie fort – ich bin nur hier, um bei der Dokumentation und den Builds zu helfen.«
Kirsten, mit all ihrer effektiven Ernsthaftigkeit, lässt nicht locker. Sie lehnt sich nach vorne. »Nein, wirklich. Ich glaube, Sie haben ›Viel Glück, ihr Dummköpfe.‹ gesagt. Ich bin sehr an Ihrer Meinung interessiert, allein aufgrund Ihres großen Erfolgs im Anlagenbetrieb. Ich würde gern besser verstehen, was Sie so lustig finden.«
»Es tut mir leid, dass ich gelacht habe«, beginnt sie. »Es ist nur so, dass ich seit letztem Mittwoch nichts anderes gemacht habe, als zu versuchen, Phoenix-Builds auf meinem Laptop in Gang zu bringen, und vollkommen gescheitert bin. Ich warte auf Credentials, Lizenzschlüssel, Environments, Konfigurationsdateien, Dokumentation, was auch immer – ich weiß, dass jeder eine Menge zu tun hat und dass Phoenix eine umfangreiche Anwendung ist, sodass es ein ziemlich gewaltiges Unterfangen sein muss, alle Teile für einen Build zusammenzufügen. Aber wenn wir wollen, dass unsere Entwickler produktiv sind, müssen sie vom ersten Tag an in der Lage sein, Builds durchzuführen. Im Idealfall sollten sie Code in einer produktionsähnlichen Umgebung schreiben, damit sie unmittelbar Feedback bekommen, ob der von ihnen geschriebene Code im Gesamtsystem funktioniert. Nach tagelangen Versuchen habe ich immer noch nichts, was dem Gesamtsystem auch nur ähneln würde – ich habe lediglich eine Kiste voller Einzelteile, aber eine ganze Menge Werkzeuge fehlen noch. Und ich kenne mich wirklich, wirklich gut mit diesen Dingen aus.«
Sie schaut sich im Raum um und zuckt halbherzig mit den Achseln in Richtung Chris. Das musste sie sich unbedingt von der Seele reden. Chris sieht entsetzt aus.
»Ich hoffe nur, dass diese neuen Engineers, die Sie eingestellt haben, mehr Glück haben als ich«, schließt sie schnell.
Erneut setzt eine lange, unbehagliche Stille ein. Randy nickt nachdrücklich und verschränkt selbstgefällig die Arme. Jemand auf der anderen Seite des Tischs lacht lautstark. »Sie hat absolut recht! Die werden viel mehr als nur Glück brauchen! Hier eine Dev-Umgebung einzurichten, ist ungefähr so, als müsse man auf irgendeinem Amt seinen Führerschein erneuern – man zieht eine Nummer, füllt einen Haufen Formulare aus und wartet. Ach was, zum Teufel, ich bekomme einen Führerschein ja am selben Tag verlängert – es ist eher wie der Versuch, eine Baugenehmigung zu erhalten – niemand weiß, wie lange es am Ende dauern wird.«
Die Hälfte der Menschen im Raum lacht gemein, während die andere Hälfte eindeutig beleidigt wirkt.
Maxine schaut sich die kluge Person an, die gesprochen hat – ein Mann von etwa 45, leicht übergewichtig, aber in der Art eines Exsportlers. Er hat einen eckigen Kiefer, ist seltsam sauber rasiert, und seine Nase ziert eine große, quadratische Brille. Er trägt ein Skateboard-T-Shirt, und ein mürrischer Blick, der wie eingefroren wirkt, dominiert sein Gesicht.
Aufgrund seiner Verschrobenheit wettet Maxine, dass er ein leitender Entwickler ist – für eine längere Zeit in einem Projekt wie Phoenix zu stecken, scheint von den Menschen Tribut zu fordern.
Jemand aus dem vorderen Teil des Raums beginnt zu antworten – sie erkennt William, den supernetten Direktor der QA, der sich wirklich bemüht hat, ihr zu helfen. »Sehen Sie«, sagt er, »unsere Teams hinken beim Testen immer weiter hinterher, deshalb waren wir uns alle einig, dass wir, um unsere Termine einzuhalten, die Arbeit an den Environments vernachlässigen würden – die Auslieferung vollständig getesteter Funktionen sollte Vorrang haben. Wir wussten alle, dass sich dadurch die Vorlaufzeiten für die Bereitstellung von Umgebungen für unsere Teams verlängern würden. Glauben Sie mir, meine Teams sind davon genauso schwer betroffen wie Ihre – auch QA braucht Umgebungen, in denen sie testen kann.«
Der übellaunige Entwickler antwortet sofort: »William, du wurdest reingelegt. Das war eine verheerende Entscheidung – eine Katastrophe. Maxine hat recht, Entwickler brauchen die passenden Umgebungen, um produktiv zu sein. Sie sollten ein ganzes Team damit beauftragen, den Prozess der Umgebungserstellung zu fixen. Ich arbeite in drei Projekten, die Staging-Umgebungen benötigen, und wir warten bereits monatelang. Das ist so wichtig, dass ich am liebsten freiwillig mithelfen würde«, sagt er.
»Verweigert«, entgegnet Chris müde von der Vorderseite des Raums. »Kümmern Sie sich um Ihren eigenen Kram, Dave. Bleiben Sie auf die Features konzentriert.«
William sagt: »Moment, Moment … Sie sollten wissen, dass nicht wir der Engpass für Umgebungen sind – wir haben mehrere fast startklare Umgebungen, aber wir brauchen immer noch Anmeldekonten von Security sowie Speicherplatz und Mount Points von Ops. Ich habe es eskaliert, aber noch nichts weiter gehört.«
Chris zeigt mit dem Finger auf Bill und wendet sich an Kirsten: »Ich brauche Hilfe, um unseren Bedarf an Operations zu eskalieren.«
Bill antwortet schnell. »Wenn wir der Engpass sind, muss ich das wissen. Lassen Sie uns herausfinden, wie wir William das besorgen können, was er braucht.«
Kirsten nickt und scheint leicht verärgert zu sein. Maxine geht davon aus, dass es daran liegt, dass immer mehr Abhängigkeiten auftauchen. »Ja, gute Idee, Bill. Okay, gehen wir weiter zum nächsten Meilenstein auf der Liste.«
Während Kirsten spricht, dreht sich Chris zu Maxine um, und seine Miene signalisiert unmissverständlich: Welchen Teil von »halte dich bedeckt« hast du nicht verstanden, Maxine? Maxine murmelt leise eine Entschuldigung.
Aus den Augenwinkeln sieht sie einen jüngeren Mann neben Kirsten knien, der ihr etwas ins Ohr flüstert und dabei Richtung Maxine gestikuliert. Statt einer khakifarbenen Hose trägt er eine Jeans und hält ein schwarzes Moleskine-Notizbuch in der Hand.
Kirsten nickt und lächelt ihn an, zeigt ebenfalls auf Maxine und flüstert ein paar Sätze zurück. Der junge Mann nickt, während er in einem Affentempo Notizen macht.
Maxine beschließt, auf kürzestem Weg zur Tür zu gehen, bevor sie irgendeine Dummheit begeht.
Sie schafft es in den kühlen Gang und ist erleichtert, aus dem heißen, stickigen Raum herauszukommen. Sie geht in die Küche, wo es noch kühler ist. Sie denkt darüber nach, sich einen Becher Kaffee zu holen, vielleicht ihren fünften heute, als sie jemanden hinter sich sagen hört: »Hallo, Sie müssen Maxine sein!«
Sie dreht sich um. Es ist der junge Mann aus dem Meeting, der mit Kirsten gesprochen hat. Er lächelt breit, streckt die Hand aus und sagt: »Hallo, ich bin Kurt. Ich bin einer der QA-Manager, die für William arbeiten. Ich habe in der Sitzung gehört, dass Sie Lizenzen und Environments und eine Reihe anderer Dinge benötigen, um den Build-Prozess zum Laufen zu bringen? Ich glaube, da kann ich helfen.«
Einen Moment lang starrt Maxine nur zurück, nicht sicher, ob sie ihn richtig verstanden hat. Seit Tagen macht sie nichts anderes, als in allen Ecken und Winkeln nach den Komponenten für den Phoenix-Build zu suchen. Seit Tagen hat sie einer gefühl- und gesichtslosen Bürokratie ein Ticket nach dem anderen ins System geschoben. Sie ist verblüfft, dass ihr nun tatsächlich jemand helfen will.
Maxine ertappt sich dabei, wie sie Kurts ausgestreckte Hand anstarrt, schaltet zurück in die Wirklichkeit – und schüttelt sie. »Schön, Sie kennenzulernen. Ich bin Maxine, und, ja, ich nehme jede Hilfe an, die ich für den Phoenix-Build bekommen kann!«
Sie fügt hinzu: »Ich hoffe, dass ich vorhin niemandem auf die Füße getreten bin. Ich bin sicher, dass jeder sein Bestes tut bei allem, was hier vor sich geht …« Er lächelt noch breiter und zeigt mit dem Daumen zurück in Richtung des Konferenzraums, in dem sie sich befanden. »Die? Keine Sorge. Die sind alle in so großen Schwierigkeiten, dass sie nur ihren Arsch retten und sich gegenseitig den Löwen zum Fraß vorwerfen wollen. Ich bezweifle, dass sie sich heute Abend überhaupt noch an das erinnern werden, was Sie gesagt haben.«
Maxine lacht, aber Kurt bleibt ganz sachlich. »Also, Sie müssen die Phoenix-Builds in Gang bringen. Wie weit sind Sie gekommen, und was brauchen Sie noch?«
Maxine sackt etwas in sich zusammen. »Nicht annähernd so weit, wie ich gerne wäre, und das liegt nicht daran, dass ich mich nicht genug bemüht hätte.« Sie beschreibt sehr detailliert, was genau sie bisher getan hat und welche Schritte noch zu erledigen sind. Sie öffnet auf ihrem Tablet ihre Checkliste, zeigt ihm alle offenen Aufgaben und zählt auf, worauf sie noch wartet.
»Wow, die meisten geben bereits lange vorher auf«, sagt Kurt. »Darf ich das sehen?«, fügt er mit einer Geste auf ihr Tablet hinzu.
»Aber sicher«, erwidert sie und reicht es ihm. Kurt fährt mit dem Finger über die Liste, nickt und scheint sie mit einer anderen Liste in seinem Kopf zu vergleichen. »Kein Problem, ich glaube, ich kann Ihnen fast alles davon besorgen«, sagt er. Und mit einem Lächeln fügt er hinzu: »Und ich gebe Ihnen noch ein paar Dinge obendrauf, die Sie wahrscheinlich später brauchen werden. Keine Sorge, konnten Sie nicht wissen. Wir mussten auch auf die harte Tour lernen. Die Build-Umgebung wird hier nicht besonders gut dokumentiert.«
Kurt fotografiert die Liste mit seinem Handy und gibt ihr das Tablet zurück. »Sie werden in ein oder zwei Tagen von mir hören«, sagt er. »Das Phoenix-Projekt befindet sich praktisch in der Steinzeit. Wir haben Hunderte von Entwicklern und QA-Leuten, die an diesem Projekt arbeiten, und die meisten können nur Builds für ihren Teil der Codebasis ausführen. Sie machen keinen Build des Gesamtsystems, geschweige denn, dass sie es regelmäßig testen. Ich weise die Verantwortlichen immer wieder darauf hin, aber sie sagen mir jedes Mal, sie hätten alles unter Kontrolle.«
Er schaut sie direkt an. »Das würden Sie sich in Ihrer alten MRP-Gruppe, die für die Fertigungsstätten zuständig ist, nicht gefallen lassen, oder?«, fragt er.
»Auf keinen Fall«, antwortet sie schnell. »Es ist so, wie es der Kerl in der Besprechung beschrieben hat – Entwickler brauchen ein System, das ihnen schnell und kontinuierlich Feedback zur Qualität ihrer Arbeit gibt. Wenn man ein Problem nicht schnell findet, entdeckt man es erst Monate später. Dann ist die Quelle des Problems unter all den Änderungen, die die anderen Entwickler zwischenzeitlich gemacht haben, kaum mehr aufzuspüren, und der klare Zusammenhang zwischen Ursache und Wirkung geht verloren. Das ist keine Art, ein Projekt zu betreiben.«
Kurt nickt. »Tja, und dennoch ist es so, dass wir hier das Phoenix-Projekt, das wichtigste Projekt des Unternehmens, so durchführen, wie man es in den 1970er-Jahren getan hätte. Die Entwickler programmieren den lieben langen Tag, aber integrieren ihre Änderungen und Tests erst am Ende des Projekts. Was kann also schiefgehen?«, fügt er schmunzelnd hinzu. »Mir wird immer wieder gesagt, dass solche Entscheidungen meine Gehaltsklasse übersteigen.«
Sie lachen beide.
Kurt wirkt weder verbittert noch zynisch. Von ihm geht ein gutmütiger Vibe aus, und er scheint mühelos zu akzeptieren, wie die Welt funktioniert. Er fährt fort: »Ich beneide Sie darum, wie viel Ihr Fertigungsteam geleistet hat und wie viele Plattformen Sie unterstützt haben. Wir haben zehnmal mehr Leute bei Phoenix, aber ich vermute, dass Ihre alte Mannschaft deutlich mehr erreicht als wir.«
Maxine nickt. Sie vermisst ihre alte Mannschaft definitiv.
»Oh, und übrigens gibt es ein Gerücht, das Sie interessieren könnte«, verrät Kurt und sieht sich um, als hätte er Angst, belauscht zu werden. »Es heißt, Sarah habe darauf gedrängt, dass Phoenix diese Woche gelauncht wird, und Steve habe den Termin gerade genehmigt. Jetzt wird die Hölle losbrechen. Lassen Sie es mich wissen, wenn Sie beim Release-Team mitmachen wollen. Es wird ein Riesenspaß, dem Ganzen zuzuschauen.«
Nach dieser seltsamen Begegnung kehrt Maxine an ihren Schreibtisch zurück und stellt fest, dass sie erneut wartet. Zerstreut liest sie das Zitat aus einem ihrer Lieblingsbücher von Dr. Seuss, Oh, the Places You’ll Go, das sie an ihren verschiedenen Arbeitsplätzen immer wieder aufhängt.
Das Buch beschreibt den gefürchteten »Waiting Place«, an dem man darauf wartet, dass der Fisch anbeißt, auf den Wind zum Drachensteigen, auf Onkel Jake, dass das Wasser kocht oder die nächste Pause kommt … Alle warten einfach nur.
NEIN!
Das ist nichts für dich!
Irgendwie wirst du
all dem Warten und Bleiben entkommen.
Du wirst die freundlichen Orte finden,
an denen die Boom-Bands spielen.
Alle Mitglieder des Phoenix-Projekts sitzen auf ihrem »Waiting Place« fest, und Maxine ist fest entschlossen, alle zu befreien.
Es ist 11:45 Uhr. Maxine schaut auf ihren Kalender. Es ist erst der vierte Tag ihres erzwungenen Exils. Obwohl sie nichts von Kurt gehört hat, ist es ihr gelungen, Zugang zum dritten von vier Quellcode-Repositories zu bekommen. Jetzt entscheidet sie, dass sie nicht länger auf andere Menschen warten will.
Sie wird irgendwie einen Build machen.
In den nächsten vier Stunden versucht sie, jedes Makefile, maven POM, bundler, pip, ant, build.sh, build.psh und alles andere auszuführen, was sie finden kann und was entfernt einem Build-Skript ähnelt. Die meisten Skripte brechen sofort ab, als sie sie ausführt. Einige spucken beunruhigend lange Fehlermeldungen aus.
Sie durchforstet die Fehlerprotokolle, erhofft sich Hinweise dazu, wie man etwas wirklich zum Laufen bringen könnte, und sucht den ganzen Mist nach der Nadel im Heuhaufen ab – eine mühsame und unangenehme Aufgabe. Sie identifiziert mindestens 20 fehlende Dependencies und ausführbare Dateien. Sie fragt mehrmals herum, ob jemand weiß, wo man diese Dinge herbekommt, öffnet Tickets und verschickt E-Mails, aber niemand scheint irgendetwas zu wissen. Sie verbringt drei Stunden damit, im Internet nach Hinweisen zu googeln und Stack Overflow zu durchwühlen.
In einem Moment der Schwäche beschließt sie, einige der fehlenden Komponenten aus ähnlich klingenden Komponenten, die sie auf GitHub findet, von Grund auf neu zu bauen. Fünf Stunden später ist sie in einer schrecklichen Stimmung – erschöpft, frustriert, gereizt und vollkommen sicher, dass sie gerade einen ganzen Tag damit verschwendet hat, von unzähligen Hölzchen auf noch mehr Stöckchen zu kommen.
Im Grunde hat sie versucht, fehlende Motorenteile aus eingeschmolzenen Aluminiumdosen nachzuformen. Das war wirklich dämlich, Maxine, denkt sie.
Als sie an diesem Abend nach Hause kommt, wird ihr klar, dass sie die ganze Frustration von der Arbeit mit im Gepäck hat. Sie teilt ihrem Mann und ihren Kindern mit, dass sie derzeit nicht in der Lage sei, sich zu unterhalten, und findet im Kühlschrank zwei Piccoloflaschen Veuve Cliquot Rosé. Ihre Teenager wissen sofort, dass sie ihr aus dem Weg gehen sollten – sie trägt ihr »Mama ist superschlecht gelaunt«-Gesicht.
Während die anderen das Abendessen vorbereiten, verkriecht sie sich ins Bett und sieht sich Filme an.
Was für ein total verschwendeter Tag, ärgert sie sich.
Sie denkt über den Unterschied zwischen einem guten und einem schlechten Tag nach. Ein guter Tag ist es für sie dann, wenn sie ein wichtiges Geschäftsproblem löst. Die Zeit vergeht wie im Flug, weil sie konzentriert ist und ihre Arbeit liebt. Sie befindet sich im Flow und kommt zu einem Punkt, an dem sich nichts mehr nach Arbeit anfühlt.
An einem schlechten Tag schlägt sie ihren Kopf gegen einen Monitor und sucht das Internet nach Dingen ab, die sie eigentlich nicht im Geringsten interessieren, die sie aber zur Lösung des Problems braucht. Während sie einschläft, versucht sie, nicht darüber nachzudenken, wie viel Zeit sie damit verbrät, im Netz nach Möglichkeiten zu suchen, obskure Fehlermeldungen zu beheben.
Es ist ein neuer Tag. Frisch erholt nach einem guten Nachtschlaf, sitzt Maxine an ihrem Schreibtisch – mit dem Vorsatz, den gestrigen Fehler nicht zu wiederholen. Nur weil sie sich beschäftigt gefühlt hat, bedeutet das nicht, dass sie tatsächlich etwas Sinnvolles getan hat. In einem Terminalfenster ruft sie ihre Arbeit von gestern auf und löscht alles, ohne es noch einmal anzusehen.
Dann ruft sie all ihre offenen Tickets im Helpdesk-System auf. Sie weigert sich, sich machtlos zu fühlen, der Gnade anonymer Mächte ausgeliefert, gefangen in einer kalten Bürokratie, die sie in ihren Zielen, Bestrebungen, Wünschen und Bedürfnissen aktiv behindert.
Maxine blickt auf eine lange und komplizierte Geschichte mit Ticketing- und Benachrichtigungssystemen zurück, darunter sowohl gute als auch schlechte Erfahrungen.
Letztes Jahr hat sie ein Kickstarter-Projekt für einen Mug unterstützt, der angeblich Kaffee oder Tee stundenlang bei jeder gewünschten Temperatur warmhalten sollte. Sogar eine Bluetooth-Verbindung war geplant, um die Temperatur des Getränks per App fest- und einstellen zu können. Sie fand die Idee faszinierend und beteiligte sich schnell mit 500 Dollar, um der Erfinderin zu helfen.
Sie war jedes Mal begeistert, wenn sie eine neue Benachrichtigung erhielt: als die Erfinderin ihre Finanzierungsziele erreicht hatte, als ein Hersteller ausgewählt worden war, als der erste Produktionslauf begann und, was am wichtigsten war, als ihre Tasse verschickt wurde. Es war so befriedigend, Teil einer gemeinsamen Anstrengung zu sein und schließlich einen der ersten 500 hergestellten Kaffeebecher in der Hand zu halten.
Das Ticketing-System der Entwicklungsabteilung fühlt sich völlig anders an. Sie empfindet das Gegenteil des glücklichen Gefühls und der Vorfreude, die sie bei ihrer Zaubertasse gespürt hat. Stattdessen erinnert es sie an eine schreckliche Erfahrung, als sie in den 1990er-Jahren ihr erstes Hochgeschwindigkeits-DSL-Breitbandpaket in Betrieb nahm. Obwohl sie das DSL-Modem sofort erhielt, musste sie sich danach mit dem Internetservice-Reseller (der ihr den DSL-Dienst verkauft hatte) und der Telefongesellschaft (die die Kupferleitungen zu ihrem Haus besaß) auseinandersetzen.
Wer auch immer die Installation in ihrem Haus vorgenommen hatte, musste es vermasselt haben, denn nichts funktionierte – und als sie die beiden Firmen anrief, sagte man ihr jeweils, dass es in der Verantwortung der anderen läge, das Problem zu beseitigen. Manchmal konnten sie ein Ticket finden, das mit ihren früheren Gesprächen zusammenhing, manchmal nicht. Sie war in einer grausamen, gefühllosen, kafkaesken Bürokratie gefangen. Vier Wochen lang tat ihr großartiges DSL-Modem nichts, außer rot zu blinken. Es war so nutzlos wie ein Ziegelstein, und sie hatte unzählige offene Tickets bei beiden Firmen.
Eines Tages beschloss Maxine, einen ganzen Tag freizunehmen, nur um die Aktivierung ihrer DSL-Leitung in Angriff zu nehmen. Nach drei Stunden schaffte sie es endlich, sich am Telefon bis zu einem Supportmitarbeiter der Eskalationsstufe 3 hochzuarbeiten, der Zugang zu beiden Ticketing-Systemen hatte. Er war großartig, unglaublich versiert und in der Lage, Maxines Anfrage an die richtige Abteilung zu adressieren, wobei er die beiden Vorgesetzten der zwei Unternehmen mit den richtigen Schlüsselwörtern ans Telefon lockte, die dann alle notwendigen Arbeiten in die Wege leiteten. Eine Stunde später hatte sie ihre 64-KBit/s-Breitbandverbindung endlich in Betrieb.
Noch jetzt, Jahrzehnte später, erinnert sie sich daran, wie dankbar sie dieser Person war. Sie hatte ihm gesagt: »Ich würde gern jemandem Verantwortlichen in Ihrer Firma erzählen, welch hervorragende Unterstützung Sie geleistet haben und wie dankbar ich für Ihre Hilfe bin.« Zufrieden blieb sie noch zehn Minuten in der Warteschleife, um mit einem Vorgesetzten zu sprechen, und verbrachte dann weitere zehn Minuten damit, sich ausführlich über all die Hilfe zu äußern, die sie erhalten hatte.
Es war Maxine wichtig gewesen, zu beschreiben, wie außergewöhnlich und sogar heldenhaft sie diesen Supportmitarbeiter gefunden und wie sehr sie seine Hilfe geschätzt hatte. Maxine war erfreut zu hören, dass man ihn schon für eine Beförderung im Auge hatte und dass ihr Telefonanruf wahrscheinlich den endgültigen Ausschlag geben würde.
Danach verbrachte Maxine eine Stunde damit, das blinkende grüne Licht zu beobachten und die rasend schnellen Download-Geschwindigkeiten zu genießen.
Während sie an den cleveren Supportmitarbeiter zurückdenkt, erinnert sie sich daran, wie sehr sie Herausforderungen und das Lösen von Problemen liebt und wie wichtig ihre Arbeit ist. Ihre Ergebnisse werden allen Entwicklern helfen, produktiver zu werden.
Mit einem tiefen Atemzug beschwört sie den unerschütterlichen Optimismus herauf, der ihr nachgesagt wird, und scannt ihre E-Mails sorgfältig auf Statusänderungen ihrer Tickets. Sie ignoriert alle Aktualisierungen des Teamstatus und macht nur eine Ausnahme bei den Mails, in denen sich die Leute in GROSSBUCHSTABEN gegenseitig anschreien. Sie möchte wissen, wer genau diese Hitzköpfe sind, damit sie ihnen aus dem Weg gehen kann.
Maxine scrollt weiter, und ihr Herz schlägt höher, als sie die Betreffzeile sieht:
Benachrichtigung: Änderung zu Ticket #46132: Phoenix-Dev-Umgebung.
Ist ihre Entwicklungsumgebung endlich fertig?
Sie versucht, gelassen zu bleiben, um sich nicht wieder zu früh zu freuen. Gestern hat sie auch zwei Benachrichtigungen erhalten, aber es ging letztlich nur um unbedeutende Statusänderungen eines Tickets. Die erste war gekommen, als jemand das Ticket endlich zum ersten Mal geöffnet hatte, die zweite, als es jemand anderem zugewiesen wurde.
Maxine klickt auf den Link in der E-Mail, der in ihrem Browser den Verlauf des Tickets aufruft. Sie blinzelt und lehnt sich weiter vor Richtung Bildschirm. Sie hat das Ticket vor sechs Tagen angelegt (wenn sie das Wochenende mitzählt), und es gab sieben Statusänderungen, weil unterschiedliche Personen an ihrem Environment-Problem gearbeitet hatten. Seit heute Morgen um 8:07 Uhr ist das Ticket als geschlossen gekennzeichnet.
Sie johlt laut. Endlich sind die Leute von Ops fertig! Jetzt geht es mit den Builds los!
Aber sie ist verwirrt. Wo ist ihr Environment? Wie meldet sie sich an? Wie lautet die IP-Adresse? Wo sind die Zugangsdaten?
Sie blättert bis zum Ende der Notizen und Kommentare und liest, was die einzelnen Personen während der Arbeit an ihrem Ticket eingegeben haben. Es wurde von Bob an Sarah, an Terry, zurück an Sarah und schließlich an Derek weitergeleitet. Ganz unten in den Notizen schrieb Derek:
Um eine Dev-Umgebung zu erhalten, benötigen wir die Genehmigung Ihres Managers. Der korrekte Prozess ist unten dokumentiert. Ticket wird geschlossen.
Maxines Gesicht wird heiß und leuchtend rot.
Derek hat mein Ticket geschlossen?! Nach all dem Warten hat er mein Ticket einfach geschlossen, weil ich keine Genehmigung von einem Vorgesetzten hatte?
Wer zum Teufel ist Derek?!, schimpft Maxine innerlich.
Sie bewegt ihren Cursor über die Ticket-Maske und versucht, irgendetwas zu finden, das sie anklicken kann. Der einzige anklickbare Link ist jedoch das von Derek zur Verfügung gestellte Grundsatzdokument. Sie findet nicht heraus, wer Derek ist oder wie man ihn kontaktieren kann. Sie findet einen Button, um das Ticket wieder zu öffnen, aber er ist inaktiv.
Vielen Dank, Derek, du Scheißkerl, denkt Maxine zornig.
Voller Wut wird ihr klar, dass sie eine Pause braucht. Sie stürmt aus dem Gebäude und setzt sich auf eine Bank vor dem Büro, holt tief Luft, schließt die Augen und zählt bis 50. Dann geht sie zurück in ihr Büro und setzt sich an wieder an den Schreibtisch.
Sie klickt auf die Schaltfläche für ein neues Ticket. Als das leere Ticket mit den unzähligen Feldern, die ausgefüllt werden müssen, erscheint, gibt sie fast auf. Fast. Stattdessen zwingt sie sich zu lächeln und beschwört ihre freundlichste Seite herauf:
Hi Derek, vielen Dank für die Arbeit an der fehlenden Umgebung, die wir für das Phoenix-Projekt dringend benötigen – siehe Ticket #46132 (Link unten). Ich gehe davon aus, dass ich die Zustimmung meines Managers (Randy Keyes) in dieses Ticket einfügen kann? Ich werde Ihnen in den nächsten 30 Minuten eine E-Mail von Randy mit seiner Zustimmung schicken. Kann ich Sie anrufen, um sicherzustellen, dass dies heute bearbeitet wird?
Sie klickt auf Senden, schreibt eine kurze E-Mail an Randy, in der sie ihn bittet, die Einrichtung einer Dev-Umgebung zu genehmigen, und geht direkt zu seinem Arbeitsplatz. Sie ist erleichtert, dass er da ist und nicht in einer Sitzung. Sie sagt ihm, was sie braucht, und schaut ihm über die Schulter, während er eine Antwort sendet, die lediglich »Genehmigt« lautet.
Als sie wieder an ihren Schreibtisch zurückkehrt, hat sie ein Gefühl unerbittlicher Entschlossenheit und unnachgiebiger Fokussierung. Sie wird alles tun, was nötig ist, um ihre Dev-Umgebung zu bekommen. Sie setzt sich hin, kopiert Randys Genehmigung aus seiner E-Mail in das Servicedesk-Ticket und fügt folgende Notiz hinzu:
Derek, vielen Dank. Hier ist die Zustimmung meines Vorgesetzten. Kann ich die Umgebung heute noch bekommen?
Sie klickt auf Senden.
Sie ruft das Firmentelefonbuch auf und sucht nach allen Dereks der IT-Abteilung. Es gibt drei. Derjenige im Helpdesk scheint der vielversprechendste zu sein.
Sie schreibt ihm eine nette, freundliche Nachricht mit Randy in Cc:, um ihm im Voraus für all seine Hilfe zu danken und um ihn wissen zu lassen, wie dankbar sie erst sein wird, wenn sie endlich Phoenix-Builds machen könne. Sie bittet ihn praktisch darum, ihr Ticket nicht ganz unten in die Warteschlange zu stellen, wo die Bearbeitung noch eine weitere Woche dauern wird.
Sie schickt sie ab. Fünf Sekunden später:
Dies ist eine automatische Antwort – bitte reichen Sie alle Serviceaufgaben über das Servicedesk ein. Ich bemühe mich, alle meine E-Mails innerhalb von 72 Stunden zu lesen und zu beantworten. Wenn dies ein Notfall ist, rufen Sie bitte diese Nummer an …
Sie flucht. Sie stellt sich vor, dass Derek die Beine auf seinen Schreibtisch gelegt hat und sie in ihrem Elend auslacht. Sie druckt alles aus, was mit Ticket #46132, ihren E-Mails und den Namen der drei Dereks zusammenhängt, und schaut nach, wo jeder von ihnen sitzt. Der Helpdesk-Derek arbeitet zwei Gebäude weiter, Untergeschoss.
Sie tritt auf Dereks Etage aus dem Aufzug und sieht Reihen kleiner Kabinen voller Menschen, die mit Kopfhörern vor ihren PCs sitzen. Es gibt keine Fenster. Die Decke ist überraschend niedrig. Sie kann das elektrische Summen von Leuchtstoffröhren hören. Es ist seltsam ruhig. Es sollten mehr Ventilatoren laufen, damit es nicht so abgestanden riecht, denkt sie sich. Sie hört einige Leute tippen, andere telefonieren höflich mit jemandem.
Als sie das alles sieht, fühlt sie sich plötzlich sehr, sehr schuldig wegen ihrer Wut auf Derek. Sie fragt nach, wo er sitzt. Suchend durch das Labyrinth der Cubicles wandernd, sieht sie schließlich Dereks Namensschild, das aus einem Tintenstrahldrucker mit zu wenig Tinte stammt. Dann sieht sie Derek.
Er ist keineswegs ein abgebrühter Bürokrat. In Wirklichkeit ist er Anfang 20, scheinbar asiatischer Herkunft und liest mit einem bemerkenswert ernsten Ausdruck etwas auf einem kleinen LCD-Bildschirm. Maxine hat schon mit Laptops gearbeitet, die größere Bildschirme hatten als dieser Budget-PC. Sie fühlt sich noch schlechter wegen all der bösen Dinge, die sie über ihn gedacht hat.
Es gibt keine zusätzlichen Stühle, also kniet sich Maxine neben ihn hin. »Hallo, Derek«, sagt sie mit ihrer freundlichsten Stimme. »Ich bin Maxine. Ich habe letzte Woche das Ticket über die Dev-Umgebung eingereicht. Sie haben es heute Morgen geschlossen, weil ich keine Genehmigung meines Vorgesetzten hatte. Ich habe sie gerade erst bekommen. Und weil Sie das Ticket geschlossen haben, musste ich ein neues öffnen. Vielleicht können Sie mir helfen, es irgendwie durch das System zu lotsen?«
»Oh, mein Gott, tut mir leid, dass ich das Ticket geschlossen habe. Das ist alles neu für mich!« Derek antwortet ernsthaft, offensichtlich verzweifelt, dass er es vielleicht vermasselt hat. »Meine Aufgabe lautet bloß, dafür zu sorgen, dass bestimmte Anträge, die einer Genehmigung bedürfen, diese auch erhalten. Ich kann Tickets nicht erneut öffnen. Das kann nur ein Supervisor. Und alle neuen Tickets landen in der Warteschlange, wo sie dem nächsten verfügbaren Mitarbeiter zugewiesen werden. Vielleicht kann meine Vorgesetzte helfen?«
Maxine sackt in sich zusammen, weil sie ahnt, was ihr droht. Aber als sie sich in dem Meer von Menschen um sie herum umsieht, wird ihr klar, dass sie ihre Dev-Umgebung niemals bekommen wird, wenn sie das jetzt nicht endgültig klärt.
»Auf jeden Fall. Das wäre wunderbar, Derek.« Er lächelt, und sie steuern auf eines der Außenbüros zu.
Während der nächsten 15 Minuten beobachtet Maxine, wie Dereks Vorgesetzte fachkundig durch die umfangreiche Ticket-Historie navigiert. Obwohl Maxine gerade erst zu ihrer Suche nach Derek aufgebrochen ist, hat bereits jemand namens Samantha ihr neues Ticket geschlossen und darauf hingewiesen, dass im Feld »Anmerkungen« keine Genehmigungen eingereicht werden können.
Maxine zwingt sich dazu, ruhig zu bleiben. Diese Leute versuchen, ihr zu helfen. Die Vorgesetzte entschuldigt sich und beteuert, wie unangenehm ihr das alles sei. Sie legt die beiden Tickets von Maxine zusammen, setzt Randys Namen in das Genehmigungsfeld und reicht das Ticket erneut ein. »Jetzt muss Randy nur noch einen Knopf im Helpdesk-Tool drücken, und schon kann es losgehen! Es tut uns leid, dass wir Anfragen nicht wirklich autorisieren können – nur ausgewählte Manager können das.«
»Kann er es jetzt per Telefon genehmigen?«, fragt sie mit erzwungener Heiterkeit. Offenbar nicht – die Helpdesk-Software wurde geschrieben, bevor es Smartphones gab und die Mobiltelefone wahrscheinlich noch so groß wie Koffer waren und nur sieben LED-Ziffern anzeigen konnten.
Maxine seufzt, aber sie bedankt sich überschwänglich, weil sie spürt, dass sie ihrem Ziel ganz nahe ist. Als sie sich umdreht, um zu gehen, fragt Derek zaghaft: »Stört es Sie, wenn ich eine dumme Frage stelle?«
»Kein Problem. Es gibt keine dummen Fragen. Schießen Sie los!«, lächelt sie und versucht, dabei nicht ungeduldig zu wirken.
»Was ist eine Dev-Umgebung? Ich habe mich mit Laptop-Problemen, Passwortrücksetzungen und solchen Dingen beschäftigt. Aber ich habe noch nie von einer ›Umgebung‹ gehört.«
Und da ist sie endlich, denkt Maxine, ordentlich beschämt. Die Wochenlektion über Geduld, Freundlichkeit und Einfühlungsvermögen, die Ihnen von Derek und der Helpdesk-Abteilung präsentiert wird.
Maxine ist stolz darauf, dass sie sich den Ruf erworben hat, ein besonnener und mitfühlender Mensch zu sein. Aber im Moment hat sie das Gefühl, dass sie nichts von all diesen Dingen zeigen kann. Macht ihre Zugehörigkeit zum Phoenix-Projekt sie zu einem schlechteren Menschen?
Ihr wird klar, wie fehlgeleitet ihr Zorn auf Derek war. Dieser arme Kerl hatte nichts gegen sie, bloß weil sie eine Entwicklerin war. Er wusste nicht einmal, wonach sie gefragt hatte, geschweige denn, wie wichtig es war. In seiner Unerfahrenheit hat er lediglich ihr Ticket geschlossen, weil er sich an die festgelegten Regeln hält. Er hat nur versucht, seine Arbeit so gut zu machen, wie es ihm aufgetragen worden war.
Maxine kehrt zwei Stunden später an ihren Schreibtisch zurück. Sie hatte Derek und seine Vorgesetzte zum Mittagessen eingeladen, um sich für ihre Hilfe zu bedanken und Abbitte für ihre schlimmen Gedanken über Derek zu leisten. Sie hatte die Chance bekommen, ihm die Welt der Entwicklung zu erklären, und seine aufrichtige Neugier war ansteckend. Sie beschrieb all die aufregenden Karrieremöglichkeiten, die es für technische Mitarbeiter außerhalb des Helpdesks gibt in der Hoffnung, das könne ihn dazu ermutigen, einige dieser Optionen zu erkunden.
Sie geht zu Randy, um sicherzustellen, dass er ihre Anfrage bewilligt. Er ist nicht an seinem Schreibtisch. Sie ruft ihn sofort von ihrem Handy aus an.
»Ich kann es erst genehmigen, wenn ich wieder an meinem Schreibtisch bin«, erklärt Randy ihr. »Ich verspreche hoch und heilig, dass ich die Genehmigung sofort erteile, sobald ich aus den Meetings raus bin. Das geht vor fünf Uhr klar.«
Maxine kehrt an ihren Schreibtisch zurück und fühlt sich hin- und hergerissen. Sie weiß um die Notwendigkeit automatisierter Workflows. In der Fertigung kontrollieren die von ihr geschriebenen MRP-Systeme alles, was Tausende von Menschen den ganzen Tag lang tun. Man kann ohne streng geregelte Arbeitsabläufe keine Produkte in großen Stückzahlen herstellen, die Tausende von Dollar kosten.
Und Helpdesk-Prozesse, egal ob hier bei Parts Unlimited oder bei den Firmen, die damals ihr DSL-Modem installieren sollten, ermöglichen einen konsistenten Kundenservice, selbst wenn dieser durch Tausende unterschiedlicher Callcenter-Mitarbeiter erbracht wird.
Warum also fühlt sich unser eigenes Ticketing-System so schrecklich an? Wir sind alle Teil von Parts Unlimited, warum also wirkt es so, als hätte man es mit einer seelenlosen Regierungsbürokratie oder einem gelangweilten Verkäufer zu tun? Maxine grübelt. Vielleicht liegt es daran, dass wir, wenn wir unseren Freunden einen Gefallen tun, von ihnen normalerweise nicht verlangen, dass sie zuerst ein Ticket öffnen.
Am nächsten Tag sieht Maxine, dass Randy sein Versprechen gehalten und das Ticket bezüglich des Dev-Environments bestätigt hat. Leider zu spät, als dass noch jemand mit der Umsetzung hätte beginnen können.
Trotz dieses Durchbruchs wartet Maxine also noch immer auf ihre Entwicklungsumgebung. Enttäuscht wandert sie ziellos von Meeting zu Meeting, weil sie nicht untätig an ihrem Schreibtisch sitzen will.
Während sie in der Küche Zeit totschlägt und auf eine weitere Tasse Kaffee wartet, summt ihr Telefon. Bildschirm für Bildschirm erscheinen E-Mail-Benachrichtigungen über Änderungen an Ticket #46132: eine Anforderung einer virtuellen Maschine durch die Distributed Systems Group, von Storage durch eine andere Gruppe und einer IP-Adresse durch eine weitere, eines Netzwerk-Mountpoints durch noch eine, und für Anwendungsinstallationen durch drei weitere Gruppen …
Maxine schreit vor Freude – endlich! Der Weihnachtsmann hat gerade seine magische Elfenarmee mobilisiert, damit endlich ihre so dringend benötigte Dev-Umgebung eingerichtet wird. Endlich kommt die Kavallerie!
Beschwingt liest sie die ganzen Ticket-Änderungen. Eine ganze Menge Arbeit wird an scheinbar die gesamte Ops-Abteilung verteilt. Maxine ist plötzlich beunruhigt darüber, wie viele Menschen erforderlich sind, um ein Environment einzurichten.
Sie arbeitet gerade wieder an ihrem Schreibtisch und plant, was sie in ihrer Dev-Umgebung als Erstes tun wird, als ihr Telefon beginnt, ununterbrochen zu vibrieren. Beim Öffnen ihrer E-Mails fällt ihr die Kinnlade runter, als sie die 40 Benachrichtigungen in ihrem Posteingang sieht. Oben auf ihrem Bildschirm erkennt sie eine Flut von neuen Meldungen, die alle ihre Tickets als geschlossen markieren. »Nein, nein, nein«, stöhnt sie und beginnt, die gesamte Ticket-Historie durchzugehen. Sie sieht, dass die Benutzerkonten erstellt und die Einhängepunkte konfiguriert wurden, aber dann findet sie eine Nachricht von einem der Storage-Admins:
Es tut mir leid, dass ich Ihr Ticket schließen muss. Ob Sie es glauben oder nicht, seit drei Monaten können wir keinen neuen Speicherplatz anbieten. Die nächste Bestellung von weiterem Speicherplatz wird nicht vor Januar erfolgen, und zudem sind alle Controller bereits vollständig ausgelastet. Die Einkaufsabteilung beschränkt uns auf zwei Bestellungen pro Jahr, um bei unseren Lieferanten die besten Mengenrabatte zu erhalten. Sie stehen aber fast an der Spitze der Liste, deshalb können wir die Bereitstellung für Februar einplanen.
Maxine traut ihren Augen kaum.
Es ist September.
Phoenix ist das wichtigste Projekt im gesamten Unternehmen. Dafür wurden in den letzten drei Jahren 20 Millionen Dollar ausgegeben. Und nun sitzt sie hier, versucht zu helfen, und es sind noch nicht einmal 5.000 Dollar für mehr Speicherkapazität da. Und sie soll weitere fünf Monate lang auf ihre Dev-Umgebung warten! Sie vergräbt ihren Kopf in den Händen und schreit still ihren Frust heraus.
Völlig niedergeschlagen macht sie einen Spaziergang – ohne bestimmtes Ziel. Es ist 14.30 Uhr. Keines der Meetings in ihrem Kalender scheint ihr noch von Interesse zu sein. Da sind überall nur Leute, die sich übers Warten beschweren. Warten auf etwas. Warten auf jemanden. Alle warten einfach nur. Und sie will sich im Moment einfach nicht daran beteiligen.
Sie kehrt zu ihrem Schreibtisch zurück, packt Jacke und Laptop-Tasche und beschließt zu gehen. Sie weiß nicht, wohin, aber sie kann einfach nicht länger bleiben.
Erst als sie schon in ihrem Auto am Steuer sitzt, entscheidet sie sich, zur früheren Schule ihrer Kinder zu fahren. Zum Glück sind ihre Kinder bereits an einer weiterführenden Schule – und sowieso in einem Alter, in dem sie nicht mehr mit ihren Eltern gesehen werden wollen. Nein, sie will in die Grundschule, in der sich die Fünft- und Sechstklässler zu außerschulischen Aktivitäten treffen. Sie ist stolz darauf, dass sie dem Kollegium vor drei Jahren geholfen hat, einen sehr beliebten Programmier-Club zu gründen. Und sie freut sich, dass sich so viele Schülerinnen und Schüler gefunden haben, die schon vor der weiterführenden Schule Spaß an Wissenschaft, Technik, Ingenieurwesen und Mathematik haben.
Maxine ist der Ansicht, dass das Erlernen solcher Fähigkeiten unglaublich wichtig ist, denn Programmieren wird vermutlich im nächsten Jahrzehnt in den meisten Berufen benötigt werden und nicht mehr nur auf Entwickler beschränkt sein.
Sie kommt in das Klassenzimmer und erkennt sofort Maia und Paige, zwei der Kinder, mit denen sie am liebsten arbeitet. Die beiden sind beste Freundinnen, aber gleichzeitig auch ernste Konkurrentinnen, manchmal gar Erzrivalinnen. Beide sind smart, ehrgeizig und besitzen eine besondere Gabe, Probleme zu lösen.
Es ist das erste Mal in diesem Schuljahr, dass Maxine die Schule besucht. Sie ist überrascht, wie viel älter die Kinder wirken und wie fortgeschritten ihre Programmierkenntnisse sind. Einige schreiben anscheinend Spiele in JavaScript, andere arbeiten an Webservern und zwei der Schüler an Smartphone-Apps.
Die nächste Stunde verbringt sie damit, sich zeigen zu lassen, woran die einzelnen Gruppen arbeiten, und sich an den Ergebnissen zu erfreuen, die ihr präsentiert werden. Sie liebt es, wenn die Kinder ihr Fragen stellen. Als Maia und Paige sie bitten, bei der Lösung eines Problems zu helfen, zieht sie sich schnell einen Stuhl heran.
Die beiden versuchen, eine anspruchsvolle Aufgabe zu beenden, bei der der Mittelwert, der Modalwert und die Interquartilsabstände einer Reihe von Zahlen in Python berechnet werden sollen. Sie sieht sofort, dass die Kinder immer wieder den gleichen Einrückungsfehler gemacht haben.
Wenn sie versuchen, ihr Programm auszuführen, beschwert sich der Python-Parser an diesen Stellen natürlich. Sie haben sich ziemlich bemüht, herauszufinden, was genau sie falsch gemacht haben, und alles versucht, um die Fehler zu beseitigen.
»Darf ich einen Vorschlag machen?«, beginnt Maxine, aktiver mitzuwirken.
»Natürlich, Mrs. Chambers«, stimmt Maia zu. Maxine seufzt, immer noch nicht sicher, wie sie von Teenagern angesprochen werden will.
Maxine erklärt ihnen, wie die Einrückung bei Python funktioniert und inwiefern sich Python von den meisten anderen Programmiersprachen unterscheidet. »Aber egal, welche Sprache ihr verwendet, das Wichtigste ist, euer Programm immer wieder laufen zu lassen«, sagt sie. »Wenn ich etwas zum ersten Mal mache, lasse ich mein Programm jedes Mal laufen, wenn ich irgendetwas geändert habe, um sicherzugehen, dass es sich noch kompilieren und ausführen lässt. Auf diese Weise baue ich nicht stundenlang immer wieder den gleichen Fehler ein, ohne dass ich es merke. Es ist besser, den Fehler direkt beim ersten Mal abzufangen, oder?«
Sie zeigt den Kindern, wie sie einige der Einrückungen korrigieren können. »Mal sehen, ob das den ersten Fehler behebt …«
Sie checkt die Schaltflächen im Editor. »Es sieht so aus, als ließe sich euer Programm einfach durch Drücken von Strg+Enter ausführen. Ah, es sieht so aus, als ob noch eine kleine Änderung nötig wäre. Jepp, den ersten Fehler habt ihr jetzt behoben. Behebt nun nach und nach die weiteren Fehler, bis ihr wieder einen funktionierenden Zustand habt. Wenn ihr alles nach jeder kleinen Änderung überprüft, werdet ihr niemals etwas wirklich Großes reparieren müssen …«
Ihren eigenen Worten nachsinnend, ergänzt sie: »Wenn man sein Programm häufig laufen lässt, kann man sich auch immer wieder selbst über das freuen, was man geschaffen hat, und genau um diese Freude geht es beim Programmieren.«
Die Mädchen lächeln verständig und merzen die restlichen Fehler in schneller Folge aus. Maxine schmunzelt, als die beiden die Tastaturkürzel benutzen, die sie ihnen gezeigt hat.
Die Mädchen freuen sich, weil ihr Programm jetzt tatsächlich läuft. Als Maia die Ergebnisse betrachtet, stellt sie fest, dass etwas nicht in Ordnung zu sein scheint. Ihr errechneter Durchschnitt ist eindeutig falsch.
»Hmm … ich denke, das ist ein Off-by-one-Fehler«, sagt Maxine. »Das ist einer der am häufigsten vorkommenden Fehler, die Programmierer machen. Das passiert oft, wenn dabei Elemente eines Arrays in einer Schleife durchlaufen und wir dabei falsch berechnen, welches Element das letzte ist. Genau das passiert hier: Wir haben das letzte Element übersehen – und ob ihr es glaubt oder nicht, wenn ihr versehentlich ein Element zu viel verarbeitet, kann das Programm abstürzen oder schlimmstenfalls sogar von einem Hacker missbraucht werden.«
Maxine lächelt die ganze Zeit vor sich hin. Sie freut sich ungemein, ihr Wissen teilen zu können, weil sie über die Jahrzehnte gelernt hat, dass Zustandsveränderungen und die Verwendung von Schleifen sehr, sehr gefährlich und schwierig zu korrigieren sind. Der Absturz des ODBC-Datenbanktreibers, den sie vor einem Jahrzehnt mitten in der Nacht gefixt hatte und durch den sie zu einer Art Legende geworden war, ging auf diese Art von Problem zurück.
Deshalb engagiert sich Maxine so sehr für die Anwendung funktionaler Programmierprinzipien. Das Erlernen von Clojure, ihrer Lieblingsprogrammiersprache, war das Schwierigste, was sie je getan hat, da ihr Clojure völlig die Fähigkeit nahm, Variablen zu ändern oder zu mutieren. Zweifellos war dies eine ihrer lohnendsten Lektionen, denn sie stellte fest, dass etwa 95 Prozent der Fehler, die sie früher gemacht hatte (wie die, mit denen die Mädchen zu kämpfen hatten), völlig verschwunden waren.
Funktionale Programmierung ist wirklich ein hervorragendes Denkwerkzeug.
»Wollt ihr etwas Cooles sehen?«, fragt Maxine die Mädchen. Als sie nicken, sagt sie: »Ich würde Folgendes tun. Es sieht ein wenig seltsam aus, aber man kann Schleifen ganz loswerden, indem man Iteratoren verwendet – eine einfachere und viel sicherere Art, eine Schleife zu schreiben.«
Sie scannt die Python-Dokumentation, die sie im Internet findet, tippt eine Zeile Code in ihren Editor ein, drückt ein paarmal auf Strg+Enter und landet bei der richtigen Antwort.
»Voilà! Seht euch das an. Es macht dasselbe wie der Code, den ihr geschrieben habt, aber ohne Schleifen oder bedingte Logik wie in der Prüfung auf das Array-Ende. Tatsächlich ist es nur eine einzige Codezeile ohne die Gefahr, einen Off-by-one-Fehler einzubauen«, sagt sie und ist stolz auf das, was sie gerade geschrieben hat.
Maxine wird mit »Ohs« und »Ahs« belohnt, und die Mädchen bekommen große Augen, als Maxine ihnen die Lösung zeigt. Sie ist zufrieden, denn diese kleine Übung hat ein wenig überflüssige Komplexität aus der Welt verbannt. Dies könnte die Mädchen vor jahrzehntelanger Frustration bewahren und die Welt etwas sicherer machen.
Die nächste Stunde verbringt sie damit, zwischen den Teams hin- und herzupendeln, den Kindern beim Lösen von Problemen zuzuschauen und ihnen hier und da kleine Tricks beizubringen, um sie produktiver zu machen und zu erfreuen. Als die Kinder schließlich ihre riesigen, schweren Rucksäcke packen, merkt Maxine, in welch guter Stimmung sie ist.
Es ist ihr eine große Freude, anderen Menschen, die gern lernen wollen, etwas beizubringen. Außerdem sind es wirklich großartige Kinder. Sie denkt darüber nach, wie einfach hier alles ist. Du drückst Strg+Enter, und das Programm wird kompiliert und ausgeführt. Wenn es einen Fehler gibt, behebst du ihn, drückst eine Taste und versuchst es erneut.
In ihrer derzeitigen Arbeit ist das absolute Gegenteil der Fall. Sie kann noch immer nicht mal einen Teil-Build des Phoenix-Systems durchführen. Irgendwie gehören Builds nicht mehr zur allgemeinen täglichen Arbeit.
Maia und Paige haben eine halbe Stunde lang den gleichen Einrückungsfehler gemacht. Bei Parts Unlimited gibt es wahrscheinlich 100 Entwickler, die größere Fehler machen – und es wird Monate dauern, bis sie überhaupt merken, dass sie sie eingebaut haben.
Die Kinder winken Maxine zum Abschied und danken ihr für ihre Hilfe. Sie steigt in ihr Auto und lässt sich auf den Sitz fallen. Zu ihrer Überraschung ist sie traurig und entmutigt – in ihrer Arbeit findet sie nichts von der Freude am Lernen, die sie hier gerade erlebt hat. Sie fragt sich, ob sich wohl alle am Phoenix-Projekt Beteiligten immer so fühlen wie sie jetzt.
Maxine will gerade ihr Auto starten, als ihr Telefon vibriert. Es ist eine Textnachricht von einem ihrer Kollegen bei einem Open-Source-Projekt für eine persönliche Aufgabenverwaltung, das sie geschrieben hat. Sie hat dieses Projekt vor über fünf Jahren begonnen, um endlich richtig gute Arbeitstagebücher führen zu können. Sie hat schon immer wie besessen Protokoll darüber geführt, womit sie ihre Zeit verbringt.
Anfangs war es nur dazu gedacht, ihr dabei zu helfen, produktiver zu werden und die eingehenden Aufgaben aus E-Mails, Trello, Slack, Twitter, Leselisten und einer Fantastilliarde anderer Quellen, aus denen Arbeit strömt, vorzusortieren. Mit ihrer Anwendung kann sie Aufgaben leicht zu GitHub, JIRA, Trello und in die vielen anderen Tools weiterleiten, über die sie mit anderen Menschen und Teams interagiert.
Seit Jahren setzt sie dieses Programm täglich ein, um einen großen Teil ihres beruflichen und privaten Lebens zu organisieren. Sie verwaltet alle ihre Aufgaben darin. Es ist ihre Master-Inbox, in der sie ihre gesamten Tasks sehen und die Arbeit zwischen den verschiedenen Systemen verschieben kann, mit denen sie arbeitet.
Viele andere Menschen nutzen ebenfalls diese Anwendung, und einige Nutzer wiederum haben Schnittstellen zu anderen Tools geschrieben, die sie einsetzen. Sie wundert sich immer wieder darüber, dass täglich Tausende von Menschen auf der ganzen Welt ihre Anwendung benutzen und mehr als 20 Personen aktiv am Code mitwirken.
Sie schaut sich die Nachricht mit dem neuen Pull-Request an – jemand hat für den Task-Manager eine weitere Schnittstelle geschrieben. Die vorgeschlagene Änderung sieht fantastisch aus. Etwas, das sie schon seit Jahren einbauen wollte. Die Änderung ist ziemlich clever, und sie stimmt der Art und Weise zu, wie die automatisierten Tests geschrieben wurden, die beweisen, dass die Änderung keine negativen Auswirkungen hat. Der Vorschlag ist gut dokumentiert und nachvollziehbar erklärt. Sie begrüßt, dass der kurze Text als eine Art Tutorial formuliert wurde, sodass andere etwas Ähnliches umsetzen können.
Sie freut sich über den Einfallsreichtum anderer Menschen und deren Bereitschaft, die Anwendung weiter zu verbessern. Als Ownerin des Projekts sieht sie es als ihre Hauptverantwortung an, dafür zu sorgen, dass alle Mitwirkenden produktiv daran arbeiten können.
Vor ein paar Jahren gab es über 20 aktive Pull-Requests, aber aus unterschiedlichsten Gründen konnte sie sie nicht zusammenführen – manchmal widersprachen sich die Änderungen, manchmal konnte die API nicht ganz das leisten, was benötigt wurde. Sie weiß, wie entmutigend es sein kann, wenn man eine Änderung für ein Projekt einreicht und niemand den Vorschlag anschaut oder man gesagt bekommt, dass er nicht integriert werden kann. Wenn das zu häufig geschieht, geben die Leute schließlich auf oder forken das Projekt und spalten die Community.
Als das auch ihrem Projekt drohte, verbrachte sie wochenlang jeden Abend damit, ihre Systemarchitektur so zu überarbeiten, dass alle Mitwirkenden die gewünschten Änderungen schnell, einfach und sicher vornehmen konnten. Das war mühsam, und sie hat persönlich jeden Pull-Request umgeschrieben, damit die Mitstreiter ihre Arbeit nicht wiederholen mussten. Aber alle waren froh und dankbar, als ihre Änderungsvorschläge es ins Projekt schafften – aber nicht annähernd so froh wie Maxine.
Maxine ist sich darüber im Klaren, dass es Agilität nicht umsonst gibt. Ohne diese Art von Aufwand wird es mit der Zeit immer schwieriger, Software zu ändern. Es gibt Ausnahmen, z. B. Bibliotheken für Fließkommaberechnungen, die sich seit 40 Jahren nicht geändert haben – die sich aber auch nicht zu ändern brauchen, weil sich die Mathematik selbst ja nicht ändert.
Aber in fast allen anderen Bereichen, insbesondere wenn man mit Kunden zu tun hat, ist Wandel eine Konstante des Lebens. Ein »gesundes« Softwaresystem ist ein System, das man mit der erforderlichen Geschwindigkeit ändern kann und bei dem andere Personen leicht Beiträge einbringen können, ohne sich übermäßig verrenken zu müssen. So kreiert man Projekte, die Spaß machen und bei denen es sich lohnt, mitzuarbeiten – und bei denen man oft die lebendigsten Communitys findet.
Sie fährt nach Hause und freut sich, dass ihr Mann sich bereits um das Abendessen gekümmert hat. Sie berichtet ihren Kindern von ihrer spontanen Entscheidung, ihre alte Schule zu besuchen, und von der jüngsten Geek-Generation.
Als sich ihre Sprösslinge verkriechen, um ihre Hausaufgaben zu machen, schnappt sie sich ihren Laptop und ruft erneut den jüngsten Pull-Request auf. Sie zieht sich den neuen Code, loggt sich ein und klickt etwas herum, um einige Grenzfälle zu testen und sicherzustellen, dass der Kollege die Details im Griff hat.
Mit einem zufriedenen Lächeln ruft sie den Pull-Request in ihrem Browser auf und klickt auf eine Schaltfläche, um den Request in die Codebasis zu mergen. Sie schreibt dem Einreicher ein kurzes Dankeschön und beglückwünscht ihn zu seiner cleveren Idee und Initiative.
Als sie gerade auf Senden klicken will, bemerkt sie noch etwas, das der Kollege geschrieben hat: »Maxine, ich würde eine Riesenparty schmeißen, falls immer dann eine Desktopbenachrichtigung angezeigt werden könnte, wenn jemand diese Eigenschaft ändert …«
Gute Idee, findet sie. Sie öffnet ihren Codeeditor und versucht in den nächsten 15 Minuten, den Vorschlag umzusetzen. Als es gleich beim ersten Mal funktioniert, lacht sie laut und applaudiert sich mit fröhlichem Selbstlob selbst. Sie ist in bester Stimmung. Dank all dieser Wunder der Technologie kann man mit wenig Aufwand wirklich viel erreichen.
Sie setzt ihre Nachricht an den Einreicher fort:
Nochmals, wirklich gute Arbeit. Ich bin sicher, dass es allen so gut gefallen wird wie mir. Danke! (Und ich habe gerade die Benachrichtigungsfunktion hinzugefügt. Dein Angebot, eine Party für mich zu schmeißen, nehme ich gerne an.)
Als sie auf Senden klickt, fragt sie sich, ob das Universum ihr eine Nachricht schicken will. Zuerst ihr Nachmittag mit den Schülern und dann die Leichtigkeit, mit der sie ihrer Anwendung (die um Jahre älter ist als das Phoenix-Projekt) gerade ein neues Feature hinzugefügt hat, haben ihr wieder gezeigt, wie sich Programmieren anfühlen sollte.
Sie kann voller Konzentration mit Flow und Freude Dinge umsetzen. Sie hat schnelles Feedback zu ihrer Arbeit bekommen. Andere Menschen konnten etwas beisteuern, ohne von einer Vielzahl weiterer Personen abhängig zu sein. Das ist es, was eine gute Architektur ermöglicht. Sie wurde in das strategisch wichtigste Projekt des Unternehmens verbannt, von dem das Überleben der ganzen Firma abhängt. Und dennoch sind Hunderte von Entwicklern wie gelähmt und nicht in der Lage zu tun, was getan werden muss.
In diesem Moment beschließt Maxine, dass sie diesen Grad an Produktivität, den sie für die Schüler und ihr Open-Source-Projekt ermöglicht hat, auch ins Phoenix-Projekt bringen muss, selbst wenn das für sie kurzfristig persönliche Opfer bedeutet.
