

On gathering requirements - KiwiCoder
https://medium.com/@KiwiCoder/on-requirements-gathering-d270d078bbac

======
onion2k
Interesting article, and something close to my heart.

My startup, UsableHQ, went through the Ignite100 accelerator, got funded, and
then failed because no one wanted to buy our product, was all about
requirements management. We built an app that helped you gather the
requirements (clever Apache Tika integration for pulling things out of
tendering docs in different formats), manage the process of keeping track of
how the requirements change though the project (lovely Node and Backbone
single page app), and then export the final requirements document at the end
to pass on to acceptance and testing QA teams. We spent about 2 full years
thinking about how best to stop requirements getting out of hand, putting a
stop to scope creep and gold plating, and making project less prone to
failure.

Unfortunately we forgot to prove that there was actually a market. At the top
end when you're designing an aeroplane there are huge enterprise apps for
doing this stuff. At the bottom end a decent project manager can keep it all
in their head. In the middle, there's a few project management apps that make
a nod to requirements, but not much, so we thought we could sell to that
segment. We were wrong.

The problem is that the cost of failing to manage change in a project isn't
actually very big. The project might be a few weeks late, or $5000 over
budget, or it fails to do something that was in the list of requirements, but
that's not really a big deal to either the client or the team implementing it.
No one's job is on the line. There aren't any penalties. It's just 'oh, we
should fix that I guess'.

Gathering requirements, and keeping on top of what changes, is never as
important as the project as a whole, and it turns out that a lot of projects
just aren't very important to the people doing them.

~~~
KiwiCoder
I don't think your experience is at odds with what I'm saying. There are
practical, real-life issues that will always trump the mechanics of product
development.

~~~
onion2k
I wasn't disagreeing with you. Quite the opposite. Doing a good job of
gathering requirements can be the difference between success and failure. I
think my experience shows that there's a lot of education necessary before the
software industry as a whole realises how much time and money a project can
save with requirements. That will happen though, in time. Usable was about 5
years too early.

