4 ms·

That's a nice sentiment, but I don't see how you can apply it to any situation that involves estimating a project for a client, based on client's requirements.

That's a nice sentiment, but I don't see how you can apply it to any situation that involves estimating a project for a client, based on client's requirements. I wish the article actually addressed the problem of estimating the time/effort for the whole project. What I'm dying to learn is what one is supposed to do when the client says "I need a system that does X, Y and Z. How long do you think it will take you and how much would you charge for it?" One thing I'm sure you can't do is say "I don't know, because making accurate long-term estimates is fundamentally impossible. But hey, I know we're going to do a great job, so why don't you just trust us?"

evolve2k 13y ago
I think what the article is highlighting is that the it needs to do x, y and z for the cost of the implicit budget I have in my head as a client is fundamentally broken and discussions need to address the inherent risk otherwise estimates will continue to be wildly wrong. It's hard because it takes a mature operator to say no I won't give you a total time estimate for what you just explained to me in 5 minutes. The context needs to be, crafting software is difficult what's important is that you prioritize your desired features in case delivering those early ones blows out and uses up your budget it's then about hiring developers who you can trust to drive the project professionally and honestly and work hard and not stuff you around. Let's talk about why we think we are the ones worthy off your trust and the sorts of things you should be looking for in hiring a developer.
dreamfactory 13y ago
If the client is asking for an implementation as per your example, you already have a major problem (and are in a race to the bottom as a supplier). The spec should be expressed purely in terms of business outcome (e.g. I need a system that can handle more transactions within the next 3 months). (Not to mention that the most interesting and valuable requirements are usually the ones that the client doesn't yet know about.) Second problem with this scenario is that if you are charging a fixed amount for a complete system, you are assuming all the risk (and essentially selling a form of product). Generally that's a lousy deal for a client on build cost and maintenance of a bespoke system. Few desired business outcomes are so unique that they require a bespoke solution - so this should really be a very niche business, not the norm at all.
rwallace 13y ago
Usually the best reply is along the lines of: Refining the requirements is an iterative process; we'll both learn more on the way about exactly what the system needs to do and how it should do it. So let's break it down into small steps. We'll implement X first, then you pay us for X based on how long it turned out to actually take, then we can move on to Y. If you're unsatisfied at any stage you can walk away and keep everything you've paid for thus far.

evolve2k 13y ago

I think what the article is highlighting is that the it needs to do x, y and z for the cost of the implicit budget I have in my head as a client is fundamentally broken and discussions need to address the inherent risk otherwise estimates will continue to be wildly wrong. It's hard because it takes a mature operator to say no I won't give you a total time estimate for what you just explained to me in 5 minutes. The context needs to be, crafting software is difficult what's important is that you prioritize your desired features in case delivering those early ones blows out and uses up your budget it's then about hiring developers who you can trust to drive the project professionally and honestly and work hard and not stuff you around. Let's talk about why we think we are the ones worthy off your trust and the sorts of things you should be looking for in hiring a developer.

dreamfactory 13y ago

If the client is asking for an implementation as per your example, you already have a major problem (and are in a race to the bottom as a supplier). The spec should be expressed purely in terms of business outcome (e.g. I need a system that can handle more transactions within the next 3 months). (Not to mention that the most interesting and valuable requirements are usually the ones that the client doesn't yet know about.) Second problem with this scenario is that if you are charging a fixed amount for a complete system, you are assuming all the risk (and essentially selling a form of product). Generally that's a lousy deal for a client on build cost and maintenance of a bespoke system. Few desired business outcomes are so unique that they require a bespoke solution - so this should really be a very niche business, not the norm at all.

rwallace 13y ago

Usually the best reply is along the lines of: Refining the requirements is an iterative process; we'll both learn more on the way about exactly what the system needs to do and how it should do it. So let's break it down into small steps. We'll implement X first, then you pay us for X based on how long it turned out to actually take, then we can move on to Y. If you're unsatisfied at any stage you can walk away and keep everything you've paid for thus far.