Normal division of labour between a programmer and business analyst?
March 20, 2014 5:33 PM Subscribe
My organization avoids drawing a line between the responsibilities of the system analyst and those of the business analyst in completing a change request. Can you tell me what's typical?
A BA I often work with complains to my manager about me over the course of nearly every piece of work we do together. This is my first job in the industry so I might be out to lunch here, but I have been working with the impression that when I have business-process questions (as opposed to technical), I go to the BA with them. She thinks I should either know the answers, or go to other SAs. My organization won't say either way. My boss backs her every time and I do not see where he or the BA are coming from. I feel like I am being shafted. We have a huge insurance application that deals with all aspects of insurance enrollment, benefit plans, claim payment, etc. , and there are many parts of the application we have no idea how to use. We don't receive user training in the application or 'here's how our insurance business works' training. We don't have access to the documentation that our customer services folks and BAs have access to.
Examples: What is business concept X?
Can you please set up this test scenario in the system?
How do I use this part of the application?
What is the expected outcome when ......
Experienced SAs have the answers to these questions, but if I take advantage of their generosity, I will lose their goodwill and become a complete pariah.
So, is my organization weird, or is it normal to expected the programmer to be handed the requirements, do the work, and not need the BA for anything? What is the typical division of labour?
Sorry, this is not explained with the greatest clarity and detail. I'm stressed and my boss decided to book my performance review tomorrow. I am afraid that I'm going to lose it on him and quit. I'll be happy to provide any details requested.
A BA I often work with complains to my manager about me over the course of nearly every piece of work we do together. This is my first job in the industry so I might be out to lunch here, but I have been working with the impression that when I have business-process questions (as opposed to technical), I go to the BA with them. She thinks I should either know the answers, or go to other SAs. My organization won't say either way. My boss backs her every time and I do not see where he or the BA are coming from. I feel like I am being shafted. We have a huge insurance application that deals with all aspects of insurance enrollment, benefit plans, claim payment, etc. , and there are many parts of the application we have no idea how to use. We don't receive user training in the application or 'here's how our insurance business works' training. We don't have access to the documentation that our customer services folks and BAs have access to.
Examples: What is business concept X?
Can you please set up this test scenario in the system?
How do I use this part of the application?
What is the expected outcome when ......
Experienced SAs have the answers to these questions, but if I take advantage of their generosity, I will lose their goodwill and become a complete pariah.
So, is my organization weird, or is it normal to expected the programmer to be handed the requirements, do the work, and not need the BA for anything? What is the typical division of labour?
Sorry, this is not explained with the greatest clarity and detail. I'm stressed and my boss decided to book my performance review tomorrow. I am afraid that I'm going to lose it on him and quit. I'll be happy to provide any details requested.
For that matter -- what have the other SAs said when you ask them this as an "in general" question? They'll be the most likely to give a good read on what how your organization manages it, and whether your BA is acting normally in the confines of your organization or not.
posted by brainmouse at 5:51 PM on March 20, 2014
posted by brainmouse at 5:51 PM on March 20, 2014
Response by poster: I've had other SAs say "your BA should be able to tell you that/do that" and others say "Well, you could ask this SA". I can't get a clear answer from them either. I guess I am trying to determine if my department is a bit strange and dysfunctional about this. If so, I begin to work on leaving. If not, I work on staying. I need some outside views because people on the inside are reluctant to talk and I don't have experience with other organizations to measure mine against.
posted by kitcat at 6:03 PM on March 20, 2014
posted by kitcat at 6:03 PM on March 20, 2014
To brainmouse's point, it really matters how YOUR organization works but based on my experience working in two Fortune 100 companies as a PM, my observation would be that you are probably directing some questions to your BA that should be directed elsewhere.
In my experience, the BA would draft the requirements, and yes, hand them to the programmer. The programmer might ask some clarifying questions, but because the developer has to sign off on the functional requirements in my org (and therefore has in theory participated in a walk through of said requirements), you would expect that most of those questions have been answered prior to the hand off. Are you not a part of a walk through? We literally walk through LINE BY LINE of the functionals and folks ask questions/provide clarifications as we go.
"Business context" might be a bit broad. Maybe go with can you help me understand the business need for requirement 2.1.2?
As for setting up a test scenario in the system, do you mean loading data or setting up an account so that a requirement can be tested? I would expect the development/Db teams to work to copy data from prod or where ever else so the appropriate data is available for test. Testers identify what data they need to test and developers get it there in cases I typically see.. Or do you mean creating test scripts/cases? I would expect my testers to set theirs up in whatever tool is used in your org. They might run test cases by the BA to make sure that there isn't an oversight, but the BA doesn't have accountability for that in my experience. My developers would be responsible for their test cases for unit/integration testing. Again, BA might be a spot check point but not really involved.
If you aren't familiar with how to use a part of an application, ask someone for a demo. I have had BAs demo an app but on the technical side, you may be better served by asking another SA.
In general, what I have seen is BA does requirements, developers participate in walk through and sign off (NOTE: your sign off is your agreement that the requirements as documented are in sufficient shape to allow you to do your work. If not, make them clarify. Yes, questions will come up during coding but hopefully there is a clear, common understanding BEFORE you move into design/dev), BA isn't particularly engaged as much during dev, and then they re-engage during testing to help review defects logged to determine if it's a legit defect or if the requirement needs updating.
Not saying that my experience is necessarily right (believe me, there is always a certain level of dysfunction in organizations), but this is what I have observed.
posted by polkadot at 6:16 PM on March 20, 2014
In my experience, the BA would draft the requirements, and yes, hand them to the programmer. The programmer might ask some clarifying questions, but because the developer has to sign off on the functional requirements in my org (and therefore has in theory participated in a walk through of said requirements), you would expect that most of those questions have been answered prior to the hand off. Are you not a part of a walk through? We literally walk through LINE BY LINE of the functionals and folks ask questions/provide clarifications as we go.
"Business context" might be a bit broad. Maybe go with can you help me understand the business need for requirement 2.1.2?
As for setting up a test scenario in the system, do you mean loading data or setting up an account so that a requirement can be tested? I would expect the development/Db teams to work to copy data from prod or where ever else so the appropriate data is available for test. Testers identify what data they need to test and developers get it there in cases I typically see.. Or do you mean creating test scripts/cases? I would expect my testers to set theirs up in whatever tool is used in your org. They might run test cases by the BA to make sure that there isn't an oversight, but the BA doesn't have accountability for that in my experience. My developers would be responsible for their test cases for unit/integration testing. Again, BA might be a spot check point but not really involved.
If you aren't familiar with how to use a part of an application, ask someone for a demo. I have had BAs demo an app but on the technical side, you may be better served by asking another SA.
In general, what I have seen is BA does requirements, developers participate in walk through and sign off (NOTE: your sign off is your agreement that the requirements as documented are in sufficient shape to allow you to do your work. If not, make them clarify. Yes, questions will come up during coding but hopefully there is a clear, common understanding BEFORE you move into design/dev), BA isn't particularly engaged as much during dev, and then they re-engage during testing to help review defects logged to determine if it's a legit defect or if the requirement needs updating.
Not saying that my experience is necessarily right (believe me, there is always a certain level of dysfunction in organizations), but this is what I have observed.
posted by polkadot at 6:16 PM on March 20, 2014
Response by poster: Thanks polkadot. These are the kind of details I'm hoping to hear. I don't know what a walk through is, so no, we don't do that. We just get handed the requirements. The BA = the UAT tester in our organization. Setting up a test scenario might mean "create a new member in our system, set them up in plan x, and put some claims through for product y" - stuff that would be ridiculous to try to do with a script and that I definitely don't know how to do properly via the GIU interface. More 'this is how we do it at my organization' would be greatly appreciated.
posted by kitcat at 6:29 PM on March 20, 2014
posted by kitcat at 6:29 PM on March 20, 2014
Who is your QA tester? Is your BA just doing UA testing or the system/functional/component testing (or whatever else they call it in your organization)? I have found a good QA tester is a great resource for how things work from a system perspective. After all, you are coding on the FRs and they are testing off of them.
But the lack of walkthroughs is abnormal to me.
posted by polkadot at 7:23 PM on March 20, 2014
But the lack of walkthroughs is abnormal to me.
posted by polkadot at 7:23 PM on March 20, 2014
Response by poster: There are separate QA testers. We do not interact with them. If I tried to ask them questions, I would have my hand slapped for sure. The BA/QA tester makes sure the requirements are fulfilled. The QA tester makes sure no existing functionality has been altered.
posted by kitcat at 7:35 PM on March 20, 2014
posted by kitcat at 7:35 PM on March 20, 2014
Response by poster: To clarify, I'm talking about maintaining a system here, not doing new development. And with that, I'll stop threadstitting.
posted by kitcat at 7:38 PM on March 20, 2014
posted by kitcat at 7:38 PM on March 20, 2014
Well, I'm usually of the opinion that since the company/department's whole purpose is to produce or maintain software, the people actually doing the development work are doing their jobs properly by requesting documentation and assistance in defining the work so they can get to business. But in practice this is always a point of contention between the programmery people in the organization and the businessy people. Politics are usual.
Really, what we're talking about is the "requirements gathering" phase of the SDLC. So are you saying you don't have enough information to do the development work? That means the "requirements gathering" phase isn't being done properly.
At the big tech company I worked at, developers could say, in so many words, "No, I'm not working on this yet because you didn't provide me with document X that we need to make sure we're doing it right." And you could invoke the wrath of your manager if someone was giving you grief about doing something without knowing the requirements ahead of time.
Sounds like maybe in your org programmery people don't have quite enough power to say that. So it goes.
posted by deathpanels at 8:26 PM on March 20, 2014
Really, what we're talking about is the "requirements gathering" phase of the SDLC. So are you saying you don't have enough information to do the development work? That means the "requirements gathering" phase isn't being done properly.
At the big tech company I worked at, developers could say, in so many words, "No, I'm not working on this yet because you didn't provide me with document X that we need to make sure we're doing it right." And you could invoke the wrath of your manager if someone was giving you grief about doing something without knowing the requirements ahead of time.
Sounds like maybe in your org programmery people don't have quite enough power to say that. So it goes.
posted by deathpanels at 8:26 PM on March 20, 2014
It sounds like you're newish to the team, and you're struggling to get enough institutional knowledge to effectively do your work. Which means that it's great news that you have a performance review coming up. Rather than going into it feeling defensive, angry, and accusing, go in and ask your manager "how should I handle this situation? Can you suggest how I should get enough background information to do X? Can you explain the process for getting test data into the system?"
Part of it is likely a methodology issue. Whether or not it's "dysfunctional" I really, really dislike waterfall development models, where it's more likely that the requirements team throws a set of requirements "over the wall" to programmers, who then build a system and pass it on to QA. I worked for one company as they switched from waterfall to agile, and though the process wasn't seamless, our time estimates improved by about a factor of three (stop for a second and think about that: we were taking three times longer than we promised to build something), and we stopped having the kind of death marches that caused huge developer turnover. The best part of it was that instead of business analysts and requirements managers throwing a set of not-very-feasible requirements at us, we had a product manager and QA person who came to daily stand-up meetings. The PM was deeply involved in the business analysis. So it was really easy to get clarification, work out alternate requirements when we discovered something wouldn't work, or go through test cases. It's a very rare waterfall requirements set that actually foresees all potential pitfalls enough to specify how to manage them.
But you're doing maintenance instead of new dev? Does that mean bug fixing or maintenance minor feature development? If it were me, I'd ask for a full set of QA test plans as well as high quality bug tickets. Because, yeah, QA test plans are often even better than requirements at helping you understand how something should work, what the edge cases are, etc.
But it's possible that (dysfunctional or not), you just don't like waterfall methodology. In your next job, you know what to ask at the interview, if so.
posted by instamatic at 3:28 AM on March 21, 2014
Part of it is likely a methodology issue. Whether or not it's "dysfunctional" I really, really dislike waterfall development models, where it's more likely that the requirements team throws a set of requirements "over the wall" to programmers, who then build a system and pass it on to QA. I worked for one company as they switched from waterfall to agile, and though the process wasn't seamless, our time estimates improved by about a factor of three (stop for a second and think about that: we were taking three times longer than we promised to build something), and we stopped having the kind of death marches that caused huge developer turnover. The best part of it was that instead of business analysts and requirements managers throwing a set of not-very-feasible requirements at us, we had a product manager and QA person who came to daily stand-up meetings. The PM was deeply involved in the business analysis. So it was really easy to get clarification, work out alternate requirements when we discovered something wouldn't work, or go through test cases. It's a very rare waterfall requirements set that actually foresees all potential pitfalls enough to specify how to manage them.
But you're doing maintenance instead of new dev? Does that mean bug fixing or maintenance minor feature development? If it were me, I'd ask for a full set of QA test plans as well as high quality bug tickets. Because, yeah, QA test plans are often even better than requirements at helping you understand how something should work, what the edge cases are, etc.
But it's possible that (dysfunctional or not), you just don't like waterfall methodology. In your next job, you know what to ask at the interview, if so.
posted by instamatic at 3:28 AM on March 21, 2014
Are you getting a requirements document? Use cases? Anything like that from your BA? The BA should be documenting the user/system interaction.
The fact that you're not encouraged to talk with QA is puzzling.
posted by vivzan at 3:42 PM on March 21, 2014
The fact that you're not encouraged to talk with QA is puzzling.
posted by vivzan at 3:42 PM on March 21, 2014
This thread is closed to new comments.
posted by brainmouse at 5:49 PM on March 20, 2014 [1 favorite]