Ананьева Екатерина Андреевна
Генеральный директор - GetAnalyst.ru
Moscow, Russia

Системный аналитик по образованию и по жизни.

Анализирую требования не только к тому, что видит пользователь снаружи, но и к тому, как все устроено внутри систем. Проектирую архитектуру.

Основной опыт связан с проектами, где важно делать не только по требованию от заказчика, но и генерировать идеи вместе с ним.

На сегодняшний день я руковожу отделом системного анализа в компании МойСклад, создающей удобные сервисы для работы с торговлей и складом.

Talks (4)
  • 06.02.2022
    The Dangerous Integrations

    It's hard to find isolated systems today. They exchange with data, transfer control to each other to automate complex processes, spend less resources on “reinventing the wheel”. Moreover, connections create not only outside, and also inside large projects. Integrations are everywhere. But along with the benefits, there are also problems. Integrations are major points of failure.

    I want to share my experience and tell you how to build reliable relationships between systems.

    Are you an analyst or an architect? Do you often work with integrations? Do you want to know how to insure your system against the unpleasant consequences of organizing communications with the outside world? Go and to take the insurance package “The Dangerous Integrations”!

    • Average
    • 40 min
    • Analyst Days / 14
  • 31.08.2021
    Bugs of systems design can be avoided

    It is always good to study the best practices of designing systems and try them in your projects. And it is even better to know about possible pitfalls.

    It is signs that something went wrong during the designing process:

    • the team asks a lot of questions about the problem statement;
    • developers find unrealizable requirements and ask to change them;
    • testers find many unreported cases in the testing process;
    • a change request for functionality comes from the customer, and you need to add "crutches" to support it.

    The talk is devoted to the bugs of design that I encountered in my practice, how to avoid them, and how to take them under control. It will be helpful for both systems analysts working with systems architecture design and business analysts collecting and describing development requirements.

    • Average
    • 40 min
    • Analyst Days / 13
  • 24.01.2021
    Seeing through: what is hidden behind simple requirements

    Let's assume a multicomponent system: web interfaces, mobile and desktop applications, a cloud that provides information exchange, integrations with external systems, several REST API implementations. The architecture of the application is similar to a complex molecule, even without diving into depth.

    There are simple demands such as adding a field to a document. It would seem that everything is very easy! The user work script and logic have changed to a slight extent, there are small edits in the database. The task is quickly sent to development. But unexpectedly, a "complex molecule" can remind of its versatility and begin to influence.

    Sometimes, in the absence of system analysis, even for a simple requirement, more and more errors may appear with each iteration of development and testing. Sound familiar?

    How to defeat influence on everything? Try to learn to see right through when designing systems.

    • Hard
    • 40 min
    • Analyst Days / 12
  • 29.07.2020
    How we started the documentation process

    Organising processes properly from scratch is quite expensive for young IT-projects. Imagine two developers who started a project. At the start, they embraced all team roles. Their processes are simple, and they can share knowledge first-hand.

    Once their project becomes successful, their team grows: new developers, testers and others. As a result, processes become more sophisticated too. But who knows how processes are organised? Maybe those developers who started the project? Not sure.

    As the team grows and changes, the time comes to organise knowledge about the product into a single source - documentation. Where new team members can get answers why a particular process is performed that way and not another or how a feature works without review the code.

    How to sum up everything and describe indescribable? How to create project documentation after the 10 years later from creating the project? A story about project documentation is a story about the role of a Systems Analyst in a team.

    • Average
    • 40 min
    • Analyst Days / 11
To leave a feedback you need to

Chat with us, we are online!