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.
>> Jim Barrow wrote:
>> As the software project that I'm working on creeps in scope, I have a simple question about gathering and developing
>> business and functional requirements: Do you think developers should be involved in this process?
My initial response is no. There are, of course, caveats. The biggest problem I have with developers being involved with the requirements phase is that--in my experience--developers have a difficult time seeing past their code and, in some instances, their own self interest ("that will be too hard to code"). Every business level discussion that I've been in that involves a developer has instantly drilled down to the "how" and specific technical issues before the "what," "why," and "who" have been defined. There is a time when developers are valuable, but I think that comes later, once the what, why, and who have been established.
Of course, I'm sure that there are developers out there who are capable of discussing the what, why, and who without drilling into the how, in which case, I would certainly involve those individuals because they are more likely to add the _right_ kind of value at the _right_ time.
But my response also assumes that there is some sort of step-by-step process when in fact requirements gathering is often iterative in nature involving much back and forth between the business side and the development side.
>> Gordon McLean wrote:
>> I'd venture that it's beneficial to take developers along but, as Dori
>> suggests, the tech writers should be the interpreters.
It's only beneficial if the technical writer has the skills to elicit the what, why, and who; ie if the technical writer can add the _right_ kind of value at the _right_ time. Some technical writers can. Some technical writers can't. Again, it depends on the individual and what value the individual can add to the discussion. I know that technical writers have always fought to position themselves as user advocates and that's great if the technical writers have the business knowledge and skills to do that. If they don't have those skills, however, you run a higher risk of missing a critical path or leading development down the wrong path. I say this because there are areas of knowledge that the client assumes everyone knows and while good interviewing techniques can expose some of these areas, an understanding of the business combined with those techniques will expose more.
In the OP, if the scenario you decribe is occurring, then the developers should not be talking to clients. There's a whole business aspect involved that they appear to be missing.
********************************************
Sean Hower - communications specialist http://www.sean-hower.com
_____________________________________________________________
Create your own web site for FREE at http://www.freehomepage.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
