Article Preview
Buy Now
COLUMN
Telling the Story of An Application
Getting your client to communicate with you
Issue: 10.1 (November/December 2011)
Author Bio: Bob is the owner of BKeeney Software that provides Real Studio and iOS consulting for clients all over the world. In addition to providing consulting, BKeeney Software provides REAL Studio training videos (currently over 30 hours worth) and sells software to consumers and developers alike. He is a founder and former President of the Association of REALbasic Professionals.
Article Description: No description available.
Article Length (in bytes): 5,995
Starting Page Number: 77
Article Number: 10010
Related Link(s): None
Excerpt of article text...
People often accuse developers of being nerdy and not having good communication skills. While that might be true in many instances, it has been my experience that many people looking to hire a developer are worse. It's not that they can't communicate it's just that they don't know how to tell the story of their application and it's up to you to help write it for them.
Let's face it, most people looking for a developer are not very technical themselves. If they were, they would probably be attempting to code their project themselves. So they start with several strikes against them. They don't know the lingo that we use. They may not be very computer literate in general, but they've got this great idea. You ask them to write a story about their application with as many details as possible and send it to you.
And you get two paragraphs.
I can hear some of you laughing because you know this happens all too often. Their two paragraphs could describe any application in the world or it's a work of fiction. They're thinking accounting application and their story sounds like a third-person shooter game. Okay, that might be a bit of an exaggeration, but it's certainly not uncommon to have a huge disconnect between what they say and what they give to you in writing.
In cases like that I usually try to have a high level overview conversation with the client. Start with what the application does, in broad terms. If the client starts to get into details, stop them and guide them back to the "big picture." The details don't matter yet.
Who is the intended user? Is it someone in their organization that they're training themselves? Is it an anonymous internet user? Perhaps it's someone that will be intimate with the jargon and data used in the application. These answers tell you what the followup questions will be. Do they have a help manual? Do they have a support email or forums? Believe it, or not, some potential clients might expect you to provide support to their clients so it's best to discover that early (and say no).
...End of Excerpt. Please purchase the magazine to read the full article.