Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: OT: Project clients

by FoxtrotUniform (Prior)
on Oct 20, 2004 at 00:50 UTC ( [id://400721]=note: print w/replies, xml ) Need Help??


in reply to Re^2: OT: Project clients
in thread OT: Project clients

(I)f you don't know what you want why do you want me to do something that you will change?

Because it's the best I can do.

As a client, I probably don't know exactly what I want until I try to do it. I can give you a general idea of what I want, and when you give me a program that does it I can use it for a while, see what I like and what I don't, and ask for updates.

Making people sign off on requirements ahead of time isn't a great idea
I have to disagree here. If this was the case then there would be no need for a business case for a project.

Okay, I think I stated my point a bit too strongly. I don't mean that specifications are useless, and that design and development should proceed on an ad-hoc, seat-of-the-pants basis. What I mean is that getting your clients to sign off on a comprehensive business case that doesn't change, ever, is probably going to result in unhappy clients. If nothing else, the business environment is probably going to change between specification and delivery.

By all means, maintain the project's business case: solving the business problem is what your software's all about. When the business case changes, make allowances in the schedule, because changing the program takes time. But it's much better to keep getting feedback over the course of a project's lifetime than it is for the developers to deliver a product that satisfies the initial requirements perfectly and is completely unsuitable for what the company's trying to do now. ("Hey, you signed off on it two years ago, don't come complaining to me if it isn't what you wanted.")

Finally there is a difference between the following (using your example):
all textures will be created from a bitmap.
and this
All textures will be created by our designers. We must agree the formats the application will support as part of the new workflow in the design team.

Sure there is: the first one is a technical requirement, while the second one is not. Only the first one is at all interesting in the context of my example, which was purely technical. Your misunderstanding is probably my fault; I'm using technical jargon with subtle semantic nuances in a public forum that isn't dedicated to graphics programming. (To me, a "texture" is a chunk of memory that the graphics card can map onto polygons, while a "bitmap" is a chunk of memory representing pixels in a raster image. No designers are involved at this level of abstraction.)

This thread is an example of what I'm talking about: we don't really understand each other's assumptions, so we need to go back and forth, clarifying our points and (with luck) iteratively coming closer.

--
Yours in pedantry,
F o x t r o t U n i f o r m

"Lines of code don't matter as long as I'm not writing them." -- merlyn

Replies are listed 'Best First'.
Re^4: OT: Project clients
by simon.proctor (Vicar) on Oct 20, 2004 at 08:18 UTC
    We don't really understand each other's assumptions, so we need to go back and forth, clarifying our points and (with luck) iteratively coming closer.
    That must make my list in some form ;).
Re^4: OT: Project clients
by radiantmatrix (Parson) on Oct 20, 2004 at 13:38 UTC
    getting your clients to sign off on a comprehensive business case that doesn't change, ever, is probably going to result in unhappy clients. If nothing else, the business environment is probably going to change between specification and delivery.

    The point behind getting a signed business case isn't that it shouldn't ever change. The idea is that it can't be changed lightly, and there is an understanding that altering the business case is going to change your estimate of time and may even require you to re-write code.

    If I am given a business case, I can make a reasonable projection of how long the project will take and what resources it will require. If the business case changes -- and especially if that change requires re-work -- those projections must change, as I will never be able to meet the original deadline. By having a signed business case (or "deliverables" document), you CYA: the client has an understanding that they are essentially altering the contract.

    radiantmatrix
    require General::Disclaimer;
    "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://400721]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2024-03-28 19:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found