Re: Productivity Metrics

["Elna Tymes" <etymes -at- lts -dot- com>]

rebecca rachmany wrote:

> IFor those of you who contract, you
> *must* have some kind of measurement in place, unless you always charge by
> the hour.

The biggest problem with productivity measurements is that it's measuring output
from a process that is usually not well defined or contained. It's one thing to
measure pages per day or character strokes per minute, but that assumes that the
source material is (a) available, (b) accurate, and (c) not going to change.
Most of us in the software industry have armloads of war stories about trying to
write about a product that has sketchy or no specs, development schedules that
are routinely ignored, review processes that turn into endless loops of
correction/rewrite, and prima donna developers who think they can write.  Since
half of most productivity measures is the time variable, the ability to work to
some sort of reasonable schedule is an assumption - but one that in my
experience is subject to far too many unpredictable outside forces. To be held
accountable to a schedule that is subject to the whims of others is
unreasonable. To thus consider it as a factor in productivity metrics is simply
ridiculous.

Consider this one, fresh from the frontlines:  you are given a tight schedule
for producing a first draft.  You are rewriting an existing manual, adding new
information that should be available in bug reports and from using the beta
version of the product.  However when you go to talk to the programmers you find
that (a) one is on medical leave, (b) one has been hijacked to fight some other
fire and can't talk to you, and (c) the third developer is going on a 3-week
vacation next week and has too much on his plate to be able to talk to you.  So
you go to the QA people, thinking that they probably know about the new
features.   It turns out that they are still working with early alpha software,
because the programmers didn't release the beta code to them, and they know that
marketing requested the inclusion of four new features and a major rewrite of
the interface, none of which has been made available to QA yet. So you go to
marketing in search of some definition of the new features and the new UI, and
discover that most of the new features and all of the new UI was specified in a
meeting held last month, the minutes from which are stored on a server that has
been down for the last two weeks.

Note that your schedule hasn't moved one iota: you're still expected to produce
a draft of the manual. Howinell can you accurately measure productivity in this
environment?

Elna Tymes
Los Trancos Systems