Semi-OT: Programming Question

[Jack]

--- Jared <jared at hatwhite.com> wrote:
>  >> >Beware the client who always changes the
>  >> requirements... :)
>  >>
>  >> Think there is a method of discovering such
> clients
>  >> ahead of time?  My
>  >> experience so far has been that people with
> vague
>  >> ideas of what they
>  >> want are the worse.  They don't know what they
> want,
>  >> so you try to build
>  >> what they describe
> 
>  >This is the totally wrong approach. It is the
>  >deisgner's job to extract from a client a clear
>  >picture of what it is they want. This means
> getting
>  >input from the people who will use the product. It
>  >maens asking questions, restating the answers, and
>  >developing a data map and interface requirements.
> 
> Exactly. Become the expert, and then implement what
> the
> customer wants (but cannot define clearly).
> Thereafter,
> scope creep is not the customer's fault, it is part
> of
> what you manage as the expert.
> 
> I know this all in principle; practice is a lot
> harder,
> because, essentially, it requires a geek to have the
> social skills to tell a customer what they
> want--with
> enough precision to keep them happy... which I am
> only
> just learning how to do.
> 
Yes, this requires some people skills, but there are
tools and methods to extract the information from
clients. Tools and methods that every geek should
learn and use. There is even software that can be
bought that virtually develops the skeleton of the
program. However, I don't recommend buying these very
expensive tools. What it comes down to is focusing the
clients on the data. Here's a quick primer for those
interested
(if I'm way OT and anyone wants me to shut up just say
so.).
First, get the clients together (obviously) and ask
them questions about the objects they use in thier
business. Let's say they rent equipment and they have
asked you to rewrite their tracking and billing
systems. So, the first question might be "What defines
a piece of equipment?" or "What do we need to know
about a piece of equipment to track it (bill it)?".
This will porobalby elicit all the things they
currently capture to track or bill. To which you need
to respond, "Ok, this is good, but what do you need to
know about equipment that your current system doesn't
capture?". Now while all this question/answer is going
on, you as the expert are of course using a Big
Post-it board of paper to write down on the top the
name of the object and underneath all the properties
of the object.
You repeat this for every object that need to be
captured. You should have a basic understanding of the
clients business so that you can inject a few objects
to get them thinking. After you get all the properties
of an object you can then ask them what arfe the key
fields of the object, and also any fields which they
"need" to do frequent look up on. Remembering that you
have to constantly remind the client that we are
looking for what they need or want and not what it is
they currently do. It's those things they want to do
that they currently can't that lead to ever expanding
requirements (scope creep). When you have explored all
the objects you will wind up with your database
structure, and the client has done most of the work
for you. If you have the man power you could have a
second person at the meeting "taking notes" on a
laptop. The notes of course being table definitions or
UML. With this data one could then design screens for
data entry and querying. However, we still need to ask
more questions. Such as "what kinds of questions do
they need to ask of the data", "what do they need to
do to fix mistakes in the system","what kinds of
reports do they need","what information needs to be on
bills","what information do they need to see when
asking certain questions","what kind of what if
questions do they want to be able to do",etc.
With these questions answered you should be able to
build interfaces and report queries. Now of course,
some of these wants will be easier to do than others,
based on what inforamtion is stored in the objects.
This is where you need to put prices on all the
questions they need to be able to answer about the
data. the important thing to remember is to try to use
the client's knowledge to extract the questions and
data. You will most likely not know enough about their
business to ask all the right questions. Getting them
to ask the questions is the key. Now this won't
elminate scope creep, but if you get them thinking
about this, you'll find that you'll get most of what
you need and over the next week they will undoubtedly
think of more things as they do their day to day jobs.
This way you should be able to contain 99.9% of scope
creep to within the first week or two of the project,
plus the clients have automatic "buy-in" on the
project because they helped design it.
Well this is probably long enough, sorry if this is
all old-hat for everyone. Hope this help a few.

Brian D.


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/