I was on an engagement and they had a small BI team there. The SQL guy. The ETL guy. The Qlikview guy and then I was inserted as the BA. I came in and was asked to document everything they had so far and to add processes to the madness. So one of my tasks was to understand the data. I documented everything. I came in and saved the day. The existing team was good at developing reports. I came in and developed functional requirements documentation, technical requirements documentation and then documented report to Source documentation.
Why do I bring that up? BA's are sometimes an afterthought, especially for a small company that has limited resources to dedicate to technology. The role of the BA is extremely important to develop a relationship with the business, to document what the business is asking for scope, and the ensure that the IT/Technology teams deliver on those requirements. One of the issues with this team was the impact of the no input process. For example: what were the requirements. Are the requirements documented? The last thing your team wants is for the business to start asking questions down the road of where is this data or that data because their request is not only documented but signed off on those requests. Additionally, sometimes your team gets so interested in pushing out code and reports that they forget to check little things, like spelling, data accuracy, layout.
The BA can help to find all of those mistakes by writing test cases that make sense. By documenting those test cases against requirements and then ensuring that the new code didn't break the rest of the code. It also helps to document what code is currently being used so that in the future, you understand if I change that code it will impact, report a, report b and dashboard 123. One other bonus is that if the BA is the interface between IT and the business, the development staff can focus on developing instead of meetings, Q&A, etc.
No comments:
Post a Comment