People think that programmers sit in a 4 x 4 cube and write code all day. Yet this is clearly not the case. We are assigned projects, interact with customers, gather specs, WRITE CODE, have meetings, test the code and deploy to production.
Yet when getting a new project, one should really look at it from three angles: Technology, Business and Value. If you become an expert in all three areas, you will become valuable asset to the org.
Here's some questions on a fictitious project to show an example.
Let's say you are on a conference call with a person from another department. You were told that they own a set of data. You would like to interrogate them to see if that data could be of value. Your existing project is to gather as much data as possible, mash it together, to create a complete customer profile from start to finish.
What server is it stored on?
What type of web server?
What is the IP Address?
Is it a relational database or log files.
What protocol is used to transmit data files?
What language are the websites?
How often are the backups available?
How can we obtain your production data?
What are the business rules for the company?
What are the products we sell?
Who sells our products?
Who creates the products?
Who do they report to?
What is the pricing matrix?
Who heads that department?
What information are you capturing?
How can we use the data?
What does the data contain?
How can we mash the data?
What insights can be captured?
Can we get the big picture from small details?
I see lots of project meetings where people spend 25% introductions, 50% re-defining the project when everyone already knows the scope, then racing through the difficult details in 25% of the time. A real time waster.
By separating the spec gathering into three distinct buckets, you can really get to the guts of the problem faster. When speaking with a business knowledge expert, the trick is to get them to open up and explain how things work from the Technology perspective, from the Business perspective and from the Value perspective.
So instead of weaving and wandering through the conversation, you can approach the project systematically with intent.
Get to the point. Get the information. And get busy.