Леонова Наталья
Бизнес-аналитик - Devexperts
Saint Petersburg, Russia

Тестировщик, перешедший на сторону бизнес-анализа. Люблю коммуникации во всех их проявлениях, новые предметные области и понятную документацию.

Talks (7)
  • 07.07.2021
    Interview. How to talk to people about requirements

    The interview is a basic communicative element of an analyst's work. All of us have conducted it a thousand times, and it would seem that we can hardly be taught anything new.

    But in fact, the skill of effectively asking questions and getting the right information is a complex science that experts in the field have been learning for years. 

    We've done the research, and we'll tell you: 

    • How to analyse focus groups
    • How to prepare for an interview
    • Why it's hard to ask a good question
    • What good and bad questions are in general
    • What qualities you need to learn to conduct interviews well
    • How to construct an effective question structure
    • What types of questions exist and how to combine them
    • How to listen and take notes
    • How to process and analyse the results

    • Average
    • 40 min
    • Analyst Days / 13
  • 15.11.2020
    Whether you are an engineer or a poet, great communication skill will always strengthen who you are

    The analyst career path can go to different ways – it may lead to management, UX, or even development of technical skills and focus on the non-functional side of requirements. Wherever the career path is leading, one thing remains unchanged – it is communications and mending fences with Business and IT stakeholders, teammates and your manager. 

    Every single month, we see that more development tools, methodologies, and techniques are available on the market, and IT brings us new communication tools and opportunities, such as Zoom, Google Hangouts, Slack. 

    If an analyst wants to master communications with people, he or she needs to understand people, and for that purpose, some basic theories from Humanities & Social Science are of great use. We will talk about the Communication Theory, Cognitive Models and why Humanities & Social Science can bring us some great insights in daily work. We will go through a few practical examples to see how to bring the theory into daily life and practice.

    • Easy
    • 20 min
    • Analyst Days / 12
  • 15.12.2019
    How long does the tech spec remain?

    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.

    • Average
    • Analyst Days / 11
  • 22.01.2018
    Special requirements - describe and analyse them!

    Requirements are the keystone for an analyst. It doesn`t matter in which domain the analyst works, what kind of project he (or she) conducts and what a software methodology is used  -  the analyst's primary task is to identify, analyse and describe the requirements. But the requirements can be different, and sometimes the analysts and the rest of the project team have to face a new level of complexity - "special" requirements, which are out of bounds of the standard IT world.

    We will discuss a system and requirements for disabled users, their specifics, identification and description. What such requirements differ from "standard" requirements, what features of communication with the customer and the customer itself appear in this case and how these requirements affect the life cуcle of the application. We will check on the example of a real project how we can work with these requirements, analyse them and implement into the project.

    • Easy
    • 20 min
    • Analyst Days / 8
  • 14.12.2016
    Communication failures and their friends

    Communication is probably one of the most important parts of the analysts work. Communication with customer during clarification of requirements, communication with developers and testers, and also a simple communication with colleagues  - all these things require certain communication skills. Every analyst knows that a clear and uncluttered written document needs a lot of time and effort spent on it. 

    There are often difficulties in communication process  that make our live more complicated. And if misunderstandings can occur in case of communication with colleagues and clients, that speak one (native) language, how we can behave if a job includes communication in a foreign language, and sometimes no only one. 

    We will discuss a number of terms and concepts that will help us to cope better with the difficulties in communication, as well as they will contribute us  to begin "to call a spade a spade". We will check on the example of the multicultural project that it really works.

    • Easy
    • 20 min
    • Analyst Days / 6
  • 04.12.2015
    How we specified a project with UML

    Business analysts have to write documentation in the different conditions - it isn`t always clear what our customer wants. It could happen that requirements are written after the "magic" of development.

    In the talk, we consider a project when analysts were integrated after development, and the main task was to find a convenient way of documentation that would be good for all project's members .

    The situation is also complicated by an international team - part of the development and analysis were in St.Petersburg, and customers - in Germany. Things were not running well with normal specifications and documents became quickly obsolete, we solved this problem using the modeling language UML, and we described web services as diagrams, using Enterprise Architect.

    Pictures are always a good idea and they play an important role in the documentation. As a result, we have a "living" and clear model of the project, and with some small tricks, it`s possible to generate a "paper" version of the spec.

    • Easy
    • 40 min
    • Analyst Days / 5
  • 11.09.2015
    Effective tester & analyst cooperation

    In the software development process communication between the testing and analysis is inevitable. To give tester a clear and high-quality documentation, analysts need to understand what he should change / reword / clarify and that`s why a dialogue and teamplay are required. All team members should also clearly understand how to deal with each other - analysts can be different and sometimes they speak an unknown language.We all know that a true (waterfall) testing should begin as soon as possible - with the documentation. So the testers questions occur in the early stages of creating / writing of the documentation. In general communication between the two camps is more active than it seems.  That`s why (as well as for other reasons) an analyst rides whip and spur to the tester - all for software quality! A good example is a large number of tools for tests -requirements synchronizing, for example, Polarion or QC. 

    • Easy
    • 20 min
    • SQA Days / 18
To leave a feedback you need to

Chat with us, we are online!