TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Erika awesomely asks...
=================
So my questions are:
1. Do you also see this transformation?
2. If yes, how do you cope with it?
3. Should we manage each chunk separately according to the old model (sounds a bit crazy) or replace the old model with a new one?
=================
I most definitely see this transformation. I'll add that I would describe my workplace as hyper-agile, meaning we take all the increased fluidity of agile while discarding much of the structure. This means that the SMEs are under as much or more pressure as/than the tech pubs team (me). So there's no way I could get full reviews of the full document from the full consort of SMEs. We do DITA, which means topics. The theory is that a topic stands on its own, so review of a single topic (or at least a small set of topics) is meaningful. When a related group of topics is pretty much done, I generate that set of topics as a PDF and send it out to the manager of that team, the QA dept, Support, and other groups that are interested. That's sort of like reviewing a chapter. Near the end of the cycle, I try to generate a full PDF and send it out, but nobody ever reads the whole thing.Â
My DITA is stored in SVN alongside the code, so for each daily build I get my latest changes out to the world as online help. That used to be great until we started using ReviewBoard, and insisting that you get a review before you commit code. Since I'm the only writer, I have to wait for developers to review, and they always put that off. When the lucky day comes and we get another tech writer, we can be more agile... Can commit content changes much more quickly. Then people can see the whole doc set as it develops. Can't wait (are you looking for a job?).
I think strictly following the old model can't work. I think a new model is kind of distilling itself as we speak. It's kind of like Agile, but not necessarily. For me the biggest problem is keeping up with changes. I think some sort of automation can be implemented to track versions of X that we support, maybe other strictly technical values, maybe other things that don't strictly require a tech "author". These should be viable for automatically import into an overall doc set. Identifying who needs to review what, and getting it to him -- that would be great to automate somehow as well. Since the source is "code" and it's in source control, and it can be transformed and transported at will, we should be working along these lines. Who's got the time?
Random thoughts... I hope this thread continues.
cud
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
