What mistakes an analyst makes in the first six months of work and how to avoid them

Heidi ho, Kyle!

My name is Diana and I am a Business Analyst at Surf. Last year I completed my Bachelor’s degree in Computer Science at VSU: this gave me basic theoretical knowledge. However, the theory is not very applicable without practice: now I am bumping into real projects.

I have come to you to share the experience that I received on my first combat project. We made a mobile banking application with a complex architecture and a bunch of features.

It is always interesting to listen (or read, in our case) about the mistakes of others, but besides this, the article can help novice and future analysts not jump on someone else’s rake. After all, if you figure out how to interact with customers and colleagues, you can avoid misunderstandings and difficulties in future development and successfully lead the project.

Buckle up tight: we are starting an exciting journey through the world of mistakes of a novice analyst (all the tricks were performed by professional stuntmen, do not repeat at home).

Don’t be afraid to ask more questions and ask for clarifications

My experience shows that when you conduct high-level analytics, it is impossible to take into account all the key points – that’s why it is high-level. Understanding the feature and its implementation occurs gradually, as you immerse yourself in the analysis process. At first, it is difficult to determine what is worth paying special attention to, and to isolate the important among the large amount of information that is thrown to you from all sides. This will ultimately affect development time and labor.

It is better to ask more questions than to miss something. For example, when working on a project, it is important to clarify:

• On which side will the logic be implemented: front, middleware, back?

• How to determine the desired state of an element? How and where to get and process the required parameters?

• An approximate design mockup, because it clearly shows what exactly needs to be implemented, it is easier to perceive the requirements.

• Do these requirements relate to your side, or will no modifications be required from you?

Before transferring information to the developers, you need to make sure that you and the client understand each other: discussed all the key points and figured out what the client wants to get at the end.

Check and double-check the fulfillment of agreements

When a large number of people participate in the process of developing a feature, this at least means that it will not be easy for the parties to agree. It also means that it will be difficult to keep track of all the requirements and agreements.

For example, on my project, project managers and business analysts from the front and back teams, product owners and testers from the customer’s side can participate in the discussion of new functionality.

We usually discuss tasks in correspondence or at online meetings. It is easy to understand that on a call of 20 people it is easy to miss an assignment. Therefore, I am writing down the basic information that was discussed during the call. After that I duplicate the requirements in printed form and ask my colleagues for confirmation to make sure I haven’t missed anything. In addition, written agreements guarantee that the customer cannot change shoes and change requirements if desired.

Then I monitor the implementation of these instructions: periodically (depending on how the feature is on) I check with the performers the status of readiness and kick them as needed.

Feel free to be persistent and even annoying, sometimes you and the project manager are the only ones who can influence the fact that the agreements are completed on time. If you see that there are no answers at the agreed time, do not hesitate to ping your colleagues. Otherwise, the wait can be very long.

Before you give the feature the green light, step on the gas and release it into production, check if there is an unfulfilled requirement going along the pedestrian crossing, which will then stall your development. It may seem like a trifle, but believe me, such things are better not to be missed.

Real life example

We developed a feature that, when a certain condition was met, displayed a button on the main screen. When we discussed the implementation, we decided that the condition will be checked on the backend, and the front will receive a field with a sign of the fulfillment or non-fulfillment of this condition.

I did not focus the attention of the backend and the product owner on how important it is for the backend to send us this sign. When the feature was about to go into development, there was still no trace of this sign, because neither the backing service nor the third-party service, whose API we accessed, developed it.

Because of this, the process was delayed by another week, because a lot of time had to be spent on re-discussion. As a result, we decided to always display the button 🙂

Don’t be like me – draw the attention of colleagues to the key points necessary for implementation.

Clarify how to make it easier

It happens that a business analyst finds it convenient to implement a feature. He offers it to the developer, and in response he receives: “Che is difficult, can we do it differently?” This is normal: the views of the analyst and the developer on the implementation of a feature can be strikingly different: the developer realizes that they want to suck something complicated and confusing to him, and goes to rejection.

If a business analyst lacks the experience to assess how difficult an implementation option is, it is best to go straight to the developers and consult with them. Otherwise, then you will have to go through a new circle of hell: discuss changes. In addition, it can shift the implementation timeline: there is no need to explain why this is bad 🙂

Friendly reminder

If the question arises on which side the complex logic related to comparisons, calculations, sorting, and so on should be implemented, it is almost always more logical to put it on the back. Remember my advice and repeat it like a mantra on all calls (and before bed).

Be alert to potentially problematic requirements

If, at the stage of high-level analytics, a chuika whispers to you that requirements can grow from a small task for the day into a large and clumsy feature, do not ignore these signals and do not let everything go on the brakes, they say, we will break through. Usually I make a long list of questions to the customer and to the back-end according to the requirements, where I write if I understood the wording correctly.

Check (if necessary, several times) if you understood correctly that your task is simply to add a picture of a cat to the screen. It may turn out that you need to add a Cheshire cat, and he should also smile at the moment when you blink. I specifically gave an exaggerated example.

And here is an example from life. Recently, we were running two features in parallel from different product owners. The features were partially interconnected, but the requirements in many places were conflicting. Each product saw the UI in its own way: it was quite difficult to agree. Then I had to “knock their heads together.” After that, we finally came up with an option that suits everyone.

It is important to be on the lookout and check if the new requirements are in conflict with the already implemented functionality.

Remember that there are many requirements that may not be visible to the untrained eye under the water column from a requirements document. The good news: the more experienced a business analyst becomes, the more potential problem areas he sees and the more thoroughly he torments the customer with questions and clarifications. Therefore – take a deep breath and be patient! The further is better.

How to determine that you are facing a werewolf task that can turn from human to wild? By the number of misunderstandings. Watch out if:

• There is no exact information on how to process values, how and where they will be calculated, how to substitute and display them.

• Flow initialization and transition between screens are not obvious.

• There is no clear understanding of the logic.

For example, a few months ago we started discussing a feature with no specific requirements. The product owner did not have a clear understanding of what should be the result. It cost us many hours of phone calls and discussions and redrawn TK several times.

It works the other way too. Sometimes the task is described so confusingly that it seems as if the development will take a lot of time. However, if you find out the details, it may turn out that you do not need any modifications at all, and the requirements do not apply to you at all. This is due to the fact that the customer himself does not fully understand the development process.

Example

Requirements arrive: you need to determine the value of the field by the parameters that will come from the server. The field value should be displayed in the interface.

When we start discussing the problem, it turns out that the parameters will be sent to the middleware layer, the definition of the value does not concern us, and the field display in the interface remains the same.

To avoid such misunderstandings, try to find out as much as possible the flow and the effect of this task on you specifically.

_______

I have described only a small part of the mistakes that a beginning business analyst can face. You still have to make many mistakes yourself anyway. However, I tried to describe in more detail the processes of interaction and communication in a real project. Hopefully this will help you integrate more easily into the project.

That’s it, my little hobbits. I shared my wisdom with you, now you are on your own. Don’t drift, don’t get lost, be persistent and attentive. Good luck!