Oleg Tuzov, project manager of Belka Games, spoke about the experience of launching an R&D department, building processes in it, and also gave several recommendations to those who are interested in launching a similar department in the company.
Oleg Tuzov
To begin with, I will briefly share what we have achieved in three years of work in the R&D direction.
We have tested hundreds of hypotheses. We brought two of them to a softlonch, and then a full-fledged release. Both hypotheses turned into cool projects, real hits.
The firstborn is Solitaire Cruise. Last October, the project turned two years old. At the time of publication of the article, he is consistently in the top 5 of the highest-grossing tapeworms in the world.
The second project is Bermuda Adventures. We released it a year and a half ago. Now it is in the top 10 cash farms in the world.
1. Key principles of functioning of the R&D Department at Belka Games
Three years ago, when forming the R&D Department, we proceeded from the following principles:
- the development of new products within the walls of the department should not affect the development and support of existing ones;
- the development itself should be fast;
- the scale of the product takes place outside the R&D department.
2. Approach to the formation of R&D teams
Today, the R&D department consists of several teams. Each of them tests one or another hypothesis.
When forming and building the work of each team, we try to follow four rules.
A) At the start, the team should be small in composition
The initial composition of each team is eight people. With them, we start testing a new hypothesis. This way we can discuss and distribute upcoming tasks faster, and it is also so convenient to manage all areas of development. We expand only if we see the potential of the product.
B) At the start, each employee should be maximally involved in the development
At the first stages of prototyping, we expect that everyone will fully invest both in research and directly in development. Product hypotheses are discussed and implemented by all members of the department, so in fact at this stage we all have producers.
C) Teams should consist of versatile specialists ready for multitasking
Each member of the R&D team is an established Lead or Head of their direction. Everyone has their own specialization, and within its framework he is a generalist.
D) The R&D department should be ready to release the project and its employees along with it
After the softlonch, the project is given to the main department. Every R&D employee can leave with the project, and we are always ready for this. Also, every specialist in our department knows how to quickly switch between projects and not to be frustrated if it was decided to curtail work on a hypothesis.
3. Practices underlying the management of the R&D Department
When operating, we rely on a number of practices, thanks to which we minimize the number of errors and build effective operational development.
It’s about:
- building templates;
- maintaining documentation in accordance with uniform standards;
- detailed prescribing of the roadmap;
weekly sprints; - correct setting of tasks;
- mandatory follow-up-ah;
- one-to-one meetings;
- maintaining a backlog of employee ideas.
Let’s analyze each of these practices separately (at the same time I will give some tips on working with them).
3.1 Templates
For many regular processes, we prepare templates or, speaking in Russian, templates. This saves a lot of time for the manager on repetitive or similar tasks.
For example, at Belka Games we use templates, including for tasks such as:
A) Exit of a new employee
As a rule, the first tasks of all employees are the same regardless of specialization. This is an introduction to the team, documentation, and project. So why create the same tasks every time? We use one template for this with all the necessary information, which is duplicated for each new specialist.
B) Development of the same type of content
The project may have content that is developed on a single pipeline. For example, chapters or events that differ only in art. Actually, we once prepared templates with a complete list of tasks, in which, conditionally, we change Halloween for Christmas.
Tip: once every 2-3 months, run through your templates to update the information in them.
3.2 Documentation
Well-written documentation is very important for development, it makes life easier for all its participants. When working on it, we always start from clearly defined goals and recommendations. For example, when we write TK, we always rely on the following:
A) Development of the general structure of TK
All TK should have the same section structure. This is how we achieve completeness of documentation. In addition, a structured document is easier to read even at the draft stage.
B) Completeness of the TK
The developed functionality is described as concretely and fully as possible. This removes questions at the stage of discussion, decomposition, execution and testing of tasks.
C) Perception and readability
Our TOR should be written so that after reading it, any employee understands how this feature or mechanics works.
Recommendations:
- Introduce a single and end-to-end terminology and add new terms to it as they arise.
- Avoid subjunctive moods — perhaps, I would like, approximately. These are the most important enemies for the clear operation of your feature or mechanics. The feature should look like this, work like this, if necessary — here are the references.
- In the context of the document, use fixed values — hours, minutes, seconds. Not half an hour, but 30 minutes. Before the end of the promotion, not two days, but 48 hours — and so on.
- Create a template for a document on TK, where all the necessary blocks will be immediately written.
Additionally, we fix general approaches to the narrative. If there are dialogues in the project, then there should be a guide for working with them, and so on.
The Council: think carefully about the goals and recommendations for the preparation of documentation. This saves the team a lot of time and minimizes the risk of getting the wrong thing in the wrong time frame.
3.3 Roadmap
At the start of development, the roadmap is always scheduled before the first launch of the project in techlonch.
As a rule, we make a roadmap in three iterations.
In the first iteration, the project producer, the head of the department and the development director form a list of product features and KPIs.
In the second iteration, we show this plan to the employees responsible for their areas, we polish the document.
During the third iteration, we show the roadmap to the whole team. If she has no questions, then we send her to work.
Usually, in our roadmap, each version of the game has prescribed which ones it has:
- dates (when to start and when to finish work on it);
- purposes;
- key features;
- secondary features;
- improvements (art, UI, UX and so on);
- internal development tools;
- documents.
Some items, depending on the version, may not be filled in (for example, well, what improvements can the project have at the start of work?!), but they are in the template.
Tip: the development time of the first version should not exceed two to three weeks. This will keep the team in good shape.
The first version does not necessarily have to end with a technical release. The main task here is to get the reporting build.
3.4 Weekly sprints
As it is clear from the subtitle, in Belka Games the duration of the sprint is a week.
In the R&D department, we work with sprints as follows:
- PM prepares a preliminary work plan for the week based on the roadmap;
- then, on a call with the team, this plan is adjusted;
- after agreeing on the sprint, PM publishes it in the project chat;
- at the end of the week, PM summarizes the results (what was implemented, what was not done).
The sprint itself resembles the description of the version of the game from the roadmap:
- sprint dates;
- the key in the sprint (version start, release, and so on);
- what will go into the weekly build;
- what won’t go into the weekly build, but will be in the works;
- analytics;
- documentation;
- questions (for example, something you need to pay attention to,
- solve a related problem or adjust the process).
Tip: do not adjust your weekly plan if an unplanned force majeure has occurred. Remove unnecessary features, postpone deadlines, take only key decisions into the build, without secondary ones. And analyze the reasons to avoid this in the future.
3.5 Tasks
When forming tasks, we usually follow the following pattern:
A) The name of the task
It should be clear from it what needs to be done. Don’t sign for many letters — stay concise. You can also specify a priority and/or specialization.
B) Task description
In the description, as fully as possible (but without water), reveal what needs to be done. Depending on the task, attach all the necessary links — to the TOR, the dialog guide and the paths of the necessary sources. You can also give a link to a similar task as an example.
C) Task dependencies
Be sure to put all the dependencies between the tasks. So you can see clearly what you need to push into development in the first place. This helps in making a weekly plan.
D) Assay on the performer + due date
Who will be involved in the implementation and when the results are needed. If you have a large development team, then all tasks should be assigned to the lead directions. He will already distribute them among specialists and set the correct deadlines depending on the load.
E) Followers
At Belka Games, we adhere to a culture of joint decision-making, but this does not mean that each task should contain a huge list of followers and cause heated discussions on each issue.
Each task should have a compact list of followers. In most cases, you do not need to subscribe non-core specialists or the entire art department to the task — take pity on their inboxes.
F) Location of the task
The structure of the project version always repeats the structure of our roadmap. The task should always lie in its feature and in the correct section. The task of animating the bank window should not lie in the analytics section of the battle pass.
Tip: start the tasks yourself — do not throw the case to others. This will allow you to see the entire feature / version/ project.
3.6 Follow-up
Now that the majority of IT is working remotely, it is very important that the information is not left buried in Google Meet. Therefore, in our R&D we actively use the follow-up system.
When we decide on an important issue on the call, the PM fixes the key points. After that, he makes them into readable text and fumbles at all team members. This way we keep the development team in context and are at the same point on the decisions made.
As a rule, once a week PM goes through the follow-up and starts tasks for their implementation.
Tip: If you can’t take part in the call, be sure to ask the organizer to prepare a follow-up meeting for you. So you will definitely always be aware of what is happening.
3.7 One-to-one meetings
We hold one-on-one meetings with employees at least once a month. This allows you to keep abreast of the pulse of the team as a whole and monitor the moral and psychological state of each participant in the development individually.
PM has a separate document for each employee, which is opened at the meeting with him. In the document, PM duplicates useful links to the development project, the production calendar of the employee’s country, and so on. The employee’s KPIs, current issues that he needed to solve by the meeting, and an archive of already resolved issues are immediately prescribed.
Tip: meetings are recommended to be held at the beginning of each month. The best books on their implementation: “Feedback in Business” by Angela Lane, “All bosses do It” by Bruce Tulgan and “High-performance Management” by Andrew Grove.
3.8 Backlog and employee ideas
At the beginning of the article, I mentioned that we need the maximum involvement of each employee. And the backlog of ideas helps us a lot in this. We have a workspace in R&D where everyone can fix their ideas on the current product or any other.
So the guys understand that their ideas are important, and they themselves participate in the life and development of both the project and the department. Plus, we can always refer to the document when we need features for implementation.
4. Conclusion
In the R&D department of Belka Games, we believe that the main responsibility for the result falls on the shoulders of the PM. Accordingly, development errors are a flaw in the first place, too, it is PM.
Naturally, no one is immune from mistakes. So one of the main tasks for PM is to minimize them. Only in this case it is possible to replace the team to get a successful product.
Minimizing errors implies: competent configuration of processes that are transparent and not overcomplicated, as well as a well-chosen team.