I have been in the IT industry for about thirteen years now. Thanks to my haphazard career planning and often the complete lack of it, I have changed just as many jobs during that time.Not content with merely job hopping every year, I have also worked in all kinds of roles and not in any chronological order. So for instance, I may have managed a program for a year and then found a business analyst gig for a change of scene. Coming out of that I have done a few months of testing followed by a spot of database design or process re-engineering work.
Since recruiters had no idea what the heck I had been doing and were not able to find a concentration of keywords to help them navigate through my resume, I ended up in random places assigned to do whatever came in handy. I went with the flow because it gave me an unique opportunity to gain first hand experience of things I would have had no idea of if I had followed any defined career path.
The most significant gain from all this has been my empathy for the different roles that have to work together to make an undertaking in the IT world successful. Unless you have been a tester working like a bot with no idea of the application, how it interacts with external systems and been actively discouraged to learn more, you have little appreciation for what it is to be in that person's shoes. Calling this test-bot person obtuse is easy.
Likewise only a developer who has had horribly non-technical business analysts throw vague requirements at him will know of the nightmares building that system entailed. They learn the hard way to pad their level of effort estimates by three hundred percent.
Of all the things that I have been, the business analyst role has probably taught me most about how the organization works or more accurately dysfunctions. Everyone who thinks they have what it takes to make it to the big league and snag the coveted corner office tends to highly disdainful of anyone who "gets too much into the weeds". They let the techs work that shit out and make sure to stay as far away from it as possible.
When you hang out in these circles the words that you hear repeated ad nauseum include strategic direction, architectural direction, organizational goals, vision statement, big picture and high-level objectives. If you get into a meeting with a few of these types hoping to figure out what problem they are looking to solve, chances are you would waste three hours and come back with a zilch.
Since they are determined to not get into the weeds like the lowly tech drones, the problem cannot even be articulated let alone solved. You need to tune out all the bombast and glean the couple of key pieces of information to arrive at the requirements pretty much independently because they will most likely not be able to vet what you present because it is way too "detailed". They struggle with the retarded, vision challenged worker-bees who fail to see how the big pieces of the puzzle fit to make this castle in the air which is the CIO's Utopian vision defined in his one line vision statement.
I could not agree more with David Meggison that business requirements often become the weakest link. Organizations still follow the age-old adage "Don't define how in the business requirements. Confine it to the what alone. How will be defined in design ". As Meggison points out this approach in inherently waterfall and that most people agree is not the wave of the future. Sometimes thinking of the how spurs discussions around the what and if wanting a certain piece of functionality is even realistic.
Considering the what in isolation from the how is like signing up to build a jet-plane while having the wherewithal to build only a bicycle. Sure you can always de-scope requirements that don't prove viable at the design phase. You may just as easily deliver the jet-plane without the engine and wings. Common sense would say it may be better to get a fully functional bicycle out of several man-months of work than an inoperable jet-plane. Somehow, this premise does not hold true in the realm of IT.
Since recruiters had no idea what the heck I had been doing and were not able to find a concentration of keywords to help them navigate through my resume, I ended up in random places assigned to do whatever came in handy. I went with the flow because it gave me an unique opportunity to gain first hand experience of things I would have had no idea of if I had followed any defined career path.
The most significant gain from all this has been my empathy for the different roles that have to work together to make an undertaking in the IT world successful. Unless you have been a tester working like a bot with no idea of the application, how it interacts with external systems and been actively discouraged to learn more, you have little appreciation for what it is to be in that person's shoes. Calling this test-bot person obtuse is easy.
Likewise only a developer who has had horribly non-technical business analysts throw vague requirements at him will know of the nightmares building that system entailed. They learn the hard way to pad their level of effort estimates by three hundred percent.
Of all the things that I have been, the business analyst role has probably taught me most about how the organization works or more accurately dysfunctions. Everyone who thinks they have what it takes to make it to the big league and snag the coveted corner office tends to highly disdainful of anyone who "gets too much into the weeds". They let the techs work that shit out and make sure to stay as far away from it as possible.
When you hang out in these circles the words that you hear repeated ad nauseum include strategic direction, architectural direction, organizational goals, vision statement, big picture and high-level objectives. If you get into a meeting with a few of these types hoping to figure out what problem they are looking to solve, chances are you would waste three hours and come back with a zilch.
Since they are determined to not get into the weeds like the lowly tech drones, the problem cannot even be articulated let alone solved. You need to tune out all the bombast and glean the couple of key pieces of information to arrive at the requirements pretty much independently because they will most likely not be able to vet what you present because it is way too "detailed". They struggle with the retarded, vision challenged worker-bees who fail to see how the big pieces of the puzzle fit to make this castle in the air which is the CIO's Utopian vision defined in his one line vision statement.
I could not agree more with David Meggison that business requirements often become the weakest link. Organizations still follow the age-old adage "Don't define how in the business requirements. Confine it to the what alone. How will be defined in design ". As Meggison points out this approach in inherently waterfall and that most people agree is not the wave of the future. Sometimes thinking of the how spurs discussions around the what and if wanting a certain piece of functionality is even realistic.
Considering the what in isolation from the how is like signing up to build a jet-plane while having the wherewithal to build only a bicycle. Sure you can always de-scope requirements that don't prove viable at the design phase. You may just as easily deliver the jet-plane without the engine and wings. Common sense would say it may be better to get a fully functional bicycle out of several man-months of work than an inoperable jet-plane. Somehow, this premise does not hold true in the realm of IT.
Comments