Comment Let the process help and implement wikis for certa (Score 1) 370
I haven't worked for a company that had much in the way of process documentation for almost 10 years now ... but that could be because I choose to work for startups and on open source projects, both of which tend to fly a little by the seat of their pants.
Process documentation became a lot easier to face when we adopted a species of Agile and applied it to our everyday work. Allowing those processes to guide us has taken a lot of the required negotiation between teams and roles out of the picture and eliminated the need to document some of the more mundane first-do-this-then-if-you-encounter-that-do-this kind of tedium that can bore a newbie to their core. Plus, I've been lucky enough to work as the writer embedded in teams of developers for many years, so there is little need to negotiate who has what and why aren't they sharing it - we all know who has what and how to get it from them.
I've never seen the 'if I document this well, they won't need me' situation, but I have seen the situation where a consultant/contractor comes in, does a great job, but doesn't present a leave behind document and I find that slightly despicable. Leaving behind the guide to what you did only makes me want to hire you again.
I have to agree with many of you that wikis are an absolute godsend. No one wants to spend time documenting how to do their work when they could be doing the work, but they will do a quick wiki modification when prompted. Plus, since we can all challenge each other's processes in the wikis, it makes for a little competition as we write them and that doesn't hurt our performance one bit.
In short, relying on the wikis and day-to-day communication has ensured we have to support a remarkably limited amount of process documentation.
Now, to tackle that hit-by-a-bus problem ... hmmm .... wonder who's on top of that one?
Virginia
Process documentation became a lot easier to face when we adopted a species of Agile and applied it to our everyday work. Allowing those processes to guide us has taken a lot of the required negotiation between teams and roles out of the picture and eliminated the need to document some of the more mundane first-do-this-then-if-you-encounter-that-do-this kind of tedium that can bore a newbie to their core. Plus, I've been lucky enough to work as the writer embedded in teams of developers for many years, so there is little need to negotiate who has what and why aren't they sharing it - we all know who has what and how to get it from them.
I've never seen the 'if I document this well, they won't need me' situation, but I have seen the situation where a consultant/contractor comes in, does a great job, but doesn't present a leave behind document and I find that slightly despicable. Leaving behind the guide to what you did only makes me want to hire you again.
I have to agree with many of you that wikis are an absolute godsend. No one wants to spend time documenting how to do their work when they could be doing the work, but they will do a quick wiki modification when prompted. Plus, since we can all challenge each other's processes in the wikis, it makes for a little competition as we write them and that doesn't hurt our performance one bit.
In short, relying on the wikis and day-to-day communication has ensured we have to support a remarkably limited amount of process documentation.
Now, to tackle that hit-by-a-bus problem
Virginia
