Conversation with MATEUSZ FALKOWSKI, SENIOR BUSINESS ANALYST
WHAT WAS YOUR PROFESSIONAL JOURNEY LIKE BEFORE YOU JOINED ENGINIETY?
My professional adventure began working in marketing and PR. I went through e-commerce and finally moved to the world of IT projects. As part of IT, I was an account executive, first-line support, trainer, consultant, business/system analyst and manual tester. I have had the opportunity to work in these roles for various clients. Thanks to this, I have a pretty good overview and understanding of both business and IT.
YOU HAVE A BUSINESS BACKGROUND BUT ALSO AN ENGINEERING APPROACH.
It's true. My adventure with IT started a bit later. Although, as far as I can remember, I was most interested in topics related to digital, when working in marketing. When I joined ENGINIETY, there was a lot of talk about engineering. So I started to wonder if I would fit into the team.
However, I quickly understood that it is not the title of a technical university but the way or philosophy of operation that can qualify us to be "transformation engineers". In our understanding, it is a guide in a journey called project or product development. It’s someone who needs to understand where we want to go and why we are going there and then choose the right solutions.
HOW WOULD YOU DESCRIBE YOUR ROLE IN PROJECTS?
I am a Business Analyst. Although, at present, I would describe my role more as a Solution Analyst or Product Analyst. Why? Because the way I work with teams on the client side is focused mainly on the analysis and development of the solution/product, not on analyzing business processes per se.
In practice, together with the client's IT architects, we look for the best solutions for the company, thinking about our goal to provide good quality. Of course, business assumptions are challenged continuously here and require business discussions with the Product Owner.
MUST AN EFFECTIVE ANALYST BE AGILE?
He/she must act like that and regard his/her involvement in a given project this way. I redefine my role whenever new challenges or needs arise. I will draw a mockup when needed. Examples or diagrams if the topic is more complicated. Sometimes short descriptions are enough.
For me, the game-changer for creation of comprehensible tasks and formulating requirements was to learn Gherkin-like syntax (Given-When-Then). It allowed me to catch many gaps at the stage of describing the solution.
Adapting the approach and tools to stakeholders - this is what I believe to be an agile analyst. Sometimes in a project, we will work in such an environment that you cannot move without documenting every decision. Sometimes the development team will require the most precise and detailed descriptions of the solution. Sometimes, all parties will work closely together, and such practices will only slow down the work. Therefore, an "it depends" approach to analysis is most relevant here.
BESIDES THE ABOVE-MENTIONED OPERATIONAL STUFF, WHAT IS AN ANALYST'S CONTRIBUTION TO THE PROJECT OR PRODUCT DEVELOPMENT?
I want to do my job well and help others through it. I also promote an understanding of the reasons why certain decisions are being made. And I often repeat to look for causes of why something is being done. It helps catch gaps at the early stage of creating the solution, i.e. where possible corrections cost the least.
THE ANALYSTS SEEM TO BE EXTREMELY BUSY…
There is a bit of it: we organize and conduct meetings, gather/extract requirements, write out and design proposed solutions, consult the technical team, create tasks, maintain documentation, and often manage many other side activities in the project. Analyst's work means different challenges. You have to get along with both the client and the development or testing team (internal and external). You must have a holistic approach, know what we are doing and why, and understand the technical details at the appropriate level. However, the moment you become a specialist in a given system or field brings a lot of satisfaction.
BUT IT ALSO SOUNDS LIKE A LOT OF RESPONSIBILITY.
The project's responsibility is from A to Z. Often, the analyst's work starts at the very beginning when the project's business goals are being defined. It often ends with tests and production release support as well as user training.
WHAT QUALITIES DO YOU THINK ARE KEY TO BEING A GOOD BUSINESS ANALYST?
When choosing this path, it is worth assessing both your communication and technical competences. Domain knowledge is also beneficial, but we will not always be well prepared for every industry. We learn the specificity of the client and the industry in each project. Therefore, I believe that an effective Analyst is also a person curious about the world.
AND WHAT IS DIFFICULT FOR YOU IN THE DAILY WORK OF AN ANALYST?
To observe how – despite your recommendations – a decision is made to choose a solution that you do not consider as appropriate or optimal. Or when there is a poor technical implementation in the system for which you are responsible, but you have little influence on the very technical details. It can be difficult because it's frustrating.