Myths and legends of system analysis or what does an analyst in the bank

Hello! My name is Nastya, I am an analyst of the Alpha Business mobile application. Sometimes they ask me about what I do at work. Friends, relatives and, oddly enough, the developers. Every time I answer differently, trying to bring the closest examples to the interlocutor.

“The system analyst translates user requirements from a human language to a development language ...” sounds quite understandable to a non-IT person. But if you are directly involved in the development, such a definition is unlikely to be enough. For the sake of a small experiment, I asked my team the question: “What does a systems analyst do?”. We read under the cut that came out of it.

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

As for the Earth, maybe a bust, but otherwise pretty accurate. Where to store data, how to transfer them, how the feature works, why the feature does not work ... Every time something incomprehensible is found in the backlog of the product, the phrase “we need analytics” follows.
')
To understand how the system works, the analyst refers to internal documents. Usually the answer is among the text, charts 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 reading from 30-page TK to a few requests. The main thing is to know what to look for. The logs contain information about the called methods, input and output parameters, the causes of errors. If the composite service is about step-by-step execution of the operation. Analytics need 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 complements the search by application code. The project covers information about data sources, the logic of processing variables and many other useful things. The success of the event depends on the skills of the analyst and the specifics of the company. In some organizations, analysts do not have access to the code. Right or wrong - the question is complicated. In any case, if there is no access (or understanding of what is happening), you can always ask the developer.

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

Another source of information is people. An analyst who knows the subject area can solve a problem in five minutes, for which you have scheduled a couple of days to complete. 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, bending around obstacles, and is constantly looking for shorter paths (c) front-end developer

To get from Petersburg to Saratov, you need a reliable car and car map. Well, if there is a first aid kit, spare wheel, tools. It will not be superfluous to communicate with the locals, well, in general, understanding why you are going to Saratov, and not to the Krasnodar Territory, for example. With analytics as well. You must have tools for work, the ability to interact with people and a clear understanding of the expected result. Roadmap knowledge of systems and technologies.

Any task has at least two solutions. It is important to choose a path that is not shorter, but more correct. More correctly in terms of architecture, 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 technology development. By implementing 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 older versions. If the system has several fronts - about the uniformity of their work. When using multiple data sources - about their consistency. In general, the headache of fascinating features in work is enough.

Well, I do not know, you're just a tester for me. Well, or a mixture of product with a tester, something like that (c) backend developer

I agree, it sounds a bit offensive, but there is some truth in it. First, the analyst examines the system in order to understand how it works. Then he is convinced that the result of the work of the developers works correctly at all levels: the base contains reliable data, the service returns the correct answer, the user sees the expected result. If something goes wrong, the level of the error, the cause of the inconsistency and possible corrections are determined. Assessing the compliance of a system with various types of requirements is an integral part of analytics.

With the grocery aspect more difficult. The product owner knows what to do to make the user happy. The system analyst knows how. My subjective opinion is that the analyst to the same extent as other team members should (or can) deal with product issues. When the whole team cares about improving user experience and achieving financial goals, better solutions are born than when one or several people are involved.

Collects information about the products, projects and systems of the bank, is engaged in its actualization and distribution, is on the edge of the information knife (c) Scrum Master

Everything begins with 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 according to internal standards. Documentation methods may also vary by system layer.

When writing documents, various methodologies, standards and system modeling notations are used. Rarely do you need immaculate adherence to the rules. It should be reliable and relevant. And if it is clear from the first time, it is 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. I learned something new - tell others. Want to share your experience - make a report. Again, this is not always and not everywhere. But if the enterprise has a knowledge management process, analysts will definitely take part in it.

There are many different things that the analyst must know in order to meet the team’s role and expectations. Depending on the specifics of the product and industry, the composition and degree of their significance varies. What an analyst does, 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 road map analyst. The scheme contains the main skills in different directions, as well as an attempt to distinguish between systems and business analysis.

It is difficult for me to judge how versatile the map is. Therefore, I am waiting for comments from developers and analysts from other organizations :)