In part 1 we spoke about getting started, and interacting with you customer. Today I’ll clear a few things up about cocktail napkin specs and the advantages of sitting on-site, amongst other things.
Also please note that what I’m saying in this guide might not apply to everybody, this works for me, and works well. I think smaller teams might benefit from some of these tactics.
Dangers of cocktail napkins
Like most things in life you would have to take the good with the bad. Cocktail napkin specs can be a potential hazard to any development process if handled incorrectly. Bear in mind that you make the notes as you’re discussing the requirements with the user. From personal experience, I’ve learned that hastily scribbled notes whilst listening to the customer can look like an extreme form of abstract modern art.
So it’s important to ensure you make the notes clear and readable. Also, don’t be shy to ask if Uncle Joe or Joe Jnr. has some documentation already explaining some of the processes; user created documentation can shed light on previously unexplored areas.
On-site vs. off-site
The dangers of cocktail napkin specs can be minimized by actually spending a lot of time on-site at the customer. Be honest, the most time wasted is time spent not really knowing what the customer wants, rather than chopping around in the code with the hope of producing something that resembles the Cookie Recipes requirements.
I find sitting on-site at least 60-70% off the time is extremely valuable. If something in you notes does not make sense, it takes 2 minutes to run down to Joe Jnr. and clear up the issue with him. With the requirement still fresh in your mind, you can get back to your workstation and produce the perfect solution. Also get Joe Jnr. to sit next to you and show him what you’ve done, if a change is required and it’s possible to do it quickly do it as Joe Jnr. explains it to you.
Once again, if sitting on-site is not possible, e-mail Joe Jnr. with an overview of how you see the problem, and then phone him. Clarifying issues can assist you in producing a well thought out solution.
If you’re not sitting on-site, try and produce a workable release every 2-4 days. This way when Joe Jnr. has a free minute he can have a look at that change you discussed earlier and get back to you with his feedback. Have a look at ClickOnce deployment, if you’re wondering about how to deploy your regular builds. Also if you do not want to release so often, make a screen cast. This way you can focus on the features/changes you created without the need to send the user the entire application. I discovered this fantastic open source solution that makes this easy.
Lose the red tape processes
I recently spent some time doing contract work for a company. To make a long story short they have a helpdesk system that tracks change and support logs. On this system they have a preferred release and release version; now looking at the data contained in the two fields, they look pretty much identical. But beware the brave man, dare you select the wrong values for these fields ;not that this would happen because only certain individuals can change them. The point I’m trying to make is that it took me 40 minutes to discern from no less than 4 people on what Release version and preferred release the log should be. I’m not saying the process is wrong, if it works, great! All I’m saying is keep it simple, keep it clear and precise.
I know processes need to be in place to protect both you and the customer. But too stringent processes could pretty soon leave you without any customers at all.
So…keep your processes lean and flexible, your customers will thank you for it. This brings me to another point, which is :
E-mails:the scourge
E-mail is a brilliant communication medium. But it still does not beat telephonic or face to face communication. In the above example, if someone had just walked to me, and explained what everything should be and how things worked, it would’ve taken 5 minutes. Instead a quagmire of misunderstood e-mails flew around for 40 minutes and eventually I placed the log on any status that the helpdesk allowed me to select and save.
When trying to explain something to Joe Jnr. via e-mail, always give him a call and discuss it as well. The customer will not feel helpless and dumb. Believe me there aren’t many things as bad as a customer that has a perception that he’s an idiot. In the word of Mr. Allan Cooper "Imagine users as very intelligent but very busy."
Frameworks, technologies and other technical jargon
Uncle Joe could not care less about what you use to write his system. Whilst on the other hand Joe Jnr. is a big fan of Microsoft and read about all the cool stuff you can do with .Net.
In my experience, most users could not give two ducks in a dry pond about what programming language, database or framework you use to develop their application. But in the interest of those readers that are a bit geeky, I’ll handle the technical considerations in Part 3.
That’s it for part 2, thank you for reading. Check back soon for part 3.
