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:Robert Lauriston <robert -at- lauriston -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Fri, 6 Nov 2009 09:08:59 -0800
I've seen several reasons for useless features ending up in a product.
- The product manager is demonstrating the Peter Principle.
- The company cut product management too far, so the decisions are
being made by developers who have no contact with the customers and
don't know what they need or want, or by overworked product managers
who don't have time to get it right. (This is most likely to happen
when the CEO is a former engineer and demonstrating the Peter
Principle.)
- Program management is inadequate (perhaps PP again) or absent, so
the developers take whatever specs or design documents product
management produces and go in the wrong direction.
- An incompetent, half-hearted implementation of Agile or the like has
replaced use cases from product management (which may have been laid
off) with "stories" coming out of brainstorming sessions by
developers.
- The underlying functionality meets the requirements, but the UI was
slapped together as an afterthought, and isn't usable. (This at least
can usually be fixed in a release or two.)
Dilbert celebrated its 20th anniversary this year.
On Fri, Nov 6, 2009 at 8:11 AM, Chris Despopoulos
<despopoulos_chriss -at- yahoo -dot- com> wrote:
> Actually, I'm surprised to hear that. I find that for the last 5 years or more nobody has been willing to spend money on this type of implementation. Maybe I'm working in a bell-jar, but I don't think so. The designs I've been in on have really sought to focus on only the necessary stuff before implementation begins. To the degree that this succeeds, you can count on the feature set to require a fairly even level of coverage, and you can bet that there's some form of use case analysis. The groovy-for-the-fun-of-it features are generally commented out, and waiting for the next design cycle. It's just to expensive to implement and support this stuff, and management knows it.
> Janice Says:
> The features that the product provides are not always
> the features that need to be emphasized in the documentation
> for the presumed user. For example, I've seen features
> included in software products because the designers
> thought they were cool or were jazzed because they had
> figured out a way to implement them, but they weren't
> necessarily features that actual purchasers of the product
> either wanted or really needed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-
