HMD Praxis der Wirtschaftsinformatik

ISSN 1436-3011

19.03.2010


Home
Suche
HMD aktuell
Aktuelle Ausgabe
40 Jahre HMD
Vorschau
Buchbesprechungen
HMD-Glossar
Veranstaltungskalender
HMD beziehen
HMD Probeabo
HMD Abo
HMD Einzelheft
Bezugsbedingungen
HMD archiv
HMD Info
Mehr über HMD
Herausgebergremium
Gastherausgeber
Mediadaten
Redaktion /' Verlag
Impressum
Autoren/ Gutachter
Autorenrichtlinien
Autorenfragebogen
Gutachter für die HMD
Beurteilungsbogen

Neue Konzepte in der Softwareentwicklung

[Zurück zum Inhaltsverzeichnis -
- Feedback an den Herausgeber]

Einwurf

Softwareentwicklung - höher als alle Vernunft

Früher musste ich manchmal schätzen, wie lange eine Softwareentwicklung dauert. Ich weiß die wahre Antwort (eine richtige kenne ich auch): "Es kommt darauf an." Da hat mein Gegenüber stets geseufzt, weil diese Antwort zwar wahr ist, aber nicht zulässig. Im Wesentlichen leidet die Welt nämlich daran, dass für die Projektdauer nur ein numerisches Feld in einer Datenbank reserviert ist. Es geht hauptsächlich darum, dass dieses Feld mit einer politisch korrekten Zahl gefüllt ist. Ich hatte zuerst vermutet, dass die erwartete Projektdauer im mathematischen Sinne eingetragen werden muss, und zur Berechnung dieses Erwartungswertes würden wir alle Szenarien durchgehen, alle diese mit Wahrscheinlichkeiten versehen und am Ende irgendetwas ausrechnen, so grob es dann immer noch ist.

Uiiih, war das ein Irrtum! Wahrscheinlich sind die Leute nur so unwahrscheinlich. Techies kennen nur die Wahrscheinlichkeit, dass ein Projekt länger als geplant dauert. Es kann nicht kürzer sein, weil wir Techies immer noch so lange an allem herumschrauben, bis der Abgabetermin naht. Das Produkt sieht besser perfekt aus, es ist eine Frage der Ehre. Manager können sich dagegen nicht vorstellen, dass ein Projekt länger dauert als die Datenbank sagt - das ist ja aus Budgetgründen verboten.

Deshalb dauert ein Projekt immer so lange, wie es geplant wurde.

Wie läuft nun eine vernünftige Planung ab? Ein Anwender möchte Software kaufen, weil er zu einem bestimmten, fest eingebildeten Termin einen großen Nutzen braucht. Unabhängig von der Sachlage verlangt sein Unternehmen aber, nur Standardsoftware zu verwenden. Diese ist ja preiswert und verkürzt die Projektdauer erheblich. Deshalb muss der Anwender nun so lange warten, bis es Standardsoftware gibt - mindestens aber bis zur nächsten CeBIT, bei der man viele Jutetaschen voller Standardversprechen mitnehmen kann. Nach der CeBIT ist klar, dass es keine Standardsoftware gibt. Es dauert sehr lange, dies dem eigenen Unternehmen zu beweisen, weil es keinerlei Hinweise für die Nichtexistenz gibt - denn die Softwarehersteller stellen allesamt partout nur Standards her, eben, weil nur diese vom Kunden ausschließlich verlangt werden. Nun ist aber die viele Zeit, die ursprünglich nur für Standardsoftware geplant war, so kurz geworden, dass der ganze Plan zugunsten des neuen aufgegeben wird, nämlich, statt einer Standardsoftware eine schnelle Lösung zu suchen. Jetzt stellt sich ein neues Problem. Wer Standardsoftware einsetzen will, hat kaum Alternativen, meistens etwa zwei. Dagegen gibt es Unmengen von schnellen Lösungen, so dass der ganz verwirrte Anwender nun erst einen aufwendigen Selektionsprozess starten muss, der unter dem entstandenen Zeitdruck stark darunter leidet, dass eben gerade jetzt die CeBIT gewesen ist - es wäre wohl besser, man wartete noch ein Jahr? Vielleicht gibt es bis dahin schon Standardsoftware? Wahrscheinlich müssen jetzt namhafte Beratungshäuser eingeschaltet werden! Ich kenne privat Menschen, die sich unter horrenden Ausgaben für Fachzeitschriften und Messebesuche schon seit vielen Jahren keine Digitalkamera kaufen, weil sie sich noch kein rechtes Bild machen konnten. Das Kaufen einer Digitalkamera ist nämlich viel zeitaufwändiger als deren spätere Nutzung! Und stellen Sie sich einmal vor, nach allem jahrelangen Ringen um so eine Digitalkamera stehen Sie endlich im Media-Markt und wollen kaufen: "Acht Wochen Lieferzeit." Da kommen Sie sich doch blöd vor.

Ganz genauso schaut jemand, der mich fragt, wie lange es noch zum Entwickeln von Software dauert, jetzt, wo er endlich will! Und ich sage: "Es kommt darauf an." Worauf kommt es an? Ich habe einmal eine Liste gemacht. Anwender sollten tolle Anwendungen bekommen, also müssten sie für eine lange Projektlaufzeit eintreten. Sie wählen aber gezwungenermaßen eine kurze, weil sie mit dem Planen überraschend viel Zeit verbrauchten und nicht mehr viel Geld haben. Fachabteilungen sollten lange überlegen, was sie nutzen wollen, aber sie wollen schnell sparen, votieren also für schnell. Der Manager der Softwareentwicklungsfirma muss interessiert sein, eine lange Projektlaufzeit zu vereinbaren, weil er dann Qualität liefern kann und Gewinn erzielt. Er wählt aber aus Erleichterung über den Abschluss für seine Karriere und seine Quartalszahlen die kurze. Der Vertriebler der Softwareentwicklung sollte langfristig eine lange Projektzeit vereinbaren, damit der Kunde hinterher zufrieden mit der Qualität ist; außerdem wird die Abschlusssumme des Vertrags höher. Er verspricht aber eine kurze Zeit, weil er den Umsatz damit schnell in die Bücher bekommt. Schnell ist in den Büchern besser als viel.

Ach ja, und der Techie, der als großer Maestro der Softwareentwicklung gilt, der wird auch noch gefragt. Der Techie schaut sich alles in Ruhe an, schaut gedankenverloren (bei Techies ist das: hochkonzentriert) und flüstert (bei Techies ist das: ernst und sicher) nach peinlichem zwanzigsekündigem Schweigen: "X Monate." Das entrüstet alle, weil es zu lange ist. Viel zu lange. Alle wissen, dass er ein triviales Interesse hat, die Projektlaufzeit zu hoch zu schätzen, weil er dann in Ruhe arbeiten kann. Alle wissen, dass die Schätzung des Meister-Techies so etwas wie die furchtbarste Alternative von allen ist. Sie ist der nie mehr überschrittene Mondpreis, der nur den Dümmsten nicken lässt. Techies haben kein Gefühl für Geld. Sie sind vielleicht neurotisch, aber nie wirklich eurotisch (da lasse ich mir kein Blank für ein u vormachen).

Ich musste früher öfters mal sagen, wie lange ein Projekt dauert - ich glaube, dies ist eine richtige Antwort: Ich gehe zum Maestro und frage ihn, wie lange es dauert. Er sagt: "X Monate." Die Zahl multipliziere ich mit 2,1 (i.W.: zwei Komma eins). So lange dauert es.

Ein Maestro denkt nämlich, Zeit sei nicht Genie. Wenn er hohe Zahlen nennen muss, wird er sich schämen. Er tötet sich aber durch seine damit selbst verschuldeten Deadlines lieber selbst, bevor er sich schämen wollte. Ein Maestro denkt irrtümlich, alle Menschen programmierten mindestens halb so gut wie er selbst. Er denkt, Software eines Maestros müsse nicht getestet werden, jedenfalls kaum oder nur pro forma. Ein Maestro wird eher unbezahlte Überstunden leisten, als den Kunden übers Ohr zu hauen.

Verstehen Sie? Die Software ist für den Maestro eine Frage seiner Ehre. Deshalb 2,1 mal X mal Monate, punktum.

Bei Menschen, die schielen, unterscheiden wir zwischen Hypophorikern, das sind solche, die ständig nach unten schielen, und den Hyperphorikern, die dies nach oben tun. Alle Leute, auch Sie, sie mögen alle schielen, wohin sie wollen, die Wahrheit ist höher.

Prof. Dr. Gunter Dueck
Chief Technologist
IBM Deutschland GmbH
Vangerowstr. 18
69115 Heidelberg dueck@de.ibm.com
www.de.ibm.com

HMD, Heft 231, Juni 2003

hosted by dpunkt.verlag