There is something called "A Problem Statement". No this is not a 20 page business requirement document. Its a single (at most two) line statement that describes what a customer is trying to solve. Believe me the ones who can not give it, don't know what they are doing. With repetitive refinements these are some typical problems you get:
- To speed up our company's web-site's responses.
- To stop our application getting bogged down under heavy load.
- To exercise stocks under xx Milli-seconds.
- To bring the application back up with x% of data loss with in 't' minutes.
Why a Problem Statement is important?
Nah.. I am not a qualified MBA but I will tell you a story. A business analyst comes to Engineering and asks for a Cassette player for a Car so that the customer can play his songs. Engineering builds it and the player gets integrated in the car. Analyst is happy. Customer is happy and the Analyst moves on (gets a promotion). But was he/she right? No. Because the Customer never asked him to get him a Cassette player. What he really meant was "I need a way to play my favorite music while I drive". So what happens? Cassette players gets outdated and we build CD players. In a few years we build MP3 players and so on. And if not cautious you could end up driving a car with a Cassette player, a CD player and a MP3 player. Believe me its a bad car.
So whats wrong?
The baggage is wrong. Engineering ends up supporting features that has no revenue potential. The better solution is you gave the Customer a Cassette Player in '80s because that was what technologically possible then. In '90s your car only offers a CD player and so on. And in turn you assist a parallel industry or professional services who provide you gadgets to convert your Cassettes to MP3s. The continuous refactoring of your product is as important as providing solutions to the problems. So never lose the Problem Statement. Its not the cassette but the music what Customers are really paying for.
No comments:
Post a Comment