|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
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?
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.
> 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. ;-)
>> 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.
Then again, our business model is the extraction of money from people
who, by definition, have constant budget cuts, so...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/02/2014 08:40, Orchid Win7 v1 wrote:
>
> Is there a way of doing that which is more accurate than sticking your
> finger in the air?
>
> 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.
>
Standard rule of project management: 90% of the project will take 90% of
the time allocated; the other 10% will take 90% of the time. Recurse.
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/02/2014 8:55 AM, Doctor John wrote:
> On 04/02/2014 08:40, Orchid Win7 v1 wrote:
>>
>> Is there a way of doing that which is more accurate than sticking your
>> finger in the air?
>>
>> 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.
>>
> Standard rule of project management: 90% of the project will take 90% of
> the time allocated; the other 10% will take 90% of the time. Recurse.
>
That is better than the 80 - 20 percent rule.
I might use it tomorrow. With your permission.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/02/14 19:52, Stephen wrote:
>
> That is better than the 80 - 20 percent rule.
> I might use it tomorrow. With your permission.
>
Be my guest :-)
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 04/02/2014 8:18 PM, Doctor John wrote:
> On 04/02/14 19:52, Stephen wrote:
>>
>> That is better than the 80 - 20 percent rule.
>> I might use it tomorrow. With your permission.
>>
>
> Be my guest :-)
>
Do you want a byline?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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... don't think he has sufficient brainpower to attempt such a thing. I
get the impression he's just very excitable and easily distracted.
> 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.
Heh, perhaps.
>>> 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.
Hypothetically we *are* a "software company". Oh and hey, we do have
planning meetings. Trouble is, the estimation process is roughly
"everybody picks a number, and we see if the numbers look similar". That
still doesn't seem very scientific. Then again, when you're asked to
produce a new feature and you have no idea what libraries might be
available to help you or what OS-specific hiccups will trip you up, what
more can you do?
(We do seem to consistently over-estimate how long anything related to
C++ will take, which is... surprising. You would have thought we would
be *under-estimating* that.)
>> 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?
Our entire company is ten people. We don't have a lot of anything much.
Realistically, it is quite hard to figure out what customers and
potential customers *actually want*. I'm sure most companies have this
problem. Then again, most companies probably have a marketing department...
There are some specific features which the MD is *desperate* to have,
that (as far as we can tell) no customer has ever been remotely
interested in. And that's what kind of amuses us sometimes.
>> 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.
My point being, if they have no money, it doesn't MATTER how much money
they could be saving. We are not getting a sale. End of.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Feb 2014 21:41:08 +0000, Orchid Win7 v1 wrote:
>> He might also be looking to see if he gets a different answer.
>
> I... don't think he has sufficient brainpower to attempt such a thing. I
> get the impression he's just very excitable and easily distracted.
Perhaps, but I have seen some people act very flaky just for this
reason. The CEO I was talking about earlier might well be in that
category as well.
>> 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.
>
> Heh, perhaps.
Might be an interesting thing to try.
>>>> 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.
>
> Hypothetically we *are* a "software company". Oh and hey, we do have
> planning meetings. Trouble is, the estimation process is roughly
> "everybody picks a number, and we see if the numbers look similar". That
> still doesn't seem very scientific. Then again, when you're asked to
> produce a new feature and you have no idea what libraries might be
> available to help you or what OS-specific hiccups will trip you up, what
> more can you do?
Do the numbers seem to be reasonably accurate when the thing they're for
are done?
The way estimating tends to be done on projects is using a weighted
average - best case/worst case/likely case, with the likely case weighted.
> (We do seem to consistently over-estimate how long anything related to
> C++ will take, which is... surprising. You would have thought we would
> be *under-estimating* that.)
You could take the average over-estimate and figure that into your
estimates as well. That might help identify a realistic estimate
(indeed, that's how it's generally done).
>> Do you have a product manager?
>
> Our entire company is ten people. We don't have a lot of anything much.
Even still, someone should be functioning in the role of a product
manager, even if it's not their full time job. Someone who manages the
release schedule, feature documentation, etc.
It's not surprising, though, that in a small company nobody's doing that
- just that the small companies that do that tend to be a bit more
organised. :)
> Realistically, it is quite hard to figure out what customers and
> potential customers *actually want*. I'm sure most companies have this
> problem. Then again, most companies probably have a marketing
> department...
True. But marketing isn't about gathering requirements, that's a sales
job, and an engineering job. It's important for a product manager (in
particular) to be in touch with the customer base and prospective
customer base in order to identify what features customers want and need
(and to differentiate between the two, because they're not the same).
> There are some specific features which the MD is *desperate* to have,
> that (as far as we can tell) no customer has ever been remotely
> interested in. And that's what kind of amuses us sometimes.
If it were me, I might be inclined to ask what it is about that feature
that he thinks customers would like. It could be that there's a value
proposition there, and he's just not sharing it for some reason. If he
can be made to look at it from a customer's perspective (he wouldn't have
been a customer at some point in his career, would he?), he might either
see the feature as pointless (but interesting), or he might help others
see why it would be valuable.
>>> 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.
>
> My point being, if they have no money, it doesn't MATTER how much money
> they could be saving. We are not getting a sale. End of.
Only if you don't have the price point right.
Most companies respond very well to demonstrations that if they spend
£1,000, it'll save them £5,000. But you have to have data to back such a
claim up - if you make the claim and there's no data, then they'll think
you're lying.
A good salesperson is going to be able to take data like that and spin it
into (without explicitly saying it) "you'd be stupid not to spend the
money with us."
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hypothetically we *are* a "software company". Oh and hey, we do have
> planning meetings. Trouble is, the estimation process is roughly
> "everybody picks a number, and we see if the numbers look similar". That
> still doesn't seem very scientific. Then again, when you're asked to
> produce a new feature and you have no idea what libraries might be
> available to help you or what OS-specific hiccups will trip you up, what
> more can you do?
You iron out those issues in the "investigation" phase of the project,
or whatever you want to call it. Here we call it Phase 3, which is the
engineers scratching the surface, doing some rudimentary testing etc,
and providing very specific deliverables at the end, which includes a
detailed time schedule. Phase 4 is then where all the detail work gets
done, of course you'll hit hiccups, but hopefully during phase 3 you
minimised the risk of any big ones and identified the things most likely
to trip you up.
Although we do products that consist of mechanical, electrical and
software elements, I assume a similar development process is in use for
software-only products. I can imagine phase 3 being selecting which
libraries to use and doing some basic testing on them, identifying any
high-risk areas and doing some testing on those, planning a framework
for the product etc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.02.2014 09:39, schrieb scott:
>> Hypothetically we *are* a "software company". Oh and hey, we do have
>> planning meetings. Trouble is, the estimation process is roughly
>> "everybody picks a number, and we see if the numbers look similar". That
>> still doesn't seem very scientific. Then again, when you're asked to
>> produce a new feature and you have no idea what libraries might be
>> available to help you or what OS-specific hiccups will trip you up, what
>> more can you do?
>
> You iron out those issues in the "investigation" phase of the project,
> or whatever you want to call it. Here we call it Phase 3, which is the
> engineers scratching the surface, doing some rudimentary testing etc,
> and providing very specific deliverables at the end, which includes a
> detailed time schedule. Phase 4 is then where all the detail work gets
> done, of course you'll hit hiccups, but hopefully during phase 3 you
> minimised the risk of any big ones and identified the things most likely
> to trip you up.
>
> Although we do products that consist of mechanical, electrical and
> software elements, I assume a similar development process is in use for
> software-only products. I can imagine phase 3 being selecting which
> libraries to use and doing some basic testing on them, identifying any
> high-risk areas and doing some testing on those, planning a framework
> for the product etc.
Sounds like feasibility study to me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|