Help developers do their job and make clients satisfied at the same time – IT Analysts uncovered
Allow me to start this with a quote from Charles Dickens.
No one is useless in this world who lightens the burdens of another.
This pretty much sums up the job description of a business or systems analyst. Especially in a fast-paced, dynamic, ever-changing modern enterprise development environment. Why is that so?
Let’s break our quote and statement down to some simpler elements, let us analyze it.
Well, the job title does not give you much insight on what the person doing it actually does, at first glance, doesn’t it? Unlike developer – where someone might think (and would not be wrong, to a point) that a person doing it types code, solves logical problems with it and builds applications in specialized tools – analysts possess more of a soft skills package.
In order to analyze something, it has to be big and complex enough, with a number of influencing factors, to provide grounds for examining, identifying and documenting the findings. Where can such complex structures be found? In big businesses, of course. And those come from variety of economic areas – food production, transportation, commerce, construction, etc. All those have at least one thing in common in the 21st century – they rely on reliable business software to automate much of their manual work and enable them to focus on more important areas and processes.
People creating such software for them all work in IT but have very distinct roles and they also have at least one key thing in common – they need to communicate with those clients and understand the actual needs and requirements before translating them into tangible pieces of code, however complex it is.
Let us make things a little simpler for a moment – say that we have developers at one end of the spectrum and business people on another. And those two groups need to work on finding a solution for something which no one can actually identify but at least one group – business – knows that they want. In reality, businesses are often unsure in the details of their needs and requirements – not to offend anyone by this statement, it’s simply the nature of doing business. Theirs is to have an idea and recognize that a business process could be improved but they don’t have all the details nor do they (always) have a clear picture of how some improvement or a feature should look like.
On the other hand, there are developers, who are technical people and who view any process as a sequence of steps with twists, turns, loops, if’s and else’s. They do go into details because they have to – computer programs, however big and comprehensive they are, are in essence nothing more than a sequence of (simple) commands. And they will do exactly what you tell them to do. Nothing more and nothing less. If you leave something in the code unhandled, sooner or later that situation will occur while someone is using the software and that software will fail, leading to serious issues.
Business and technical people do not understand each other very well, no matter how hard they try – and no one is to blame there. They have educated themselves in completely different areas throughout their lives, with completely different focus, values and understandings while at the same time each of them has their own set of soft, personal skills which pushes their formal education and knowledge further in the specific direction. In the end, they need to be distinct in order to fulfill their roles better.
So, where is the “catch”, how do these distinct groups manage to work together and create something? It’s in the analysts. They fill the gap between people who have ideas and people who make those ideas a reality. They ask questions, they are “clearing the path” and investigating the ideas business people expressed. Their responsibility is to always take a step back and look at the broader picture and question whatever part of the process there is. It helps tremendously to business people to recognize if their ideas are, for starters, even feasible in terms of current processes and do they actually solve the problem or create a new value in a correct manner. If the answers to those questions are “yes” (we won’t cover “no”-s for now), business people will immediately have much clearer picture of how their idea will look like.
Now an analyst would translate the analysis work into a tangible requirements document and present it to developers. Imagine just for a second if developers never received a working requirements and/or had a person handling those for them? How stressful, painful and inaccurate would development process be? What would be the cost of it? I will leave you to think about it but there are certainly those who know how that looks like all too well.
Role of an analyst doesn’t end there – someone has to work with the developers during the actual process of code creation. There are always unforeseen situations and still uncovered questions. Analysts are a first line of defense in the, so called, war against unknown special cases and show-stopping issues. Their best tools are, again, taking a step back, including all the factors into play, researching and investigating similarities and finding patterns. All that reduces load of the developers who can focus on other parts of work in the meantime. Stress is ever present and mainly driven by uncertainty – analysts are actually fighting stress since theirs is to reduce uncertainty with knowledge, information and facts. In the end, there is also testing of the latest solution and providing feedback.
In order to do all that successfully, person who is doing the job has got to understand people, anticipate their needs, face problems and communication issues in an assertive way, be very knowledgeable about the environment and the project it’s engaged on. Also, having the ability and freedom to speak and express thoughts and concerns is a crucial asset.
You will find analysts in most email correspondence, calls, meetings, discussions, documentation or testing. You will often just see them thinking about something without the actual work being done. If you are working with one, regardless if you are a technical or business person, you might find them annoying or overly boring at times. They also might seem rude and/or direct. Sometimes you would think that they over-engineer every step and thinking too much. And all that can be true, it just depends on whether your process is going fine without issues or you are suddenly experiencing problems you are not able to (easily) solve.