|
|
| Author | Subject | Snark
Registered User
(7/30/00 11:37:52 pm)
4.3.199.193
Reply | Edit | Del All | Good Enough?
I have a situation loosely related to the "nice guy" thread here. I am on this project as a sort-of project manager and technical resource. We are right at the point of our first milestone delivery -- which is (on my specification) supposed to include enough functionality to go into (limited) production immediately.
The problem, of course, relates to that "sort-of" business. I came into the middle of the project -- "middle" being after it had already overrun the (unrealistic) initial estimate by 100%. The only politically palatable option was to try to salvage the existing code. Two guys on the project had come on from the earlier effort -- and worked to bring me in. The budget was already set, with a deadline of this Xmas for final delivery. My project management had to fit within these constraints. OK, fine. But now, on the virge of first delivery, I find that the overall QUALITY of the work is not what I consider acceptable.
I've already begged two extra weeks, a reasonable request as we never got two staff positions filled. But my first glance at the "finished" work was very distressing. I have these two weeks scheduled for review, fixes, QA, and acceptance. But from where it is now, I doubt that two weeks is going to be enough.
So, do I deliver dubious quality, or try to finagle more time, ... or what?
Well, that's as may be. Let me move the question to another perpective: how do you know when a system is good enough to deliver?
Relating back to the "clients" forum, there has been pressure from the client sponsors to cut corners. Normally, I would not cut these corners -- leave out various minor features in order to (supposedly) speed completion by a day or two. I am concerned that these minor features will be perceived as missing by users, reducing the success of rollout. Well, I could deal with that if it was the only issue, but suddenly I have this overall quality issue on top of it, "quality" meaning bugs, crashes, missing highly desireable (but perhaps not strictly necessary) features. The overall "critical mess" number just went into the red zone late Friday. So this post.
"Discuss". 
Snark
| tracyb
Registered User
(7/31/00 1:31:03 am)
24.29.232.178
Reply | Edit | Del | Re: Good Enough?
>Well, that's as may be. Let me move the question to >another perpective: how do you know when a system is good >enough to deliver?
Are you in a position to speak frankly to the end users? Example "We can deliver X right now, with the following known problems (or a host of untested unknown problems) or if we have 3 more weeks, we can deliver a better product. Which option best suits your needs?"
If not, make sure you CYA with the client about the risks of delivering such a product with inadequate testing. In writing is best - such as - any status reports you might provide to the client on a regular basis, or email. Save judgment on their foolishness of making such a decision, just state objectively: "Current status of the product indicates that the users will not be receiving the quality or functionality expected (explain specifics).... I would recommend delaying deliverables until such a time when product can undergo further improvements and/or testing. If time does not permit, risks include (detail here)."
| David Randolph
Registered User
(7/31/00 10:06:44 am)
4.3.139.111
Reply | Edit | Del | Re: When is Good Enough?
Lets start with the basics here.
1. Are you documenting the defects found? If so, then you are able to bump the question up the chain. Simply, point out the list of defects found and let your management make the decision.
This, of course, is assuming that you are working on a per hour basis. If you are working on a fixed cost basis (as well as the fixed time basis which is a bad mistake) then you have got a headache that we are not able to help with.
If you are not documenting the defects, then start NOW!
2. The types of defects found indicate where in the development cycle your project "really" is. What I have noticed is that the first line of defects found are those in individual modules - those that are easily noticed with minimal testing. The second line of defects occur in the interplay between modules (do this action over here and that module over there stops working). Then, come the system wide problems - capacity loads, it works in this environment but not at the customer site, etc. Then come the intermittant and /or timing and /or wierd problems (only when these values occur over here and those circumstances over there, does that module over there stop working).
(Does anyone have more things to add to this list?)
Basically, if the type of problems you are documenting right now are of the first type, then you are not even half way through the bug detection and correction phase. I would not recommend to anyone to give such a system to the final user. I would note the time it takes to get to the second level of bugs and allocate at least twice as much time for the rest of the debugging phase. (other rule of thumb suggestions?)
David Randolph
| Snark
Registered User
(7/31/00 11:13:22 pm)
4.3.199.193
Reply | Edit | Del | Re: Good Enough?
>Are you in a position to speak frankly to the end users?
Yes, but they are, y'know, end users. Remember, I mentioned that they are encouraging me to cut corners. The concept of "bug" doesn't really occur to them. Yes, I am keeping a log of bugs discovered and fixed, but what can I do with it? If I show them the list, they'll berate me for wasting time coding all of those bugs in the first place!
I am actually more concerned with the "soft" problem of being coerced into delivering a system without features I think it should have. Users will moan, and nobody will come out a winner. But I've gotten nowhere with this discussion -- nowhere with client personnel, also nowhere in one or another discussion with most other developers.
Sigh.
Yes, I do plenty of CYA, I leave a lovely paper trail everywhere I go. But that don't feed the bulldog.
Snark
| Snark
Registered User
(7/31/00 11:17:18 pm)
4.3.199.193
Reply | Edit | Del | Re: When is Good Enough?
>2. The types of defects found indicate where in the
>development cycle your project "really" is.
Don't remind me (holding my head in my hands).
>I would note the time it takes to get to the second level
>of bugs and allocate at least twice as much time for the
>rest of the debugging phase. (other rule of thumb
>suggestions?)
Hmm. I'm afraid that sounds about right to me, and if it is, I'm going to have to slip delivery again.
Well, now I've got to get creative, and figure out how to blame it on something or someone else.
Actually, I think that in time and dollar terms we're not too bad, but, y'know, a slip is a slip, no matter on what flimsy basis the original goals were set. Still need to find a patsy, ...
Snark
| tracyb
Registered User
(8/1/00 12:20:01 am)
24.29.232.178
Reply | Edit | Del | Re: Good Enough?
>I am actually more concerned with the "soft" problem of >being coerced into delivering a system without features I >think it should have.
If you really think there are features that the user community will miss, try 'splaining it to them in their own language. Translate the technical issues into one they can relate to on a business level. If there are infrastructure type issues that don't relate directly to functional usage of the product, explain this to them in terms of system cost, reliability, or some other such terms that won't make their eyes glaze over, praying for you to end the technobabble!
What I've tried to do on most projects is to determine business drivers for each user requirement. This way, when functionality is heading for the cutting board, we are able to say who originally requested the feature, what the business drivers were behind the requirement, and thus, can determine what the business impact will be if the feature is not delivered. Additionally, in our bug tracking database, we've added a field for "business impact" where we can provide an explanation of the impact to the end user if the bug is not fixed.
Of course, I know all to well that frequently, business users are "too busy" to provide requirements and input during the life-cycle. This frequently leaves developers who may not understand the business domain to come up with their best guess as to what the users might need.
I'd be happy to help you translate into 'business-ese' if you want to get more specific. tracyb555@hotmail.com
| Michael Stein
Registered User
(8/1/00 7:39:46 am)
207.172.11.147
Reply | Edit | Del | Re: Good Enough?
This thread deals with some of the knottiest problems we can face! Despite the flack that will get thrown, I tend to go with the folks who say that if you don't think its ready for production, you should say so. You will get a carload of criticism today, but you will get ten times as much if you let them go blindly into production! Sharing the burden is critical - call a meeting and explain the problems.Don't let it turn into a blame-allocation session - the problem exists,lets talk about solving it. If the powers that be are dead set on going live, remind them again of the types of problems that might occur and talk about what plans can be put in place to deal with them. This brings it to a nuts a bolts level that can scare them off of their ill-advised plans. If the users really need to see something, maybe you can change the "going into production" idea into a "going into a test period" - we've had pretty good luck with this. The users see something, and feel involved with the process, so they become a little less cranky.
TracyB - I really like your idea of a business impact field in your tracking software... think I might add that to ours!!
|
|
