radical revamping of techpubs

[Rene Stephenson]

Perhaps. 
  However, I can speak from the experience I had at a company where the  manager of documentation attended design-phase meetings for the  products, and then she assigned a writer when a prototype was  available. The doc mgr was able to provide key input about the user  base and do some basic QA of GUI concepts that eliminated a lot of the  inconsistency issues within the GUIs, and she provided ideas for  combining GUIs or menu architecture in ways that made sense to the  users, based on comments we received in (oddly enough) documentation  feedback forms. (Apparently people will complain whenever they see an  opening, in hopes that someone will pass it along.) When a prototype  was available, the doc mgr then assigned a writer and handed off to the  writer at a product meeting. 
  
  After about 6 months of handling products this way, product managers  commented positively about the effect on the product of having the doc  mgr involved. They didn't have as many issues with rework at a point  when the code was more complicated. They got better feedback from  customers when marketing presented prototypes. QA was pleased with the  improved consistency and usability of the screens. Engineers, while  initially resistant to the idea, discovered that they could leverage  TWs for screen checks, freeing up themeselves for more technical  efforts in development. 
  
  Of course, the impact on documentation itself of earlier involvement in  the process was readily apparent. TWs knew more about the subject  product, because they had more time to learn it before the final  delivery. Extending the timeline for the documents by involving TWs  earlier in the process resulted in higher quality documents from a  technical standpoint as well as from an organizational/doc  structure/writing quality standpoint. It became possible to deliver  high-quality documentation AT the general availability (GA) date of the  product, rather than doc lagging behind. And of course, the customer  benefited.
  
  It may be an old argument, but when it is put into practice, the proof  is in the pudding. It's an old argument because it stands the test of  time and trial.
  
  Rene Stephenson

Technical Writer <tekwrytr at hotmail.com> wrote:        .hmmessage P  {  margin:0px;  padding:0px  }  body.hmmessage  {  FONT-SIZE: 10pt;  FONT-FAMILY:Tahoma  }  The argument that TWs should be involved from the design  inception is an old one, and not often found outside the circle of  TWs. The reason is simple; in the olden times when the waterfall was  the design method of choice, the docs--and the app--pretty much  stayed the same. And most of both failed miserably. 
   
  In 2007, agile development is proliferating, and RAD and XP are the  methods of choice for initial prototyping and proof-of-concept. The  reason some 70% of software development projects fail is not that it is  especially difficult to write good apps; it is because the majority of  those apps are so poorly designed that they don't do anything useful.  With RAD, it is more useful to develop a working prototype, and let the  people paying the bills see what they are going to get. THEN is  the time to involve TWs--at the same time it is handed off the Java  Dilberts.
   
   
   
   
   
   
  

 
    
---------------------------------
  Date: Thu, 18 Oct 2007 17:27:59 -0700
From: rinnie1 at yahoo.com
Subject: Re: radical revamping of techpubs
To: techcommdood at gmail.com
CC: athloi at yahoo.com; framers at lists.frameusers.com; tekwrytr at hotmail.com

HA!  Quite true! TW's usually also bring an approach that is closer to  "green field" than the developers, engineers, etc., can provide.  Because they understand how THEY INTEND for it to function and be used,  they can be a bit myopic about how what they have CREATED actually  plays out.

Rene

Bill Swallow <techcommdood at gmail.com> wrote:   I'd say that those are additional skills. What I took Chris' remark to
mean is that writers should be there through the entire process,
involved with design, so not only do they influence the product design
along with the other stakeholders, but also have a means of thoroughly
planning the entire documentation effort as part of that product
development planning. Let's face it, most tech writers come at a
product from a different angle than an engineer or a tester. It may
not always be user focused, but it certainly is from a task-based
angle. "Is this thing going to be well thought out and therefore easy
to explain or is this going to be yet another 100 page install
procedure?"



---------------------------------
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try now!