Multi-handled deadline god or Broad Analytic Opportunity

It is no secret to anyone that analysts are one of the most freely and multifacetedly treated professions. And, despite the presence of as many as two professional standards, each company individually outlines the range of tasks assigned to the specialist occupying this position. In my article, I want to share my personal experience and tell you what roles the analyst is able to combine during the course of an ordinary project, what tasks to close, and where to develop if the main project employment becomes quite boring.

I hope my story will help you to find out with surprise what your fellow minds are like, and also highlight possible points of growth and development.

Disclaimer

All that will be discussed further is purely personal experience in a well-defined type of activity, which consists in developing and implementing custom solutions based on a specific system with its own platform and its own programming language.

Moreover, this activity is additionally limited by the subject specifics of the system being introduced, as well as by the vendor’s internal technologies, which act as local standards.

Well, as a cherry on the cake - this activity is carried out for the benefit of a bloody enterprise. And when I talk about a bloody enterprise, I mean projects in very large companies - almost all of the oil and gas, major banks, industrialists, retail, etc.

Accordingly, the analyst, which will be discussed in the article, is a person who exists within the whole of the aforementioned paradigm. Moreover, it is a very real and lively person, no matter how spherical a horse in a vacuum, he may seem to you in the course of reading.

Prelude

In general, the topic of self-determination of the analyst in space is quite explosive. Every time when in professional communities, on forums, meetings, conferences, or in telegrams, chatikas the question “who in the end is these fucking analysts” is raised, fierce holivars begin, during which some analysts prove to other analysts that each of them should and should not do.

It becomes even funnier (or sadder) when various Euchars or methodologists begin to reason on this topic.

In all these holivaras, I prefer to take a position, the essence of which lies in one single word - specificity. In other words, it is necessary for everyone and everyone to understand that the set of functions and tasks of the analyst will always vary greatly depending on the final employer, project and team.

Perhaps you are wondering - why did I suddenly decide that I can talk about it? It's simple. It is enough to list the roles that I change throughout any of my projects:

• business analyst;
• Systems Analyst;
• UI / UX designer;
• technical writer;
• tester;
• teacher;
• support

If we are talking about projects of increased complexity and scale, with a team of several analysts, among which may be newcomers, then additional roles are added:

• mentor;
• Tech Lead;
• Team Lead.

And in all this variety of roles I have been working for almost eight years.

Market

However, let's start from afar. Or rather, from the current situation on the market.

If you go, for example, to headhunter and type the word “analyst” into the search box, all the wealth of fantasies and interpretations on the subject will fall upon us.

Of course, most common analysts. Without any clarification, away from sin. In the description of these vacancies you can see a lot of various interesting functions, tasks, job responsibilities and requirements for candidates.

Some employers dare to voice in their vacancy categorization of business and system analysts, and thus practically dig their own pit. They do not even know how many analysts themselves were killed in this bloody battle.

The streamlined and capacious category of IT analysts is quite popular. In their description, usually, the whole Russian field of experiments with duties, limited, in fact, only by the sphere of IT. These vacancies most of all remind me of stories about tyzhprogramistov who are regularly asked to fix a vacuum cleaner or kettle.

More honest of all are those who, at least in the title, are trying to indicate what exactly it will be necessary to “analyze”. As a result, completely different vacancies of the form “SQL analyst”, “business process analyst”, “requirements analyst”, “1C analyst”, “sales analyst”, “analyst-marketer”, etc. appear. However, this does not save from the difference of tasks even in vacancies with two identical names.

Standards

It would seem that the point in this story should have been set professional standards, whose task is precisely to fix the goals of a particular professional activity and give an exhaustive description of the work functions of a specialist, the actions performed within their implementation, as well as the required knowledge and skills.

But it was not there.

Of course, we should be glad that standards still exist, although they appeared relatively recently. The system analyst standard will be five years old in the fall. Much later, the standard for a business analyst was pulled up - he doesn't even have a year.
Interestingly, the difference between a business analyst and a system analyst, these standards are already declared at the level of professional sphere codes: code 06 for system analyst, and 08 for business analyst. In other words, the system analyst is classified as “communication, information and communication technology, ”and a business analyst in the area of ​​finance and economics. And no you IT.

If we turn to the goals of professional activity, enshrined in the standards, the difference will become even more obvious and entertaining. Systems analytics, since it is related to the field of IT, work with requirements is imputed with a clear conscience, software is mentioned, automated systems, in general, everything we love. The business analyst, in turn, does not work with requirements, but with needs, but his goal is focused on changes in the organization that are beneficial. And note that not a word about systems or software and hardware complexes.

At the same time, a huge number of those involved in the creation of various kinds of software products have a simple “business analyst” record in their workbook. However, why go far, personally, for eight years, I have never called anyone, performing the same functions. Therefore, in order not to get involved in terminological disputes, in the further narrative I will still use the most general and neutral word “analyst”.

Missions

Let us turn to the specifics.

Any project in which our analyst participates in one way or another runs 4 global missions, let's call them - presale, pre-project, project and implementation. Of course, the analyst may not participate in all missions, but connect in isolation to any of them, but since we are switching to superhero mode, let's talk in detail about each one. Immediately make a reservation, escort, as a mission, I removed from the list quite deliberately, because I consider it irrational to keep a high-level specialist on these tasks.

Pre-sale

The first mission is, of course, presale.

It is worth noting that analysts on this mission are connecting far from everything and not always, considering the presley as a patrimony of vendors and project managers. However, over time, analysts were able to prove their usefulness and viability at this stage.

First of all, the analyst on presale is of course useful for expertise. And both subject and system. While traveling with the seller for meetings and demonstrations, the analyst speaks the same subjects to the subject and helps the seller to scoop out various situations related to characteristic professional vocabulary and terminology. In addition, having a deeper knowledge of the system being sold and vast project experience, the analyst is more quickly and more accurately guided in the possibilities of fulfilling the desires of the Customer, and also convincingly tells about the existing experience in solving similar problems.

After a series of successful meetings, the analyst begins to work in isolation from the seller and travels to the Customer independently, performing an express study of the processes, existing systems that require replacement, the infrastructure into which it will be necessary to be built in, etc.
The results of all these activities are the delineated contours of the future project, as well as a preliminary TOR, according to which it will be possible to carry out an initial assessment of the time, labor intensity and cost of work.

Pre-project

After the sale is completed and the organizational arrangements for signing the contract and ritual dances to initiate the project begin, the analyst can no longer sit idle, but begin preliminary work.

At this stage, a lot of information may already be available to him: this is the results of the express analysis, notes from the meetings, and the final TK to which the team subscribed, and, if lucky, a pile of various standards and regulations of the Customer, whose requirements It will be necessary to take into account with further design. In other words, a mountain of unstructured data that needs to be processed and formulated in its head the concept of a future solution.

Most often, this mission is typical for large-scale projects with a large team. It is in them that the analyst becomes a technical member and decides that we, figuratively speaking, will build on this project - a steamer or a plane. It also coordinates the team throughout the project, helping to select the best technical and substantive solutions, as well as ensure the consistency of the designed system.

Gradually plunging into the context of the future project, the analyst draws its framework and determines which conditionally isolated components can be divided into it. After that, already together with the project manager, distributes the team into the selected blocks. Here it is very important to take into account the interconnections of the modules of the future system and to understand how much work can be painlessly allocated to an independent unit.

After examining all the currently available information, the analyst builds the concept of automation, where he scrutinizes the skeleton of the future system with large strokes. It is these solutions that will form the basis for all further work and will set the direction for analysts who solve their local problems on independent blocks. Also, in addition to the concept, the first process diagrams may appear, which are still top-level. Most often this, in some ways, a side effect of the analyst’s immersion into the project is the result of analyzing the available information. But in the future, analysts on the blocks will also be guided by these schemes when they go to the Customer for detailed research.

In addition, the concept is closely related to the solution architecture - here the analyst interacts with the leading developer, embedding the future system into the existing landscape of the Customer and identifying the volumes of required integrations and migrations, both starting and regular.

At the same time, the analyst is not only preparing himself for the upcoming project, but at the same time he is preparing the Customer’s working group for it - those people who will later become the main sources of requirements for the future system. The analyst holds meetings with the working group and demonstrates a boxed version of the system, paying particular attention to the modules and functions that will be affected by the upcoming implementation. The main task here is to immerse the Customer in the context of the system in order to lower the barrier and achieve a more conscious attitude to the generation of requirements. At the demonstrations, the live analyst shows how TK items fall or will fall on the existing system. Here the very first connections of the TZ points and the real needs of the Customer occur.

Project

The main work, of course, begins directly on the project. At this stage, there is a constant change of roles.

First, the analyst works closely with the customer in the role of business analyst. At the same time, he can either occasionally travel to meetings and interviews, or even be on the Customer’s territory in full-time mode. At this stage, an in-depth study of the company's processes is carried out, bottlenecks and needs for automation are identified, consultations on possible solutions to the problems found are provided. Moreover, these decisions can be not only systemic, but also administrative-organizational. According to the results of the study, detailed diagrams and descriptions of the “as is” and “to be” business processes are born, with all the subtleties and possible scenarios. Along the way, requirements for objects of the future system are identified and collected.

When the information is collected, the business analyst is transformed into a system analyst, putting the requirements of the Customer into the capabilities of a particular system. At this stage, the design of the system modules is performed, while an experienced analyst independently assesses the possibilities of implementing a particular requirement and looks for ways to bypass possible platform limitations. However, lack of experience can always be compensated by consulting with the leading project developer.

At the same stage, the analyst becomes a designer, designing and drawing layouts for future system interfaces. Here it is important to consider not only the visual component, but also the basic postulates of UX, as well as the logic of the processes in which the projected objects will participate. All screen forms will sooner or later have to be formed into one logical and harmonious picture, and the system will have to respond equally to identical actions of users.

A separate stage is the design of all sorts of integrations and migrations. It all depends on the experience of the analyst and his system competencies. In general, the analyst should understand the place of the system in the general landscape and be well aware of its interaction with the rest of the Customer’s systems. This interaction should be described at least at the level of the interconnecting entities, the rules of the transmitted data and the mapping of details. The technical part of the design usually takes on the developer.

After all the solutions are designed, the analyst becomes a technical writer and writes a large and beautiful document that contains a detailed description of the future system. This document includes previously developed diagrams and process descriptions, and interfaces, with a detailed description of the application logic of elements, and other descriptions of modifications that need to be performed in the system in order to implement the designed solutions. Here, the analyst is aided by the verified structure of the document and ready-made templates that allow nothing to be missed.

After completing the documentation stage, the fundamental work passes at least two reviews - by the lead analyst and the lead developer of the team. And, if possible, also external review by colleagues from other teams and projects. After reviewing the document is sent for approval to the Customer. And it does not fall down on him with an incomprehensible multipage Talmud, but at first it is shown in the form of a presentation with explanations, songs, dances and funny pictures. Next, the analyst accompanies the approval process, answering the Customer's questions, correcting certain formulations, updating, if necessary, the requirements and decisions. After successful completion of the agreement, the document is sent to the development.

At this point, our analyst comes a short respite. In the course of development, he, of course, connects to work on the project, but with a noticeably less workload. In his tasks, mainly, answers to the developers' questions and periodic updates of requirements with the Customer.

When the development is complete, the analyst becomes a tester and is taken for a long, thoughtful and rigorous testing of the developed solutions. Immediately, I note that we are talking about user testing, but this does not mean that it is superficial. Every button, every window, every sprig of the route is checked, all reporting forms are built, all scripts are launched. In this case, testing is divided into two major stages. The first stage concerns the verification of basic functions. Here everything should work as it is written in the documentation, and as if an experienced and knowledgeable user was sitting at the computer. After all the positive usage scenarios have been verified, the analyst begins to “break” the system and test it from the perspective of an inexperienced user who is too lazy to even read the instructions. Separately, I want to draw attention to the fact that at this stage there may be additional requirements and finalizing the decisions. When testing is finally completed, we are ready for the next mission.

Implementation

At this stage, the analyst participates in the deployment and configuration of the system on the Customer’s servers. Initially, a test loop is configured, in which the working group together with the project team will perform the final testing of the solution. To ensure this testing, the analyst writes test cases, thinking through which scenarios the Customer will need to carry out in order to cover a maximum of functions within a limited period of testing and convince the working group that everything works as it should.

Of course, the testing phase again leads to a cycle of additional requirements, system modifications and repeated tests, but the inexhaustible wishes of the Customer should be significantly limited to terms and time-consuming, trying to take into work only the most critical moments. The main task is to get into operation as soon as possible to live users, no matter how inhuman it may sound.

At this stage, the analyst turns into a trainer-teacher, teaching ordinary users to the future system. Training can be conducted in a variety of ways: face-to-face courses with practical tasks and final certifications, seminars, webinars, videos, screencasts, etc. Parallel written user instructions (although in general, their development begins at the stage of internal testing).

Finally, when all tests and trainings are completed, the system is put into trial operation and the analyst becomes a support, providing continuous consultations and support to the Customer’s users. As well as training, support can also be very different - from the live running around on the floors, to the duty on the hot phone line.

During operation, users begin to receive suggestions that allow the analyst to remember that he is still an analyst and again plunge into working with the requirements, managing the requests for change and subsequent additional modifications. Of course, as you understand, these modifications will also need to be tested, deployed and then in a circle.

Sooner or later the project is completed, it is transferred to support the dedicated services, and our analyst receives the coveted sock.

Bonus-level

In addition to external project tasks, the analyst has many internal tasks in which you can also develop and realize yourself.

First of all - this is mentoring. Each new employee of the company must receive a personal tutor for the first 3-4 months of work. The mentor draws up a personal development plan, helps the newcomer to adapt, explore products and technologies, learn everything about the internal kitchen, and as a whole becomes practically his own mother.

Also, if the analyst has successfully completed several projects and gained experience, he can act as a reviewer for the decisions of his colleagues on other projects. Moreover, it can be included directly in the main product release team, as a technical or subject matter expert.

The next step is the development of the company's internal technologies. This stage requires solid experience and an indestructible desire to make the world a better place. Often - in spite of.

By default, translation of irreplaceable experience to the masses by any means is welcome - publications on internal and external platforms, reports and webinars, internal training of less experienced employees, etc.

Over time, if desired, our Shiva-analyst can take over the leadership of a group or department, become an external public expert of the company, and even provide on-site consulting services to third-party companies, partners, or potential Customers.

Epic-fail

Well, it can not be so rosy, you tell me. And you will be right. Sooner or later, our analyst lurks the biggest trap called - overqualified.

At this point, the analyst is in a rather difficult situation. Inside the company, all possible peaks have been reached, the largest projects have been implemented, and there is practically nothing left that could surprise or interest. Tasks that are challenges to others become a chore for such an analyst.

Moreover, it becomes quite difficult for a specialist of this level to realize himself somewhere else. For similar companies in which you can sell expertise, it is in demand, but very expensive. This cost will have to compensate for projects that still need to get. And let's be honest - the company would rather take a less expensive employee and grow it on their own, gradually integrating into the team and seeking loyalty. And for companies of a different profile, all this gigantic expertise is completely irrelevant. But to land a specialist with career and financial support is almost twice as interesting for neither the company nor the specialist himself.

However, I am sure that there is a way out of this labyrinth and our analyst will definitely find it. And if those present are ready to share their experience of existence in such situations - let's communicate in the comments!