|
in reply to Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle
Why give the customer more than the bare minimum they asked for? Why spend more time developing software than you're getting paid to spend?
If your new releases break things, that's a process problem. Try unit testing and integration testing. Everything that works in the old release should work in the new one.
|
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by Your Mother (Archbishop) on Jul 27, 2015 at 16:27 UTC
|
Why give the customer more than the bare minimum they asked for?
I understand this is definition issue but communication is often terrible with customers so it invites this theater.
Customer: I want a door.
Contractor: Here's your door.
Customer: It doesn't open.
Contractor: Oh, you didn't specify that you needed it to open. We'll add a handle.
Customer: It doesn't lock.
Contractor: Oh, you need it to lock? We'll add that.
Customer: We just tried the door. You put it on the second floor without steps. No one can reach it.
Contractor: Oh, you wanted an entry door...
The bare minimum the customer orders must be balanced with forethought and good design. I'm not saying you don't know this already. I'm quite sure you do. Just wanted to say that doing more than the bare minimum has saved me a lot of trouble in the past and when it cost more than it returned, the cost was generally quite a lot smaller than the trouble saved in the other cases.
Update: I meant when it cost me extra, not the customer. I have a strong work ethic and I put in extra time to make things right or above and beyond when I think it needs to happen.
| [reply] |
|
|
So you're saying that the actual bare minimum when a door is ordered is that it functions as a door in an opening, fully installed. That's pretty understandable if the door is ordered by an end user tenant. If the property owner wants to hang the door, you don't have to hang the door. If it's a construction contractor who orders a door from you but hinges and latches elsewhere, they just want a door. If someone wants what's called a pre-hung door -- that is, one with hinges attached and an attached jamb that then is inserted into the rough frame -- then they get the hinges and jamb. If I order a slab door from you, paid someone else for the latch, paid someone else for the hinges, and paid another party to assemble and install the pieces I probably don't want you to send a workman and additional hardware. I just want the door.
"Give the customer what they ask for" is not shorthand for "screw the customer over by misrepresenting your agreement to get out of work". You should gather the requirements and deliver what's required. Just as you shouldn't short the customer by delivering much less, you shouldn't short yourselves by delivering a bunch extra. The customer would rather pay you no more than necessary, and any extra time you have to give them they'd rather get the extra features THEY want, not what you GUESS they MAY want. When you're coming in way under budget, make that extra customer meeting about whether they want early delivery, a partial rebate (horrors!), or WHICH extra features they may want included in the original price. It's much better, trust me, then the meeting THEY call to ask why you overpriced their initial requirements to provide all this fluff they didn't ask you to write.
| [reply] |
|
|
I've found many, maybe most, customers don't have a good idea of what they actually need (I only do web-work professionally; back and front end). There is a dialog and chance to apply expertise there, not guessing, or the price-padding fluff you somewhat unkindly allege. Bare minimum, while I understood you were speaking in code for some kind of ship early best practice, would be interpreted as cheap, half-baked, or rip off in most industries. Were the cleaners good? They did the bare minimum. How's the new car? It's the bare minimum.
"I need a customer contact form," is a typical requirement for a website. Bare minimum could be interpreted a few different ways there and different levels of expertise will apply different standards. That's about as simple as the stuff gets and it's still ambiguous.
Again, I did say I knew you knew this stuff. Throwing out things like "trust me..."? And CAPS? No, you TRUST me! :P
| [reply] |
|
|
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham (Prior) on Jul 27, 2015 at 16:06 UTC
|
Why give the customer more than the bare minimum they asked for? Why spend more time developing software than you're getting paid to spend?
In general, teams are paid to support the customer. The bare minimum is not what they are asking for; they are asking for a lot more. As problems arise, they begrudgingly settle for the bare minimum.
Try unit testing and integration testing.
Full tests are expensive in both time and resources. Usually, a quick test, if anything at all, is done instead. Unfortunately, for all the teams i've been on, the testing environments were either used for more development or were not actually production-like.
If we're talking about an ideal environment where things are actually tested properly, why not wish for applications that are actually designed properly from the beginning?
| [reply] |
|
|
No. The bare minimum is what the customer requirements state. You deliver to the customer requirements. You don't deliver less, because that wouldn't meet the requirements. You don't deliver well beyond the requirements, because you'll guess incorrectly which direction to build.
If you come in ahead of schedule and below budget, looking around furiously for more value to add for the customer, then ask the customer what else they need. Don't just build more random stuff just because you have time to do so.
How this nonsense of "the bare minimum" somehow being less than what was promised comes about I'll never know. The bare minimum is what was promised. That's how promises work.
| [reply] |
|
|
The bare minimum is what the customer requirements state. You deliver to the customer requirements.
It's all about negotiation. Everything else get pushed to "another release." The "bare minimum" changes in order to release faster, and what was originally requested can take many releases to get to.
| [reply] |
|
|
|
|
