how to divide tasks without conflicts

Basic knowledge of code gives the analyst a huge boost: in the speed of completing tasks, relationships with colleagues, and benefits for the client. For example, it becomes easier to assess the feasibility of clients’ “wants” and immediately voice risks. Over two years of working on implementation projects, I gained a lot of experience communicating with engineers and developers. I began to understand that there are actions that are difficult for the system: implementing a complex dependency or large scenarios where it is necessary to take many parallel steps.

However, sometimes you can get carried away and start doing the work for the developer. I have encountered situations where lack of communication with colleagues could lead not only to an unsuccessful result, but also to negative consequences for the business. So I once again confirmed for myself that it’s not for nothing that analysts are called “the connecting link.” After all, competent communication, including when dividing tasks, is necessary for effective work.

Vika Anisimova

System Analyst Naumen Service Management Platform

In this article I share three cases where knowledge of code and the lack of defined work boundaries did more harm than good, and I tell you how I fixed it. I hope my examples will help you find a balance and outline the boundaries of areas of responsibility between development and analytics.

Case 1. About the primacy of your tasks

On one project, the client had many integrations with an external system. I needed to refine existing methods and write a couple of new ones. When I was given this task, they advised me to go to another analyst on the team to find out more details.

The analyst shared that the methods that have already been implemented can be taken as an example and rewritten to suit your tasks. He wrote integration methods himself, so he explained that the task could be done independently. I studied everything that already exists, conducted experiments and eventually implemented the necessary methods.

Problem: As it turned out later, in this case it was a task for the developers 🙂 But since I had already implemented the methods, I asked the developers to only review the code. It was successful and I completed the task. Yes, I gained good experience in writing integration methods, but I had to sacrifice time and take on fewer core tasks at the moment.

Solution: Now in such situations, I do this: I always clarify what is required of me before starting to complete the task. I leave all integrations for development. This helps me free up time for other tasks, focus on creating solution models and not overwork. It’s cool to dive into new areas, but you need to do it wisely, without interfering with the tasks of other specialists.

Case 2. About the speed of work

Recently there was a case when another implementation analyst received a request for a developer – can we reset an employee’s password when logging into the system using a link. The developer immediately began to offer options, without understanding why this was needed and why there was such a need.

Problem: None of the options suited the author of the request, and the situation had already begun to develop into a conflict. Then the developer offered to connect me, since I have expertise in the platform. I read the request and did not understand why the client needs to reset the user’s password when logging in. After talking with the author of the request, I found out that the password only needs to be reset the first time you log in. The developer's options really didn't cover this case at all, as he was trying to solve the question of “how to reset the password every time I log in.”

Solution: The first thing is to clarify all the input on the task at the start. The second is to offer solutions when the client's goal is clear. In this situation, the developer wasted his time. It was the analyst’s expertise that was important here in order to offer the optimal solution.

Case 3. About understanding each other

About a month ago, I was asked to complete the fix for a feature that was not working properly — another analyst had done this before. According to him, all that was left was to write the text for a user error and hand it over to development. It turned out that in order to fix something that was not working, I would have to take away some of the working functionality from the user. This decision seemed illogical to me, so I went to talk to the developer. I was warned in advance that the conversation could be difficult. The dialogue was indeed difficult — it is always unpleasant to redo a solution, so the developer, as expected, defended the implemented solution.

Conflict: The developer does not feel the expertise of the analyst because he does not see the value in the new solution: “if the previous analyst approved the solution, then why change anything? I only need to get the user error text and complete the task.”

Solution: For the analyst and developer to understand each other, it is important to remember that you have one goal – to benefit the client. It’s also useful to be fundamentally immersed in your colleague’s activities.

In this situation, I took on the role of a validator. Since I have a basic understanding of the code, I invited the developer to jointly discuss the risks of the current solution and how they can be minimized in a new one. After my arguments, my colleague gained confidence in my expertise and we implemented the required functionality.

It’s cool to have a basic knowledge of code: be able to read it and write a simple script. Since you can speak the same language with the developer, you will be able to complete tasks more effectively and find more convenient solutions for the client. But, as my experience has shown, knowledge of code is sometimes harmful – in cases where there is no clear division of tasks. There is a risk of becoming a “one-man orchestra”—one who takes on some of the tasks and blurs the boundaries of areas of responsibility between analytics and development. Not only the quality of the result, but also communication may suffer from this.

It is useful to develop in related areas, but it should be in moderation. Expand your capabilities, but don’t spread yourself thin: don’t speculate on knowing everything and don’t violate your work boundaries, even if it seems like you can do the task yourself.