SiteCrafting Blah Blah Blog
Nov. 20, 2006 at 11:55am
Two Dollars - Follow up
In response to my last post, one reader mentioned that sometimes clients take advantage of a developer's generosity, and that it seemed like I wanted the developers to grin and bear it to keep their clients happy. This is actually quite different from what I wanted to say, and so I want to expand on that a little, and why it's very important for both developers and clients to have a written set of guidelines to keep projects on track.
In my last article, I wanted to tell developers that creating something that works perfectly is almost the only acceptable outcome of a job. For example: do you notice how the gas gauge in your car (or someone's car, if you don't have one) changes depending on the angle the car is sitting on? If the car is perfectly level, the gauge reads correctly, but on hills the level may be deceptively low or high, depending on where the sensor is in the tank. This is hardly a problem when it comes to using the car; it'll keep driving as long as there is some amount of gas in the tank, but it bugs me.
I don't have a clue how modern fuel gauges work, but it's really easy to solve this problem: put four sensors in the tank, one at each corner. Average the output from the sensors, and you have a system that will display exactly how much gas is in the tank, regardless of any incline. You could even calibrate the sensors to return the exact volume of the remaining gas if you wished. Drivers don't notice any change in functionality, it just works better.
The confusion comes in when developers take the last article to mean that they have to do whatever the client wants, but that is far from the truth. It benefits both clients and developers greatly to have a Specifications Document written up and signed, before any work on a project begins. (Specifications Documents are documents that use plain but specific language to define the scope of a project)
I'm sure that most people, developers and customers alike, have had a situation where a contracted project went horribly wrong. I am no different. Usually, it's a lack of communication that causes this problem. The developer may promise something, and then forget about until 6 months into a project, or the customer may forget to mention a vital part of the project. The best way to fix this is to write out the agreement before a project starts.
Also, make sure to use very specific language that leaves no room for assumptions or interpretations. If you are creating reports from a webservice, stating that you will "Create a handful of reports" is a problem. How many is a handful? Two? Six? A hundred? I can hold a gigabyte flash drive in my hand, so does that mean I need to write a gigabyte worth of reports code? What you should do instead is put a specific number on how many reports you'll make, and then define each one. Developers don't really care how many you want, but we need to know up front.
Then, when a customer asks for something new, or even a modification of an existing piece, you'll be able to point to your document and say, "We never talked about this before." This is really handy when you have a signed document to point to, and it can be done when no document exists. It's as easy as, "Have we talked about this before?". But, if the agreements were verbal, it's possible to forget what you agreed to especially months after work has started.
Creating that document will save developers and designers many headaches, and it's also very beneficial to their clients as well. When the clients are sending out RFP's, they want to know for how long a project will take, and how much it'll cost. They also don't want surprises, and having a good, detailed proposal will go a long way. It's beneficial for them to be able to remind developers that some key functionality is missing. There aren't any nasty fights, or contract disputes, and that makes everyone happy.
Writing that document is incredibly important, and there is no good reason to not create it. If you don't have any specifications, there is still hope. As a developer, you can ask the client if you have talked about this before. If you are talking about a new feature or modification, asking for additional payment will probably be needed. Sometimes, though, someone will ask for something new, but they won't want to pay for it. In this case, it's acceptable to politely say, "I can't do that for free". After all, we do have to eat.
Probably the most important part of any web project is the Specifications Document, but they are very seldom used. When they are used, they are usually vague and leave a lot of room for interpretation. This is the cause of most headaches relating to software, and I'm campaigning to get everyone to expect and demand good specifications. I've been bugging Brian about this so much that we're now doing it for every new project, no exceptions. Having this kind of document benefits everyone, so start writing. And remember, be specific.
Posted in Software Engineering by Dave Poole
Comments (0)
Add your comment below