Years ago, I was 1 of 2 task leads in the team. Both of us were responsible for understanding the requirements that the BAs gave us, and getting enough information out of it so we can have the developers develop code. There was a significant differrence between our individual styles of working.
His style of working was very methodical. He would go over the whole document, and prepare a big list of questions to ask the BA. The BA will make their best attempt at answering their questions. Unfortunately, some of the answers didn't make sense when taken into context of all the requirements. He would read everything again, come up with new questions. He would go back and forth couple of times till he had enough clarification. Of course, what would happen is that during implementation some things will come up and then he had to start the whole process of going back and forth with the BAs. Very methodical.
My method was quite differrent. I would "speed-read" the document. Then I would say "Screw the document". I would go to the BA, and then ask them tell me what you really want. During this process, I would throw in some suggestions. What if we did things this way? What if we change the page flows this way? What if we moved the drop down here? The goals was to understand what the BA (and by proxy, customer) needs. My goal was to get into their head. The BA would go back and rework the document based on the conversation that we had. I didn't care about the document at that point. I'll just start working on implementing the requirements. I had no need for the document.
The BAs loved me. Why? Because I was collaborative. I worked with them. I was helping them come up with ideas that they got credit for. Everyone wants free ideas. I'm all for giving away ideas if it makes my job easier. The other guy was trying to be very organized, but the end result was that the BAs thought he was critiquing their work. No one wants to see a list of bullet points that detail how bad a job they have done. Also, I could make minor course corrections on the fly. Remember, I was in their head. So, during implementation, if a question came up, I would come up with a solution that I knew the BA would agree with. I would get the developer working on it, and in the meantime, I checked with the BA to make sure they were ok with my solution. 80% of the time they were. The other guy would get stuck 100% of the time. I would be wrong 20% of the time. It so happens that in an agile environment, it's better to be wrong some of the time than stuck all of the time.
Yes, I had one BA who would sneak in requirements into the document without talking to me. QA would find it, and open a bug. I would be like "That's not a requirement".They would point to the document. Look Look.. requirement.. documented requirement. I would put my head down.. say my fault...I'll fix it. 6 months later, they moved him away. I stayed in the project. Why? Because I had a proven track record of working with the other BAs who all loved me.
* Learning how to ask (the right) questions and then ask, ask, ask & listen, listen, listen. Never.stop.asking.
I would say that the goal behind asking and listening should be to build mutual understanding. Never.stop.understanding. Too much asking can get.. umm.. annoying.
1
