“Ravi Olee”.
“You want ‘ravioli’?”
“Ah kay.”
My toddler wanted ravioli, but didn’t exactly say it. I knew what she meant. I fix it, and she eats 80% of it.
Client says, “I want a video player like Viddler has. The comment feature is a way to ask questions.”
I assume the client means they want this to create a link to comments below, and the comments are threaded discussions like Stack Overflow. I explain this, and my client gives me the same look of “Ah kay” my 2 year old does (it’s over the phone, but I can read tones). I create it, and they like 20% of it.
My 2 year old does this too. Sometimes she’ll eat like 1 piece of ravioli, and ask for rice pilaf instead. I just wasted a lot of food, but dutifully fix her rice instead, 90% sure this’ll please her since she almost always eats rice or ravioli. Â This is worse at dinner, however, when I have 3 other mouths to feed, invest more work, and more resources. Â It can be quite costly if she doesn’t like it, and build up much frustration, sadness, and resentment. Â Same with larger software projects.
I’ve done enough video players to know what clients will dig, and dislike. I know if something doesn’t work, something else probably will. While my 2 year old ends up wasting food when I’m wrong, at least the client pays me for my, and their, time in figuring out what they really want.
What they both have in common is “seeing”. When my 2 year old “see’s” the food, I get a crystal clear understanding within 60 seconds of knowing whether she’ll eat it or not. Â There are no assumptions, just black and white answers. Â Sometimes I think she just likes me acknowledging her, so while she asked for ravioli, she meant rice. Since we appeared to be on the same page, I was surprised when she didn’t want what I gave her. Clients are the same way; when we appear to be on the same page, we’re both disappointed when I give them something they didn’t want.
This is the exact reason why I dislike “requirements” and “specs” for software. Time and time again they fail to deliver what the client really likes, work towards preventing what the client really wants, and puts a burden on someone to keep it up to date. The only thing they help is to solidify a contractual agreement between 2 parties to ensure 1 gets paid.
This is also why I’m a big fan of Iterative development; getting the client a working build of the software quickly to confirm whether you’re on the same page or not. I’ve taken it upon myself to show my 2 year old the ravioli can and the rice bag, and let her choose and be involved in the preparation more. Her majesty says that encourages them to want to eat it and helps the 2 year old independence thing. Â Showing a client a spec and getting them to sign off on it does very little to ensure the software I deliver is what they want. Â Showing them working, in progress software, does.
Even if my contract clients don’t actively do an iterative development style, I do it anyway. This ensures we’re on the same page and condenses all surprises down to weekly vs. a bunch of big ones after 2 months.
For my 2 year old, this significantly reduces wasting of food, ensures she & I are happy, and ensures she has more food later. Â This vs. me resorting to something weird she might not eat when we’re out of ravioli and rice. For software, this saves my client many hours of wasted work on my part, and makes the most of their money they are investing in me. Â Also, it ensures they get the best ROI with faster confirmation it was in fact a good investment or not.
Planes that travel from LA to Hawaii are constantly off course, but routinely correct to ensure they are on course. My 2 year old is constantly learning on how to communicate with me, and me with her. Iterative development constantly ensures what I’m building is what the client wants, and when my contract is up, they have working software. Over time, this results in better communication between my client and I. Like marriage/dating for a long period of time, you start to learn what your partner “meant” vs. what they “said”.
You can get away with Waterfall approaches in the ad agency world because the development cycles are so short. You can get away with Waterfall in consulting with large Enterprises by just “surfing the problem wave”, and just waiting for the money funnel to stop without worry of reprise. This doesn’t work in the Enterprise world where people pay attention, nor with startups.
This year, I endeavor to empower others to more easily get into Iterative development with their clients through software to help them.
Jesse,
I agree and disagree. I am a big fan of prototyping, but requirements/specs are critical especially if the application is large/complex. Ideally if you are able to prototype while gathering requirements this leads to a product that has a much greater chance of succeeding.
to use your kid and food analogy (and I am so with you there, nothing like fixing multiple meals at dinner), showing the choices is the prototype, but then the wife wants the kid to eat carrots (requirement) so then you adjust prototype and suggest carrots mixed with rice pilaf or on the side (raw /cooked – please the stakeholder ;) ). Now potentially you are satisfying both stakeholders and getting closer to “I like how daddy fixes it”.
In my brevity, I didn’t get to clarify. I believe you have to have specs. What I disagree with is the attitude/perception that you need to “build to spec”. No you don’t, you need to build to spec, and if the client doesn’t like what you built, screw the spec since it clearly has failed in it’s duty to effectively communicate what you’re supposed to be building.
High level things like “Flash Player 10” or “encrypted video”, etc. HAVE to be documented somewhere, and legally agreed upon. Using that same document to guide your development vs. a flexible backlog, however, no way; screw the spec.
I don’t get the opportunity to prototype. I think in my entire career, I’ve done it twice.
I agree with your adjusted food analogy. However, whether Agile or Waterfall, most of those “prototypes” are wireframe and design comps tweaked for the client. I’ve seen agencies sometimes use fake Flash sites to prove a point (I’ve created one myself once), so I can see the value there when you have some dense clients, and sales needs a better communication tool.
Come on give the kid a break, I mean the client.
To me a ‘spec’ and a ‘prototype’ are one in the same. In the majority of situations it’s possible to at least create a semi-functional prototype using the Flex Framework faster than writing out a spec – I’m talking about a UI/UX spec.
Want to prototype a video player with comments and voting? That’s what, a few hours work at most? Then the client gets something they can experiment with. If you want to spend a few more hours work then you can add controls to the prototype to let the client edit it. Simple things like resizing controls, changing colors, etc don’t take much time to build in. I’ve seen clients get a real kick out of stuff like that.
Later on you can even drop that stuff into an admin panel that the client can use to change the design after it’s live. They want to give it a Christmas theme? No prob.
What would be fantastic is if Catalyst is easy enough to use then clients might be able to create their own simple prototypes. I know it’s a long shot but we can hope, can’t we?
I’m not sure I agree that prototyping can trump spec documents. In my experience if I show the client a prototype they will complain about all the missing features. Then after I have fixed them all and polished the aesthetics, only then will they say “oh by the way, this isn’t what we wanted at all.” It’s as if they are only willing to evaluate a finished product. I think they lack the foresight to see where the product is heading. Because of this, I think giving a detailed spec actually does more to illuminate that you are on the wrong path. The reason I think is that my specs usually have price tags attached to each line. This forces them to consider if something is needed, unneeded, or just plain wrong.
Very insightful and a joy to read!
Specs are important to give the general direction in which to produce for the developer. The client, though, doesn’t necessarily knows what he/she want before he/she sees it.
Both by working iterative, agile and with fast mock-ups it becomes a good basis on which the client and developer can discuss and plan what to do with the rest of the … ravioli- software
Okay just to clarify she does eat more then rice and ravilio! Cheese, grapes, bread, carrots, strawberries, soy beans etc!!!