POV-Ray : Newsgroups : povray.off-topic : Set complement : Re: Set complement Server Time
28 Jul 2024 18:25:20 EDT (-0400)
  Re: Set complement  
From: Jim Henderson
Date: 4 Feb 2014 16:08:59
Message: <52f156eb$1@news.povray.org>
On Tue, 04 Feb 2014 08:40:48 +0000, Orchid Win7 v1 wrote:

>>> First, you frequently find that what he *thinks* the product in the
>>> Internet video does isn't what that product *actually* does.
>>> Frequently he asks us to do XYZ, when that's mathematically
>>> impossible.
>>
>> Then what you do is drill into details.
> 
> This guy seems to have a memory like a sieve.
> 
> He asks us to implement a feature. We tell him it can't be done. "Oh,
> can't you just do X?" "No, because Y, Z." "Hmm, but what about... oh, I
> guess you're right. Oh well."
> 
> Two weeks later... he asks for the exact same feature. And we repeat an
> identical conversation, again with the same conclusion. He understands
> that, no, what he wants us to do isn't technically possible. And yet, a
> few weeks later, he's completely forgotten that this conversation ever
> happens.

He might also be looking to see if he gets a different answer.

I might counter it by saying "we talked about this a couple weeks ago - 
here's a summary of the conversation."  Do it enough times, and he'll 
remember.

> On the other hand, it means that next time he asks us to implement some
> whizzy new feature, we'll have forgotten all about it in a few days'
> time. ;-)
> 
>> Work up an actual estimate of the time it would take to do it.
> 
> Is there a way of doing that which is more accurate than sticking your
> finger in the air?

Of course there is.  Google "PMP" and "project estimation".  Software 
companies do this all the time.

> I mean, we all know what will take us ten minutes, and what will take
> months. But it's hard to be more accurate than that.

Hard, sure - nobody said life was easy.

>> Of course, eventually he ran out of patience for the work I was doing
>> (because it was never finished), and he didn't renew the contract (but
>> that was OK as I had another gig lined up), and looking at the product
>> today, I see very little of what he actually paid me for, because the
>> product functionality has changed completely.
>>
>> Oh, and 2 years later, they still don't really have a "version 1
>> release".
> 
> We release a fairly constant stream of updates and improvements. We do
> this by more or less ignoring everything that comes out of the MD's
> mouth, and just doing what we planned to do in the first place. ;-)

Which is a good tactic to use sometimes.  Otherwise, what you have to do 
is estimate using a weighted average what the impact to the project is 
and then say "we can do that, but it'll take us at least x amount of time 
to add that, which will delay release by y days."

>>> Then again, often a customer has no interest in buying our product, so
>>> they will start playing a game of "Does it do X? Does it do Y? Does it
>>> do Z? Oh, it can't do Z? Then we won't be buying it." Which our MD
>>> takes as meaning "if only it could do Z, we could sell MILLIONS!" Erm,
>>> no, if it could do Z, the customer would simply find some other excuse
>>> to not buy it. There is a difference between a customer who can't use
>>> the product without Z, and a customer who just wants an excuse to fob
>>> you off with.
>>
>> It might not be good for customer A to have feature Z, but if it's a
>> significant enough feature, it might entice a new customer.
> 
> Even if one specific customer really does want feature Z... Are they
> *actually* going to buy the product, or buy more of the product than
> they would have? Because if the answer is no, why are we disrupting the
> schedule to spend development time on this? If there's *lots* of
> customers that want a feature, then we should totally do it. But this
> business of developing something for one specific customer who may or
> may not even give us any money... that doesn't seem very profitable.

Depends on whether it's a useful feature or not in the context of the 
software.  Depends on if your salespeople can use it as an additional 
hook with other customers.  That's what product management is all about - 
gathering requirements from customers (and prospective customers), 
turning those into requirements, and then building a plan for creating 
the product.

Do you have a product manager?

> Then again, our business model is the extraction of money from people
> who, by definition, have constant budget cuts, so...

Which seems to still work pretty well - from a sales perspective, the way 
you sell to customers like that is to show them that by spending money, 
they save money.

Jim
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.