Es gibt schon eine Menge Bücher zu Requirement-Gathering, Requirement Management, usw.
Gib mal bei Amazon Requirement ein.
Oder Use Cases.
Oder Bücher über Unified Process, agile bzw. xTreme Programming behandeln das Thema auch.
Solche Leute wie dieser freundliche Kanadier:
http://www.ambysoft.com/scottAmbler.html wollen ja keine supertheoretischen Abhandlungen schreiben, sondern praktische Hilfen für solche Dinge wie Kommunikation mit dem Endanwender, Prozessmanagement, usw.
Wird das nächste sein, dass ich mir kaufe:
http://www.ambysoft.com/enterpriseUnifiedProcess.htmlEr geht auch auf diese Disziplinen ein:
* Chapter 4: The Production Phase
* Chapter 5: The Retirement Phase
* Chapter 6: The Operations and Support Discipline
Dein Landsmann hier reviewed manchmal solche Bücher:
http://radio.javaranch.com/val/2005/06.htmloder auch im Mai.
Diesen Monat ein teures Marketing Buch.
Oder das ist vielleicht auch interessant:
http://www.amazon.com/exec/obidos/tg/detail/-/0131407287/002-0196898-1435204?v=glanceAnsonsten:
Man muß schauen, dass man die Anwender nicht überfordert und sich v.a. auch Mühe machen
jeden Schritt zu erklären, wenn man Anleitungen herausgibt. Und immer am Ende der Satz: Wenn Sie etwas nicht verstanden haben, bitte rufen Sie mich an.
Und den Anwender nicht von vornerein für blöd halten sondern ihn ernst nehmen.
In größeren Projekten:
- sich Rückmeldungen einholen.
- fitte Leute finden und sich mit denen über bestehende Anliegen informieren
Ich hab auch öfters mit Endanwendern zu tun (zum Glück). Ich trenne aber die Zeiten zwischen für mich komplexerer Entwicklung und reden mit Endanwendern. Für schwierigere Entwicklung braucht man eine gewisse Konzentrationstiefe, die durch telefonieren sehr gestört wird.
Gruß Axel