 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Feb 2014 09:34:09 +0000, Orchid Win7 v1 wrote:
>>>> Whoever asked you the question has got a bright future in Senior
>>>> Management.
>>>
>>> I'd rather guess they already have a bright /history/ in Senior
>>> Management...
>>
>> Well, some sort of history. ;)
>
> Yes, this is a question direct from our MD, so...
>
> We quite often asks us what features we *don't* have. There's a logic
> there - whatever feature we don't have, that's probably what we want to
> go implement next. Except... this set is extremely poorly defined!
If he's got a good sense of humour, maybe try "well, it doesn't herd
goats" - or something equally as ridiculous, and see if he picks up on
how broad his question is.
If he doesn't have a good sense of humour, then maybe just ask some
clarifying questions that point this out in a similar manner, along the
lines of "well, that's a pretty broad question - did you have something
more specific in mind?"
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.02.2014 20:51, schrieb Francois Labreque:
> Le 2014-02-01 12:42, clipka a écrit :
>> Am 01.02.2014 10:34, schrieb Orchid Win7 v1:
>>>>>> Whoever asked you the question has got a bright future in Senior
>>>>>> Management.
>>>>>
>>>>> I'd rather guess they already have a bright /history/ in Senior
>>>>> Management...
>>>>
>>>> Well, some sort of history. ;)
>>>
>>> Yes, this is a question direct from our MD, so...
>>>
>>> We quite often asks us what features we *don't* have. There's a logic
>>> there - whatever feature we don't have, that's probably what we want to
>>> go implement next. Except... this set is extremely poorly defined!
>>
>> Sounds more like the sales department is poorly "defined". Shouldn't
>> they keep an eye open to what customers are asking for, and what the
>> competitors are offering?
>>
> Yes, but they're not technical enough to understand that mumbo jumbo, so
> they're asking the techies, in this case, Andy and his team.
That's obviously a false assumption.
If it was just about not understanding mumbo jumbo, they'd ask the
developers to implement mumbo jumbo by next thursday with a budget of 42
man-hours, because that's what they've already sold.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If he's got a good sense of humour, maybe try "well, it doesn't herd
> goats" - or something equally as ridiculous, and see if he picks up on
> how broad his question is.
The usual joke is "well it doesn't have an espresso function yet".
> If he doesn't have a good sense of humour, then maybe just ask some
> clarifying questions that point this out in a similar manner, along the
> lines of "well, that's a pretty broad question - did you have something
> more specific in mind?"
The trouble is, the answer will be something of the form of
"Hey, we should get our product to do XYZ. I saw an Internet video of
another product that does XYZ, so it shouldn't take long for us to do it."
There are two problems here.
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.
Second, he has this strange delusion that if any other company, anywhere
on Earth has done something, it must be trivial for us to do it as well.
Never mind that some of these products have a team of hundreds of
developers behind them; the feature *sounds* simple, so it must be easy
for our team of 4 developers to duplicate that feature. By the end of
this month, please?
But the main problem, of course, is simply that, like many managers, he
wants our product to have *every* feature. But, unlike the *good*
managers out there, he is physiologically incapable of prioritising
stuff. To him, *everything* has maximum priority - which isn't helpful.
Also, he becomes obsessed with certain features because they sound cool
and exciting, rather than because actual customers are willing to pay
money for it.
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.
Then again, I am the world's foremost expert in reading people's
intentions, so maybe I should just STFU...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 02 Feb 2014 11:03:16 +0000, Orchid Win7 v1 wrote:
>> If he's got a good sense of humour, maybe try "well, it doesn't herd
>> goats" - or something equally as ridiculous, and see if he picks up on
>> how broad his question is.
>
> The usual joke is "well it doesn't have an espresso function yet".
I like it. :)
>> If he doesn't have a good sense of humour, then maybe just ask some
>> clarifying questions that point this out in a similar manner, along the
>> lines of "well, that's a pretty broad question - did you have something
>> more specific in mind?"
>
> The trouble is, the answer will be something of the form of
>
> "Hey, we should get our product to do XYZ. I saw an Internet video of
> another product that does XYZ, so it shouldn't take long for us to do
> it."
>
> There are two problems here.
>
> 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.
> Second, he has this strange delusion that if any other company, anywhere
> on Earth has done something, it must be trivial for us to do it as well.
> Never mind that some of these products have a team of hundreds of
> developers behind them; the feature *sounds* simple, so it must be easy
> for our team of 4 developers to duplicate that feature. By the end of
> this month, please?
Work up an actual estimate of the time it would take to do it.
> But the main problem, of course, is simply that, like many managers, he
> wants our product to have *every* feature. But, unlike the *good*
> managers out there, he is physiologically incapable of prioritising
> stuff. To him, *everything* has maximum priority - which isn't helpful.
> Also, he becomes obsessed with certain features because they sound cool
> and exciting, rather than because actual customers are willing to pay
> money for it.
I've worked with managers like that - and it's important in situations
like that to learn how to manage your manager, and to manage the
expectations.
The first company I contracted with on writing gigs was (is) owned by
someone who is like that - every day, the feature set would change, which
would change the documentation I was working on. His CTO described his
job as being "Joe's handler," and I made sure the CTO (who had contracted
me) knew every change in product functionality made work that I'd done
irrelevant, and that because the spec was changing - something not in my
control - that meant the project would take more time for me to finish.
"Joe" didn't understand that, but as he was personally funding the
company, as long as he kept paying the bills, I was fine with him
changing the spec.
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".
> 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.
>
> Then again, I am the world's foremost expert in reading people's
> intentions, so maybe I should just STFU...
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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
