hi,
könnte mir mal jemand den exakten unterschied darstellen?
ich habe nämlich noch nicht ganz begriffen, warum ich noch ein lastenheft erstellen soll, wenn ich das gesamte projekt selbst von anfang an mache.
es kommt halt oft vor, dass der kunde nur kommt und sagt: ‚ich will ins web.‘ - mehr weiß er nicht.
warum erarbeite ich mit ihm zuerst ein lastenheft und mache daraus ein pflichtenheft, wenn ich doch gleich ein plichtenheft erstellen könnte!?
gruß
tobias
Hei,
ich habe das immer so verstanden - und erlebt - daß der Kunde das Lastenheft als Beschreibung dessen erstellt, was er haben will.
Das Pflichtenheft wurde dann von uns/mir erstellt um darzustellen was man machen kann bzw. was in der gewählten Zeit und dem gewählten Budget möglich ist.
Der einzige Grund der mir einfällt, um beides von Dir erstellen zu lassen ist das Lastenheft beschreibt die ultimative Lösung der nice-to-have bis genial wäre und das Pflichtenheft beschreibt was eben möglich ist.
Ciao,
Uwe
Hi!
das Lastenheft ist nach meinem Verständnis ein grobes Pflichtenheft. Wichtig dabei ist, dass alle Rahmenbedingungen erfasst sind und die komplette Funktionalität beschrieben ist. Damit meine ich, dass du kurz und knapp und an vielen Stellen oberflächlich beschreibt, aber nichts vergisst. Ein Lastenheft dient dann dazu, festzuhalten, was das zu erstellende System kann, und was es eben nicht kann! Desweiteren kann man bereits auf dieser Abstraktionsebene eine Aufwandsabschätzung abgeben (da gibt’s einen ganzen Sack voll Methoden, am wichtigsten ist Function Point Methode).
Wenn das Lastenheft abgesegnet ist (Unterschrift Kunde), dann kann man das Pflichtenheft erstellen, das das zu erstellende System in seinem Verhalten und seiner Funktionaliät detailliert beschreibt. Das Plichtenheft ist normalerweise ein juristisch relevantes Dokument: Die Abnahme des Gesamtsystems erfolgt gegenüber des Pflichtenheftes. In der Praxis wird natürlich auch das Pflichtenheft im Rahmen der Entwicklung erweitert und verändert. Dann aber immer in Absprache und Konsens mit dem Kunden.
So, und warum das alles? Wenn es um ein Projekt geht, das eine Woche Arbeit bedeutet, dann setze ich mich mit dem Kunden zusammen, mache meine Notizzen, liefere nach einer Woche mein Ergabnis ab, frage ob er zufrieden ist, stelle meine Rechnung - und fertig ist die Laube.
Das andere Extrem: Ein Projekt mit 500.000 DM Entwicklungskosten und einem Gesamtbudget (Hardware, Einführug, Schulung, Support, etc.) von 1.2 Mio. Dann wäre es fatal, nach einem Jahr feststellen zu müssen, dass man was programmiert hat, was der Kunde nicht braucht und deshalb auch nicht bezahlen will! So ein Projekt kiregt man nur gebacken, indem man Meilensteine einbaut, um bzgl. Funktionalität, Termine und Kosten mit dem Kunden einen Konsens zu erarbeiten.
Langer Rede kurzer Sinn: Soviel Zwischenschritte und Dokumentation wie für das aktuelle Projekt notwendig. Hängt nicht nur von Projektgröße, sondern ach vom Kunden ab: Wenn du mit dem Kunden auf einer Wellenlänge bist, geht’s auch relativ locker, wenn das ein ängstlicher Erbsenzähler ist, dann muss man ihn mit Papier versorgen.
Ich stelle mir immer folgende Fragen:
ciao,
Bernhard
PS: Sehr gutes Buch zum Thema professionelle Software-Entwicklung:
„Lehrbuch der Software-Technik“, Helmut Balzert, Spektrum Verlag
danke für die sehr ausführliche antwort. echt klasse!
ich hatte das buch von balzert auch schon in der hand, aber irgendwie nicht gesehen, dass es da auch um projektmanagement geht… jetzt muss er wohl doch den weg in meinen schrank finden.
aber nochmal zum lastenheft/pflichtenheft:
findest du es sinnvoll auch eine website wie ein software-projekt zu planen? ich meine: im prinzip ist sie nichts anderes als eine gui, oder?
wir haben wir nämlich den fall, dass dem kunden immer mehr einfällt, was er gerne hätte (das ist bei unseren datenbank-kunden genauso). und wenn wir dann sagen, es übersteigt das vereinbarte, wird er pampig. ich denke, um solchen sachen vorzubeugen, ist es schon wichtig, auch ein pflichtenheft zu machen.
gruß
tobias
danke für die sehr ausführliche antwort. echt klasse!
Gerne!
ich hatte das buch von balzert auch schon in der hand, aber
irgendwie nicht gesehen, dass es da auch um projektmanagement
geht… jetzt muss er wohl doch den weg in meinen schrank
finden.
Mit Projektmanagement hat das Buch (zumindest der erste Band) nur zum Teil zu tun: Balzert geht es darum, den kompletten Softwareentwicklungsprozess von der Planung bis zur Wartung zu beschreiben und dem Entwickler die richtigen Methoden und Werkzeuge an die Hand zu geben… (wie beschreibe ich Funktionalität bzgl. Daten, Funktionen, Benutzerführung: Datenflussdiagramme, Zustandsdiagramme, objektorientierte Ansätze, …) Damit habe ich den Weg, wie ich ein Produkt (oder die fertige kundenspezifische Lösung) bekomme.
Projektmanagement geht noch weiter: Wie stelle ich das Produkt mit allen seinen Funktionen in der geforderten Qualität fertig, und halte dabei Kosten- und Terminrahmen ein. Hier geht’s also um Management: Wie zerlege ich das Projekt, so dass es möglichst effizient abgewickelt werden kann, wann brauche ich wieviele Mitarbeiter, wie stelle ich die Kommunikation zwischen den Mitarbeitern und zum Kunden sicher, wann brauche ich welche Ressourcen (Testsysteme, Netz, etc.), wie erkenne ich möglichst frühzeitig, wenn eines meiner Ziele gefährdet ist: Produkt wird nicht so, wie es sein sollte, der Terminrahmen wird überzogen, das Budget gesprengt. Was mache ich, wenn das Kind in den Brunnen zu fallen droht…
Bei kleinen Projekten ist ein professionelles Projektmanagement nicht notwendig: Bitte keinen unnützen Wasserkopf aufbauen (alle sind Manager, keiner macht die Arbeit…), man kriegt die meisten Sachen mit gesundem Menschenverstand und 'ner guten Portion Einsatz und Engagement gebacken.
aber nochmal zum lastenheft/pflichtenheft:
findest du es sinnvoll auch eine website wie ein
software-projekt zu planen? ich meine: im prinzip ist sie
nichts anderes als eine gui, oder?
Genau. Eine website IST ein Software-Projekt:
wir haben wir nämlich den fall, dass dem kunden immer mehr
einfällt, was er gerne hätte (das ist bei unseren
datenbank-kunden genauso). und wenn wir dann sagen, es
übersteigt das vereinbarte, wird er pampig. ich denke, um
solchen sachen vorzubeugen, ist es schon wichtig, auch ein
pflichtenheft zu machen.
Das kenne ich, passiert mir auch immer wieder! Klar, am Anfang sind Kunden wie Entwickler begeistert: „Geil, machen wir…“ Dem Entwickler fällt dann auf, dass manche Sachen doch komplizierter sind als gedacht, dem Kunden fällt auf, dass er noch was vergessen hat… Somit hat jeder bereits seinen „Kulanzrahmen“ ausgeschöpft, und dann gibt’s Gejammer…
Da hilft nur, die Funktionalität so genau wie möglich und sinnvoll bereits im Vorfeld zu definieren. Am besten am „lebenden Objekt“: Mit dem Kunden bereits implementierte Software-Lösungen oder websites durchgehen und durchsprechen, was er bekommt und WAS ER NICHT BEKOMMT (zumindest nicht für dieses Geld!)
Kaufen und Verkaufen ist aber immer Vertrauenssache, also auf ein gutes Verhältnis und eine gute Kommunikation hinarbeiten. Wenn man sich auf eine Sache geeinigt hat und auch jeder die Konsequenzen dieser Einigung versteht, dann mein Tipp: schriftliches Protokoll und zu den Projektakten. Was man schwarz auf weiß hat, kann man nicht „versehentlich“ vergessen. Auf der anderen Seite heißt das aber auch, dass es als Entwickler durchmogeln à la „dass ich ihm dieses eklige Spezialfeature versprochen habe hat der doch sicher schon vergessen…“ auch nicht mehr gibt - schade 
Noch viel Spaß und Erfolg bei deinen Projekten!
Bernhard