Whil Hentzen
Von den Fragen, die sich bei der Entwicklung von Software immer wieder stellen, ist die Schätzung von Zeit und Kosten für die Entwicklung wohl diejenige, die sich am hartnäckigsten stellt. Im letzten Jahrhundert hat die Menschheit Flüge zum Mond durchgeführt und eine Million Transistoren auf einem kleinen Stück Silikon untergebracht. Warum können wir aber immer noch nicht herausfinden, wie viel Zeit die Entwicklung einer Software in Anspruch nehmen wird? In diesem Kapitel erfahren Sie einiges über die Mechanismen, die Sie einsetzen können, um die magischen Fragen "Wie lange?" und "Wie teuer" zu beantworten. In den letzten Kapiteln haben wir uns mit der Frage beschäftigt, welche Schritte Sie durchführen müssen, bevor Sie die den Aufwand an Zeit und Kosten korrekt einschätzen können. Lassen Sie uns aber zuerst untersuchen, wie der Status Quo aussieht.
Dabei ist es wichtig zu bemerken, dass die hier besprochenen Mechanismen auch für Entwickler in Unternehmen eingesetzt werden können. Diese Entwickler können wir in zwei Gruppen teilen - einerseits diejenigen, die in einem Unternehmen arbeiten und Software für den internen Gebrauch entwickeln, andererseits die Entwickler, die für ein Unternehmen arbeiten, das die entwickelte Software an Endkunden verkauft.
Der einzige Unterschied zwischen diesen beiden Gruppen ist derjenige, dass sich der "Kunde" dieser Zeit- und Kostenberechnung im ersten Fall in der gleichen Firma befindet.
Wenn es sich um eine interne Anwendung handelt, müssen Sie wahrscheinlich mit einem Abteilungsleiter oder Arbeitsgruppenleiter zusammenarbeiten. Handelt es sich um eine Anwendung für ein anderes Unternehmen, ist Ihr Ansprechpartner ein Produktmanager.
In jedem Fall treffen Sie auf jemanden, der den Preis der Software möglichst genau wissen will. Diese Kosten können den laufenden Geschäftskosten zugeordnet werden oder können dazu genutzt werden zu bestimmen, ob der potentielle Markt für das geplante Produkt die Kosten decken kann. In beiden Fällen müssen Sie angeben, wie lange die Entwicklung dauert und wie teuer sie wird. Sicher, die Art, wie die Bezahlung vom "Kunden" zum "Entwickler" gelangt, ist unterschiedlich. Die Notwendigkeit einer korrekten Schätzung von Zeit und Kosten bleibt aber bestehen.
Wie werden der Entwicklungsaufwand für Softwareprojekte heute geschätzt? Mit den Jahren haben wir sechs allgemein übliche Methoden gefunden.
Alle diese Methoden für eine Schätzung werden heute eingesetzt - aber bei den Ergebnissen handelt es sich nur um eine Schätzung der Kosten und des Zeitrahmens. Aber genug gescherzt.
Offensichtlich gehen alle aufgeführten Methoden am Ziel vorbei. Keine verfügt über einen methodischen Mechanismus, mit dem sie das Ziel erreicht. Außerdem sind die Resultate nicht reproduzierbar. Daher kann eine Schätzung des gleichen Softwareprojekts an drei Tagen drei unterschiedliche Ergebnisse hervorbringen. Welches Ergebnis ist aber das Richtige? Geht der Entwickler bei einem der Ergebnisse (oder auch bei mehreren) das Risiko ein, Geld zu verlieren? Keiner weiß es.
Nachdem Sie eine Schätzung über das Projekt abgegeben haben ist die Arbeit noch nicht getan. Sie müssen noch entscheiden, wie Sie Ihrem Kunden die Rechnung stellen wollen. Dabei haben Sie sich zwischen zwei Möglichkeiten zu entscheiden: Abrechnung nach Zeit und Material oder Festpreis.
"Zeit und Material" hat seinen Namen von anderen Arten der Arbeit erhalten, bei denen der Auftragnehmer sowohl die von ihm aufgewendete Zeit als auch die verbrauchten Materialien in Rechnung stellt. Wenn Sie zum Beispiel einen Schornstein reparieren lassen erhalten Sie eine Rechnung sowohl über die geleistete Arbeit als auch über die verwendeten Materialien - Ziegel, Mörtel, Hilfsmittel usw.
Die Alternative ist der Festpreis. Er bedeutet genau das, was der Name aussagt - eine feste Summe für eine Arbeit. Diese Methode beinhaltet drei Annahmen. Zunächst hat der Auftragnehmer abgeschätzt, wie lange die Ausführung der Arbeit dauert (und welches Material er benötigt) und diese Zeit mit seinem Stundensatz multipliziert, um den Festpreis zu errechnen. Zusätzlich akzeptiert der Auftragnehmer einen geringeren Stundensatz, wenn die Arbeit länger dauert als geschätzt. Daraus ergibt sich die dritte Annahme: Wenn die Arbeit schneller erledigt ist als geplant, erhält der Auftragnehmer einen höheren Stundensatz.
Lassen Sie uns jetzt die Vor- und Nachteile der Abrechnungsarten untersuchen.
Dabei handelt es sich für den Entwickler um die sicherste Methode, da der Kunde alle möglichen Risiken trägt.
Eines der Risiken ist die Erweiterung der Anforderungen, wenn dem System zusätzliche Features hinzugefügt werden. Dieses Risiko muss natürlich der Kunde tragen, da er der einzige ist, der diese zusätzlichen Funktionalitäten haben will.
Ein anderes Risiko ist es, wenn Sie mit unerfahrenen oder inkompetenten Entwicklern zusammenarbeiten. Das kann dazu führen, dass Sie dem Kunden die Kosten für den Lernprozess dieser Entwickler aufbürden. Die Maßeinheit ist hier die Entwicklerzeit, so dass der Kunde das Risiko für die Kompetenz des Entwicklers trägt. Der Entwickler gibt eine Aufwandsschätzung ab und versucht auch in diesem Rahmen zu bleiben, aber am Ende zahlt der Kunde für die gesamte Zeit, die der Entwickler aufgewendet hat.
Wer soll diese Kosten tragen? Im ersten Moment könnten Sie argumentieren, dass der Entwickler dafür verantwortlich ist - im Endeffekt bezahlt der Kunde aber doch für die Lernkurve eines neuen Entwicklers. Dies geschieht vielleicht nicht direkt, statt dessen wird der Kunde mit den Kosten indirekt belastet, indem Sie ihm einen höheren Stundensatz für erfahrene Entwickler in Rechnung stellen, mit dem Sie die noch fehlende Leistung eines anderen Entwicklers ausgleichen.
Allerdings ist das Risiko nicht auf unerfahrene oder inkompetente Entwickler begrenzt. Ein erfahrener Entwickler kann eine zu hohe Aufwandsschätzung abgeben oder auch gewollt eine zu niedrige abgeben, um den Auftrag zu erhalten, auch wenn es ihm bewusst ist, dass der Aufwand letztendlich erheblich höher ist. Auch kann eine Firma eine gute Schätzung abgeben und planen, das Projekt mit den entsprechenden Arbeitskräften auszustatten. Wenn das Projekt startet, sind diese Entwickler aber mit anderen Aufgaben beschäftigt oder es sind keine entsprechenden Arbeitskräfte zu erhalten.
Unabhängig davon, wie Sie vorgehen: im Endeffekt trägt der Kunde das gesamte Risiko. Aber auch der Auftragnehmer ist nicht vor Gefahren gefeit. Es besteht die Möglichkeit, dass ein Kunde eine Aufwandsschätzung akzeptiert und später die gestellte Rechnung als zu hoch erachtet.
Auf der anderen Seite profitiert die Kunden davon, wenn Sie mit erfahrenen Entwicklern zusammenarbeiten und der Umfang des Projekts sich nicht ändert. Der Kunde zahlt den niedrigsten möglichen Preis und der Entwickler wird für die gesamte Zeit bezahlt, die er aufgewendet hat. Nur - wie oft geschieht das?
Diese Lösung ist für den Kunden scheinbar die beste Lösung, da die Risiken beim Programmierer liegen. Das Problem der unerfahrenen oder inkompetenten Entwickler, die an dem Projekt arbeiten, bleibt aber strittig, obwohl die dadurch entstehenden Kosten beim Auftragnehmer liegen. Nachforderungen an den Kunden, die durch Missverständnisse oder Fehler entstehen, fallen in diesem Fall nicht an. Das Risiko durch unerfahrene oder inkompetente Arbeitskräfte liegt beim Auftragnehmer.
Ein zweites Risiko besteht, wenn ein Entwickler eine der oben beschriebenen Schätzmethoden für den Aufwand gewählt und ein Resultat erzielt hat, das erheblich unter dem tatsächlichen Aufwand liegt. Ist die Differenz sehr groß, kann es passieren, dass der Entwickler aus dem Projekt ausscheidet oder auch sein Gewerbe aufgibt. Dieses Risiko trägt der Kunde.
Auf der anderen Seite sollte der Entwickler nicht das Risiko tragen, dass die Anwendung umfangreicher wird als ursprünglich vereinbart. Trotzdem ist dies häufig der Fall. Wird der Kunde mit einem Festpreis und einer dicken Dokumentation konfrontiert neigt er dazu anzunehmen, dass alle Funktionalitäten in der endgültigen Anwendung enthalten sind, die ihm vorgeführt oder mit ihm diskutiert wurden oder die er sich einmal unter der Dusche vorgestellt hat. Unabhängig davon, wie umfangreich die Dokumentation ist: der Kunde findet immer noch ein weiteres Feature, das für ihn ein absolutes Muss ist und für das er nicht extra zahlen will. Berechnende Kunden führen dieses Spiel exzessiv durch, um möglichst viel Funktionalität für ihr Geld zu erhalten.
Im Ergebnis sieht sich der Entwickler mit einer ganzen Reihe Forderungen des Kunden nach zusätzlichen Funktionalitäten konfrontiert, welche noch eingefügt werden sollen und von denen der Kunde meint, sie seien Teil des Festpreises. Der Entwickler könnte auf diese Forderungen eingehen, da er sich davon Folgeaufträge verspricht.
Irgendwann wird dieses Vorgehen aber unwirtschaftlich und mit einigen Fällen bricht der Entwickler das Projekt einfach ab. Jeder hat schon einmal eine Firma erlebt, die ein Projekt als "zu 90 % erledigt" kennzeichnet und über Monate und Monate nicht über diesen Status hinauskommt, da der Kunde der To-Do-Liste ständig weitere Punkte hinzufügt. In anderen Fällen beendet der Entwickler einen Auftrag, obwohl er noch Fehler enthält und der Kunde muss sich einen anderen Entwickler suchen, um das Projekt nach seinen Vorstellungen zu beenden.
In jedem Fall ist auch der Kunde nicht auf der sicheren Seite. Durch seinen Versuch, sämtliche Variationen sämtlicher Möglichkeiten in der Software zu behandeln, kann er den Entwickler dazu verleiten, in seine Schätzung einen hohen "Unsicherheitsfaktor" einzubauen, um das Risiko so weit wie möglich zu begrenzen.
Insgesamt kann bei einem Festpreisvertrag eine gespannte Stimmung entstehen, da der Entwickler so wenig wie möglich für den Festpreis arbeiten will, während der Kunde in der Regel so viel wie möglich für sein Geld erhalten möchte.
Der Vorteil des Festpreises ist also, wenn alle Faktoren zusammenkommen, der Kunde weiß, wie viel die von ihm in Auftrag gegebene Software kostet - und der Auftragnehmer kann einen angemessenen Gewinn erzielen, wenn er fähige Entwickler mit der Durchführung des Projekts beauftragt und diese effizient arbeiten.
Der Kompromiss, eine Höchstgrenze zu vereinbaren, ist in unseren Augen einfach eine unfaire Möglichkeit, dem Entwickler die Risiken aufzubürden, ohne dass er dafür etwas erhält. Der Kunde zahlt den niedrigstmöglichen Preis und erhält dabei die Garantie, dass eine bestimmte Marke nicht überschritten wird. Zusätzlich meint er noch die Möglichkeit zu haben, dem System viele zusätzliche Features hinzuzufügen und Änderungen am System vornehmen zu können, ohne dass dies für ihn Konsequenzen hat. Auf der anderen Seite erhält der Entwickler für die Erledigung eines anspruchsvollen Auftrags keine zusätzliche Zahlung und geht das Risiko ein, bei Änderungen oder Ergänzungen am System nicht auf seine Kosten zu kommen.
Nun wird bereits seit über 40 Jahren Software in der einen oder anderen Form entwickelt. Man sollte annehmen, dass in dieser Zeit eine Firma es geschafft haben sollte festzustellen, wie man dieses Problem in ihrem Interesse am besten in den Griff bekommt. Eine Firma hat es tatsächlich geschafft - und wer sonst sollte das gewesen sein als die weltweit größte Softwarefirma - die IBM. In den späten 70ern war die IBM nicht nur die größte Softwarefirma auf diesem Planeten, sondern entwickelte auch die größtmögliche Bandbreite an Software: sie benötigte Betriebssysteme, Anwendungen und andere Werkzeuge.
Es war erforderlich, die Größe (und damit die Kosten) eines Software-Projekts festzustellen. Die dafür entwickelte Technik war die Funktionspunkt-Analyse (FPA). Damit war es möglich, nicht nur die Größe einer Software festzulegen, sondern diese Größe konnte auch über verschiedene Sprachen, Plattformen und Anwendungen verglichen werden. In der Funktionspunkt-Analyse wird die Größe einer Software aus der Sicht des Anwenders (bzw. Kunden) festgestellt. Sie kann eingesetzt werden, um jede Art von Software zu messen - kundenspezifische Datenbanken, Prozesskontrollsysteme, Betriebssysteme, Virenscanner und auch den Assemblercode, der Ihren Toaster, Ihre Uhr oder Ihren Herzschrittmacher steuert.
Unseren ersten Kontakt mit FPA hatten wir auf einer von Bob Kehoe und Ken Florian (beide arbeiten bei Geneer in Chicago) gehaltenen Präsentation. Das Folgende fasst meine Kenntnisse über FPA zusammen. Wenn Sie jemals die Möglichkeit haben, jemand von RDI über Software-Engineering reden zu hören, sollten Sie den Vortrag nicht verpassen.
Traditionelle Methoden der Messung der Größe einer Software benutzten künstliche Definitionen, die durch externe Faktoren gebildet wurden. Eine der Maßeinheiten für die Größe der Software ist die Anzahl der Codezeilen. Diese Anzahl wird aber durch die Programmiersprache (und die Version) genau so beeinflusst wie durch den für die Programmierung angewandten Stil und die Erfahrung des Programmierers.
Ein Programm, das direkt im Maschinencode entwickelt wird, benötigt mehr Codezeilen als das gleiche Programm in C++ geschrieben. Eine neue Version der Sprache könnte Funktionalitäten enthalten, die eine bestimmte Aufgabe mit weniger Codezeilen erledigen - ein einfacher Funktionsaufruf erledigt die Arbeit, die vorher ein Dutzend Codezeilen oder eine ganze Subroutine erfordert hat.
Ein typischer Programmierstil könnte für alle Module je einen Ein- und Ausgang vorschreiben. Diese Anforderung kann immer erfüllt werden. In Abhängigkeit von der Sprache kann die Anforderung "ein Ausgang" aber zusätzliche Schichten des Code erfordern. Dadurch werden weitere Codezeilen produziert im Vergleich zu einem Programmierstil, bei dem an den strategisch wichtigen Stellen die Anweisung "Exit" eingesetzt werden darf.
Letztendlich kann auch die Erfahrung des Programmierers die Zahl der Codezeilen drastisch vermindern. Ein Beispiel dafür wäre ein unerfahrener Programmierer, der seine eigene Routine für die Erledigung einer Aufgabe schreibt ohne zu wissen, dass seine Programmiersprache eine solche Funktionalität bereits enthält, die lediglich aufgerufen werden muss.
Ein anderes Beispiel betrifft den Einsatz der Objektorientierung in einem System. Ein Programmierer, der seine Klassen entwickelt und korrekt einsetzt, erstellt eine Anwendung mit erheblich weniger Codezeilen als ein anderer Programmierer, der seinen Code nicht mehrfach verwendet. Werden die Anwendungen nun nach den Codezeilen bewertet erscheinen sie sehr unterschiedlich, obwohl beide die gleichen Funktionalitäten bieten.
Diese Beispiele haben eins gemeinsam: die Größe des Projekts ändert sich durch Faktoren, die sich außerhalb der Kontrolle des Kunden befinden, der aber letztendlich die Kosten für die Softwareentwicklung tragen muss.
Bei der Funktionspunkt-Analyse handelt sich um ein synthetisches Messverfahren, das nicht an eine Sprache oder Sprachgruppe gebunden ist. Im Grunde ist es nichts anderes als die synthetische Maßeinheit Quadratmeter, mit dem Sie die Größe Ihres Wohnzimmers angeben, die Größe des Tanks Ihres PKW oder die Menge des Regenwaldes, die im letzten Jahr zerstört wurde. Daher kann eine in COBOL geschriebene Anwendung durch die Zählung ihrer Funktionspunkte mit einem anderen in C++ geschriebenen System verglichen werden. Durch den Einsatz der Funktionspunkte können wir eine Buchhaltungssoftware, die in RPG für ein System/32 entwickelt wurde, mit einem in Assembler entwickelten Controllingsystem für eine andere Plattform vergleichen.
Weshalb ist eine synthetische Messmethode besser als die Alternativen?
Anders als die meisten Versuche zum Messen der Größe einer Software bieten die Funktionspunkte einen objektiven Maßstab für die Größe und damit für die erforderliche Zeit und die Kosten. Wenn wir also feststellen, dass ein System 500 Funktionspunkte enthält, ein anderes aber 800 Funktionspunkte, ist es für uns nicht von Bedeutung, in welcher Sprache die Systeme entwickelt sind oder auf welcher Plattform sie ausgeführt werden. Wir wissen lediglich, dass ein System im Vergleich zum anderen 1,6 mal so groß ist. Die Entwicklung dauert also 1,6 mal so lange.
Ein Funktionspunkt ist eine Funktionseinheit, die an den Endanwender ausgeliefert wird. Wie finden wir die Funktionspunkte? Sinn dieses Abschnitts ist es nicht, zu sehr ins Detail zu gehen. Es geht hier um die Hintergründe. Wir wollen das für uns neue System verstehen. Um die Anzahl der Funktionspunkte eines Systems zu ermitteln zählen wir die Anzahl der Eingaben, die Anzahl der Ausgaben, der Abfragen, der internen und externen logischen Dateien sowie ungefähr ein Dutzend anderer Charakteristika des Systems, um die gesamte Komplexität zu ermitteln. Bei diesen Charakteristika (GSCs = General System Characteristics) handelt es sich um Fähigkeiten wie die Datenkommunikation, verteilte Verarbeitung, Transaktionsverarbeitung, automatische Dateneingaben, Onlineupdates, einfache Installation und anderes.
Nachdem wir mit dem Zählen fertig sind, verarbeiten wir die gezählten Punkte in einer Formel und erhalten die Anzahl der Funktionspunkte. Und wie übersetzen wir dieses Ergebnis in bare Münze? Das kann ich Ihnen hier auch nicht abschließend beantworten. Wie bei allen anderen Aufgaben während der Erstellung eines Projekts benötigen Sie auch hier einige historische Daten. Anders gesagt, Sie benutzen Ihre Erfahrungen aus früheren Projekten für die Entscheidung über die Kosten zukünftiger Projekte. Wenn Sie ein Projekt mit 300 Funktionspunkten fertig gestellt haben und dieses $ 300.000 gekostet hat, belaufen sich die Kosten je Funktionspunkt auf $ 1.000. Das nächste Projekt, das 500 Funktionspunkte enthält, wird also $ 500.000 kosten.
Diese Darstellung ist stark vereinfacht (das mache ich im Moment aber viel), aber Sie können daran bereits die Idee erkennen. Stellen Sie sich die Funktionspunkte analog zu den Quadratmetern als Flächenmaß vor. Wir können zwei Gebäude der gleichen Größe vergleichen. Nur hat das eine Haus auf einem unebenen Grundstück errichtet und hat Marmorfußböden, während das andere auf ebenen Grund gebaut wurde und einen billigen Fußboden hat. Die Kosten je Quadratmeter sind natürlich unterschiedlich. Dementsprechend ist die Entwicklung der Oberfläche einer Anwendung in C++ aufwändig und benötigt seine Zeit, da es sich hier um eine Low-Level-Sprache handelt. Wenn Sie statt dessen Assembler einsetzen, wird die Aufgabe noch umfangreicher, während das gleiche Ergebnis in einer Sprache wie Visual Basic einfach und schnell erreicht wird.
Es gibt mehrere Faktoren, die die Kosten pro Funktionspunkt beeinflussen - die eingesetzten Werkzeuge genau wie die Erfahrung des Entwicklers. Die Muliplikatoren werden nur eingesetzt, um die Kosten zu ermitteln. Die Anzahl der Funktionspunkte in einem System bleibt unabhängig vom eingesetzten Werkzeug immer gleich.
Ihr Anwender wird es zu schätzen wissen, dass Sie hier über eine Methodik verfügen, bei der die Preisgestaltung auf den Funktionalitäten beruht, die er sieht und wegen derer er die Anwendung kauft. Verlangt der Anwender nun vier weitere Formulare, zählen Sie einfach die Funktionspunkte neu, jagen diese durch Ihre Formel und erhalten den neuen Preis. Im Prinzip ist es nichts anderes als ein Einkauf im Supermarkt. Während des Einkaufens stellen Sie fest, dass Sie noch 20 Eier benötigen. Sie packen die Eier in Ihren Einkaufswagen, addieren den Preis zu den Waren, die Sie sonst noch gekauft haben und erhalten den neuen Endpreis.
Sie fragen sich jetzt vielleicht, wer die Funktionspunkte zählt. Diese Frage ist einfach zu beantworten: die Funktionspunkt-Zähler. Die Funktionspunkt-Analyse ist ein komplexer Prozess, der einiges Wissen voraussetzt. Daher gibt es eine internationale Organisation, die International Function Point User Group (www.ifpug.org), die definiert, wie Funktionspunkte gezählt werden, und die Schulungen durchführt, in denen Firmen und Einzelpersonen die Zertifizierung für diese Technik erhalten.
Sie können einen Berater engagieren, der für Sie die Funktionspunkt-Analyse einer Anwendung vornimmt und eine unabhängige Zählung durchführt. Warum sollten Sie dies tun, wenn Sie die Zählung doch auch selbst durchführen können? Durch den Einsatz eines neutralen Beraters verfügt Ihr Kunde über eine unabhängige Zählung. Sie müssen dem Anwender also nie mitteilen: "Das System enthält irgendwo 1156 Funktionspunkte, aber die Formel verstehen Sie eh' nicht. Sie müssen mir schon vertrauen."
Bei großen Projekten ist es möglich, dass der Anwender und der Entwickler unabhängig voneinander unterschiedliche externe Firmen mit dem Zählen und Bewerten beauftragen. Wenn sich die Ergebnisse unterscheiden (es handelt sich hier nicht um eine exakte Wissenschaft), muss der Vertrag zwischen dem Anwender und dem Entwickler dafür eine Lösung finden.
Warum setze ich die Funktionspunkt-Analyse nicht ein? Andy Griebel sagt dazu: "Es wäre zu schwierig". FPA ist eine komplexe Methodik - RDI Software ist ein Softwarehaus mit mehreren Millionen Dollar Umsatz und die IBM ist noch größer. Wenn Sie Anwendungen entwickeln, die zwischen $ 10.000 und $ 50.000 kosten, wäre der Einsatz von FPA in der Regel übertrieben. Wenn Sie auf der anderen Seite in ein Projekt einsteigen, für das vier Mannjahre veranschlagt sind und das 2.000 Anwender auf drei Kontinenten bedienen soll, reicht die FPA eventuell nicht aus - auch wenn diese Methode dann immer noch besser ist als gar keine.
Einfach ausgedrückt ist FPA nicht die richtige Wahl, wenn Sie ein Projekt vor sich haben, das etwa sechs Wochen in Anspruch nimmt. Aber auch dann benötigen Sie eine Methode für das Festlegen des Preises - eine Sechs-Wochen-Anwendung, die am Ende vier Monate beansprucht, kann Sie auch in den Ruin treiben.
Ich habe hier die Ideen der FPA verwendet und sie an die Anforderungen meiner Firma als kleinerem Softwareentwickler angepasst. Dann brauchte das Kind noch einen Namen. Zunächst habe ich die Methodik spaßeshalber "Function Point Lite" genannt. Diesen Namen will ich aber nicht aufrecht erhalten, da ich die Anwender von FPA nicht gegen mich aufbringen will. Daher nenne ich sie jetzt Aktionspunkte, da sie zwar auf dem gleichen Konzept wie FPA basiert, sich aber in der Implementierung und Verarbeitung unterscheidet.
Der Sinn der Zählung der Aktionspunkte ist das Schaffen der Möglichkeit, eine ungefähre relative Größe eines Projekts zu erhalten. Dies soll schnell, einfach und mit einem reproduzierbaren Ergebnis geschehen. Behandeln wir diese Ziele kurz.
Genau wie die Funktionspunkt-Analyse ist auch die Aktionspunkt-Analyse keine exakte Wissenschaft. Außerdem ist es nicht der Sinn der Aktionspunkte, einen komplexen Mechanismus zu erstellen, der sämtliche Möglichkeiten ausschöpft.
Zunächst einmal ist es eine irrige Vorstellung, die Größe (Zeitaufwand und Preis) einer Anwendung auf eine genaue Zahl reduzieren zu können. In einer Software stecken viele unbekannte Faktoren, und Sie können einfach nicht erwarten, dass Sie diese Faktoren alle kennen und korrekt berechnen können.
Die Menschen bauen seit Hunderten von Jahren Häuser, aber immer noch kommt es vor, dass ein Hausbau das Budget sprengt. Warum das? In jedem Bauprojekt stecken Unwägbarkeiten, die sich einer Kontrolle entziehen. Das Wetter macht ein Weiterarbeiten unmöglich. Ein Handwerker wartet auf eine Lieferung. Die Gewerkschaft ruft zum Streik auf. Beim Ausheben der Baugrube trifft der Bagger auf einen großen Felsen oder einen rostigen Öltank. Für das Beseitigen dieser Hindernisse war aber kein Geld vorgesehen.
Diese Probleme treten in einem gut geplanten Projekt auf, für das Planungsunterlagen und lange bekannte Standards bestehen. Die Steine, der Stahl und das Glas werden von Menschen verarbeitet, die diese Aufgaben bereits seit Jahren erledigen. In der Softwareentwicklung haben wir es mit Spezifikationen unbekannter Herkunft und unbekannter Genauigkeit zu tun, die Entwickler sind unterschiedlich erfahren, die eingesetzten Werkzeuge sind neu, ungetestet und eventuell fehlerhaft. Und letztendlich wissen die Anwender nicht genau, was sie wollen. Kostenüberlauf? Welch eine Überraschung.
Die gleichen Probleme können auch bei der Entwicklung einer Software auftreten, selbst wenn sie sehr gut geplant war. Ein OCX, das immer korrekt gearbeitet hat, verhält sich nach der Installation eines Servicepacks für das Betriebssystem nicht mehr wie gewohnt. Das Format einer Datendatei, das in einem der Importprozesse beschrieben ist, stellt sich als falsch heraus - und schon fällt eine Menge zusätzlicher Arbeit an, um die Daten für den Gebrauch innerhalb des Systems aufzuarbeiten.
Die Größe einer Software ist ein Maßstab für die Aufgaben, die erledigt werden müssen. Jede dieser Unwägbarkeiten ändert die Größe dieser To-Do-Liste. Häufig wissen wir nicht, wie viele Aufgaben der Aufgabenliste hinzugefügt werden und erst recht nicht, wie viel Zeit diese Aufgaben in Anspruch nehmen. Nehmen wir noch einmal das OCX als Beispiel: um es mit einem neuen Servicepack korrekt auszuführen, kann es ausreichend sein, eine Abfrage auf die Datenbank des Kunden auszuführen, um einen Aufrufparameter, die wir bislang ignorieren konnten, neu zu setzen. Es kann aber auch zwei Wochen Arbeit mit dem Entwicklungsteam bedeuten exakt herauszufinden, wo der Grund dieses Problems liegt und eine weitere Zeit des Wartens, während das OCX komplett neu entwickelt wird.
Der Sinn der Zählung der Aktionspunkte lag in der Entwicklung einer Kostenschätzung - und diese Kosten werden festgehalten. Ob die Kosten sich auf $ 23.105 oder $ 23.220 belaufen macht nicht wirklich den Unterschied. Wichtig ist es zu erkennen, wo die Kosten entstehen, so dass Sie nicht ein Projekt, das $ 55.000 verschlingt, mit $ 35.000 veranschlagen.
Was haben Sie von einer exzellenten Methodik zur Kostenschätzung, wenn Sie ihnen drei Wochen Arbeit einbringt und Sie $ 10.000 kostet und Sie am Ende erkennen, dass die Kosten der Entwicklung $ 15.000 betragen? Warum sollten Sie mehr Zeit in die Schätzung investieren als in die Entwicklung?
Diese Kosten müssen irgendwo in die Schätzung einfließen, und es ist wahrscheinlich, dass andere Entwickler diese Summe nicht in die Schätzung einbringen. Wenn Sie die Kosten doch berechnen, können Sie sich Nachteile einhandeln. In der Zeit, in der Sie die Funktionalitäten feststellen, wollen Sie möglichst auch gleich die Kosten feststellen und damit ist gut. Wenn die Schätzmethode zu viel Zeit in Anspruch nimmt ist es möglich, dass Sie die Sache zu sehr vereinfachen und einiges unter den Tisch fällt. Das widerspricht aber unserem ursprünglichen Ziel, oder?
Die Aktionspunkte für eine $ 100.000-Anwendung können Sie in wenigen Stunden zählen.
Die Zählung der Aktionspunkte ist keine intellektuelle Herausforderung, und das ist gut so. Ist es nicht eine gute Sache, wenn Sie jemand anderen beauftragen können, die Routinearbeit des Zählens zu erledigen und Sie müssen lediglich die Gegenprobe machen?
Die Zählung der Aktionspunkte ist einfach und kann durch eine Hilfskraft oder jeden anderen halbwegs intelligenten Mitarbeiter erledigt werden.
Eine Methodik, die jedes Mal ein anderes Ergebnis ergibt, ist nutzlos. Stellen Sie sich vor, Sie geben zweien Ihrer Entwickler das gleiche Pflichtenheft und jeder errechnet einen anderen Wert. Das wäre nicht sehr hilfreich. Was machen Sie, wenn Sie zwei Kalkulationen vor sich haben? Nehmen Sie die höhere? Das ist nicht sinnvoll, wenn sich auch andere Firmen um den Auftrag bemühen. Nur mal nebenbei: woher wissen Sie, dass diese Kalkulation die richtige ist? Was ist, wenn beide Entwickler Fehler gemacht haben und die echten Kosten liegen höher als beide Kalkulationen?
Wenn Sie erst einmal Ihre Maßeinheit entwickelt haben - die Multiplikatoren für spezielle Objekttypen, die auf den Erfahrungen Ihrer Firma aufbauen - können Sie zwei Personen mit der Zählung beauftragen, und beide kommen zu dem gleichen Ergebnis, da hier nur wenig Platz für individuelle Annahmen ist.
Die Zählung der Aktionspunkte erfordert eine strenge Spezifikation. Dort muss exakt aufgeführt sein, welche Aufgaben das System erfüllen soll, welche Regeln befolgt werden müssen sowie die Komponenten jedes Formulars, Prozesses und Berichts.
Die Grundidee der Zählung der Aktionspunkte entspricht der der Funktionspunkt-Analyse: Arbeite Dich durch das Pflichtenheft und zähle die "Dinge" auf jedem Formular, in jedem Bericht und jedem Prozess. Anschließend multipliziere die "Dinge" mit einem "Gewichtungsfaktor", der darauf beruht, um welche Art "Ding" es sich handelt. So erreichen Sie die endgültige Menge der Aktionspunkte. Zuletzt multiplizieren Sie die Anzahl der Aktionspunkte mit den Kosten pro Aktionspunkt und erhalten so die Gesamtkosten. Darauf, was ein "Ding" ist, gehen wir noch ein. Im Moment gehen Sie aber davon aus, dass ein "Ding" eines dieser technischen Konzepte ist, die Ihr Lebenspartner und Ihr Kind nicht verstehen.
Sehen wir uns ein Beispiel an. Das Formular scheint fünf "Dinge" zu beinhalten - zwei Labels, eine Schaltfläche, eine Checkbox und eine Listbox. Für den unbedarften Betrachter nicht sichtbar, aber für jeden, der das Pflichtenheft gelesen hat, enthält das Formular noch zwei Prüfroutinen und eine Regel auf der Ebene des Formulars. Die Prüfroutinen beziehen sich auf die Checkbox und die Listbox, die Regel auf der Ebene des Formulars wird ausgeführt, wenn auf die Schaltfläche geklickt oder das Formular geschlossen wird.
Abbildung 1. Beispielformular für die Berechnung der Aktionspunkte
Dieses Formular erscheint sehr einfach, und für Entwickler, die mit Visual Basic, C++ und Visual FoxPro arbeiten, ist es dies auch. Wenn Sie aber Webanwendungen entwickeln, ist es schon recht skurril die Auswahl so zu gestalten. Und wenn Sie für den Handheld arbeiten, kann dieses Formular bereits zu komplex sein. Lassen wir das, die Idee haben Sie verstanden.
Auf jeden Fall enthält das Formular alle Komponenten, die wir benötigen, um die Arbeitsweise des Zählens der Aktionspunkte zu behandeln.
Wenn Sie die "Dinge" auf dem Formular zählen erhalten Sie eine Tabelle, die wie die folgende aussieht:
| Name des Formulars | Anzahl Labels | Anzahl Schaltflächen | Anzahl Checkboxen | Anzahl Listboxen | Anzahl Regeln | Anzahl Regeln auf der Eben e des Formulars |
|---|---|---|---|---|---|---|
| Form A | 2 | 1 | 1 | 1 | 2 | 1 |
Das Formular Form A enthält 2 Labels, 1 Schaltfläche, 1 Checkbox, 1 Listbox, 2 Prüfregeln (Sie sehen sie nicht auf dem Bildschirm, wissen aber, dass die hinter der Checkbox und der Listbox vorhanden sind, da Sie das Pflichtenheft gelesen haben), sowie eine Regel auf der Ebene des Formulars.
Wenn Sie ein Framework, einen Anwendungsgenerator oder wiederverwendbare Module einsetzen fragen Sie sich jetzt vielleicht, wie die dort vorgefertigten Teile in diesen Prozess passen. Wie wird es zum Beispiel behandelt, wenn es sich bei der Schaltfläche um einen Teil einer Formularklasse handelt, mit der das Formular erstellt wurde?
Die kurze Antwort ist, dass diese Problematik hier nicht behandelt wird. Wir wenden uns diesem Thema zu, wenn wir die tatsächlichen Kosten auf der Grundlage der Aktionspunkte ermitteln.
Jede Art "Dinge" wird anders bewertet, da einige "Dinge" komplexer als andere sind. So ist beispielsweise ein Label schnell und einfach auf dem Formular untergebracht, aber es sehr schwierig, einem Label weitere Funktionalitäten hinzuzufügen. Auf der anderen Seite erfordert die Anlage einer Listbox erheblich mehr Arbeit, während sie einfacher zu erweitern ist. Lassen Sie uns der Einfachheit halber annehmen, ein Label hat eine Gewichtung von 1, Schaltflächen und Checkboxen von 2, Listboxen werden mit 4 gewichtet, Prüfroutinen mit 6 und eine Regel auf der Ebene des Formulars hat die Gewichtung 10.
Daher werden die oben gemachten Zählungen mit den Faktoren multipliziert, etwa so:
| Name des Formulars | Anzahl Labels | Anzahl Schaltflächen | Anzahl Checkboxen | Anzahl Listboxen | Anzahl Regeln | Anzahl Regeln auf der Ebene des Formulars |
|---|---|---|---|---|---|---|
| Form A | 2*1 | 1*2 | 1*2 | 1*4 | 2*6 | 1*10 |
Wir multiplizieren die Anzahl der Objekte mit der Gewichtung dieser Objekte, um die Gesamtanzahl der Aktionspunkte zu ermitteln.
Auch das Formular selber erhält in Abhängigkeit von der Art des Formulars eine Gewichtung. Formulare können einfache Verwaltungsformulare sein, es kann sich um komplexe Formulare zur Dateneingabe handeln oder sie können Auswahllisten enthalten. Jede dieser Formulararten hat eine andere Gewichtung. Unser Beispielformular habe ich mit 0,1 gewichtet, da es sehr einfach ist. Die Ergebnisse der Zählung werden mit den Gewichtungen der Kontrollelemente multipliziert und die sich daraus ergebenden Produkte werden zu einem Zwischenergebnis addiert. Dieses Zwischenergebnis wird mit der Gewichtung des Formulars multipliziert, um einen Wert für das Formular zu erhalten.
| Name des Formulars |
Anzahl Labels | Anzahl Schaltflächen | Anzahl Checkboxen | Anzahl Listboxen | Anzahl Gültigkeitsregeln | Anzahl Regeln auf Formularebene | Formulartyp | Gewichtung | Aktionspunkte |
|---|---|---|---|---|---|---|---|---|---|
| Aktions-punktformular |
2*1 |
1*2 | 1*2 | 1*4 | 2*6 | 1*10 | Einfach | 0,1 | 3,2 |
Es gibt keine absolute Reihenfolge der Gewichtungen. Alle Werte sind hier relativ. Sie könnten entscheiden, dass eine einfache Messagebox eine Wertigkeit von 1 hat und die anderen Wertigkeiten hiervon ableiten, oder Sie werten ein einfaches Formular für die Dateneingabe mit 1 und leiten davon die Wertigkeiten der anderen Formulare ab. Es gibt auch keine maximale Bewertung, da es schlecht abzuschätzen ist, wie problematisch die Entwicklung eines Formulars werden kann.
Dieser Basisprozess wird, wenn auch in detaillierterer Form, für sämtliche Formulare, Berichte und Prozesse der Anwendung durchgeführt. Dadurch erhalten wir die Gesamtzahl der Aktionspunkte der Anwendung.
Vielleicht haben Sie ja eine komplette Liste der Formulare, Berichte, Prozesse usw. Die ist aber "nur für den internen Gebrauch". Eventuell geben wir dem Kunden eine Liste mit Modulen und Preise, die den einzelnen Modulen zugeordnet sind. Genauer als für die Module geben wir dem Kunden aber keine Preise an.
Der nächste Schritt besteht darin, die Anzahl der Aktionspunkte des Systems mit den Kosten pro Aktionspunkt zu multiplizieren und wir erhalten die Gesamtkosten. Einfach genug? Lesen Sie weiter.
Nun sind wir fast fertig. Der letzte Schritt ist die Multiplikation der Aktionspunkte der gesamten Anwendung mit den Kosten pro Aktionspunkt. Damit erreichen wir die Gesamtkosten, etwa so:
| Name des Formulars | Aktionspunkte | Kosten pro Aktionspunkt | Gesamtkosten |
|---|---|---|---|
| Aktionspunkt-Formular | 3,2 | € 100 | € 320 |
Wie Sie sehen, würde das Formular $ 320 kosten. (Sie meinen, das wäre zu viel? Sie kennen aber die Regeln nicht). Beachten Sie, dass dies nicht der endgültige Preis ist. Der kommt später. Der Sinn der Aktionspunkte ist die Ermittlung der Kosten. Mit dieser Methodik können Sie die Kosten jedes Teils einer Software ermitteln.
Wenn Sie diese Übung einige Male durchgeführt haben werden Sie in der Lage sein, Teile Ihrer Anwendung zu vergleichen und zu bewerten. Sie werden erstaunt sein, wenn Sie feststellen, dass das eine Formular mit dem hässlichen Pageframe und mehreren Grids preiswerter zu erstellen ist als ein einfaches Formular für die Verwaltung einer einzelnen Tabelle, das aber Daten von vielen unterschiedlichen Datenquellen erhalten muss.
Jetzt wundern Sie sich gewiss über einige Dinge in diesem Artikel. Als Erstes haben wir Ihnen eine technischere Definition des "Ding" versprochen. Dann sind Sie zweifellos neugierig, wie die Gewichtung jeder Art des "Ding" zustande kam. Außerdem würden Sie sterben für die Information, wie wir die magischen $ 100 pro Aktionspunkt errechnet haben. Für jetzt ist es aber genug zu wissen, dass wir uns die Zahlen für dieses Beispiel ausgedacht haben. Aber es dauert nicht mehr lange, bis wir Ihnen zeigen, wie Sie reelle Nummern erhalten, die Sie auch tatsächlich benutzen können.
Jetzt waren Sie lang genug geduldig. Lassen Sie uns jetzt einen genaueren Blick auf die "Dinger" werfen. Diejenigen von Ihnen, die über ein gutes Gedächtnis verfügen oder die kleine Kinder haben, wissen bereits, dass ein "Ding" etwas mit unbestimmtem Geschlecht und Alter ist, dessen Hauptaufgabe darin besteht, die größtmögliche Unordnung anzurichten und ständig im Weg zu sein. Wir können aber noch weiter in die Details gehen.
Ein Formular ist jede fensterbasierte Benutzerschnittstelle, die auf dem Monitor eines Rechners angezeigt wird. Wenn Sie Software für eine Oberfläche entwerfen, die nicht im Fensterstil aufgebaut ist, müssen Sie diese Techniken für Ihre Zwecke anpassen.
Die Arten der "Dinge", die auf einem Formular angezeigt werden, differieren je nach dem von Ihnen eingesetzten Entwicklungswerkzeug. Sie haben ja bereits erfahren, wie ein Basisformular aussieht und wie einige typische Arten an "Dingen" gezählt und gewichtet werden könnten. Welche weiteren Details der Arten der "Dinge" gibt es auf einem Formular und wie könnten diese gewichtet werden?
Die "dummen" Dinge, wie Labels, Bilder und andere "nur zum Ansehen"-Dinge haben eine minimale Gewichtung, da Sie, nachdem sie einmal auf dem Formular platziert und richtig dimensioniert wurden, keinerlei weitere Arbeit machen. Bei diesen Dingen kann auch nicht viel schief laufen. Wenn die Notwendigkeit besteht, dass bei einem Klick auf ein Label oder ein Bild eine Aktion ausgeführt wird oder dass in Abhängigkeit mit einem anderen Ereignis unterschiedliche Texte oder Bilder angezeigt werden sollen, so wird dies von einer Prüfung oder einer Regel auf der Stufe des Formulars gesteuert.
Die nächste Gruppe an Dingen, die auf einem Formular platziert werden können, umfasst Textfelder, Editboxen und Optionsgruppen, Checkboxen und ähnliches. Alle haben gemeinsam, dass sie mit einem Feld einer Tabelle verbunden werden können. Daher ist einige Arbeit erforderlich um sicherzustellen, dass die Relation arbeitet. Dies ist in der Regel aber keine schwierige Aufgabe.
Die dritte Gruppe an Dingen, die wir auf einem Formular platzieren können, bilden komplexe Objekte wie Listboxen, Comboboxen, Grids, Drehfelder und ähnliche Kontrollelemente. Selbst wenn diesen Objekten keine Regeln hinzugefügt werden müssen, benötigen sie doch einigen Aufwand, damit sie beginnen können zu arbeiten.
Bei der vierten Gruppe handelt es sich um Dinge, die auf Aktionen des Anwenders reagieren, also Schaltflächen und Pageframes. Diese Objekte sind zwar nicht an Daten gebunden, aber normalerweise enthalten sie Regeln. Die Regeln werde ich gleich noch näher behandeln - aber vergessen Sie nicht, die Objekte selbst zu zählen.
Befassen wir uns jetzt mit der Magie - dem Code, der unterhalb der Objekte liegt und den der Anwender nicht sieht, obwohl er die Auswirkungen des Wirkens des Code ständig fühlt. Der Code kommt generell in einer von zwei Formen vor - als Prüfroutine, die speziell für ein einzelnes Objekt entwickelt wird, und als Regel auf der Stufe des Formulars, die für mehrere Objekte zuständig ist.
Nachdem Sie alle Dinge auf und unter dem Formular abgehandelt haben können Sie nun das Formular selbst beurteilen - wie komplex ist es? Für das Framework, das wir einsetzen, teilen wir die Formulare in fünf oder sechs Grundformen ein, die wir als "Eimer" benutzen. Wir finden, dass dieses Vorgehen einfacher ist als für jedes denkbare Formular einen eigenen Typ zu erstellen und diesen zu gewichten, wobei sich die Typen kaum voneinander unterscheiden würden. Außerdem verfügen wir über ein "Anpassungsfeld", die genutzt werden kann, um dem Formular insgesamt Aktionspunkte hinzuzufügen oder herauszunehmen. Dies ist sinnvoll, um Situationen abzuhandeln, in denen die Zählungen, Gewichtungen und die Formulargewichtung an ihre Grenzen stoßen.
Letztendlich haben wir noch ein Multiplikatorenfeld für das Formular insgesamt. Die Multiplikatoren, die das gesamte Formular betreffen, basieren dem einfachen Hinzuzählen einiger Aktionspunkte auf mehreren Faktoren. Dazu gehören unter anderen die folgenden Punkte:
Insgesamt ermöglichen es diese Gewichtungen und Multiplikatoren, Aktionspunkte für jedes Formular unabhängig von dessen Komplexität zu vergeben.
Ein Prozess ist eine Operation, die ohne den Einfluss des Anwenders ausgeführt wird und die keine Oberfläche benötigt. Beachten Sie, dass einige Prozesse ein Formular benötigen könnten, um dem Anwender die Möglichkeit zu geben, den Prozess zu beeinflussen. Nachdem der Prozess gestartet ist, erfordert er aber keine weitere Interaktion. Das den Prozess aufrufende Formular wird als Formular gezählt, nicht als Teil des Prozesses.
Prozesse sind trickreich - sie scheinen zu keiner der oben aufgeführten Arten zu gehören. Es macht mehr Arbeit, die Aktionspunkte in einem Prozess zu zählen. Wir haben aber hier einen Grundstock gelegt, auch wenn noch weitere Verfeinerungen erforderlich sind.
So weit lassen sich Prozesse generell in die folgenden Operationen aufteilen:
Haben wir mit dieser Aufzählung die gesamten Möglichkeiten innerhalb von Prozessen erfasst? Wohl nicht. In den letzten fünf oder sechs Jahren haben wir aber festgestellt, dass wir mit diesen Punkten die meisten Dinge erfassen, die routinemäßig ausgeführt werden. Damit kommen wir dem Ziel der Größenschätzung eines Prozessmoduls schon erheblich näher als die Bemerkung "Ich denke mal, dass die Erstellung dieses Prozesses drei Tage in Anspruch nehmen wird".
Sie werden sich auch wundern, wie diese "Dinge" gezählt werden können ohne den Code selbst zu schreiben. Um das Pflichtenheft so schreiben zu können, dass keine Missverständnisse auftreten können, müssen Sie über die durchzuführenden Operationen detailliert Bescheid wissen. Beispielsweise müssen Sie eine Ausnahme beschreiben und dabei angeben, welche Felder sich in einem neuen Datensatz befinden müssen usw.
Und denken Sie daran: sowohl das Pflichtenheft als auch Ihr Schätzmechanismus können jederzeit geändert werden!
Bei einem Bericht handelt es sich um jede Ausgabe, die durch den Anwender aufgerufen wird. Dabei kann es sich um einen Ausdruck auf Papier handeln, er kann aber auch auf dem Monitor angezeigt oder in eine Datei auf dem gleichen oder einem anderen Rechner ausgegeben werden. Wenn wir über die unterschiedlichen "Dinge" reden, die wir auf einem Bericht platzieren können, kann es hilfreich sein, wenn Sie sich einen gedruckten Bericht vorstellen.
Die erste Art Dinger, die wir auf einem Bericht finden, sind genau wie beim Formular dumme Dinger, beispielsweise ein Label, ein Kasten oder ein Hintergrund. In der Regel sind diese Dinge einfach, sie könnten aber auch einer Regel gehorchen müssen, beispielsweise "der Hintergrund soll nur angezeigt werden, wenn der Prozentsatz höher als 10 % ist".
Die Ausgabe von Daten bildet die zweite Art Dinger - Daten eines Feldes einer Tabelle werden im Bericht ausgegeben. Damit sind keine berechneten Felder oder Felder mit Regeln gemeint, die zu einer speziellen Ausgabe führen (wie beim Hintergrund). Der Grund für die Differenzierung zwischen einfacher Ausgabe eines Feldes und berechneten Werten liegt in der Zweiteilung der Erstellung eines Berichts. Zunächst erstellen wir einen temporären Cursor, der in der Form einer denormalisierten Tabelle sämtliche benötigten Daten enthält. Anschließend platzieren wir diese Felder auf einem Bericht. Dieser Vorgang ist einfach. Berechnete Felder erfordern zusätzliche Arbeit, so dass sie separat gezählt werden.
Die dritte Art der Dinger wird durch die gerade besprochenen berechneten Felder gebildet.
Die Anzahl der im Bericht benötigten Gruppen bildet die vierte Gruppe. Dafür gibt es zwei Gründe: zum Einen müssen in der Regel die Felder in jeder Gruppe speziell positioniert werden, zum Anderen müssen berechnete Felder und Zwischensummen als zu der Gruppe gehörend gekennzeichnet werden.
Wir haben für unsere Anwendungen über Jahre ein zugekauftes Tool für die Erstellung von Berichten verwendet. Dieses Tool erforderte einige spezielle Einstellungen. Daher konnten wir im Data Dictionary des Tools noch einen Platz für das Zählen der Berichts-"Dinge" einrichten.
Stabil laufende Anwendungen verwenden grundsätzlich ein Data Dictionary und benötigen Testdaten, ein Menü, eine indizierte Hilfedatei und andere Punkte, die alle erstellt werden müssen. Ihr Entwicklungssystem kann noch weitere Punkte beinhalten. Das Problem liegt darin, dass Sie alle diese "Dinge", mit denen die Grundlagen eines neuen Systems gebildet werden, aufteilen und zählen müssen.
Vielleicht denken Sie jetzt noch an andere Dinge. Wie sieht es aus, wenn eine Anwendung über eine Toolbar verfügt? Werden die Schaltflächen der Toolbar wie die anderen Schaltflächen behandelt? Wie gehe ich mit Regeln um, die sich im Data Dictionary befinden? Was ist mit Triggern? Was geschieht mit Anwendungen, die auf mehreren Plattformen laufen müssen? Wie sieht es aus, wenn die Anwendung mit unterschiedlichen Menüs arbeitet, die in Abhängigkeit vom momentanen Benutzer gewechselt werden? Auf welche Weise werden Sicherheitsfunktionalitäten behandelt - Anwenderstufen, Zugriffsmöglichkeiten auf der Ebene des Formulars und des Kontrollelements?
Wahrscheinlich fragen Sie jetzt: "Was mache ich mit den Myriaden anderer Dinge einer Anwendung, die in keine der oben beschriebenen Kategorien passen?" So enthalten viele Windows-Anwendungen ActiveX-Kontrollelemente, Hyperlinks auf Webseiten usw. Wo werden diese Dinge in den Kosten berücksichtigt? Muss ich jetzt zu Schätzen anfangen?
Es gibt einen besseren Weg. Wir haben ein Konzept genommen - zählen, gewichten, multiplizieren und summieren der Dinge in einer Anwendung - und auf unsere Art der Entwicklung kundenspezifischer Software angewandt. Wir entwickeln individuelle Datenbankanwendungen mit vielen allgemeinen Bibliotheken, setzen Werkzeuge von Drittanbietern ein und haben das Zählen der Aktionspunkte im Hinblick darauf entwickelt.
Wahrscheinlich arbeiten Sie mit anderen Tools als wir. Sie müssen also die hier beschriebene Technik Ihren Bedürfnissen entsprechend anpassen. Sie werden andere Arten "Dinge" hinzufügen, einschließlich Methoden der Zählung der "Dinge" abhängig von Ihrem Stil der Softwareentwicklung.
Verwechseln Sie aber die von Ihnen eingesetzten Tools nicht mit Dingen, die Sie noch nie eingesetzt haben. Nehmen Sie zum Beispiel an, Ihr Kunde erwartet, dass Ihre Anwendung Webseiten generiert und diese an einen entfernten Server liefert. Die Generierung der Webseiten klingt einfach - Sie können hier die "Dinge" in ähnlicher Weise zählen wie bei der Generierung einer Standard-Textdatei. Aber die Auslieferung an den remoten Server? Aber lesen Sie weiter.
Stellen Sie sich vor, Sie müssen zum ersten Mal einen HTML-Generator eines Drittherstellers einsetzen, der erst vor drei Monaten freigegeben wurde. Wie zählen Sie die "Dinge" in einer solchen Situation? Oder Sie müssen mit einem Ihnen unbekannten ActiveX-Kontrollelement arbeiten, das Sie im Web gefunden haben, das aber als einziges die Anforderungen Ihres Kunden erfüllt.
Dies ist im Wesentlichen R&D - Research and Development - eine Aufgabe, für die Sie keinen Festpreis nennen können. Auch Ihr Kunde kann keinen festen Preis nennen, wenn er beispielsweise ein neues Heilmittel entwickelt. R&D ist per Definition undefiniert und es ist nicht möglich, einen Festpreis für etwas zu nennen, das nicht definiert ist.
Was machen Sie nun?
Als Erstes trennen Sie den R&D-Teil vom Rest der Aufgabe. Machen Sie Ihrem Kunden klar, dass diese spezielle Komponente oder das spezielle Modul (oder was immer auch R&D erfordert) nicht im Festpreis dabei ist. Dann haben Sie die Auswahl zwischen zwei Möglichkeiten: Die erste Möglichkeit ist, die Entwicklung auf Basis von Zeit und Material durchzuführen, bis sie zur Zufriedenheit Ihres Kunden beendet ist. Dies ist der Fall, wenn die Funktionalität der des Pflichtenhefts entspricht oder wenn Ihr Kunde es leid ist, Geld in die Entwicklung zu stecken und erklärt, dass es jetzt gut genug ist.
Die zweite Möglichkeit ist es, den R&D-Teil zu entwickeln, bis ein bestimmtes Budget erschöpft ist. Anders ausgedrückt: machen Sie eine Schätzung, benutzen Sie diese als Höchstgrenze und erklären: "Wir benutzen das Ergebnis , das in diesem finanziellen Rahmen erreicht werden kann". Bedenken Sie, dass auch Ihr Kunde eine Firma führt und weiß, bis zu welchem Punkt das gewünschte Feature gewinnbringend ist. Wenn diese Schwelle erreicht ist, ist die Implementierung nicht mehr sinnvoll.
Mindestens: identifizieren Sie R&D und trennen Sie diesen Teil vom Rest. Wenn Ihr Kunde auf einem Festpreis für eine die gewünschte Funktionalität in einem unbekannten oder undefinierten Prozess besteht - suchen Sie sich einen neuen Kunden.
Zweifellos ist die Gewichtung der einzelnen Arten der "Dinge" eines der wichtigsten Teile dieser Methodik. Ich gebe es zu - wir haben auch keinen wissenschaftlichen Algorithmus für die Entscheidung, dass ein Label eine Gewichtung von 1 hat, während wir einer Checkbox eine 4 zuordnen und einer Listbox eine 4.
Wenn Sie in eine Fabrik gehen, die Haartrockner oder Drehbänke herstellt stellen Sie fest, dass dort ein Mensch mit wichtigem Gesicht und einem wichtigen Titel ein Klemmbrett und eine Stoppuhr durch die Werkhallen trägt. Seine Aufgabe ist es, die einzelnen Arbeitsschritte zu definieren, die für die Erledigung einer Produktion notwendig sind und anschließend die Zeit zu messen, die die Arbeiter am Fließband für die Ausführung dieser Arbeitsschritte benötigen. Nach einigen Tagen oder Wochen stehen die Zeiten fest. Für die Montage eines Haartrockners sind 3 Minuten und 50 Sekunden erforderlich. Jede Sekunde dieser Zeitspanne ist verplant: 14 Sekunden sind erforderlich, um das Gehäuse von einer Palette zu nehmen und es auf dem Arbeitsplatz zu befestigen. Innerhalb von 22 Sekunden wird der Motor eingelegt und eine Schraube angesetzt. Weitere 7 Sekunden werden benötigt, um die Schraube mit dem elektrischen Schraubenzieher zu fixieren. Und so geht es weiter.
Glauben Sie es oder nicht - wir haben bei uns keine Zeitnehmer, die bei jedem Entwickler die Zeiten stoppen und die Dauer aufzeichnen, die es erfordert, eine Checkbox auf einem Formular zu platzieren und sie mit der Zeitspanne vergleichen, eine Combobox zum Arbeiten zu bewegen. Seien wir realistisch - wo findet man jemanden, der so wild auf einen Job ist, dass er das akzeptieren würde?
Statt dessen haben wir während der Entwicklung der Formulare beobachtet, wie groß die Unterschiede bei der Arbeit mit den unterschiedlichen Objekten sind. Ist diese Methodik exakt? Nein. Ist sie für unsere Zwecke gut genug? Ja.
Jeder möchte einen schnellen Zugriff haben und wir hätten gerne Geld für jedes Mal bekommen, bei dem uns jemand nach einer Kopie unserer Gewichtungen gefragt hat. Aber Sie müssen schon auf der Grundlage Ihres Entwicklungsstils und Ihrer Erfahrungen mit der Entwicklungsumgebung Ihre eigenen Gewichtungen entwickeln. Ein sehr erfahrener Entwickler hat vielleicht eine geringere Bandbreite der Gewichtungen, da er verschiedene automatisierte Werkzeuge einsetzt, die ihm beim Aufbau der Formulare helfen und da er die Tipps und Tricks der unterschiedlichen Kontrollelemente beherrscht. Ein weniger erfahrener Entwickler benutzt für ein einfaches Kontrollelement vielleicht die gleiche Gewichtung, für ein komplexeres Kontrollelement aber eine höhere als Sie.
Sehen Sie die Gewichtungen analog zum Erlernen des Weitsprungs. Sie könnten andere Weitspringer beobachten, deren Techniken übernehmen und sie kopieren. Es wäre aber nicht gut, die Anzahl der Schritte zu übernehmen, da jeder Mensch anders ist und daher auch seine Schritte - einschließlich der Schrittlänge, der Kraft seiner Beine und der Geschwindigkeit. Wenn die physikalischen Attribute nicht identisch sind, wird die Kopierung der Schritte keinen optimalen Sprung bringen.
Jetzt haben wir alle Zählungen der Aktionspunkte in den verschiedenen Formularen, Berichten, Prozessen und den anderen Dingen beisammen. Nun ist es an der Zeit sich mit dem zu befassen, das die Anwender der Funktionspunkt-Analyse "General System Characteristics" nennen.
Wenn Sie eine Anwendung auf einem simplen LAN mit vier Rechnern installieren ist dies erheblich einfacher, als wenn die Anwendung auf drei Kontinenten laufen soll, dabei auch auf Notebooks eingesetzt wird, wobei noch ein remoter Prozess auf dem EvilAlienOS bedient werden muss.
Wir benötigen also noch einen letzten Multiplikator für die gesamte Anwendung, der auf der Beziehung mit dem Rest der IT-Umgebung der Firma basiert.
Noch einmal: wie Sie mit diesem Multiplikator umgehen ist von der Art der Anwendungen abhängig, die Sie entwickeln. Wenn Sie in der Regel Client/Server-Anwendungen entwickeln, bei denen ein in Visual Basic entwickeltes Frontend auf eine Oracle-Datenbank zugreift und daneben noch Single User-Anwendungen erstellen, die auf Notebooks eingesetzt werden, verfügen Sie über zwei anwendungsweite Multiplikatoren. Sollten Sie dann eine neue Anwendung entwickeln, beispielsweise für Handhelds oder für eine verteilte Architektur unter einem neuen Betriebssystem, müssen Sie zusätzliche Multiplikatoren einsetzen.
Bislang haben wir unser Thema immer aus der Perspektive "Ich arbeite an einem brandneuen System" betrachtet. Wie sieht es aber aus, wenn Sie an Erweiterungen einer bestehenden Anwendung arbeiten? Wenn Sie eine Anwendung erweitern, die mit einer älteren Version Ihrer Entwicklungsumgebung erstellt wurde und Sie sowohl bestehenden Code ändern als auch neue Funktionalitäten hinzufügen? Wie werden in einem solchen Fall die Zählungen und Gewichtungen behandelt?
Sie können diese Methodik auch für die Erstellung einzelner Komponenten einer Anwendung einsetzen, genau als wenn Sie eine vollständige Applikation entwickeln.
So weit es um Erweiterungen eines bestehenden Systems geht, das in einer älteren Version des Entwicklungswerkzeugs geschrieben wurde, kann ich die Frage nicht aus eigener Erfahrung beantworten, da meine Firma solche Aufgaben selten ausführt. Die Antwort könnte aber sein, den gleichen Analyseprozess zu durchlaufen, die Funktionalitäten zu identifizieren und die anfallenden Arbeiten zu zählen und zu gewichten. Ich behaupte nicht, dass das einfach ist. Es sieht nach ähnlich viel Arbeit aus wie bei einem neuen System, aber es dürfte eine Lösung sein, sich mit einem leeren Blatt Papier hinzusetzen und die Funktionalitäten zu trennen.
Was geschieht, wenn das Projekt teilweise fertiggestellt ist und plötzlich ein neuer Manager kommt, der die Hälfte der Aktionspunkte aus einem Projekt herausnimmt? Kostet das Projekt dann die Hälfte? Selbstverständlich können Sie nicht einfach diese Aktionspunkte weglassen - Sie müssen wahrscheinlich für einen sauberen Projektabschluss sorgen, auch wenn die unvollständigen Teile nicht weiterentwickelt werden.
Diese Anfrage - das Verstümmeln einer Anwendung, während sie entwickelt wird - fällt unter die Kategorie "Erweiterungen" und muss genau wie jede andere Erweiterung spezifiziert und mit Hilfe von Aktionspunkten festgehalten werden. Sie müssen sich darüber im Klaren sein, dass Sie eventuell schwierige Verkaufsgespräche führen müssen. Wenn eine Anwendung plötzlich verkleinert wird, sind wahrscheinlich Umstrukturierungen beim Kunden im Gange und Ihre Gesprächspartner wollen in einem solchen Fall wahrscheinlich nicht hören, dass sie nicht einfach den Hahn zudrehen können. Sie könnten die Analogie eines Atomkraftwerks benutzen. Wenn es abgeschaltet werden soll, kann man auch nicht einfach einen Schalter umlegen und anschließend die Tür hinter sich schließen.
Die andere magische Zahl, die wir verwendet haben, sind die $ 100 je Aktionspunkt. Wahrscheinlich ist dies die interessantere Zahl, da jeder seine eigenen Vermutungen in Bezug auf die Gewichtung der "Dinge" hat.
Die nächste Frage, die auftaucht nachdem Sie wissen wie viele "Dinge" (Aktionspunkte) sich in der Anwendung befinden ist: "Wie viel kostet das denn nun?" Die Antwort ist für viele Menschen eher unangenehm, da hierfür Informationen erforderlich sind, die sie nicht haben - eine korrekte Berechnung, wie teuer es in der Vergangenheit war, eine entsprechende Software zu entwickeln.
In diesem Punkt sind viele Softwareentwickler unterentwickelt, denn sie haben keine Vorstellung, wie hoch ihre historischen Kosten sind. Ich kenne mindestens ein Dutzend Firmen, die keinerlei Daten darüber erhoben haben, wie lange eine Anwendungsentwicklung gedauert hat. Das sind die gleichen Firmen, die ansonsten jeden Pfennig pingelig beobachten. Am Ende des Jahres wundern die Firmen sich dann, weshalb bei allen diesen Software-Projekten das Budget überschritten wurde und die Projekte zu spät abgeliefert wurden. Warum? Ich verrate es Ihnen: die Techniken der Aufwandschätzung stehen auf Treibsand - dem Treibsand des Fehlens historischer Daten.
Sie müssen Ihre Kosten verfolgen - die Dauer, die erforderlich war, um in der Vergangenheit ein Projekt fertig zu stellen - wenn Sie einem Aktionspunkt einen Zeitwert zuordnen wollen. Whils Firma war darin erfolgreich - bevor er wusste, was er mit den Daten anfangen wollte, ließ er seit 1993 jeden Entwickler exakt Buch darüber führen, wie viel Zeit die einzelnen Komponenten jedes Projekts in Anspruch genommen haben.
Das Ergebnis war, dass er über realistische Werte aus der bereits beendeten Arbeit verfügte, als er auf die Idee mit dem Zählen der Aktionspunkte kam. Als er Ende 1994 mit den Aktionspunkten zu arbeiten begann nahm er sich ein Dutzend Anwendungen, in denen 4000 Arbeitsstunden steckten, und hat in jeder Anwendung die Aktionspunkte gezählt. Die gesamte Zeit wurde mit der Anzahl der Aktionspunkte verknüpft, um die ersten Multiplikatoren zu errechnen.
Aus diesen Zahlen wussten sie nun, dass ein durchschnittlicher Entwickler 20 Minuten benötigte, um einen Aktionspunkt abzuarbeiten. Dies ist ein fiktiver Wert, da die wirkliche Zeit niemand anders interessiert. Das Framework, die Erfahrung des "durchschnittlichen Programmierers" und andere Faktoren sind in jeder Firma unterschiedlich.
Wir haben bereits die Frage aufgeworfen, wie Frameworks, Anwendungsgeneratoren und wiederverwendbare Komponenten bei der Zählung der Aktionspunkte behandelt werden. Dies geschieht in zwei Stufen.
Zunächst gehen Sie davon aus, dass Sie durch den Einsatz von Tools beschleunigt in die Produktion der Anwendung einsteigen können. Das einfache Zählen der "Dinge" und das einfache Multiplizieren mit den Standard-Gewichtungen erzeugen eine Zahl, mit der die Realität nur unvollständig wiedergegeben wird. Nehmen Sie an, Sie verwenden zum Erzeugen eines Formulars eine Formularklasse, die bereits ein Dutzend Schaltflächen sowie einigen Code enthält. Das zu erzeugende Formular benötigt nur wenige Funktionalitäten, die über die der Formularklasse hinausgehen. Sie könnten durch Zählen auf 50 Aktionspunkte kommen, während Sie in der Realität lediglich einige Textfelder auf dem Formular platzieren und diese mit einer Tabelle aus der Datenumgebung des Formulars verknüpfen - damit kämen Sie auf 10 Aktionspunkte. Wenn Sie Ihrem Kunden nun den Gegenwert von 50 Aktionspunkten in Rechnung stellen erscheint das nicht richtig. Dieses Vorgehen erinnert an die Zusatzgewinne, die von den internationalen Ölkonzernen am Ende der Ölkrise in den 70er Jahren eingefahren wurden.
Wenn Sie aber so intelligent sind, dass Sie ein automatisiertes Tool zur effizienteren Entwicklung einsetzen - sollten Sie dann nicht auch mehr verdienen? Stellen Sie sich zwei Fahrradproduzenten vor. Einer montiert die Räder von Hand und hat damit $ 500 Kosten pro Rad, das er für $ 600 verkauft. Der andere hat den Produktionsprozess weitgehend automatisiert und kann daher ein Rad für $ 200 produzieren. Soll er nun seine Räder für $ 300 verkaufen oder soll er sie für $ 595 verkaufen und damit einen gesunden Gewinn dafür erzielen, dass er die Räder preiswert produziert?
Die Antwort ist doch wohl, dass er die Räder für $ 550 verkaufen und dem Konkurrenten die gesamten Kunden abnehmen sollten, während er trotzdem gesunde Gewinne erzielt.
Auch wenn Sie mit dieser Taktik übereinstimmen, haben Sie vielleicht doch das Gefühl, dass es eine schlechte Geschäftspolitik ist, einem Formular 50 Aktionspunkte zuzuordnen obwohl lediglich 10 Aktionspunkte anfallen, da dieses Vorgehen nicht Ihren Kosten entspricht. Kommt nun ein Mitbewerber mit dem gleichen Werkzeug und macht niedrigere Preise, wissen Sie nicht, wie hoch Ihre aktuellen Kosten tatsächlich sind und können nicht angemessen reagieren. Das bringt uns zur zweiten Stufe.
Bedenken Sie, dass Ihre historischen Daten auch auf der Verwendung des Frameworks basieren. Die Vorteile des Einsatzes eines Frameworks zeigen sich bis zu einem bestimmten Grad also, wenn man die Kosten auf der Basis historischer Daten analysiert.
Zunächst einmal ist es unwahrscheinlich, dass Sie über keine Historie verfügen - wahrscheinlich hat sie nur nicht den Feinheitsgrad erreicht, den Sie benötigen. Sie können die Aktionspunkte in den von Ihnen realisierten Anwendungen zählen und anschließend kontrollieren, wie viel Zeit die Entwicklung in Anspruch genommen hat. Zumindest können Sie feststellen, wie viel Geld die Anwendung gekostet hat und welche Entwickler an dem Projekt beschäftigt waren. Mit diesen minimalen historischen Daten können Sie bereits einige Circa-Werte entwickeln. Dazu könnte gehören, dass Sie versuchen, die Anzahl der Formulare, Berichte und Prozesse mit Zeit- oder Geldwerten in Beziehung zu setzen. Sind diese Werte genau? Nein, aber sie sind schon besser als die wilden Annahmen, die Sie bislang benutzt haben.
Die Genauigkeit Ihrer Berechnungen erhöht sich mit der Anzahl der Projekte, die Sie in Ihrer Datenbank erfassen. Denken Sie daran: Einmal ist kein Trend und Zweimal ist auch nicht viel mehr. Wenn Sie aber ein oder zwei Dutzend Projekte erfasst haben verfügen Sie über genügend Daten. Wenn dann ein oder zwei Projekte aus dem Ruder laufen geraten Ihre Daten nicht so in Schieflage, als ob Sie nur zwei oder drei Projekte analysiert hätten.
Egal wie - nur weil Sie in der Vergangenheit diese Daten nicht gesammelt haben müssen Sie auf diese Methodik nicht verzichten. Es ist an der Zeit, diese Historie anzulegen - und heute ist genau der optimale Zeitpunkt dafür.
Am Einfachsten fangen Sie an, wenn jeder Entwickler die Zeiten erfasst, die er in die Projekte investiert und Sie diese Zeiten in einer Tagesübersicht einträgt. Wenn Sie intelligenter an die Sache gehen wollen, können Sie eine entsprechende Software kaufen, beispielsweise TimeSlips (www.timeslips. com), TraxTime (www.spudcity.com) oder Time Trakker (www.west-wind.com). Und wenn Sie wirklich wählerisch sind, können Sie sich Ihr eigenes Werkzeug zur Zeiterfassung entwickeln.
Sie sollten aber zwei Dinge beachten. Zum Ersten versuchen Sie nicht, zu viel zu früh zu machen. Beginnen Sie mit den Grundlagen. Später können Sie bei Bedarf noch weitere Stufen hinzufügen. Und zweitens - beginnen Sie jetzt.
Wir werden häufig gefragt, welche Aufgaben verfolgt werden sollen. Wir sammeln sämtliche Zeiten, die mit der Arbeit zu tun haben - nicht nur diejenigen, die bei der Codierung anfallen. Reisezeiten, Entwicklung einer Spezifikation (Analyse und Design, schreiben des Pflichtenhefts, Zählen der Aktionspunkte), das Debugging, Schreiben von Memos und Briefen und die Datensicherung - alle diese Aufgaben sind Teil des Projekts. Sie müssen Ihre Beschäftigten für die Erledigung dieser Aufgaben bezahlen, daher sind sie definitiv Teil der Kosten des Projekts.
Gehen wir weiter. Was ist mit dem Besuch von Treffen der Usergroup? Das Lesen von Büchern? Die Suche im Web nach einem neuen Utility? Wir erfassen das alles. Sie können die Zeit, die Sie für die Suche einer Zeitschrift mit einem interessanten Artikel aufwenden, Ihrem Kunden vielleicht nicht in Rechnung stellen, aber auch diese Zeit ist Teil Ihrer Kostenstruktur.
Ein Punkt, der teilweise Probleme bereitet, sind die Zeiten die jemand aufwändet, um während der Freizeit etwas festzuhalten oder "mit etwas herumzuspielen". Nehmen Sie z. B. an, dass einer Ihrer Entwickler gerne zu Hause etwas ausprobiert oder dass er regulär Teile des Projekts mit nach Hause nimmt, um andere Techniken auszuprobieren. Diese Zeiten lassen sich nicht erfassen. Was machen Sie dann?
Zunächst einmal müssen Sie die rechtliche Seite dieses Problems prüfen - dafür sollten Sie aber Ihren Anwalt konsultieren. In Abhängigkeit von dem mit dem Entwickler geschlossenen Arbeitsvertrag müssen die in der Freizeit aufgebrachten Zeiten mit der Arbeitszeit verrechnet und als Überstunden gerechnet werden, während Sie von den Überstunden profitieren.
Wichtiger - während Sie vielleicht durch die Freizeitarbeit Ihrer Entwickler profitieren, erhält die Firma auf jeden Fall einen Vorteil. Es ist also sinnvoll mit der Uhr festzuhalten, wie viel Zeit dieses R&D in Anspruch nimmt. Wenn Sie diese Zeiten kennen, können Sie sie auch in Ihre Multiplikatoren einfließen lassen.
Nehmen Sie an, Sie erfassen diese Zeiten nicht, beginnen aber sich darauf zu verlassen, dass ein Entwickler zu Hause noch weiterarbeitet. In diesem Moment würden Sie bei der Kostenrechnung Ihrer Projekte diese Zeiten nicht einbeziehen während Sie gleichzeitig auf diese Zeiten vertrauen. Kurzfristig könnten Sie von dieser Situation profitieren, langfristig verbrennen Sie sich aber die Finger daran.
Außerdem können Sie in einem solchen Fall nicht wissen, wie viel Zeit jemand zusätzlich investiert und ihm daher auch keinen entsprechenden Bonus geben.
Erfassen Sie jetzt jede einzelne Minute? Wahrscheinlich nicht. Auch der disziplinierteste Programmierer ist zeitmäßig gesehen auch ein Cowboy - und daher schreibt er auch nicht auf, dass er 24 Minuten benötigt hat, eine neue Hilfefunktion zu installieren. Aber je exakter die Aufzeichnungen sind, desto besser sehen Sie damit aus.
OK, jetzt die $ 25-Frage: in welchen Zeiteinheiten erfassen Sie die Arbeit? Wir behandeln diese Frage in einem anderen Abschnitt. Aber wir verraten Ihnen, wie sehr wir ins Detail gehen und dann können Sie Ihre Entscheidung treffen. Kurz gesagt, wir haben die Entwicklungszeit in vier Stufen aufgeteilt und finden, dass das schon viel ist.
Die erste Stufe ist "Kunde" - und Sie können sie nach Belieben definieren. Grundsätzlich habe ich den "Kunden" als eine Einheit definiert, mit der ich einen Erstkontakt hatte und die ihre Rechnung von einem Punkt aus zahlt. Vielleicht arbeiten Sie ja mit großen Kunden zusammen, mit denen Sie unterschiedliche Projekte verwirklichen - wenn Sie Ihre sämtlichen Rechnungen an die gleiche Adresse senden, können Sie ihn als einen einzelnen Kunden betrachten. Andere Kunden arbeiten, als ob sich ihre Niederlassungen auf unterschiedlichen Planeten befinden würden. Daher könnten Sie diese Niederlassungen als unterschiedliche Kunden betrachten. Es handelt sich einfach um eine Betrachtungsweise aus der Sicht der Buchhaltung und um die Frage, ob Sie am Ende des Jahres ausrechnen wollen, wie viel Geld Sie mit der InterGalactica GmbH verdient haben.
Die zweite Stufe ist das "Projekt". Jedes Projekt, das vom Kunden eine neue Bestellnummer erhält, wird in unserem System als neues Projekt angelegt. Wenn eine Firma ohne Bestellnummern arbeitet versuche ich zu erraten, ob der Kunde ein separates Konto für dieses Projekt führt.
Die dritte Stufe ist das "Modul". Dabei handelt es sich um ein auslieferbares Teil innerhalb eines Projekts. Dabei kann es sich um einen einzelnen Prozess oder Bericht handeln, es kann aber auch aus mehreren Formularen, einem Prozess und vier Berichten bestehen. Grundsätzlich ist alles, das auf ein Mal an den Kunden ausgeliefert und von ihm akzeptiert wird ein Modul.
Die niedrigste Stufe ist die "Aufgabe". Das ist ein einzelnes Formular, ein Prozess, Bericht oder eine andere Einheit, in der wir Aktionspunkte zählen können. Die Grundlage einer Anwendung könnte drei Aufgaben enthalten: Data Dictionary, Menü und Hilfe. Auch ein R&D-Projekt könnte eine Aufgabe bilden, allerdings könnte es sich hier auch um ein Modul mit mehreren identifizierbaren Aufgaben handeln.
Mit Hilfe unserer historischen Daten haben wir ermittelt, wie lange ein Entwickler benötigt, um eine Anwendung zu erstellen. Außerdem kennen wir die Kosten dieses Entwicklers - seinen Stundensatz, seine besonderen Fähigkeiten und andere Stärken.
Wir kennen auch unsere Kosten - Miete, Arbeitszeit die wir nicht in Rechnung stellen können, Zeitschriftenabonnements, Bildschirmschoner usw. Die Addition von Entwicklungskosten, Verwaltungsausgaben und Gewinn ergibt die Geldmenge, die für die Softwareentwicklung erforderlich ist.
Hersteller industrieller Waren berechnen auf diese Weise seit 200 Jahren ihre Preise - einschließlich der Kosten, die durch die bloße Existenz der Firma entstehen. Sie erinnern sich: wir stellen ein Produkt her und eine korrekte Kostenrechnung erfordert die Berücksichtigung sowohl der variablen als auch der festen Kosten. Wenn Ihre Firma größer wird, werden auf Sie auch Kosten wie der Kauf neuer Rechner, Abonnements von Dr. Dobbs, Software Development und Object, ein vernünftiges Telefonsystem einschließlich Voice-Mail statt des billigen Anrufbeantworters, administrative Unterstützung und jede Menge kostenloses Junkfood in der Küche zukommen.
Das kann wirklich trickreich werden.
Sie haben bemerkt, dass die Multiplikatoren in Relation zu dem Entwickler stehen, der an dem speziellen Projekt arbeitet. Arbeiten mehrere Entwickler am gleichen Projekt, haben wir die Aktionspunkte für jeden Entwickler getrennt erfasst und daraus ihre Bezahlung errechnet. Wir kamen so auf eine Darstellung, die wie in der folgenden Tabelle aussieht. Die angegebenen Zahlen sind eine Addition für jeden Entwickler über mehrere Anwendungen hinweg.
| Entwickler |
Stunden |
Aktionspunkte | Aktionspunkte pro Stunde | Stundensatz |
|---|---|---|---|---|
| A |
100 |
2900 |
29 |
$27 |
|
B |
180 |
3000 |
16 |
$26 |
|
C |
215 |
21500 |
100 |
$49 |
|
D |
240 |
9100 |
38 |
$41 |
Aus dieser Tabelle können Sie mehrere Punkte ersehen. Zunächst einmal müssen die Stundensätze nicht an die Erfahrung des Entwicklers gebunden sein. Wie werden die Entwickler bezahlt? Einmal werden die Menschen nach ihren akademischen Titeln eingeteilt und diese Titel haben nichts mit den tatsächlichen Erfahrungen zu tun. Ein anderes Mal werden die Menschen mit höheren Stundensätzen von anderen Projekt abgeworben. Auch in diesem Fall hat die Bezahlung nichts mit ihren Erfahrungen oder ihrer Produktivität zu tun.
Das ist eine schwierige Situation. Beispielsweise ist der Entwickler B am wenigsten produktiv - entweder aus mangelnder Erfahrung oder mangelnder Geschicklichkeit - aber sein Stundensatz ist nicht viel niedriger als der von Entwickler A, der erheblich erfahrener ist.
Dann taucht eine zweite Frage auf: Wie sieht es aus, wenn ein Entwickler innerhalb seiner Software einen hohen Grad an Wiederverwendbarkeit erzielt? Erreicht er lediglich das untere Ende der Skala der erledigten Aktionspunkte pro Stunde? Nein. Die Aktionspunkte innerhalb einer Anwendung basieren auf der Anzahl der "Dinge" - Schaltflächen, Prüfungen, Berechnungen innerhalb eines Berichts oder der Erzeugung temporärer Dateien. Ob diese Aufgaben durch die Verwendung eines Werkzeugs oder einer Klasse oder manuell erledigt werden spielt bei der Zählung der Aktionspunkte keine Rolle. Diese Punkte werden erst aktuell, wenn Sie den Aktionspunkten aufgrund historischer Daten Zeitspannen oder Geldmengen zuordnen. Während der Entwicklung steigert die Wiederverwendbarkeit und der Einsatz automatisierter Tools die Produktivität.
Wie sieht es aus, wenn ein Entwickler einen Code mit höherer Qualität abliefert, der anschließend weniger Pflege bedarf? Wir diskutieren hier über die Produktivität und, ganz hart gesagt, ist die spätere Pflege des Code hier kein Thema. Sie schütteln jetzt vielleicht den Kopf - aber Sie werden noch bemerken, dass wir auch diesen Punkt behandeln, allerdings in einem anderen Abschnitt.
Als Drittes scheint es unmöglich, die Bezahlung des Entwicklers an seine Produktivität zu knüpfen. Entwickler C ist in unserer Tabelle drei mal so produktiv wie die anderen Entwickler. Es ist aber schwierig, ihm das dreifache Gehalt zu zahlen. Dies gilt sowohl vom finanziellen als auch vom firmenpolitischen Standpunkt aus.
Auf jeden Fall ist es aber aufgrund dieser Daten möglich, die Zahlungen objektiver zu gestalten. Erhält beispielsweise ein Entwickler mit einer Produktivität von 16 Aktionspunkten pro Stunde $ 26 als Stundensatz (auch hier benutze ich wieder fiktive Zahlen), müsste ein Entwickler, der 32 Aktionspunkte je Stunde erledigt, mit $ 52 je Stunde entlohnt werden. In der Realität sind die Unterschiede in der Produktivität noch höher, aber ich wollte hier nur den Gedanken rüberbringen.
Jetzt könnten Sie die Frage stellen: "Sie sagen, dass ein Formular mit 50 Aktionspunkten bei einem Satz von 1,5 Stunden je Aktionspunkt 75 Stunden für die Entwicklung benötigt. Aber ist dieser Satz nicht von der Produktivität des Entwicklers abhängig?"
Nun, in dieser Frage steckt ein kleiner Gedankensprung. Bedenken Sie, dass jeder Entwickler ein eigenes Produktivitätsmaß hat. Ein erfahrener Entwickler sollte in der Lage sein, dieses Formular in einer kürzeren Zeit zu erstellen als ein Anfänger, da er innerhalb einer Stunde mehr Aktionspunkte erledigen kann. Allerdings ist ein erfahrener Entwickler auch teurer, oder? Damit liegen die Kosten pro Stunde bei ihm auch höher. In einer idealen Welt hätte das Formular immer den gleichen Preis - unabhängig davon, wer es entwickelt. Wenn also ein sehr erfahrener Entwickler, der $ 200 je Stunde erhält, das Formular an einem Tag entwickelt, hat unser Anfänger für $ 50 je Stunde für diese Aufgabe vier Tage Zeit.
Wir behandeln die Produktivität und die Entlohnung der Entwickler intensiv in einem anderen Kapitel dieses Buches.
Ist das alles zu viel, um es auf einmal zu machen? Vielleicht. Wenn alles neu für Sie ist, sollten Sie als Erstes die Aktionspunkte einiger Anwendungen zählen um festzustellen, wie groß die Systeme sind. Die Zahl, auf die Sie dabei kommen ist dabei nicht entscheidend - es macht nichts, wenn Ihre Anwendung 200 Aktionspunkte enthält und die Anwendung von jemand anders 380. Entscheidend ist, dass Sie jetzt verschiedene Projekte vergleichen können, die Sie erstellt haben. Sehen Sie sich die Zeiten an, die Sie für die Entwicklung aufgewandt haben. Wenn Sie den Prozess wie hier beschrieben Schritt für Schritt durcharbeiten besteht kaum die Gefahr, etwas zu vergessen.
Dabei handelt es sich um einen großen Vorteil.. Häufig läuft eine Anwendung nicht deshalb aus dem Ruder, weil die Entwickler unerfahren sind oder ihnen Fehler unterlaufen, sondern weil der Kunde nach einer kleinen Schaltfläche fragt, die sich anschließend zu einer großen Anzahl Formularen auswächst. Diese Schaltfläche nicht zu implementieren kann Ihnen aber erheblich teurer kommen als die Vorstellung, dass die Entwicklung der Formulare statt 88 Stunden nur 68 Stunden dauert.
Jetzt können Sie versuchen, einen Preis für die Anwendung (oder auch ein einzelnes Formular oder einen einzelnen Bericht) zu nennen. Dieser Preis basiert auf Fakten, nicht auf einer wagen Schätzung. Auch der Aufwand für die Preisfindung ist nicht zu hoch, wenn Sie erst einmal die Grundlagen geschaffen haben.
Es geht noch weiter - hören Sie jetzt nicht zu lesen auf. Wie Sie zweifellos wissen, kann ein sehr erfahrener Entwickler leicht zehn mal so produktiv sein wie ein anderer. Ein extrem erfahrener Entwickler kann sogar die zwanzigfache Produktivität eines Amateurs erzielen. Aber auch der mieseste Entwickler verlangt $ 40 bis $ 50 pro Stunde. Wie viele hoch erfahrene Entwickler kennen Sie, die je Stunde 20 x $ 40 berechnen - also einen Stundensatz von $ 800? Wir kennen wohl nicht mehr als zwei oder drei Dutzend.
Mit Hilfe der Zählung der Aktionspunkte können Sie aber von der Erfahrung des Entwicklers profitieren und die Leistung entsprechend in Rechnung Stellen. Vergleichen Sie dazu den nächsten Abschnitt.
Ein weiterer Vorteil der gesammelten Daten ist die Möglichkeit der Zeitplanung. Da Sie nun die Aktionspunkte der Anwendung und die Produktivität des Entwicklers in Aktionspunkten pro Stunde kennen, ist es einfach festzustellen, wann der Entwickler die Anwendung fertiggestellt haben wird.
Letztendlich können Sie Ihrem Kunden darlegen, wie Sie die Kosten ermittelt haben, ohne sich wie Ihre Mitbewerber in nebulöse Andeutungen flüchten zu müssen.
Bislang haben wir eine weitgehend theoretische Diskussion geführt. Was geschieht aber im richtigen Leben, wenn der Kunde den Vertrag für die Entwicklung einer Software unterschrieben hat und der Entwickler beginnt, daran zu arbeiten? Der Entwickler wird für seine Arbeit entlohnt und die Firma muss eine festgelegte Menge an Funktionalität abliefern, unabhängig davon, wie viel Zeit der Entwickler für diese Arbeit benötigt. Wie läuft dieses Szenario ab, wenn wir es von der Menge der Erfahrungen des Entwicklers abhängig machen?
Nehmen Sie an, wir berechnen $ 100 pro Aktionspunkt. Ein Formular mit 50 Aktionspunkten würde also $ 5000 kosten. Ein sehr erfahrener Entwickler benötigt für dieses Formular vielleicht 25 Stunden, wodurch sich ein Stundensatz von $ 200 errechnet. Ein Anfänger benötigt für diese Aufgabe vielleicht 125 Stunden, was einen Stundensatz von $ 40 ergibt. Wenn der Anfänger Erfahrungen sammelt, erledigt er mehr Arbeit innerhalb einer festgelegten Frist und erzielt damit einen höheren Umsatz für die Firma und liefert für seine Entlohnung einen höheren Wert ab. Auch der erfahrene Entwickler produziert höhere Werte. Diese Werte sind nicht proportional zur Leistung je Stunde, da hier auch die fixen Kosten der Firma eingerechnet werden müssen.
Der Kunde zahlt immer den gleichen Preis für die Funktionalität, unabhängig davon, welcher Entwickler die Arbeit ausführt. Der sehr erfahrene Entwickler kann dabei ein sehr hohes Einkommen erzielen, da er nicht länger an die Obergrenze "niemand zahlt mehr als $ 90 für einen Programmierer" gebunden ist. Die Kosten für die Firma bleiben dabei gleich, da der unerfahrene Entwickler eine längere Zeit benötigt. Dadurch kann die unterschiedliche Produktivität ausgeglichen werden. Die Kosten von $ 5000 für das Formular bleiben konstant, unabhängig davon, welcher Entwickler die Arbeit erledigt. Der Unterschied liegt darin, dass der weniger erfahrene Entwickler das Formular später fertig stellt.
Das haben wir bereits festgestellt, aber es ist sehr wichtig festzustellen, dass wir bislang lediglich die Kosten, nicht aber den Preis berechnet haben! Ziel des Zählens der Aktionspunkte ist es, die Kosten zu ermitteln, die durch die Entwicklung eines Projekts entstehen und nicht den Preis, den der Kunde zahlt. Dazwischen gibt es eine Differenz. Sie wollen natürlich, dass Ihr Kunde mehr zahlt als Ihnen Kosten entstehen. Wie viel mehr er zahlt ist eine andere Sache, aber wenn er nicht mehr zahlt, würden Sie nichts verdienen.
Wie entscheiden Sie, welchen Wert die Anwendung für den Anwender hat und wie viel Sie ihm für die Anwendung berechnen können? Dieser Vorgang erfordert einiges Fingerspitzengefühl. Haben Sie ein gutes Verhältnis zu Ihrem Kunden können Sie feststellen, welchen Wert die Anwendung für ihn hat. Wenn Sie Ihre Hausaufgaben gemacht haben - also festgestellt, wo ihm der Schuh drückt und wie ihm geholfen werden kann - kennen Sie bereits die Antwort.
Wie wandeln Sie unsere Diskussion über die Funktionalität in den Preis um, den der Kunde zu zahlen hat? Leider gibt es keine allgemeingültige Antwort auf diese Frage. Vielleicht hat Ihnen der Kunde ein Budget zugeordnet, aus dem Sie sich bedienen können. Vielleicht können Sie auch die Anwendung in die Aufgaben aufteilen, die sie in der Firma des Kunden erledigen soll - und wie viel Geld der Kunde dadurch spart. Verdient der Kunde mit der Anwendung Geld? Und wenn ja - wie viel?
Sie könnten eine offene Diskussion mit dem Thema "wie begründen Sie dieses Projekt" führen. Dabei müssen Sie nicht unbedingt nach Zahlen fragen, sondern danach, welchen Prozess der Kunde gerade durchläuft. Will er Personal abbauen? Sucht er nach neuen Geschäftsfeldern? Sollen durch diesen Prozess Kosten gesenkt werden? Weiß er eigentlich gar nicht, was er vorhat? Mit solchen Fragen können Sie erfahren, welchen Wert der Kunde dem Projekt zumisst.
Nachdem wir die Zählung der Aktionspunkte detailliert besprochen haben sind Sie in der Lage, bequem einen Festpreis für eine Anwendung zu nennen. Dafür gibt es drei Voraussetzungen: eine ausreichend genaue Funktionsbeschreibung, möglichst genaue historische Daten und Entwickler, die sich mit dem eingesetzten Werkzeug auskennen.
Wie sieht die Abwägung "Festpreis oder Zeit und Material" jetzt aus?
Zunächst einmal sind Sie nicht gezwungen Ihrem Kunden einen Festpreis zu machen, auch wenn Sie dafür jetzt die notwendigen Voraussetzungen haben. Durch das Zählen der Aktionspunkte haben Sie lediglich Ihre Kosten besser im Griff, so dass Sie nicht irrtümlich einen Preis machen, der nur knapp über Ihren Kosten oder gar darunter liegt.
Zweitens war einer der Gründe für die Implementierung der Zählung der Aktionspunkte, uns in die Lage zu versetzen, einen Festpreis anzubieten, da wir das Gefühl hatten, dass wir auf diese Weise mehr Geld verdienen können als auf Basis einer Stundenabrechnung.
Trotzdem hier noch einige Bedenken, die Sie aus dem Weg räumen sollten, bevor Sie sich kopfüber in mehrere Festpreisprojekte stürzen. Zunächst einmal sollten Sie sich vollständig mit den drei oben genannten Voraussetzungen vertraut machen - einer genauen Beschreibung, einer fundierten Behandlung Ihrer Kosten und einer realistischen Einschätzung der Erfahrungen Ihrer Entwickler. Wenn Sie nur über eine eher wage Beschreibung verfügen können Sie nicht wissen, wie viel Ihnen die Entwicklung kosten wird. Sind Ihre Entwickler nicht erfahren genug, sind die Probleme vorprogrammiert.
Dann erinnern Sie sich, dass viele Kunden von Ihnen einen Festpreis bekommen wollen, bevor Sie bereit sind, einen zu nennen. Die Kunden benötigen eine Summe, um sie in ihrem Budget einplanen zu können, sie ihrem Chef zu präsentieren oder sie ihrem IT-Verantwortlichen vorzulegen. Mit einer Summe - je exakter desto besser - können sie in ihrem Betrieb besser auftreten.
Die Aktionspunkte arbeiten sowohl für den Entwickler als auch für den Kunden - genau wie bei einem Einkaufswagen im Supermarkt -, der Kunde entscheidet, was er kaufen will. Wenn Sie einen Preis nennen, der über dem liegt, den der Kunde sich vorgestellt hat, ist es einfacher zu fragen welche Funktionalität herausgenommen werden kann (beim Einkaufswagen wäre es die Frage, ob er die Äpfel oder das Bier zurücklegen will). Wenn Sie über eine klar definierte Methodik für die Kostenrechnung (und evtl. die Preisfindung) verfügen, ist es für den Kunden nicht mehr so einfach, den Preis zu drücken.
Nachdem Sie sich einig geworden sind, müssen Sie den Kunden an der kurzen Leine halten. Auch wenn Sie mit einem detaillierten Pflichtenheft arbeiten, fühlen sich viele Kunden immer noch, als wenn sie in eine Imbissstube mit dem Angebot "all you can eat for $ 9.99" gehen würden. Das ist aber nicht so.
Die Kunden haben vielleicht das Pflichtenheft gar nicht gelesen und nehmen einfach an, dass eine Funktionalität, die vor einem halben Jahr einmal erwähnt wurde, darin schon irgendwo enthalten sein wird. Sie haben dann vergessen, dass Sie ihnen drei Prototypen gezeigt haben, dass daran später Änderungen vorgenommen wurden, durch die das Feature zu teuer und zeitaufwändig geworden wäre und sie darum gebeten haben, die Funktionalität erst in Version zwei zu realisieren.
Letztendlich bemerkt der Kunde noch, dass Änderungen vorkommen. Nur weil Sie ihm einen Festpreis für X genannt haben bedeutet dies nicht, dass er keine Änderungen vornehmen darf. Wir behandeln die Änderungen der Bestellung und den Prozess der Änderungen in einem anderen Kapitel. Jetzt lassen Sie uns lediglich feststellen, dass Änderungen immer willkommen sind. Sie sind allerdings nicht gratis.
Dieses Kapitel hat unter anderem den Zweck, Sie in die Lage zu versetzen, einem Kunden darzulegen, dass Sie keinen Festpreis nennen können, bevor Sie ein vollständiges Pflichtenheft in den Händen halten. Außerdem müssen Sie auf diesem Standpunkt beharren, wenn der Kunde Sie anschließend unter Druck setzen will. Es ist einfach, klein beizugeben wenn ein Kunde immer und immer wieder Druck macht. Wir hoffen aber, dass wir Ihnen genügend Informationen vermittelt haben, festzustellen: "bis hier und nicht weiter". Sie werden überrascht sein wie häufig der Kunde als Erster zurücksteckt. Beim ersten Mal ist die Aussage noch schwierig, aber mit jedem weiteren Mal wird es einfacher. Wir behaupten nicht, dass Sie jedes Mal gewinnen werden, aber wenn Sie es nicht versuchen, werden Sie keinen Sieg erringen.
Je mehr Sie darüber nachdenken, desto lächerlicher wird es, einen Festpreis für etwas zu nennen, von dem Sie nicht wissen, wie viel es Sie kostet oder welche Überraschungen auf Sie warten. Es wäre das Gleiche, als wenn Sie jemanden für einen Festpreis von $ 100 ein Loch im Garten ausheben würden, aber diese Arbeit noch nie ausgeführt oder immer nur kleine Löcher produziert haben.
Erinnern Sie sich: Sie wissen nicht, wie viel Zeit die Aufgabe erfordert, da Sie über keine historischen Daten verfügen und Sie nicht erfahren genug sind, um zu schätzen. Es könnte sein, dass Sie nicht über die richtigen Werkzeuge verfügen. Wenn das der Fall ist können Sie nicht ausschließen, dass Sie auf einen unterirdischen Öltank, einen U-Bahn-Tunnel oder einen Felsen stoßen.
Aber der Kunde fordert von Ihnen weiterhin eine Schätzung für ein unvollständig oder falsch definiertes Projekt. Der typische Satz ist dann: "Ich will Sie nicht darauf festnageln, ich benötige nur eine Summe für meinen Chef". Wollen Sie daraufhin eine konstruierte Zahl abgeben?
Diese Frage kommt nicht nur vom "echten" Kunden. Dies kann Ihnen auch bei einem Mitglied der Geschäftsleitung geschehen, der von Ihnen einen Preis erfahren will, kurz nachdem er Ihnen zum ersten Mal von dem Projekt erzählt hat. Können die Leute unvernünftig sein!
Wie verhalten Sie sich in einer solchen Situation? Sie können aus unterschiedlichen Gründen das Projekt nicht einfach abschreiben. Eventuell hat der Mensch, der Ihnen diese unvernünftige Frage stellt, einen großen Einfluss im Betrieb des Kunden. Was tun?
Am Besten halten Sie fest was Sie wissen, welchen Umfang das Projekt haben soll und bieten an, aufgrund weiterer Informationen eine Schätzung zu erstellen. Je mehr Informationen Sie erhalten, desto genauer wird die Schätzung ausfallen. Und dabei immer: dokumentieren, dokumentieren und noch einmal dokumentieren. Wenn Sie Ihre Schätzung ändern, sei es aufgrund eines weiteren Feintuning oder aufgrund grundsätzlicher Änderungen, teilen Sie dies dem Kunden schriftlich mit.
Erinnern Sie sich an die Erwartungen? Jedes Mal, wenn Sie neue Informationen erhalten, sind Sie potentiell in der Situation, die Erwartungen des Kunden zu ändern. Tun Sie dies nicht, könnten Sie damit die Grundlage für zukünftige Probleme schaffen.
In den Augen des Kunden kann dies aussehen, als ob Sie "Ihre Haut retten" wollten - daher ist es notwendig, dass Sie diese Methode (die Verfeinerung der Aufwandschätzung) offensiv als die einzig richtige präsentieren. Eine stichhaltigen Summe können Sie ohne ausreichende Informationen nicht nennen.
Wenn sie dann nach einer Vermutung fragen, nennen Sie eine unrealistische Summe und legen Sie dar, dass Ihnen die Informationen fehlen und dass dies halt die Vermutung ist. Wenn der Kunde dies akzeptiert sind Sie auf der sicheren Seite. Akzeptiert er dies nicht und fragt nach einer neuen Vermutung, hat er für seine Arbeit hinter den Kulissen zumindest eine Zahl.
Aber die Nennung eines Festpreises ohne die erforderlichen Informationen führt zu Problemen. Unabhängig davon, wie verführerisch sie scheint und wie aufrichtig Sie diesen Preis meinen, er wird falsch sein.