A roundtable where systems analysis experts will discuss the top problems of the profession. 

Why doesn't anyone draw diagrams or read documentation? Why is business analysis turning into project management, while developers take over architecture? And why does the CTO keep saying, “We don’t need analysts”?

We’ll talk about the troubles only and suggest how to turn them into good practice.

A fast-track guide to surviving (and thriving) as a systems analyst, complete with practical advice and a healthy dose of positive thinking.

Let's talk about something that has been on the minds of developers (in a broad sense) for many years: analysts, architects, programmers, testers, and managers. 

• Why, even when consciously choosing methods and techniques, well-thought-out and tried-and-tested technologies, is the positive outcome of a project not guaranteed? 
• I often find myself having to change project decisions and involve employees in rework. Is there light at the end of the tunnel? Will we have successful systems developed on time and of high quality? 
• How to train new analysts for effective teamwork?

In the work of every analyst, skills in structuring information are essential: for identifying objects and building models, examining the world from different perspectives, and so on. That's why this workshop was created to develop these skills.

Each participant will have the opportunity to practice the use of rational and systematic thinking methods, receive feedback, and try to tailor thinking methods that align with their work tasks.

To participate in the workshop, it is recommended to attend Maxim Tsepkov's presentation — "Rational and systems thinking: practices and competencies of an analyst."

On the one hand, the Requirements Specification cannot die. The specification of requirements is a direct expression of the essence of a systematic approach and thinking. The more complex the system, the more accuracy and care required when making any changes. And the created systems do not become easier... 

On the other hand, the Facts are a stubborn thing - honest process/architectural work with a cascade of formed specifications, classic As-Is To-be transitions come across much less often, from start-ups unicorns are born, and certainly there weren't any specifications in them... 

We invite you to a discussion at the round table: 

• Influence of two paradigms on Business and System Analysis: design and product. 
• How to move from one paradigma to another with minimal personal and organizational losses.
  

It was a task for our department System Analysis over the year: to find people on 15 system analysts vacancies. 6 vacancies was in my group. The last of the 6 vacancies I closed at the end of December. A 100+ CVs, dozens of primary interviews, 3-5 resulting interviews for each vacancy. In the talk I want to to tell about the experience: career patterns, a typical set of knowledge of the candidates, their mismatch with the job profile and our understanding of analytics in a spherical vacuum.

EA&TFS in KL R&D SAO

Modern solutions of Kaspersky Lab are consist not only of applications / products, but also of services and infrastructure that allows you to quickly update the anti-virus database, receive the verdicts of malicious software from the cloud and more. In addition, in time of widespread cross-platform solutions dramatically increased the role of services that allow client applications on different platforms to display and process the same information. These and similar solutions are developed and maintained in the Kaspersky Lab as infrastructure projects. The report examines the features of analysis activities and techniques in infrastructure projects in comparison with product development.

We have only base rules of software production process in Kaspersky Lab. Each team can decide how to manage scope of their product, component or service. There are some base useful types of traces are created in last two years. These types of traces can be useful for PM to manage project scope, and can help system owners to manage their requirements for some products. We described these variants, developed instrumental support for it and can reuse it to achive of project goals in more efficient way. I will describe these patterns and will show some examples.