Lists Home |
Date Index |
On Fri, 2004-02-20 at 15:18, Bullard, Claude L (Len) wrote:
> We are RFP-driven, and this is reasonably analogous to
> use-case driving. Because our resources are always
> limited, we do not add modules (think level of QBE-forms)
> to the system until we have seen them clearly required
> in some number of RFPs and so can establish that the
> customer base at large wants this functionality. Then
> we have to decide if it is strategic for our system
> to have this or if it is better to open an API for
> systems of that class so they can buy best-of-breed.
I worked in a project that used a similar approach a couple of years
ago. I was surprised by how very well it worked. I remember the decision
process very fondly, because although there were a large number of
people involved, from different countries, and there were an enourmous
number of feature requests, the work went very smoothly.
The project got into trouble later on, but that was mostly because one
very good project manager was replaced by two bad ones. The process
itself was great to work with.
> Once the decision is made to build, then we take
> the sets of requirements of the active customers
> and attempt to generalize these into a single design
> that can meet their requirements. This is where
> the use cases are both helpful and dangerous. A
> customer will have a fixed idea for what they
> want to see, and they will vary by customer. The
> challenge is to provide functionality that they
> instantly recognize as applicable to their problem
> and yet which applies to all of their problems.
> That is the art of systems design and it isn't
> easy and it takes a practiced team to do it well.
In the project I mentioned above, we had some very good people, and in
the early phases everything just clicked. It was a very useful learning
experience for me.
> No methodology or framework, IMO, are a sufficient
> substitute for practice.
I agree. It is very common to try to use process to mitigate the need
for competence, and the results are usually bad.
I tend to go a bit overboard with emphasizing (lightweight) process,
simply because I am interested in methodologies. Fortunately my friends
and colleagues keep me in check if I try to push it too far. On the
whole, I think we balance things out fairly well. :-)