Тестировщик, перешедший на сторону бизнес-анализа. Люблю коммуникации во всех их проявлениях, новые предметные области и понятную документацию.
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
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.
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.
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.
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.
How we specified a project with UML
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.