• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Customer Requirements: non-technical skills?

 
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In your opinion, what two non-technical skills should a professional developer work on in order to be most effective in understanding and implementing software requirements?

What two tools do you find most helpful in doing so? For me, my favorite is a recording/printing white board, but I'd be interested in your preference.

Thanks!
 
Author
Posts: 141
6
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tom,
the most important ones are:

* Learning how to ask (the right) questions and then ask, ask, ask & listen, listen, listen. Never.stop.asking.
* Building an interest/domain knowledge/workflow knowledge for whatever business you are supporting with your software: I.e. if you build software for..let's say...handymen..it really helps to spend a day or two with them in real life to see how they use it, what they use it for, what their problems are. YES, even as "just" the developer at the end of the chain.
* Stop fixating and drooling over the technical aspects of your work, frameworks, languages

@Tools
Whiteboards are fine, I like them too. Otherwise a plain pen & paper or notepad or wiki. Actually the best tools are your ears

 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Marco Behler wrote: . . . Otherwise a plain pen & paper . . .

I give such advice often enough. I usually say pencil then you can use an eraser to destroy the evidence
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marco Behler
Author
Posts: 141
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yep, it is all about understanding.

(I just focus on asking so much, because while it can get annoying, from my experience there are way too many assumptions being made than questions being asked.)
 
reply
    Bookmark Topic Watch Topic
  • New Topic