|
Sorry - maybe you didn't use Waterfall, but I was suggesting the Waterfall type methods that require agreement on requirements can lead to the type of problems you experienced. That is all.
|
|
|
|
|
Are you saying that agile does not require or expect requirements or design to be approved? 
Failure is not an option; it's the default selection.
|
|
|
|
|
Don't know about Agile, but I'm lucky, my customer is always on my team. He is part of the process. Not everyone can work this way, but having reviewed sign off battles before, I don't work any other way - except, I confess, with some US clients and then I cringe.
|
|
|
|
|
I agree entirely. If you insist on coding in a waterfall, you're going to run many more risks - including damage to your computer equipment as the water pours into the back of it.
|
|
|
|
|
I've got very wet a number of times - that's why I'm very, very wary of coding in a Waterfall.
|
|
|
|
|
Your development methodology has no effect whatsoever when your client is a lying sack of dung. They can be 'engaged', and a 'stakeholder', and 'part of the process', but if they decide to stiff you, they're going to do it anyway.
The only way I've found to deal with this problem is to bill them often as the work proceeds. If they stop paying, I stop working, and I'm never more than one billing cycle in the hole.
Software Zen: delete this;
|
|
|
|
|
That will work, but doesn't sound a lot of fun working for a client who is a lying sack of dung. Why do you do it?
|
|
|
|
|
All clients have the potential for being lying sacks of dung. They usually don't exercise it immediately, which is why you can end up in that situation.
I've only had to use my solution to the problem once. In that case, the client was a university professor who didn't want to deal with his institution's bureaucracy to ensure I got paid on a timely basis. I had to 'down tools' in order to get his attention.
Software Zen: delete this;
|
|
|
|
|
Been there, done it and got a T-Shirt. 
I don't envy you! Good luck.
|
|
|
|
|
What is not written does not exist. Have you protocolled the meetingsd, and have him signed the specifications ?
|
|
|
|
|
Did you read the part about the client refusing to acknowledge the signoff ?
Failure is not an option; it's the default selection.
|
|
|
|
|
So the client denies that the signature is his? Or are you talking about a virtual signature?
|
|
|
|
|
Electronic signatures audited by a high grade document repository system and multiple meeting notes and in the presence of multiple people.
Failure is not an option; it's the default selection.
|
|
|
|
|
Or, to quote Samuel Goldwyn (The G in MGM [the movie studios]):
A verbal contract isn't worth the paper it's written on.
|
|
|
|
|
Mark Nischalke wrote: I'm seriously considering wearing a video camera and microphone any time I'm
with the client.
Forget wearing it. Setup one in the corner of the room on a tripod and tell them what it's for. It will seriously keep them VERY honest.
|
|
|
|
|
Don't you have written minutes of the meetings, email records and tracable sign-off documents with their name on it? If not, that's pretty dumb ... but if they persist in making impossible demands, tell them that if they don't pay you for phase 1 you own the IP and demand that they take the production system down, and walk away from any payment for the next phase.
|
|
|
|
|
I would recommend switching off the video camera before ripping the arms off the client so that there is no evidence of the event that will be admissible in court.
|
|
|
|
|
I've worked at my current job for almost 10 years and have never been asked to produce metrics of any sort (1). We recently installed a new departmental head and he's made it clear that everything is about to change. He wants to run the place like a highly competitive business.
So now the requests for metrics reports are starting to pour into my office.
I find this alarming for two reasons:
1: I've no idea what code to give to "Blowing time on Code Project".
2: I need a name for the report that works out with the initials TPS[^].
I'm glad I could turn to you guys for help in this matter.
NOTES
-----------------------------------------------------------------
1: My only metric has been making my clients happy.
|
|
|
|
|
MehGerbil wrote: I've no idea what code to give to "Blowing time on Code Project".
Code it under R & D. Just don't be to specific about what it is you are researching 
Common sense is not a gift it's a curse. Those of us who have it have to deal with those that don't....
Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow.
You can't scare me, I have children.
|
|
|
|
|
Depends what sort of stuff you're actually doing really. For example, if you are QA you might look at bugs found per day, if you're developing you might look at number of bugs released to QA.
However, this leads to a fairly obvious problem of QA vs Development: Devs are inclined not to release code on time (so they can find and remove all possible defects) while QA are inclined to find defects that aren't really defects (for example "the spec says the button should say 'hello' but when I set language to French it says 'bonjour'")
This is a contrived example, but it's my belief that any metric can be gamed to look better or worse easily and usually to detrimental effect. Metrics are fine when you're counting how many t-shirts a factory worker has sewn, but I'd be very worried about working anywhere with metrics set for knowledge workers.
Chris
|
|
|
|
|
This is true.
I used to have a job working in a print shop. They had metrics for everything. Any ways, the metrics allowed 45 minutes for a change over when switching to a different size of paper but the job actually only took 10 minutes.
So instead of running all jobs of the same size through and then doing a change over I'd run a job of size X paper, change over, run one job of size Y paper and switch back and forth all day long. I'd get credit for 16-20 hours of work while only having worked 8 hours. Management was pleased with my numbers and rewarded me for it.
The system actually encouraged me to work less efficiently and rewarded me for working less efficiently.
Stoo-pid.
|
|
|
|
|
Yup, and it's all too often badly applied to development:
- Lines of code written per day: use lots of carriage returns
- To counter that, lines of code written per day based on character count excluding white space: copy and paste code instead of using methods, don't remove old redundant code, write long pointless comments.
It soon turns into an arms race of people setting metrics vs programmers working out how to play the game rather than do good work.
|
|
|
|
|
When my wife worked for the NHS some brain-dead moron of a sub-manager implemented a system where the community nurses theoretically only had 32 units (15 minutes each) per day and 15 units were to be spent on patient visits and the rest updating case histories and ordering supplies, etc. The stupid pratt who came up with the system never took into account that travelling to and from a patient could take 2 units of time (often more). My wife and others only had 2-4 units a day to spend on case management. The manager then decided that they were not committing themselves to the concept so it was reported to the senior management that the staff were not supporting it. Within a few weeks, another moron came up with another system. You should be able to play them against each other. The senior managers took no notice of the moron's complaint. It was all conveniently forgotten.
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68).
|
|
|
|
|
c2423 wrote: This is a contrived example,
That is hardly contrived at all if it is made clear to the employees that that will be a primary factor or a significant one in employee evaluations.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
