🚀 go-pugleaf

david@visix.com (David Charlap) told us:

>In article <Pine.OSF.3.91a.960327221409.9179I-100000@christa.unh.edu>,
>Ben Scott  <bscott@christa.unh.edu> wrote:
>>On 26 Mar 1996, David Charlap wrote:
>>
>>> >In short, don't talk to the users, marry them.  Unfortunately, I haven't
>>> >seen nearly enough systems designed this way.
>>
>>> Yes, this is a great idea.  But there's one big problem - the cost.
>>
>>  While it is true that the cost of doing *everything* right is way too 
>>high (thus "marrage" is a bit extreme, even in metaphor), you have to 
>>consider a few things.  One, if the user doesn't like what they see, they 
>>may not buy it, period.  Two, if they buy it and hate it, you're likely 
>>to spend a lot of time fixing what you could have done right in the first 
>>place.  Don't forget the cost of supporting the product.  Assuming you're 
>>not going to charge for support, you have to hire a staff of techies to 
>>field user questions.  This becomes expensive.  So trying to do what the 
>>user wants may not be that costly after all.
>
>Well, yes.  I hope nobody thinks I'm advocating slipshod screw-the-
>user development!
>
>My point is simply that people who ask "why can't my $100 word
>processor be completely bug free" don't realize that they're asking
>the impossible.  There are five things everybody wants in software:
>
>	- Performance
>	- Stability (no bugs)
>	- Features
>	- Cheap (low cost)
>	- On-time delivery
>
>It's not possible to get all of these in any non-trivial product.  If
>you're really good, you can get three of them.  If you're willing to
>completely sacrifice "Cheap" you can get the other four.  But that's
>about it.
>
>Development, testing, and debugging use up a lot of man hours.  Very
>often, a company has to sacrifice some degree of performance,
>stability or features in order to make a deadline or to sell for a
>price the market will bear.
>
>You see the results of this in nearly all commercial software.  It's
>not incompetence, but a natural outcome of developing a product in a
>highly competitive market.
>
>Yes, occasionally someone gets lucky and manages to get four or all
>five of these criterial, but one is really foolish to expect dumb luck
>to work in your favor every time.
>
>---------------------+--------------------------------------------------------+
>David Charlap        | The contents of this message are not the opinions of   |
>david@visix.com      | Visix Software, nor of anyone besides myself.          |
>Visix Software, Inc. +---------------------------+----------------------------+
>Member of Team-OS/2  | What does this button do? |
>---------------------+---------------------------+
>

The simple answer is "of course"!  But the simple answer never
suffices, does it?

So let's add a few disclaimers.  If the company for whom you are
working is fully set up for telework or virtual corporation operation,
then this should not be a problem.  The factors will be fully defined
and you only have to comply with them to produce a satisfactory
product.  One of the more novel approaches I have seen for such a
company is to write the technical and user manuals in advance and use
these as specifications for programming work.  If the programs fully
meet the specs defined by the documentation, then they are deemed
acceptable.  If not, then they are not...

The definition of what the end-user needs / wants is a marketing
function.  In a marketing-driven virtual corporation, this requirement
is fully analyzed and documented before any development begins.
Marketing produces a definition document that is the basis for all
subsequent devlelopment.

The virtual developer then takes this def doc and analyzes it
thoroughly.  If there are problems with the definition, these problems
are negotiated, usually through revisions to this def doc.  

When all parties agree to the specs from the def doc, development
begins.  It normally begins by quoting a price/time for
implementation, but some markets might also accept t/m pricing, if
they are desperate enough.

From this point, there is absolutely no problem is remote work via the
Internet, or other mechanisms.  The bottom line is that the vendor has
committed to produce the product within the required timeframe.  This
is the standard agreement, is it not?  What is the problem?

To answer my own question, the problem is that most customers do not
have adequate measures in place to support telework, or anything even
close to it.  The def doc is a moving target, and the subject of
contstant meetings.  The process is less-than-defined.  Most customers
do not know how to encourage or support remote projects, without
falling back onto the endless-meeting scenario.

But, if they want to, they can learn...

--dh

____________________________________________________________________
David Hamilton                    Ursus Information Technology, Inc.