Video tapes may be better than no documentation, but I think it's awkward if you look for something and have to watch all the films if you're looking for some detail.
You don't just write documentation because it is fun to do so. You do it to get work done more quickly. Look for:
Documents your clients asks you to give
Things you explain twice or more to different people
Delays caused by misunderstandings or simply the absence of communication (e.g. useful comments in the code).
You can find out where these breakdowns occur: everyone who does a task (something that takes less than 2 days) gives an estimate of the time he/she would need in an ideal world. Afterwards, you check the "ideal" numbers against the real time used. Compare these ratios and try to find out what has happened. You will find that either the estimate simply was too optimistic (they are at first) or there was something unnessecary which was in the way, possibly something which could be improved whith better communication.
Once you know what has to be communicated, look for the technical solution
a folder for each project to place all those nifty drawings and a document that explains the overall design (so that you don't need to view it on the screen or print it out).
Some kind of database to put reusable information in, preferrably in some searchable way. This could be done with a Wiki or with Lotus Notes or with some kind of database
The things you use for yourself can be put where you can find them.
Slashdot Mirror
Video tapes may be better than no documentation, but I think it's awkward if you look for something and have to watch all the films if you're looking for some detail.
- Documents your clients asks you to give
- Things you explain twice or more to different people
- Delays caused by misunderstandings or simply the absence of communication (e.g. useful comments in the code).
You can find out where these breakdowns occur: everyone who does a task (something that takes less than 2 days) gives an estimate of the time he/she would need in an ideal world. Afterwards, you check the "ideal" numbers against the real time used. Compare these ratios and try to find out what has happened. You will find that either the estimate simply was too optimistic (they are at first) or there was something unnessecary which was in the way, possibly something which could be improved whith better communication.
Once you know what has to be communicated, look for the technical solution