How we improved the work of system analysts and set up interaction in a large team
First, a little context.
Our team consists of 30+ people, including developers, testers, analysts and designers.
Reasons for difficulties
We work using flexible methodologies, which allows us to design and deliver features for development iteratively, without stopping the process.
The team is divided into subteams depending on the product they are working on. At the same time, the analyst team consists of several people. This allows for several features to be developed in parallel. But there is a nuance. Everyone works in different teams, which means there is no common understanding of what colleagues are working on and in what form they maintain technical documentation. The situation becomes more complicated with each new analyst.
So, interaction within the team became a vulnerability that held up the work.
Here are the problems we encountered:
Lack of communication within the analytics department. This made it difficult to distribute tasks depending on the workload of colleagues. Some had a ton of work, others had several small tasks.
Maintaining documentation in various formats. We work in different teams of the same product, and each analyst described the documentation as he thought was right. Therefore, it was difficult to immerse ourselves in the tasks of colleagues, we spent a lot of time changing the documentation and keeping it up to date.
There is no immersion in each other's tasks. As a result, the team does not see the full picture of the project. A high bass factor has appeared: the analyst only knows his own features, the others cannot answer questions about them.
The points of intersection of tasks are not worked out.
It was necessary to understand how to improve processes and make the work of each team member comfortable. There's nothing more daunting than introducing new processes. But the team was accommodating.
This is what we decided after discussion
Developed a template for writing and maintaining documentation
Based on the shared experience of our colleagues, we came to a template in which we preserved the golden mean between the technical and user description of the application's behavior.
Started cross-review of colleagues' artifacts
It is carried out by all analysts, regardless of their level. For example, a junior reviews a senior and vice versa. It is useful for everyone: including a senior, who, due to his experience, may miss some details.
Made communication permanent
We started to regularly synchronize on task status, blockers, problems, and solution statuses. This allows us to constantly exchange context and stay informed about each other's affairs, as well as control the workload of team members. In order not to overload the team, we hold calls once a week and change the frequency if necessary.
What are the results?
We lived in the new reality and felt the benefits. We immersed ourselves in each other's tasks and were able to easily replace colleagues during vacations or illnesses. We knew the intersection points of tasks and finally evenly distributed the workload among the team.
What if we weren't the only ones with problems?
While implementing new processes at our place, we wondered: what happens when interacting with other teams during the development process?
We organized a meeting with developers and testing and found out that there were problem areas here too. We solved most of the issues by building new processes. But some things remained:
different levels of documentation detail
the same elements can be described differently by different analysts
insufficient communication between departments
Minimizing conflicts between teams
Although we already had a template, depending on the complexity of the process, the analyst himself decided how detailed to describe the documentation.
For identical elements that are used in different places of the application, we created separate documents. They described the system's behavior. If such a component is encountered somewhere, we no longer describe it again, but provide a link to the finished document. This way we avoid contradictions in the operation of the same component.
We have set up meetings with the development team before handing over tasks. This saves time on going into details and creates a common understanding for everyone of how the described process should work.
There is no instruction or golden rule on how to build ideal processes. Depending on the project, volume of work, team and other factors, the processes will differ, and this is normal. In development, one of the key criteria that influences the quality of the product is the interaction within the team. If it is debugged, the team works productively. If it is not debugged yet, you need to look for someone who will do it.
Bonus: The ideal development team composition according to our experience
The size of the team depends on various factors: deadlines, complexity of tasks, etc. You remember our initial data: we are creating a mobile application for a bank.
The analyst is the link between all participants in the development process. According to our observations, one analyst can work in a team of eight people without compromising deadlines:
two developers per platform (if we are talking about mobile development)
tester
designer
project manager
optional – product.
If there are more designers or developers on the team, it's time to assign another analyst.
This was the team's recipe for efficiency. Clevertec. Have you encountered difficulties in team interaction? Share how you solved them.
