Myths and legends of system analysis or what an analyst at a bank does

Hello! My name is Nastya, I’m an analyst at Alfa-Business mobile application. Sometimes they ask me what I do at work. Friends, family and, oddly enough, developers. Each time I answer differently, trying to give examples closest to my interlocutor.

“A system analyst translates user requirements from a human language to a development one ...” - it sounds pretty clear to a person who is not connected with IT. But if you are directly involved in the development, it is unlikely that such a definition will be enough. For the sake of a little experiment, I asked my team the question: “What does a system analyst do?” We read under the cut, what came of it.

For me, a system analyst is a person who can give an answer to any question: from “How the feature should work” to “Why the Earth is round” (c) tester


As for the Earth, it may be too much, but otherwise pretty accurate. Where to store the data, how to transfer it, how the feature works, why the feature does not work ... Every time when something incomprehensible is found in the product backlog, the phrase “analytics is needed” follows.

To understand how the system works, the analyst turns to internal documents. Usually the answer is among text, diagrams and tables. But sometimes people leave without writing documentation. Or it is irrelevant. Or unreliable. The karma of such analysts suffers terribly, but, fortunately, there are other ways to find information.

Confident use of logging systems can reduce fiction from a 30-page TK to a few queries. The main thing is to know what to look for. The logs contain information about the called methods, input and output parameters, causes of errors. If the service is composite - a step-by-step operation. The analyst needs to understand the structure of the logs and be able to filter them: usually a huge amount of data is logged.

The information found in the logs is well complemented by a search by application code. The project contains information about data sources, the logic of processing variables, and many other necessary things. The success of the event depends on the skills of the analyst and the characteristics of the company. In some organizations, analysts do not have access to the code. Whether it is right or wrong is a difficult question. In any case, if there is no access (or understanding of what is happening), you can always ask the developer.

If a problem appears that no one has solved, external sources are used. Ok Google, cosmological models of the universe? Any means are good here: articles, forums, training courses, documentation for third-party systems. Sometimes Indians from YouTube come to the rescue, but this is an extreme case. By the way, one must be able to search in two languages, well, or immediately in Hinduin English.

Another source of information is people. An analyst who knows the subject area can solve a task in five minutes, for which you outlined a couple of days. Therefore, you need to know what colleagues are doing around and be able to correctly formulate your question.

The analyst, as a navigator, paves the way to the goal, avoiding obstacles, and constantly searches for shorter paths (c) front-end developer

To get from St. Petersburg to Saratov, you need a reliable car and a car map. Well, if there is a first-aid kit, a spare wheel, tools. The skill of communicating with local residents will not be superfluous, well, in general, understanding why you are going to Saratov, and not to the Krasnodar Territory, for example. With analytics too. You must have the tools to work, the ability to interact with people and a clear understanding of the expected result. Knowledge of systems and technologies is becoming a roadmap.

Any task has at least two solutions. It is important to choose a path that will not be shorter, but more correct. It is more correct in terms of architecture, fulfillment of product requirements and implementation costs. Sometimes the analyst only provides information for a team decision; in other cases, he makes the choice himself.

To offer an adequate implementation, you need to understand the structure of the system: from architectural patterns to development technologies. By implementing the change, the analyst evaluates the impact on application components and other integrated systems. When developing a mobile application, you need to remember about users with old versions. If the system has several fronts - about the uniformity of their work. When using multiple data sources - about their consistency. In general, there are enough headaches of fascinating features in work.

Well, I don’t know, you are just a tester for me. Well, or a mixture of a product with a tester, something like this (c) a backend developer

I agree, it sounds a little offensive, but there is some truth here. First, the analyst examines the system to understand how it works. Then he is convinced that the result of the work of developers works correctly at all levels: the database contains reliable data, the service returns the correct answer, the user sees the expected result. If something goes wrong, the error level, the cause of the discrepancy and possible correction options are found out. Assessing the conformity of the system to various types of requirements is an integral part of analytics.

The food aspect is more complicated. The product owner knows what needs to be done to make the user happy. A system analyst knows how. My subjective opinion is that the analyst, to the same extent as other members of the team, should (or can) deal with product issues. When the whole team is worried about improving the user experience and achieving financial goals, better solutions are born than when one or more people do it.

Gathers information about the products, projects and systems of the bank, is engaged in its updating and dissemination, is at the forefront of the information knife (c) Scrum-master

Everything begins with the documentation, and it ends with it. It is prepared for internal use and, where applicable, for the Customer. Documents are created in accordance with GOST or internal standards. Documentation methods may also vary across system layers.

When writing documents, various techniques, standards, and system modeling notations are used. Rarely when you need to impeccably follow the rules. It must be reliable and relevant. And if it is clear the first time, then generally wonderful. Here , by the way, there is an interesting article in which the problem of the quality of documentation is disclosed.

In addition to system documents, the analyst can write material for the corporate Wiki. Learned something new - tell others. If you want to share your experience, make a presentation. Again, this is not always and not everywhere. But if the enterprise has a knowledge management process, analysts are sure to take part in it.

There are many different things an analyst needs to know in order to match the role and expectations of the team. Depending on the specifics of the product and industry, the composition and degree of their significance varies. What the analyst is doing, we sort of figured out. It remains to understand what you need to know to successfully complete all tasks. Your attention is invited to the roadmap analytics. The scheme contains the main skills in different directions, as well as an attempt to distinguish between system and business analysis.

How universal the card is, it's hard for me to judge. Therefore, I am waiting for comments from developers and analysts from other organizations :)