Neulich stieß ich auf eine ältere Diskussion bei Coding Horror: How to Write Technical Documentation:
Welcome to the world of technical documentation! The situation you are in is no different from any other tech writer. The technical writing process:
1. Ask engineer how the damn thing works.
2. Deafing silence.
3. Crickets.
4. Tumbleweed.
5. Just start writing something. Anything.
6. Give this something to the engineer.
7. Watch engineer become quite upset at how badly you’ve missed the point of everything. [...]
Das Startposting ist eine amüsante Übertreibung (wobei mir der Ablauf nicht gänzlich unbekannt vorkommt). Aber wirklich interessant fand ich die Rückmeldungen von der Sorte:
Not sure why one would go to the developer? I prefer to play with the software myself, read/decipher business requirements and specs, and if all else fails, go to the business analyst, product manager, or whoever designed the thing and wrote the requirements/specs.
Ich rede zwar mit Entwicklern, es ist aber wirklich extrem hilfreich, sich vor dem Gespräch schonmal durch die verfügbaren Entwicklungsdokumente zu lesen. Für mich “tickt” jede Software auf eine bestimmte Weise, und dieses Ticken wird primär gebildet aus
a) der Vision, die am Anfang stand,
b) Design-Entscheidungen (Architektur und Prozesse),
c) in die Entwicklung eingeflossene Use Cases,
d) GUI-Design.
Das alles macht eine Software aus, und je besser man sie in ihrer Gesamtheit versteht, desto leichter kann man sie anderen verständlich machen. Und offensichtlich bin ich nicht die einzige, die diesen Total-Immersion-Ansatz fährt…sehr ermutigend. Der einzige Nachteil dabei: ich verstehe designbedingte Einschränkungen meist so gut, dass ich wenig Visionen für Verbesserungen habe.
2 Responses to “Entwickler und Dokumentation”
Sorry, the comment form is closed at this time.
Meine Tweets abonnieren 
Das schlimmste was doch passieren kann ist, wenn zum Schluss in der Doku bzw in den Werbetexten nachher was “versprochen” wird, was die Software garnicht kann. Von daher lieber ein bisschen mehr reden :-)
Hallo Carsten :) Ich rede auch gerne und viel mit den Entwicklern, schließlich ist es am Ende leichter, was zu kürzen, als Fehlendes zu ergänzen. Die Dokumente drumherum sind allerdings auch eine wichtige Quelle der Erleuchtung.