No subject

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=