Pressestimmen
iX, Februar 2008
Kurzbeschreibung
Buchrückseite
Über den Autor
Auszug aus Adrenalin-Junkies und Formular-Zombies - Typisches Verhalten in Projekten von Tom DeMarco, Peter Hruschka, Timothy Lister. Copyright © 2007. Abdruck erfolgt mit freundlicher Genehmigung der Rechteinhaber. Alle Rechte vorbehalten.
Abstraktionsvermögen ist eine Fähigkeit, über die nur der Mensch verfügt. Wir nutzen diese Fähigkeit jeden Tag, in jeder wachen Stunde. Aber das war nicht immer so. Irgendwann in unserer Vorgeschichte muss es ein allererstes Mal gegeben haben, einen Moment, in dem ein früher Vormensch etwas vage Vertrautes anstarrte und in einem Geistesblitz erkannte: "Hoppla! Da ist das Dingsbums wieder!" Das war die erste Abstraktion. Von diesem Moment an war alles anders. Der Mensch wurde auf die Erde losgelassen. Abstraktion ist eine grundlegende menschliche Fähigkeit. Ganz im Gegensatz zur Mustererkennung - diese Fähigkeit besitzt der Mensch nicht alleine. Die Maus hat herausgefunden, wann die Katze wahrscheinlich schläft, wann die Menschen sich nicht mehr in der Küche befinden und wann die Brotkrümel heruntergefallen sind, aber noch nicht weggefegt wurden. Ihr Hund kennt alle Signale, auch die, die dem Wochenendausflug vorausgehen, der Ihrer Meinung nach völlig überraschend kommen sollte. (Kann es der Koffer gewesen sein?) Und der Waschbär aus der Nachbarschaft weiß ganz genau, dass er bei Ebbe die besseren Häppchen natürlich am Strand findet und nicht in Ihrem Komposthaufen. Aber trotz ihrer Fähigkeit zur Mustererkennung sind Maus, Hund und Waschbär zu einer Sache nicht in der Lage: zu einer Beobachtung der Art "Hoppla! Da ist das Dingsbums wieder!" Dazu bedarf es der Abstraktion.
Der entscheidende Unterschied besteht darin, auf welche Weise das Wesent-liche erfasst wird. Muster werden mit der Zeit aufgenommen und verfeinert, in den hintersten, nonverbalen Winkeln Ihres Gedächtnisses abgelegt und in Form von Gefühlen oder Ahnungen wieder hervorgeholt. Die Ahnung, dass der Ballführende vorhat, links vorbei zu spielen, oder dass Ihr Gatte oder Ihre Gattin jeden Moment vor Wut explodieren wird, ist das Ergebnis erlernter Muster aus der Vergangenheit. Dasselbe gilt für das Gefühl, dass es auf dem Projekttreffen diese Woche strittig zugehen wird. Das unausgesprochene Muster kann für Sie nützlich sein - es hat eindeutig einen Wert für das Über-leben -, aber Sie können diesen Wert merklich steigern, indem Sie darüber nachdenken und damit beginnen, erklärbare Beobachtungen daraus abzulei-ten. Was hatten die wenigen streitbaren Treffen in den letzten Jahren gemein-sam? Nun, meistens waren es die Treffen, an denen der Chef vom Chef teil-nahm, insbesondere, wenn sie zum Quartalsende hin stattfanden. Und am schlimmsten war es, als eine neuerliche Verzögerung zur Sprache kam. Sie fassen diese Erfahrungen in folgendem Muster zusammen: "Mein Chef wird wahrscheinlich extrem gereizt sein, wenn er auf einem Treffen zum Quartals-ende hin in Anwesenheit seines Chefs von einer Verzögerung erfährt." Die erkannten Signale, die zu dieser Beobachtung führten, sind nach wie vor in Ihrem Unbewussten verborgen und können immer noch gelegentliche Ah-nungen hervorrufen. Aber nun haben Sie - durch eine vorübergehende Ver-bindung zwischen der Ahnung der rechten Gehirnhälfte und der Artikulati-onsfähigkeit der linken Gehirnhälfte - die Essenz freigelegt und in Worte ge-fasst. Sie können sie aufschreiben, Tests formulieren, um ihre Gültigkeit zu überprüfen, sie mit anderen teilen, Ihre Beobachtungen mit denen Ihrer Kol-legen verknüpfen.
Die meisten Menschen, die Projektarbeit leisten, sind ziemlich gut darin, Muster zu erkennen und daraus Ahnungen abzuleiten ("Ich spüre, dass dieses Projekt in ein Desaster münden wird"), aber weniger gut darin, die Muster zu abstrahieren und in eine nützlichere Form zu bringen. Daher dieses Buch. Wir sechs Autoren haben unsere Köpfe zusammengesteckt, um die Muster in Worte zu fassen, die wir uns im Laufe unserer vereinten 150 Jahre an Erfah-rung einverleibt haben.
Die Form eines Buches macht es notwendig, dass eine Seite entweder vor oder nach einer anderen kommen muss. Für die Muster selbst gibt es aber keine natürliche Reihenfolge. Wir haben sie nach unserem Geschmack ge-ordnet und uns dabei bemüht, von der ersten bis zur letzten Seite für ein größtmögliches Lesevergnügen zu sorgen.
Ein warnender Hinweis vorweg: Wir behaupten nicht, dass die von uns beo-bachteten Muster allgemeingültig sind. Sie treffen garantiert nicht überall zu. Ein bestimmtes Muster kann auf Ihr Unternehmen zutreffen - oder auch nicht. Falls es zutrifft, hoffen wir, dass wir Ihnen damit einen Denkansatz an die Hand geben können, der andernfalls nur ein vages Gefühl von den Din-gen bliebe, die um Sie herum geschehen.
Beim Schreiben dieses Buches waren wir uns immer bewusst, dass wir in der tiefen Schuld des Architekten und Philosophen Christopher Alexander und seines Buches "Eine Muster-Sprache" stehen. Alexander und seine Mitver-fasser artikulierten in ihrer wegweisenden Arbeit einige hundert Muster der Architektur. Das Buch hat uns nicht nur geholfen, die Gebäude, die wir be-wohnen - oder gerne bewohnen würden -, besser zu verstehen, sondern hat auch gezeigt, dass sich mit durchdacht artikulierten Abstraktionen jedes Thema erörtern lässt.
Toter Fisch
Vom ersten Tag an hat das Projekt
keine Chance, die Zielvorgaben
einzuhalten; die meisten Beteiligten wissen das, doch nie-mand sagt etwas.
Die Ziele vieler IT-Projekte lassen sich wie folgt verallgemeinern: Wir brau-chen diese Funktionen, mit dieser Genauigkeit, in vertretbarer Stabilität, bis zu diesem Datum. Das Team wird zusammengestellt, die Zielvorgaben und Einschränkungen werden zu detaillierten Anforderungen und Entwürfen aus-gearbeitet und anschließend bekannt gegeben. Das große Geheimnis aber wird weiter gehütet: niemand im Projekt glaubt, dass das Projekt ein voller Erfolg werden kann. Üblicherweise ist es der Abgabetermin, der bei unver-änderten Zielvorgaben nicht einzuhalten ist. Rätselhafterweise spricht nie-mand aus, dass dem Projekt bereits jetzt der Gestank eines toten Fisches an-hängt und es zum Scheitern verurteilt ist.
Während die Tragödie ihren Lauf nimmt, schleppt sich das Projekt typi-scherweise bis wenige Wochen vor der erwarteten Auslieferung dahin; schließlich kommt der Moment, in dem sich alle Beteiligten - einschließlich des Projektleiters, des Vorgesetzten des Projektleiters und aller anderen Mit-arbeiter im Umfeld des Projekts - wie folgt verhalten:
1. Entweder äußern sie ihre Bestürzung und ihre Verwunderung darüber, dass das Projekt nicht annähernd einen Zustand aufweist, der die kurz be-vorstehende Freigabe rechtfertigen könnte.
2. Oder sie verkriechen sich und geben keinerlei Äußerung von sich, bevor sie nicht gefragt werden.
Wieso verbergen so viele Leute in so vielen Unternehmen die Realität lieber hinter einer Fassade als einfach festzustellen: "Dieses Projekt wird niemals wie geplant durchgeführt werden können. Der tote Fisch liegt direkt vor uns."
Viele Unternehmen sind so sehr auf Erfolg fixiert, dass jemand, der Beden-ken äußert, nicht dafür belohnt wird, dass er ausspricht, wovon er überzeugt ist. Im Gegenteil: Jemand, der im frühen Stadium eines Projekts auf den toten Fisch hinweist, bekommt als erste Reaktion etwa Folgendes zu hören:
"Beweisen Sie es uns! Zeigen Sie uns, dass die Wahrscheinlichkeit für einen Erfolg bei 0 % liegt. Ziehen Sie keine voreiligen Schlüsse aus den anderen getrockneten Fischkadavern, die hier noch von früheren Projekten herumliegen. Dieses Projekt ist anders. Beweisen Sie uns mathematisch unwiderlegbar, dass ein Misserfolg unumgänglich ist."
Jeder Einwand ohne schlagkräftigen Beweis wird mit einem Schwall von Un-terstellungen als Jammern und/oder Versuch, sich vor ehrlicher, harter Arbeit zu drücken, dargestellt.
"Sind Sie unter die Jammerlappen und Drückeberger gegangen? Es liegt ganz an Ihnen, aber wir haben erhebliche Zweifel, dass Sie lange bei diesem hervorragenden Unternehmen sein werden."
In einem solchen Umfeld ist es sicherer, sich die "größte Mühe" zu geben (und es dennoch nicht zu schaffen), als die Ziele in der vorliegenden Form als unerreichbar bloßzulegen. Zugegeben, manchmal müssen Sie ein höchst an-spruchsvolles Projekt annehmen und wirklich ernsthaft und hart dem Ziel entgegenstreben, bevor Sie irgendwelche Zugeständnisse bezüglich Termin oder Lieferumfang fordern. Selbstverständlich. Aber der Unterschied besteht dann doch darin, dass bei einem schweren Projekt mit einem Stichtag, den es einzuhalten gilt, niemand bis zur letzten Minute wartet, um den Notstand auszurufen. Angenommen, Ihr Projekt soll eine Software für einen Kommu-nikationssatelliten erstellen, dessen Start in 18 Monaten bereits festgelegt ist; falls Sie den Starttermin nicht einhalten können, ergäbe sich die nächste Ge-legenheit erst 16 Monate später. Dann werden Sie und alle anderen ja wohl jeden Tag die Nase in die Luft stecken und die Witterung aufnehmen. Ein erster Hauch von Scheitern - und Sie werden aktiv. Beim Muster "Toter Fisch" wartet man mit dem Handeln, bis einem die meisten Optionen nicht mehr zur Verfügung stehen.
Das Muster "Toter Fisch" ist nicht nur für die Unternehmen schädlich; es wirkt sich auch demoralisierend auf die Teams und die Leiter des Projekts mit dem toten Fisch aus. Egal, wie die Unternehmenskultur sonst aussieht, niemand sitzt gerne lange auf einem stinkenden toten Fisch. Der Preis für heimliche tote Fische ist immens.
Filmkritiker
Bei "Filmkritikern" handelt es sich um Projektmitarbeiter oder andere Personen aus dem Firmenumfeld, deren Beitrag zum Projekt darin besteht, aufzuzeigen, was falsch gelaufen ist und was gut ist, die aber keine persönliche Verantwortung übernehmen, um sicherzustellen, dass alles gut geht.
Sie befinden sich in den letzten Wochen vor der Freigabe Ihres neuen Systems für die Produktion. Die Integrationstests sind seit geraumer Zeit in vollem Gange, und die Entwickler beseitigen Fehler, sobald sie bekannt werden. Die Projektverantwortlichen gehen ihre Checklisten für die letzten Aktivitäten vor der Auslieferung durch, um zu gewährleisten, dass nichts übersehen wur-de. Auf einer einberufenen Lagebesprechung ist dann plötzlich eine neue Stimme zu hören. Für gewöhnlich gehört sie einer Person, die seit dem Be-ginn am Projekt beteiligt ist, bis zu diesem Zeitpunkt aber nicht viel beigetra-gen hat. Nennen wir diese Person Marcel.
Marcel ist mit dem Stand der Dinge nicht besonders zufrieden. Marcel hat das Gefühl, dass dem bald auszuliefernden Produkt einige wesentliche Funk-tionen fehlen. Auch bei den Designprüfungen wäre mehr drin gewesen. Und die Integrationstests hätten viel strenger durchgeführt werden müssen. Ange-sichts all der Probleme sieht Marcel bei der Auslieferung des Systems zum jetzigen Zeitpunkt ernsthafte Risiken. Die Risiken hat er in einer eindrucks-vollen PowerPoint-Präsentation zusammengestellt, die er per E-Mail an alle Welt verschickt hat.
Sie sehen sich die einzelnen Kritikpunkte an und stimmen einigen von ihnen zu. Ihre Hauptreaktion ist jedoch: "Wieso erzählst du uns das erst jetzt? Wo warst du, als wir noch genügend Zeit hatten, auf diese Punkte einzugehen?" Marcel tut Ihre Fragen ab, ohne konstruktive Vorschläge für die Dinge zu lie-fern, die er als Mängel ansieht. Stattdessen wiederholt er nur seine Bedenken hinsichtlich der Art und Weise, wie das Projekt angegangen wurde.
Marcel ist ein Filmkritiker.
Manchmal haben Filmkritiker eigentlich andere Aufgaben im Unternehmen und ihre Kritik ist mehr oder weniger ein Hobby. Manchmal werden sie auch tatsächlich von einem Manager, der diese Verhaltensweise schätzt, als Kriti-ker engagiert. In jedem Fall haben Kritiker eines gemeinsam: Sie glauben, dass sie erfolgreich sein können, selbst wenn das Projekt, an dem sie beteiligt sind, ein Fehlschlag ist. Letztendlich haben sie sich stillschweigend vom Pro-jektteam losgelöst.
Nicht alle Projektkritiker sind Filmkritiker. Der Hauptunterschied ist der Zeitpunkt der Kritik. Leute, die sich für den Erfolg des Projekts mitverant-wortlich fühlen, neigen dazu, sich sofort einzumischen, sobald sie sehen, dass etwas schiefläuft oder besser gemacht werden könnte. Sie treten vor und tei-len ihre Gedanken all denjenigen mit, die sie für einflussreich halten. Das tun sie so früh wie möglich, weil sie wissen, dass die Zeit immer knapp ist und Kurskorrekturen lieber früher als später vorgenommen werden sollten. Diese Leute sind keine Filmkritiker, sie sind Ihre gleichberechtigten Filmemacher. Sie wissen, dass sie nicht erfolgreich sein können, wenn das Projekt fehl-schlägt. Daher legen sie jeden Tag aufs Neue selber Hand an, um die Wahr-scheinlichkeit für einen gemeinsamen Erfolg zu erhöhen. Egal, ob Sie mit ihrer Kritik übereinstimmen oder nicht, Sie sehen, dass diese Leute am selben Film arbeiten wie Sie.
Um bei der Analogie zwischen Projekt und Film zu bleiben: Filmkritiker schalten sich erst ein, wenn der Film fertig ist oder so kurz vor der Fertigstel-lung steht, dass keine Zeit mehr für Korrekturen bleibt. Es ist nicht so, dass sie sich den Fehlschlag eines Projekts wirklich wünschen; vielmehr sind sie zu der Überzeugung gelangt, ihr eigener Erfolg sei unabhängig vom Erfolg des Projekts und habe vor allem damit zu tun, als scharfer Beobachter des Offensichtlichen und exakter Prophet des Unvermeidlichen zu gelten. Es ist ihnen nicht unbedingt bewusst, aber für sie ist es nicht mehr wichtig, ob das Projekt Erfolg hat oder nicht, solange man anerkennt, dass sie richtig gelegen haben.
Warum wimmelt es in manchen Projekten von Filmkritikern, wohingegen es in anderen kaum welche oder gar keine gibt? Dafür gibt es nur einen einzigen Grund: Manche Unternehmenskulturen legen großen Wert darauf, dass alles richtig gemacht wird, und andere legen großen Wert darauf, dass nichts falsch gemacht wird. Wenn die größte Sorge von Führungskräften darin be-steht, bloß keine Fehler zu machen oder wenigstens keine in der Vergangen-heit begangenen Fehler nachgetragen zu bekommen, senden sie sowohl of-fensichtlich als auch unterschwellig das Signal aus, dass es für das Unter-nehmen nicht nur wichtig ist, alles richtig zu machen, sondern auch Leute zu erwischen, die Fehler machen. Die Mitarbeiter eines Unternehmens mit einer natürlichen Neigung zum Filmkritiker fühlen sich durch solche Signale er-muntert und betätigen sich in ihrem aktuellen Projekt als freischaffende Kri-tiker, um herauszufinden, wie sie damit ankommen. Wenn ihr Treiben tole-riert oder sogar belohnt wird, werden sich die Filmkritiker im selben Maße vermehren, wie das Verantwortungsgefühl schwindet. Bedenken Sie, dass es erheblich einfacher ist, ein Filmkritiker zu sein als ein Filmemacher - sprich: ein verantwortungsvolles Teammitglied. Wenn ein Unternehmen deutlich macht, dass es den Wert von Filmkritikern zu schätzen weiß, wird es sie auch bekommen.
Filmkritik kann es auf allen Unternehmensebenen geben und sie kann auf verschiedene Weisen institutionalisiert sein. Am häufigsten anzutreffen ist der inoffizielle Filmkritiker. Diese Person spielt bereits eine Rolle im Projekt - in der Regel allerdings eine eher untergeordnete. Viele Filmkritiker befin-den sich in einer Verwaltungsrolle, aus der heraus sie zahlreiche Projekte kri-tisieren können. In einer besonders stark befallenen Führungskultur können die Führungskräfte sogar das gesamte Unternehmen dazu anhalten, sich als Wachhund für die Teams zu betätigen, die mit der Erstellung der Systeme betraut sind.
Die Ausübung von Filmkritik an Projektteams ist nur ein Beispiel für ein all-gemeineres destruktives Muster, das als Loslösung vom Ziel bezeichnet wer-den kann. Rufen Sie sich noch einmal ins Gedächtnis, was den Filmkritiker überhaupt erst möglich macht: die Überzeugung, dass es mehrere Wege gibt, um mit einem Projekt Erfolg zu haben. Zunächst einmal kann natürlich das Projekt selbst Erfolg haben. Aber der Filmkritiker (beziehungsweise der Vor-gesetzte, der den Kritiker angeheuert hat) lässt es zu, dieses Ziel durch ein verwandtes, aber unabhängiges Ziel zu ersetzen: die präzise Ermittlung der Dinge, die beim Projekt schieflaufen. Natürlich bedeutet das nicht, dass die Ermittlung von Mängeln an sich schlecht ist - das dürfte offensichtlich sein. Loslösung vom Ziel wirkt sich destruktiv aus, weil Menschen, die losgelöste Ziele verfolgen, nur zufällig auf den Erfolg des Projekts hinarbeiten. Ihre Bemühungen können genauso gut irrelevant oder sogar kontraproduktiv für das Projekt sein.
Gierschlund
Die Neigung, sich zu übernehmen, schadet dem Unterneh-menstempo und führt insgesamt zu einer
verringerten Effektivität. Aber die Versuchung kann groß sein ...
In diesen Zeiten von Kostensenkung und Personalabbau setzt sich - zumin-dest unter IT-Fachleuten - die Ansicht durch, dass Unternehmen zu wenig neue Software produzieren und folglich Chancen für echte strategische Vor-teile ungenutzt lassen. Falls Sie dies auch glauben, ziehen Sie kurz das Ge-genteil in Betracht: Möglicherweise produzieren Sie zu viel Software.
Im 21. Jahrhundert scheint es Pflicht zu sein, dass jedes Projekt bereits ges-tern erledigt sein muss. Wenn Geschwindigkeit tatsächlich von so großer Be-deutung ist, drängt sich doch der Gedanke auf, dass mehr Geschwindigkeit durch weniger Projektlast zu erreichen ist. Dieser einfache, dem gesunden Menschenverstand folgende Ansatz steht komplett im Widerspruch zu einer unausgesprochenen, aber bedeutenden politischen Realität: Durch den Ver-zicht auf irgendetwas könnte man jemandem zu nahe treten, möglicherweise einer Person mit Einfluss. Nennen wir diese Person Michael. Falls Michael genügend Einfluss besitzt und sich Gehör zu verschaffen weiß, machen Sie womöglich einen Rückzieher: Ach, was soll's, wir werden Deine Wünsche natürlich realisieren, Michael.
Lassen Sie uns kurz analysieren, was hier geschehen ist: Ihr Unternehmen hat etwas mehr Belastung akzeptiert, als es bequem bewältigen kann. Sie haben sich so entschieden, um einer einflussreichen Person nicht auf den Schlips zu treten. Da nun dieselben beschränkten Ressourcen auf mehr Arbeit verteilt werden müssen, wird die Arbeit im Durchschnitt langsamer erledigt. Sie ha-ben Geschwindigkeit in der Hoffnung geopfert, sich Michael nicht zum Feind zu machen. Es kommt noch schlimmer. Michael ist nicht die einzige einfluss-reiche Person im Unternehmen. Tatsächlich besitzt potenziell jeder Macht, der in der Lage ist, ein neues Projekt zu beauftragen oder Zusatzwünsche ein-zufordern. In Ihrem Bemühen, Kritik zu vermeiden, werden Sie zu vielen von ihnen wohl Ja sagen müssen. Mit jedem Ja sorgen Sie dafür, dass die Arbeit noch langsamer wird.
Die Übernahme von mehr Arbeit, als Ihr Team gut bewältigen kann, ist ein Zeichen Ihrer Feigheit. Um persönliche Kritik zu vermeiden, schaffen Sie Bedingungen, unter denen Ihr Team nicht erfolgreich sein kann. Letztendlich wird Ihr Team unter Überlastung und geringerem Ansehen im Unternehmen leiden, weil Sie nicht den Mut hatten, von Anfang an Nein zu sagen.
Was können Sie tun, um diesen Teufelskreis zu durchbrechen? Die Antwort ist leicht zu finden, aber schwer zu realisieren: Setzen Sie Prioritäten und ü-bernehmen Sie nur so viel Arbeit, wie Sie bei maximaler Geschwindigkeit bewältigen können. Stellen Sie alles andere zurück, bis die hochwertigere Arbeit erledigt ist. Damit verzichten Sie auf Einfluss, steigern aber die Ge-schwindigkeit. Sie liefern Ihre Ergebnisse schneller, Ihre politische Macht kann dadurch aber geringer geworden sein. Das zugrunde liegende Prinzip ist nicht gerade tröstlich: Sie können mehr von der wesentlichen Arbeit und schneller erledigen, doch nur unter Verzicht auf potenziellen politischen Ein-fluss.
Machtspiele sind nicht der einzige Grund dafür, dass Firmen sich überneh-men. Auch Individuen neigen dazu, sich zu überlasten. Sie können nur schwer Nein sagen. Zwar haben alle schon einmal den Spruch "weniger ist mehr" gehört, aber dennoch sind sie im Grunde ihres Herzens davon über-zeugt, dass nur "mehr ist mehr" Gültigkeit hat.
Mehr Aufgaben zu übernehmen, als man mit maximaler Geschwindigkeit bewältigen kann, ist ein sicherer Weg, um langsamer zu werden. Den hier geschilderten Kompromiss zwischen Menge und Geschwindigkeit werden Sie fast nie zu sehen bekommen, einfach weil er nicht reizvoll ist. Dieser feh-lende Reiz kann erklären, warum so viele IT-Unternehmen durch die schiere Menge an Arbeit, die sie zu bewältigen versuchen, nahezu bis zum Stillstand ausgebremst werden. Wenn sie sich jemals die Zeit nehmen würden, die Spreu vom Weizen zu trennen, würden sie vermutlich feststellen, dass es die ganze Spreu ist, die das Unternehmen so ausbremst. Falls Sie eine leitende Position innehaben, setzen Sie Ihr Projekt einem erheblichen und unnötigen Risiko aus, wenn Sie den Fortbestand dieses Musters (entweder in Ihren ei-genen Handlungen oder in denen Ihrer Untergebenen) zulassen.
Marylin Munster
In einigen Unternehmen sind die Entwickler Könige,
in anderen Bauern.
The Munsters war eine erfolgreiche US-Comedyserie, von der ab 1964 zwei Staffeln ausgestrahlt wurden. In der Serie ging es um das turbulente Famili-enleben einer Monsterfamilie, die in einer normalen Stadt in der Mockingbird Lane 1313 wohnten. Der Vater, Herman Munster, ist eine alberne Version von Frankensteins Monster; seine Frau Lily ist ein Vampir; der Großvater ähnelt dem Grafen Dracula als Varieté-Verschnitt; der Sohn Eddie ist ein junger Werwolf.
Paradoxerweise ist Marilyn, die Tochter der Munsters, eine hübsche blonde Collegestudentin. Aber die übrige Familie betrachtet Marilyn nicht als hübsch. In ihren Augen ist Marilyn völlig unattraktiv. Sie versuchen, ihre Ge-fühle nicht zu verletzen, aber in Wirklichkeit ist sie ihnen sogar ein wenig peinlich. Es ist eine der zentralen Marotten der Munsters, dass Marilyns ge-ringer Status an dem dummen Zufall liegt, in diese seltsame Familie hinein-geboren worden zu sein. Es ist völlig offensichtlich, dass Marilyn in jeder anderen Familie der Nachbarschaft weitaus mehr geschätzt würde.
Viele Entwickler leben das Leben einer Marilyn Munster. Sie arbeiten für Firmen, die auf Technologie angewiesen sind, aber ihre Arbeit bleibt größ-tenteils unbeachtet, und ihr Status im Unternehmen ist sehr gering. In vielen solcher Unternehmen ist Status für Manager reserviert. Manager sind verant-wortlich für die Planung, die Koordination, die Leistungsüberwachung, die Kosteneinschätzung und für die Zuteilung der Arbeit an das technische Per-sonal. Planung, Koordination, Leistungsüberwachung und Kosteneinschät-zung werden üblicherweise ausschließlich von Managern zusammen mit an-deren Managern durchgeführt. Der Entwickler gilt als Technikschlaffi, je-mand, der "nicht verstehen kann", was für eine harte Arbeit es in Wirklich-keit ist, die Firma zu leiten.
Manager verdienen das große Geld, weil sie für die Auswahl der durchzufüh-renden Projekte verantwortlich sind und dafür, diese auserkorenen Unter-nehmensinvestitionen durchzuziehen. Die Techniker haben ihre Köpfe zu senken und zu produzieren, was die Manager ihnen auftragen. Wenn sie da-mit nicht einverstanden sind, steht es ihnen frei, zu gehen; und der Manager wird gemeinsam mit der Personalabteilung einen Ersatz finden. Bei diesem Ersatz kann es sich um ein Subunternehmen handeln, und dieses Subunter-nehmen kann seinen Sitz auf einem anderen Kontinent haben, wo die Tech-nikschlaffis weniger kosten als am Stammsitz des Unternehmens.
Es gibt eine weitere Variante dieses Musters, bei der sämtliche Macht beim Vertriebsapparat liegt. Am Ende läuft es dort immer auf das Argument hin-aus, dass es keine Rolle spielt, wie gut die Produkte sind, wenn sie nicht an den Mann gebracht werden können. In beiden Arten von Unternehmen gilt die grundsätzliche Überzeugung, dass es Entwickler im Überfluss gäbe und einer so gut wie der andere sei. Folglich zahlt man für ihre Dienste so wenig wie möglich.
Es gibt natürlich auch Firmen, in denen Entwickler völlig anders gesehen werden. Diese Firmen sind davon überzeugt, dass ihre Produkte und Dienst-leistungen sich durch Qualität und Innovation von denen ihrer Konkurrenz unterscheiden. Sie erkennen, dass es in Bezug auf das Talent und die Produk-tivität einen riesigen Unterschied zwischen den oberen zehn Prozent der Entwickler und einem durchschnittlichen Entwickler gibt. Sie wollen die bes-ten Leute, die sie bekommen können. Daraus ergibt sich eine Unternehmens-kultur, in der Entwickler Könige sind und große Freiheiten in Bezug auf ihre Arbeit und die zur Durchführung der Arbeit eingesetzten Methoden besitzen. Diese Entwickler definieren häufig die Funktionsmerkmale und setzen sie auch um. Und typischerweise bilden sie auch die vorderste Front bei der Ein-schätzung der Entwicklungsarbeit. Sehr erfahrene Entwickler können genau-so viel verdienen wie Teamleiter, manchmal sogar mehr. Meistens - aber nicht immer - sind es Unternehmen, die Software entweder herstellen oder als Hauptbestandteil ihres Produktes ausliefern, wo die Entwickler Könige sind.
Es gibt auch eine extreme Variante der "Entwickler-ist-König"-Firmenkultur, die nicht funktioniert. Wenn Entwickler ihre eigene Arbeit optimieren und planen, ohne die Auswirkungen ihrer Entscheidungen auf andere zu beach-ten, können Projekte in Schwierigkeiten geraten. Wir fanden beispielsweise einmal ein Projekt vor, bei dem die beiden Entwickler sich dazu entschlos-sen, die Software eines Produktes eher nur "anzureißen", indem sie viele Klassen einfach unvollständig ließen, weil sie wussten, dass sie diese später noch programmieren könnten. Sie arbeiteten nur an den "interessanten, schwierigen Bestandteilen". Der Rest des Projektteams, die Leute von der Qualitätssicherung und die technischen Redakteure hatten schließlich einen riesigen Haufen Arbeit vor sich, als der Abgabetermin näher rückte, weil noch nichts fertiggestellt war. Es konnte nichts getestet werden, es konnte nichts dokumentiert werden - bis plötzlich alles auf einmal erledigt war, nachdem die Entwickler wieder zu den Lücken kamen und sie füllten. Die Entwickler hatten das Projekt ent-optimiert, weil sie nur ihre eigene Arbeit optimiert hatten.
Wenn Sie Entwickler einstellen, sollten Sie sich fragen, wie wichtig Qualität und Innovation für den Erfolg Ihres Unternehmens sind. Wenn Sie in der ers-ten Liga spielen wollen, brauchen Sie für beides wirklich talentierte Entwick-ler. Sie werden keine Top-Talente anziehen, fördern und halten können, wenn Entwickler von Ihnen wie ein notwendiges Übel und als zu minimie-render Kostenfaktor behandelt werden.
Wenn Sie ein hervorragender Entwickler sind und sich ein wenig wie Mari-lyn Munster fühlen, seien Sie versichert, dass es da draußen noch andere Fa-milien gibt, die Ihnen die Aufmerksamkeit schenken werden, die Sie verdie-nen. Fliehen Sie aus der Freak-Show.
Über die Gilde
Wenn Ihre Organisation Softwaresysteme erstellt, dann haben wahrscheinlich einige der Methoden und Verfahren, die Sie anwenden, ihren Ursprung in der Atlantic Systems Guild haben. Die sechs Prinzipale der Gilde sind:
§ Suzanne Robertson und James Robertson, die Partner aus London, sind die Schöpfer des VOLERE-Requirements-Prozesses, in dem das unglaub-lich populäre Requirements-Template enthalten ist. Die Seminare und die Beratungsarbeit von James und Suzanne haben vie-len Firmen geholfen, ihre Anforderungen zu entdecken und klar zu artiku-lieren. Die beiden Robertsons sind die Koautoren von "Mastering the Re-quirements Process", "Requirements Led Project Management" und "Vollständige Systemanalyse".
§ Steve McMenamin ist Vice President of Engineering bei Borland Soft-ware, wo er die Entwicklungsteams von einigen Open Application Life-cycle Management-Produkten leitet. Bevor er zu Borland kam war er in leitender Verantwortung bei BEA Systems, Crossgain Corp. und Edison International tätig.
§ Tim Lister arbeitet vom New Yorker Büro der Gilde aus. Er verbringt sei-ne Zeit damit, Organisationen zu helfen, effektiver als bisher zu arbeiten. Er bezeichnet sich selbst als Risiko-Management-Fanatiker, der überzeugt ist, dass sich alles um Chancen und Risiken dreht und dass Produktivität und Qualität nichts bedeuten, wenn man sie nicht im Zusammenhang mit den Chancen und Risiken sieht. Tim und Tom sind Koautoren von "Wien wartet auf Dich" und "Bärentango"
§ Peter Hruschka, in Aachen zuhause, ist spezialisiert auf Requirements und Design von technischen Systemen. Er ist der Koautor des ARC42-Templates zur effizienten Architekturdokumentation. In einem früheren Leben war er Pionier für Modellierungswerkzeuge zur Unterstützung strukturierter und objektorientierter Methoden. Er hat ein halbes Dutzend Bücher zu Methoden und Werkzeugen veröffentlicht.
§ Tom DeMarco ist der Autor oder Koautor von elf Büchern. Als Berater ist er spezialisiert auf Projekterfolg und manchmal auf Projektmisserfolg (Rechtsstreitigkeiten). Seine Veröffentlichungen schließen auch zwei Ro-mane ein. Zur Zeit arbeitet er an einem geschichtlichen Werk. Er lebt mit Sally O. Smyth - seiner Frau und langjährigen Gefährtin - in Camden, Maine.
