For the most part it's a reflection on communication and how personal perceptions lead to differing end results. However, when I look at it, the most striking point, and the one that I feel is most overlooked, is that the customer's description and what they needed (first and last panels) are subtly, but distinctly different. This I feel is the problem with lots of software design - the customer does have a concept, a feeling, for what the software should do, but finding a customer who can vocalize this into specific functionality rarely, if ever, happens. Turning to the customer to provide feature lists or functionality is an easier way out than stepping back and making a decision about the business problem that is being solved. What does the customer really need? What do the potential customers I have yet to sell to really need? How can I quickly, economically build that, and not get sidetracked into other features that are affiliated but take away from my concentration on the main business problem?
Because of the difficulty the client/customer has visualizing and vocalizing what they want, and because of my own difficulty vocalizing what I'm going to do, I prefer to (a) work on a time and materials basis, and (b) work on a project in short chunks. I deliver a demo or prototype whenever possible, so the client can see where I'm going.
ReplyDeleteWorking in short bursts may seem inefficient, but it suits my cognitive style.
Build a little, test/ demo a little - learn a lot.
ReplyDeleteAgree with both comments, small iterations work better then anything else. I think you also have to spend lots of time just thinking - if you know the vertical space, there's a great chance you'll produce great software.
ReplyDeleteTypically, when I get a call asking for something I pause and ask "why?" which is typically followed by another pause on the caller's part, then we have the start of a discussion!
ReplyDeletemp/m