What do we at IT people really do? Do we solve problems? or Do we build solutions?
Put it another way - 'Should we provide IT people problem statements (or) ask them to build a specific software?"
What would be ideal to provide as input into an IT project?
* Customers are unhappy with support provided (Pain point)
---
* Build me a website that will allow customers to search a Knowledge base (Constrained -- pseudo solved requirement)
So, now the question is do we state the pain point or just the requirement? What will yield a better piece of software?
Well, its getting late here at I write this blog entry -- so let me get to the point. ..
A lot of software is often built so specific requirements, which often yodel on and on by providing a lot of detail about the requiremed functionality. Sometimes we get lucky and the Quality criterion is also provided. There are models galore to go with all this stuff too. I only wish that they clearly state in simple words things like "Current customer pain points are...". Is this information really needed? Ofcouse it is -- because a clear problem statement goes a long way to help the developers check that they are building a product that will get used, i.e. it solves the core problem.
For many years, I have used a simple technique to help me before starting off software development projects. Take a requirement spec. and classify the information provided inside taht into two chunks -- "Problem space" and "Solution space". If there is nothing stated about the 'problem space', the project will most likely fail or stay in the dazed state. Why? Most likely it will not be built because it has no purpose, even if it is built, then the customer will either not accept it (or) worse still, say lovely words about the software and then ignore it.
The bottom line ... Do you want software that works? or Do you want a lot of software?
3 comments:
I'm not quite sure how your bottom line links up with the rest, but the earlier question (problem statement or psuedo-solution) definitely is an important question.
Obviously the problem statement must come first. My personal feeling is that the developer and the client must work on the psuedo-solution together, each bringing the knowledge of their own domains. A solution developed by the client may not take full advantage of what the system is capable of, while a solution developed by the developer may miss the point entirely.
All software development should be collaborative, not necessarily with other developers, but with the client. Those that aren't, I believe, are doomed to receive lovely words ;)
Computers and software are products that allow for the solving of a problem.
A solution, is only defined by its problem.
With relation to the requirements, then definently there should be correlation between what is expected and what is developed. If you can't make the requirement clear then the developers won't be able to design a solution. I would rather spend time doing a proper specification so that I know what I will code instead of just coding. On the flip side I often nut out ideas and theories through code.
My 2 cents.
If your project doesn't start from a clear problem space then no matter how good your 'proposed solution' is, you have nothing to fit it to.
It's a classic problem. Develop some wiz bang thing (because you can), but it actually doesn't solve anything. Or it doesn't arise from an actual need.
Whilst a good problem description and solution is important. I'm stearing away from huge documents these days opting for a slightly more agile approach. Sure, a good architectual design is good. Check it against your problem and see if it looks like a decent solution.
At this point I would rather prototype something quickly, rather then spending more time writing tedious documentation (which often changes). At least with prototyping, you can quickly see what does and doesn't work.
At this point both design and coding have been rather light, so you don't feel the pain associated with having to throw away code or design. I find at this point you are more readily able to adapt your prior solution to the problem space as you now better understand it.
Post a Comment