The 3rd hardest thing about programming, is debugging, the 2nd hardest is testing but the hardest thing, by a landslide, is [getting good requirements]. What makes this so hard is that [getting requirements] is commonly mistaken for [getting good requirements]. (notice how one of them is missing the word “good”). “Good” matters, a lot.
If you ask nearly anyone about how to get requirements, they will start talking immediately: “blah, blah, blah, ask questions, blah blah, get answers, blah blah blah, write it down”. It seems so easy and so obvious: just communicate effectively. It is easy to think that developers would stink at doing this because they aren’t known for having strong communication skills. So, put a non-technical person as a business analyst and wait for the magic!
However, it never seems to really work that way. That is because the correct answer to the question “how do you get good requirements” is to close your eyes for a moment, produce an expression of pain and frustration on your face, maybe change colors a little, then open your eyes and ask how long the other person has got. Because, in reality, it is very hard to put it into words that others will understand.
[Communicating well] or [communicating a lot] is not the same as [communicating effectively].
So, to start, lets define the symptoms of failure. The surest way to know if you are NOT getting good requirements is to look for one of the following side-effects of not-good requirements:
- You miss your timelines
- It is hard to determine accurate timelines
- Testers aren’t completely sure how to test the app
- Programmers aren’t really sure when it will be done
- As soon as the users see it or use it, they ask for changes
- Programmers have to rewrite parts of the program more than zero times per release cycle
- People are dissatisfied with the outcome of the project
- You are picking up your requirements in a bug tracking system
If you are experiencing any of the symptoms above, you need to put more energy into working on your process instead of your project. Once your process has been improved, the project will inherently work better. This technique is more commonly known as “Working smarter instead of working harder”.
Consider the story of the lumberjack who didn’t have time to stop and sharpen his saw because he had so many trees to cut down, but if he had stopped to sharpen his saw, the trees would be cut down easier and faster. (ref. Stephen Covey, The 7 habits of highly effective people)
The sad thing is that many upper-mgt types aren’t very receptive to the idea of working on your process instead of working on your project. Many seem to believe that [good-management] = [make people work more hours]. What they don’t seem to realize is that [the software development process] (also known as Methodology) is a science, just like optimization or security. Methodology means: “the study of a method”. It can be studied and applied and improved, but 1) you have to [want to change] 2) you have to put some concerted effort into it and 3) enforce the changes.
The good new is: most bosses are evaluated on performance. So your boss will probably be receptive to improving the overall output of your team if it 1) seems easy to do 2) requires little investment 3) is likely to produce results.