Don’t write a functional specifications document. Why? Well, ther’s nothing functional about a functional specifications document.
Never thought of it that way, but hey, they may have a point..
Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.
Oh, do I know the drill! Let’s get everyone to sign-off so we’re all co-owners and equally ‘hosed’ if the project fails!
Here’s where it gets interesting:
Functional specifications document are “yes documents.” They’re political. They’re all about getting to “yes” and we think the goal up front should be getting to “no.” Functional specs lead to scope creep from the very start. There’s very little cost in saying “yeah, ok, let’s add that” to a Word document.
Point conceded about the potential for scope creep…
Functional specs are often appeasement documents. They’re about making people feel involved. But, there’s very little reality attached to anything you do when the builders aren’t building, the designers aren’t designing, and the people aren’t using. We think reality builds better products than appeasement.
Functional specs are about making decisions before you have enough information to decide. They are about predicting the future and we all know how accurate that is.
Ok, ok… so if no functional spec, then what?
So what do we do in place of a functional spec? We write a one page story about what the app should do. If it takes more than a page to explain it, then it’s too complex. If it’s simple and it takes more than a page to write it then we’re not writing clearly enough. This process should take no longer than a few days.
Then we begin building the interface — the interface is the functional spec. First with some quick and simple paper sketches, then directly into HTML. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground.
Bottom line: We want to build something we can all start looking at, using, clicking through, and “feeling” before a line of back-end code is written. We want to be in front of the customer experience for as close to 100% of the time as possible.
I like what they’re saying. It’s definitely thinking “outside the box”. I’m just trying view it from a practical perspective. 37signals appears to specialize in Web applications. How would the sketches go over in my current professional environment?
I can certainly see where this approach could work in a shop where there aren’t a lot of external dependencies and vendor involvement, but it seems like for a larger project with many organizations and stakeholders and a dozen intermingled technologies, you just have to have the formal spec and sign-off.
Anyway.. I’m not endorsing the “no functional specs” approach, but I do like the novel approach, and I won’t knock it until I’ve had a chance to try it… and it is an interesting concept.
Just think. If you could get a software shop to fully buy-in to the story/sketch approach, think of the weeks – months – that could be trimmed off a project schedule!
