It also helps in determining if the project was done correctly. Many times what is asked for is not heard or partly. If you put it down on paper the person that requested the job can read it and if what is written is not what they asked for they can let you know before it is released. I know of many times that a project was thought to be planned out and thought to have all of the ducks in a row but when finished did not do some particular feature.
----- Original Message ----- From: "Marilyn Hilb" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, October 10, 2005 10:05 AM Subject: RE: [U2] Programmers and Documenation. I may not be using the best verbiage.. but I do very much enjoy writing documentation. NOT I believe what is called "high-level integrated documentation". I think of that as integrating the new features into a very large and complex documentation manual on the whole system. "not my job mon". I do enjoy however witting a 'simple' word document incorporating screen shots and what I hope to be realistic usage/samples of the feature in the terms that the folks in the field would actually relate to. As a single shop here (not having an additional person to do a final QC of the project) I use the documentation phase as a final walkthrough and testing of the project. After putting the delivery onto a new file set as well, this also insures that I got all the pieces onto the delivery :). (yes, no version control here.. lets not get into that discussion again please). In addition I send the documentation to some folks in the field so they can approve of the project before it is installed. They often come up with good suggestions at that time! Doing the documentation cycle really helps me get an overall view of the project and often during this cycle I come up with additional quick bells and whistles that really just pull it all together. Amazing what simple/obvious things I see during this phase that I didn't see when working deep in the detail. I am very happy that even though this is a small shop, I am allowed the time to write up documentation. Many times I doubt that the folks who use the system give the documentation more than a glance. More than once I get a call asking about the new project.. and I answer and 'politely' say.. "it is in the document" and I get back "well, I didn't read the documentation". I grumble under my breath and make my voice smile and hang up the phone quickly. At my previous position where we had a QC team as well as an official documentation team, I was still able to write my documentation for the new features only and it was their job to incorporate it into the big manual. Worked for me :). They would also review it (in the cases where it was pure custom and did not go into the manual) and proof it for verbiage etc to make it a bit more professional sounding. The thing I didn't like about this is the folks who did the documentation new very little about the system and how it was used and the mindset of the folks in the field who actually used it. In addition the QC folks did also QC the documentation which was a good thing. Was their job to understand the project fully :). My 4cents. ~Marilyn ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
