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.
Re: Doc Design and Convention - to address Gene's take on
Subject:Re: Doc Design and Convention - to address Gene's take on From:Janice Gelb <Janice -dot- Gelb -at- Sun -dot- COM> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 09 Nov 2009 08:08:02 +1100
Chris Despopoulos wrote:
>
> I've just been working for the last number of years
> in environments where a developer would have serious
> explaining to do if she stepped outside of the agreed
> bounds. Maybe that's one of the benefits of Agile...
> If the story isn't approved, you don't work on it. If
> you want to noodle in some corner of the code, you put
> the idea into the backlog and see if it ever moves
> into a sprint. And in my current position, although it
> isn't Agile we do wind up being similar. It's a smaller
> company, so top-level people vet everything. I'm surprised
> that the venerable tech institutions (Sun, Microsoft,
> Adobe, Cisco, IBM...) would not have arrived at a similar
> approach. Projects become much more predictable, and the
> features that do make it into the implementation get the
> benefit of more focused attention. It's been a long time
> since I've seen a loose cannon wreak havoc on a project
> plan as you describe.
>
I wouldn't describe it as "wreaking havoc" exactly --
they just thought they were making the product *better*
:-> Seriously, in all the cases I know of, there were
plans and procedures in place that called for changes
to be discussed and approved. However, the engineers
in question figured "Oh, this won't take too much time
and I'm in there anyway" or "Hey, look, we could do
*this* and wouldn't that make this feature even better?"
In one case, the engineers added an option with an icon
to a main GUI menu because they thought it would be more
helpful to users to get directly to a feature rather than
going through a submenu. Even though we were at beta. And
numerous screen shots that included the main menu had
already been taken.
-- Janice
***********************************************************
Janice Gelb | The only connection Sun has with
janice -dot- gelb -at- sun -dot- com | this message is the return address
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help and Manual 5: The all-in-one help authoring tool. Full support for
team authoring with multi-user editing - both directly and in combination
with VSS-compatible source control systems. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-