I've been reading the How Do you Get Business Analysts Domain Experience blog series from IT Career Coach since it started. The first one was cogent, intelligent and pretty much in line with my own thoughts about being without work for so long.
The latest and final blog, Do Business Analysts Need Computer Programmer Skills? is almost on the money. IT Career Coach argues the IT Analyst does need to have programming skills because a. that's what the market is demanding and b. the BA role has "evolved" to include programming.
Balderdash. Ptoooi. Wrong.
In a properly run project, the BA and the Developer are going to be needing every second performing their respective roles. Otherwise, dear reader, the sprints will extend, the iteration will be late and the implementation team (probably composed of the developers and the BA and the PM and the Infrastructure Team....) will get the code late.
These ads IT Career Coach is referring to are a bid by companies to 1. lower development costs by lowering salaries, 2. adding as many domain and application requirements as possible so their HR scanners don't have to work so hard and 3. forcing us to guess what the real job requirements are.
Do I think the blog's thrust is wrong? No.
An IT BA needs to know programming logic to write abstract use cases, user stories and specifications, which often contain pseudo code. In other words, to talk to the developers, the BA needs to be able use and understand phrases like 'loop,' 'data layer,' 'IDE' and 'COM.'
The IT BA needs to keep up on .Net, J2EE, SAP, J.D. Edwards, Ruby on Rails, Ajax and other technologies' capabilities for design, specification and testing. In other words, the BA needs to know, at the abstract level, what the technology can do, other the BA can't design or specify, much less set up a functional description of what should happen.
By the same token, how many of your developers can talk to the business side without a. raising expectations, b. creating misunderstandings or c. not understanding that business pushes the project, not elegance or the 'gee whiz' factor?
That's why Agile projects demand high level, experienced folks in key positions...like Developer, BA, Project Manager, etc. In a small to medium sized project, this isn't an issue. But in larger or off shored projects, Agile isn't known for scaling. It can be done... but a few Waterfall and Iterative practices needs to be added to the Project's Governance and Process- with Agile's means of revising things that don't work into things that do.
I'm thinking of getting a couple of SAP certifications. Then I might be able to find a job.
The latest and final blog, Do Business Analysts Need Computer Programmer Skills? is almost on the money. IT Career Coach argues the IT Analyst does need to have programming skills because a. that's what the market is demanding and b. the BA role has "evolved" to include programming.
Balderdash. Ptoooi. Wrong.
In a properly run project, the BA and the Developer are going to be needing every second performing their respective roles. Otherwise, dear reader, the sprints will extend, the iteration will be late and the implementation team (probably composed of the developers and the BA and the PM and the Infrastructure Team....) will get the code late.
These ads IT Career Coach is referring to are a bid by companies to 1. lower development costs by lowering salaries, 2. adding as many domain and application requirements as possible so their HR scanners don't have to work so hard and 3. forcing us to guess what the real job requirements are.
Do I think the blog's thrust is wrong? No.
An IT BA needs to know programming logic to write abstract use cases, user stories and specifications, which often contain pseudo code. In other words, to talk to the developers, the BA needs to be able use and understand phrases like 'loop,' 'data layer,' 'IDE' and 'COM.'
The IT BA needs to keep up on .Net, J2EE, SAP, J.D. Edwards, Ruby on Rails, Ajax and other technologies' capabilities for design, specification and testing. In other words, the BA needs to know, at the abstract level, what the technology can do, other the BA can't design or specify, much less set up a functional description of what should happen.
By the same token, how many of your developers can talk to the business side without a. raising expectations, b. creating misunderstandings or c. not understanding that business pushes the project, not elegance or the 'gee whiz' factor?
That's why Agile projects demand high level, experienced folks in key positions...like Developer, BA, Project Manager, etc. In a small to medium sized project, this isn't an issue. But in larger or off shored projects, Agile isn't known for scaling. It can be done... but a few Waterfall and Iterative practices needs to be added to the Project's Governance and Process- with Agile's means of revising things that don't work into things that do.
I'm thinking of getting a couple of SAP certifications. Then I might be able to find a job.
Powered by ScribeFire.
Posts
No comments:
Post a Comment