The most interesting reports from the conference Analyst Days 2017

In April, our colleagues attended the international conference on systems and business analysis Analyst Days 2017 , held in Moscow. Under the cut - impressions from the most interesting, in our opinion, reports of this conference.

Reports were grouped by thematic blocks. We begin with a brief review of the reports of the Quality Requirements section, which, as could be judged by the crowded rooms, aroused great interest on the part of the conference participants, since the speakers touched upon one of the most important aspects of the work of business analysts.

Thematic block "Quality requirements"

Elena Goropeka, “ Testing requirements. We find problems before they appear. ”
')
In a brief report, Elena Goropeka told about who and how the requirements can be tested.

Everyone knows that the earlier a bug was discovered when designing software, the cheaper it costs. The speaker advises to make testing the requirements an obligatory step of the project work process. It can be conducted by the following team members:

• A senior analyst or manager is perhaps the best candidate for this role, since he knows your strengths and weaknesses well, has extensive experience and is interested in increasing the professionalism of employees. He is also the one who can help establish the process of testing requirements on an ongoing basis.
• Testers of the project, as they know how to dig in the details, know what to look for, are interested in having good documentation on which they will test the finished product. If the tester starts developing test cases according to the written specification without access to the test environment, in the process he will surely find points requiring refinement and detailing. That is, in fact, it does not do double work, but at the same time changes in the development process will bring tangible results.
• Business analyst from a neighboring department / project. The load of business analysts varies nonlinearly, and it is worthwhile to attract to test the requirements of colleagues. Among other things, it also contributes to the dissemination of best practices for developing documentation.

Types of verification may also vary depending on the situation.

• Express check can be conducted to identify only obvious errors. Or it can be a thorough check, but only parts of the requirements, and according to the comments the author can conduct a full analysis on his own.
• The basic check checks the requirements only for compliance with the standards of their writing adopted in the company (without checking the completeness of the coverage of business and user requirements).
• Extended validation is applied when the Customer is seriously dissatisfied with the quality of requirements. With this type everything will be checked. This is a solid work that requires immersion in the project and participation in sessions with the customer. This service can be ordered from professionals.

By introducing test requirements into the workflow, we improve the quality of the final product, we can involve testers at the earlier stages into the project, develop analyst cooperation and enable the manager to see that our specification is fine :)

At NIX Solutions, we actively apply testing requirements in the following situations:

• checking the quality of documentation received from the client - a detailed reading of the requirements allows you to identify problem areas in time and give a more realistic estimate of labor costs.
• Review of the project requirements by another analyst before the start of the project is a mandatory step if the documentation is developed on our side. The tester and the developers involved in estimating labor costs also read the requirements and give feedback.
• Regular quality checks of requirements by the analyst's supervisor - we mainly use the approach of thorough verification of a part of the requirements, only for beginners a full detailed reading can be carried out.

The report prompted new ways to apply testing requirements to improve the quality of the requirements, which we will certainly test in practice :)

Taisiya Tolstunova, “ As large as life. Completeness of requirements and methods of its verification »

Taisiya Tolstunova began her report with what we mean by the fullness of the requirements, and how to define it. We can consider this concept from the point of view of classics, such as Wigs, Coburn, use the definitions of Babok and SWEBOK, and other sources. Incompleteness of requirements may lead to the following consequences:

1. Not implemented what was needed
   
   • not at all what they asked;
   • forgot something important;
   • "Everything is fine, but."
2. Loss of time for the whole team
3. Reduced professional self-esteem

Further, the speaker analyzed the reasons that led to this. The following were named:

• Lack of time allocated in the project for analysis
• The absence of the possibility of additional harmonization of requirements
• Employment on other projects

To avoid unpleasant consequences, Taisia ​​suggested using the following techniques:

1. Follow the correspondence during the collection of requirements, carefully collect everything, specify with the customer and document
   Example:
   “Maria, it is important for us that all employees of the company have access to the system at once.”
   "Except us, no one will use this system, though ..."
2. Perform requirements testing
   
   • Cross, inside department
   • “Tres amigos” is a technique that allows the entire set of requirements to be checked simultaneously by the analyst, tester and developer. The discussion of requirements is carried out after a preliminary study by a team of 3-5 people representing these roles in the project.
3. Use brainstorming techniques to find under-described parts of the process.
4. Develop and use checklists:
   
   • by writing standards
   • by the functionality that is important to the customer
   • on the process of harmonizing requirements
   • your choice! ...
5. Develop charts showing the entire business process or its individual parts. Going through the diagram, step by step, the entire business process, you can more easily track its description in the requirements.

The reports of the block echoed and complemented each other, forming a more complete picture of how to adjust the process of testing requirements in particular in the company and maintaining the quality of development as a whole.

Thematic block "Improving efficiency, specialized skills"

In this section, conference participants were expected to have equally interesting and informative reports.

Olga Samarina, “ Design Thinking. What is it and can analysts use it? "

As part of her report, Olga Samarina introduced the audience to the Design - Thinking Methodology. Here's how to define it online: it is an approach to solving engineering, business and other tasks, based on a creative, not an analytical approach. The main feature of design thinking, as opposed to analytical thinking, is not a critical analysis, but a creative process in which sometimes the most unexpected ideas lead to a better solution of the problem.

Together with Olga, we looked step by step all the way from the statement of the problem to the creation of its solution. According to the speaker, it is important from the very beginning to identify the real problem of people, and in search of a solution not to follow stereotypes. The user can not always say what needs to be done otherwise. If the creators always followed the customers' requests, the car could never be invented, because people asked for something else ...



Our vision of how users will use the tools they provide may differ from reality. Therefore, when collecting information about a problem, you should watch their work, watch what they do NOT do and listen to what they do NOT say. If we are talking about improving the work product, then the opinion of users who DO NOT love our product and rarely use it, or those who have stopped using it, is very important to us. These people are often the source of new and unexpected information.

The speaker advises after collecting information about the existing solution to focus on specific problems in order to understand what the users are not satisfied with, which the system lacks in order to attract more people. Then conduct a brainstorming, according to the results of which, choosing a specific idea is one solution that we consider optimal. The next stage is prototyping and testing hypotheses. And then they check and test run.



At the end, the speaker listed the advantages of the methodology, the situation when it should be used, and when the method is ineffective. Olga gave a couple of interesting examples. In the first situation, the Sberbank team was looking for a solution for the problem of queues to the operators.



According to the speaker, during the analysis, Sberbank employees found out that the user doesn’t need an operator, the client is morally ready to examine the ATM interface, asking for help from a consultant in the hall to conduct operations independently.

Thus, to solve the problem of queues, it was not necessary to increase the staff of the bank and expand the branch area. And it seems that it helps, because now the branch of Sberbank looks like this:



The second example concerned privacy when withdrawing money from an ATM. Olga said that in search of a better solution, Sberbank tried various options, testing them on users. These were opaque partitions between two adjacent ATMs, a booth at each ATM with a closing door, video cameras aimed at the queue. As a result, an inexpensive and easy-to-implement solution was chosen - dividers between ATMs and a yellow restrictive line on the floor.



Thus, we can talk about the payback of the analysis, because you can try out the options on the test group of users and then carry out large-scale, costly changes.

Collection of requirements and description of the vision of the solution (short version)

There was also a very interesting master class in this block. After the theoretical part, we broke into teams to come up with a product and describe its target audience (with the creation of the character).



We needed to highlight the basic needs of our customers — NEEDS. This is a brief description of the current state. As an example, the need for communication, the formation of financial statements, ticket sales, etc. Then - pleasant additions - WANTS, this is what does not solve the main problem of the user, but it can be convenient, useful, please him. Once we have decided on the first two points, we can determine what exactly we will implement - JOBS TO DO. And immediately it was necessary to divide them into three groups: functional, emotional and social. We also took into account what needs to be done in addition to the main functionality - whether it is necessary to prepare documentation, carry out certification, personnel training, etc. And for each specific task, it was necessary to prescribe acceptance criteria, quality criteria, expected result, and risks associated with its implementation.



It was an interesting creative task, during which a small group of unfamiliar analysts were able to agree and find answers to all these questions.

Thematic block "Communications"

Sergey Krupenin “ PM vs BA vs World. How to behave the people whom you set tasks + Management fights. Harsh practice . In the Communication block I remember the lecture of Sergey Krupenin very much. By the way, it was he who was chosen as the best speaker by a vote.

As the name implies, the report was about managing people. And we took into account only the personified management, when the head communicates directly with subordinates. There are 4 main functions of the head.



Subordinates may react differently at each of these stages, and we looked at 7 kinds of people's reactions.



This table will help determine what kind of reaction a person shows to the requirements of a manager. Consider an example of defining order. The manager decided that the team would work on SCRUM with 2 weekly iterations. And one of the subordinates starts telling that KANBAN is better, and it was worth choosing it. You can define an employee response as " intercepting management ."



The supervisor should carefully observe the reactions of the subordinate in different situations. The most frequent reaction is his character. Depending on this, it is worthwhile to correct your behavior with him in order to strive to lead him to loyal reactions.



In the same section, the report by Alexey Kolokolov also deserves special attention:

How dashboards help businesses and analysts understand each other

Alexey Kolokolov from the Institute of Business Analytics (Moscow) spoke about the intricacies of using information panels (dashboards) as part of his report.

According to the speaker, when creating a dashboard, first of all it is necessary to determine its target audience (customer). Depends on this, what will be the design and style of dashboard. Further, depending on the goals, the analyst works on its content.

It should be noted that no matter what the audience will be and what tasks the author sets for himself, there are a number of rules that must be followed when creating dashboards. These rules were in many ways similar to the rules for making presentations. Further, the author of the report offers a ready checklist of 9 points, which analysts can use as a basis when creating their own dashboards.



From the above list, shown in the picture above, I would like to elaborate on the second paragraph. Visual perception plays a big role during the familiarization with the information panel. With the help of visualization you can achieve the expected effect, but at the same time, if the choice of color, location, brightness or position in space is unsuccessful, the author of the dashboard may encounter the fact that the information will be perceived incorrectly. For example, take a look at the picture below and try to quickly answer the question “Who worked better?”.



Most people instantly get the impression that Petrov showed the best results. And only a closer look will make it clear that the reason for the misinterpretation of the slide is the scale of revenue, which is depicted differently for the two workers, which ultimately leads to visual deception. Just as visuality is of great importance in building a dashboard, the remaining 8 points of this list also deserve special attention when creating panels.

Further, the speaker says that one of the main reasons for unsuccessful, and often trivially failed information panels is the different perception of the analyst and the customer. The analyst is immersed in the details, while the overall picture is important to the customer. It makes no sense to give a ton of information, you only need to provide a squeeze out of it in an intuitive format.

Finally, Alexey gives important advice: learn how to switch roles in yourself - try to be not only an analyst, but also imagine yourself as a customer, and then feel yourself a designer. This will help the analyst create a truly successful dashboard.



This was the Analyst Days 2017 conference: at the exit there is something to think about, what to take and note and work on.