presented as "control" and "involvement" to management is a ploy to curry f= avor and extend the development period. It is immensely profitable, and man= agement, in general, seems to believe the almost obsequious demeanor of agi= le developers preferable to the old-style "you can't have this even if you = are the CEO, because it was not filed in triplicate as an initial requireme= nt." =20 Ultimately, the situation is a response to the "developer as hostage holder= " mentality that considered management as only useful to pay the bills. Man= agement wants (at least the illusion of) control, and agile developers have= learned to play to that weakness. In so doing, they are diminishing the ro= le of TWs. Pretty simple stuff, not particularly my opinion, nor representa= tive of one or three cases of personal involvement in projects. Like it or = not, it is the future. =20 =20 http://www.tekwrytrs.com/Specializing in the Design, Development, and Produ= ction of:Technical Documentation - Online Content - Enterprise Websites
Date: Mon, 29 Oct 2007 19:46:00 -0700From: rinnie1 at yahoo.comSubject: RE: ra= dical revamping of techpubsTo: tekwrytr at hotmail.com; lhs_emf at pacbell.net; f= ramers at lists.frameusers.com TW dept managers or directors in particular do have a place in developmenta= l stages. They provide user advocacy in the initial stages, when the develo= pment is most nebulous, providing direction and focus toward the common goa= l of the team: happy customers who like the product and want to buy more. F= rom the TW perspective, the TW mgr/dir gathers info about headcount impact,= resource allocation dynamics, etc. =20 =20 You simply cannot categorically state that TWs have no place at any point i= n a project, because there are too many successful use cases that prove to = the contrary, at least 3 of my previous gigs being examples thereof. It de= pends on the pace of development and the length of the product life cycle, = among other things. The faster the products develop and the shorter the pro= duct life cycle is, the more critical it is to have TW integration at the e= arliest phase. =20 Creating user assistance is indeed a necessary task, but it is only one of = many that TWs perform. User advocacy =97 getting the user expectations back= up the chain into the ears of those who can impact what the users end up g= etting =97 is at least as important as the more common task of user assista= nce. If all the user needs is assistance, they'll just ring off the hook wi= th tech support or customer service. User advocacy ensures higher quality p= roducts that lower call volume to tech support and customer service. Writin= g good, usable Help in terms that the user understands is another way to dr= op the call volume. But, rely on either without the other and you don't rea= p the maximum benefit of TW staff. =20 Rene StephensonTechnical Writer <tekwrytr at hotmail.com> wrote: That is a very big if. A full partner participant-stakeholder, or more like= ly the department manager? It is more likely that the software developers, = business analysts, and the project manager are collaborating to get a decen= t set of requirements down. At that stage, TWs have no place, whether depar= tment managers, full partner participant-stakeholders, or something else.Wh= en the requirements are determined, and possibly after several iterations, = possibly after a prototype is up and running, TWs might be brought in. Even= at that stage, it is early, because the GUI crew may not have the interfac= e coded, the developers might not have the functionality carved in stone, a= nd everything is still uncertain (in regards to exactly what the final prod= uct will be and do).TWs complete a very necessary task; creating user assis= tance. Until the final iteration, until all the requirements have been met,= until there is little or no possibility of changes to the end product, the= re is little point in generating documentation that might become obsolete a= t the next iteration.http://www.tekwrytrs.com/Specializing in the Design, D= evelopment, and Production of:Technical Documentation - Online Content - En= terprise WebsitesDate: Mon, 29 Oct 2007 08:26:46 -0700From: lhs_emf at pacbell= .netSubject: Re: radical revamping of techpubsTo: tekwrytr at hotmail.comCC: f= ramers at lists.frameusers.comActually, I disagee, if the TW is a full partner= participant - stakeholder, or more likely the department manager in the sc= enario you are discussing, they should also participate early on to get the= sense of the uncertainty and what those issues are, at the very least thes= e issues are going to affect their scheduling and the expectations they hav= e to deal with.----- Original Message ----From: Technical Writer To: Leslie= Schwartz ; framers at lists.frameusers.comSent: Monday, October 29, 2007 8:44= :16 AMSubject: RE: radical revamping of techpubsI agree wholeheartedly. Tha= t is not the issue. The issue goes back to the BA interpretation of (and tr= anslation of) the software requirements. If there is a high level of certai= nty on the client side about what the finished product should be, TWs shoul= d start early. If not, and it is essentially a fishing expedition with ambi= guous outcome, TWs are only useful at the last. Unfortunately, the "agile" = methodologies strongly sell the sense of control to executives, pushing the= idea that they can develop on the fly, adding and removing "requirements" = as the executives see fit. http://www.tekwrytrs.com/Specializing in the Des= ign, Development, and Production of:Technical Documentation - Online Conten= t - Enterprise Websites> From: lhs_emf at pacbell.net> To: tekwrytr at hotmail.co= m; bhechter at objectives.ca; framers at lists.frameusers.com> Subject: RE: radic= al revamping of techpubs> Date: Sun, 28 Oct 2007 19:04:10 -0500> > I belong= to several message - interest groups and I am used to hearing people give = their opinions in a bombastic manner. So its no> big deal to see that happe= ning here. But if this discussion is to have any real value it will be to s= hare our perspectives with> others and learn something about points of view= 's entirely different than our own, which requires some tolerance and mutua= l respect.> > > My view and experience is that it definitely helps to get t= he TW involved early on, but it=92s a waste of time for them to sit all the= > way through each meeting, and for the entire duration of each meeting.> >= Marketing requirements documents and engineering specification documents, = if they are adequately written will help the TW formulate> the user documen= tation at a fairly early stage, but the bulk of the documentation effort co= mes towards the end of the development> cycle. And ideally the writer of th= e user guide if that is they type of documentation we are discussing now, s= hould be a> knowledgeable user with some fresh insights into the learning c= urve the novice user will face, and some empathy for that new user.> > Igno= ring the need for documentation, putting it off until the last moment is a = formula for poor quality documentation.> > - In my humble opinion.> > Have = a great work week!> > Leslie> > > -----Original Message-----> From: framers= -bounces+lhs_emf=3Dpacbell.net at lists.frameusers.com [mailto:framers-bounces= +lhs_emf=3Dpacbell.net at lists.frameusers.com] On> Behalf Of Technical Writer= > Sent: Sunday, October 28, 2007 5:47 PM> To: bhechter at objectives.ca; frame= rs at lists.frameusers.com> Subject: RE: radical revamping of techpubs> > > We= ll, a difference of opinion is what makes a horse race. Iterative software = methods do not require iterative documentation methods;> in most cases, doc= umentation before the last iteration is considered both wasteful and useles= s. While I have a great deal of respect> for Steve McConnell, proposing ear= ly draft user guides as a replacement for requirement specs is a bit off th= e road. > > If you develop software, and intend to use early draft user gui= des instead of requirements, you are going to be greeting the folks> at Wal= -Mart rather than trying to pull back a contract or two from Bangalore. The= statement is at odds with most developers' (and> most business analysts') = understanding of "requirements." Putting an occasional "agile" into a sente= nce doesn't make the process any> more reasonable. > > I didn't invent the = idea of ignoring documentation until the final product is ready (or almost = ready) to ship. Far more intelligent,> competent, and capable people than m= e have decided that "involving TWs from the early stages of development" is= only useful when the> end product is carved in stone before the first line= of code is written. That, for better of worse, is rarely the case.> > Last= ly, given that about a third of all software projects, agile or otherwise, = fail so badly they are abandoned, if you ignore> documentation completely, = you have a one in three chance of coming out ahead when the project flops b= ecause you have at least saved> the cost of documentation.> http://www.tekw= rytrs.com/Specializing in the Design, Development, and Production of:Techni= cal Documentation - Online Content -> Enterprise Websites> > > Date: Sun, 2= 8 Oct 2007 12:21:17 -0700From: bhechter at yahoo.comSubject: re: radical revam= ping of techpubsTo: tekwrytr at hotmail.comCC:> framers at lists.frameusers.comSo= rry, but I find the thread both:a) Off-topicb) Misleading. Iterative sofwar= e methods require iterative> documentation methods, but by no means do they= eliminate the parallel need for early draft user manuals. In fact, Steve M= cConnell> (Code Complete) proposes early draft user guides as an agile repl= acement for requirements specs.Ben> Because the application itself> is buil= t in an iterative process, rather than > being carved in stone, reacting to= feedback from the client, documentation > before> the last minute is point= less. The reason should be obvious; the > application being documented in t= he early stages bears little> resemblance > to the application delivered. B= en Hechter Vancouver BC bhechter at yahoo.com> _______________________________= __________________________________> Windows Live Hotmail and Microsoft Offi= ce Outlook =96 together at last. Get it now.> http://office.microsoft.com/e= n-us/outlook/HA102225181033.aspx?pid=3DCL100626971033______________________= _________________________> > > You are currently subscribed to Framers as l= hs_emf at pacbell.net.> > Send list messages to framers at lists.frameusers.com.>= > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameus= ers.com> or visit http://lists.frameusers.com/mailman/options/framers/lhs_e= mf%40pacbell.net> > Send administrative questions to listadmin at frameusers.c= om. Visit> http://www.frameusers.com/ for more resources and info.> Boo! Sc= are away worms, viruses and so much more! Try Windows Live OneCare! Try now= ! _________________________________________________________________Boo! Sca= re away worms, viruses and so much more! Try Windows Live OneCare!http://on= ecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=3Dwl_hotmailnews___= ____________________________________________You are currently subscribed to= Framers as rinnie1 at yahoo.com.Send list messages to framers at lists.frameuser= s.com.To unsubscribe send a blank email toframers-unsubscribe at lists.frameus= ers.comor visit http://lists.frameusers.com/mailman/options/framers/rinnie1= %40yahoo.comSend administrative questions to listadmin at frameusers.com. Visi= thttp://www.frameusers.com/ for more resources and info. _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop = by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=3DTXT_TAGLM_Oc= tWLtagline=
