37Signals Goes Against Conventional Wisdom in App Design

[alukindo]

Hello LAVA:

The following article has some interesting insights as to why functional spec may not necessarily be critical in designing good applications. 37 Signals are the makers of Basecamp, a simple web based collaboration software that works on the principle that project management is about 'team member communication' rather 'gantt-charting' project execution.

Another article on meetings cautions on why these may sometime be ineffective.

It is quite interesting to see how others feel about these articles.

Anthony L.

[jcarmody]

Hi Anthony,

First of all QUOTE

They often contain at least one moron that inevitably gets his turn to waste everyone's time with nonsense

We fired him in September.

Seriously, though. My experience with functional specs tends to make me agree with the first article, but specifically with this point: QUOTE

Functional specs only lead to an illusion of agreement

My situation has me building test equipment that must meet a customer-approved ATP, which is written in stone and the basis for a functional spec. The trouble begins when we start to get requests from our internal customer (the Design Engineering group) for features beyond the ATP requirements.

I've seen success with a "Statement of work" - "Statement of understanding" process where the customer writes what they want (the SOW), we read it and respond with our understanding of what they wrote (the SOU). They read our SOU and modify their SOW and we go 'round and 'round until we're sure that we have an understanding (as sure as we can be, anyway).

I can't see how to build test equipment without a good document at the beginning, whether it's called a 'functional spec' or 'requirements document'. I began a thread here looking for help (got some good pointers, too). I'd need to learn to manage the process at the beginning of the project so I can satisfy all my customers (ATE delivered on-time, within budget and slick).

Thanks for the link.

Jim