What are the real problems with the game “Smoot”?

The game “Troubles” is an interesting case that is difficult to pass by. They talk about it a lot, but mostly from the position of users, consumers of the final product. Let’s try to go behind the curtain and look at this product from the team’s perspective, from the point of view of project/product management, and evaluate what really worked, what didn’t work, and how this can be corrected in future projects or avoided in other teams and products.

A brief summary of the information that I managed to find out from open sources.

The Cyberia Nova company won government funding in the amount of 490 million rubles at a project competition. or 5 million dollars (but this is not certain). The project lasted 2 years. The team for the project is mostly new. Interaction with the audience began only 6 months before the planned release date. Before this, the company had not released any major games.

What was the output from the users' point of view.

In short, we took a swing at Ghost of Tsushima, and it turned out to be something like the first Witcher. If you don't pay attention to the bugs, the game turned out to be linear, without an open world (as promised), with virtually no points of interest, with an abundance of dialogue and simple, monotonous combat and leveling (all this in comparison with modern AAA games). But it should be noted that it turned out well – these are well-designed costumes and settings from a historical point of view

Now to the point

What could be the reason for the failure of the game “Smoot”? This case can be viewed both from the point of view of the immaturity of the government apparatus in terms of understanding the interaction with the IT industry, and as insufficient understanding/lack of experience of direct project managers, company managers in the development of large projects (projects with large budgets, teams and a large number of stakeholders) . But first things first.

Imagine this situation: you are an IT company developing games. There is an opportunity to participate in a competition for a state grant. You submit and win. Perhaps you didn't even expect this. Before that, you made small games with a team of 5-10 people, you were successful in your segment, but nothing more. And then a huge chance and a lot of money fall on your head. Having gathered your feelings, you prepare all the developments, present a plan, schedule deadlines, etc. And everything turned out great on paper, all the deadlines were written down, the budget was set, the team was drawn up (on paper), there was only a small matter left to do… It seems yes, but sort of not.

And then it begins The most interestingcomplex and incomprehensible for inexperienced teams.

What to do next? Then, having received an advance, you begin to assemble a large team to develop the game. According to a rough estimate, it takes 20-30 people to develop such a game in two years. This is, for example, 5 backend, 5 frontend, 2 devops, 4 testers, 2 system analysts, 1 business analyst, 1 administrator, 1 RP, 4 designers, plus consultants and scriptwriters. The team is diverse, multidirectional and most importantly NEW. Taking on an ambitious project in such a short time with a new team means taking on the risk that everything could fall apart simply because the team doesn’t work well together. This is the first problem of this entire enterprise – new team.

When forming a new team, it is necessary to understand the team's development path. Let's consider the formation of a team according to Tuckman. He identified 4 stages of team development:

1. Working group (forming) – new people, all enthusiastic, ready to work. Quite high productivity due to personal qualities

2. Pseudo-team (storming) – discord and disputes begin, due to which productivity sags

3. Potential team (norming) – everyone gets used to each other, mutual assistance and support begins. Productivity starts to rise

4. Effective team (performing) – a cohesive group, ready to stand up for each team member, always support and help, maximum efficiency

On average, it takes a year to reach maximum productivity. When planning work, it is necessary to re-calculate the calculated load by 1.5-2 times for the first year in order to understand the real development timeframe. But for some reason many people ignore this fact. Even if we recruit the most professional and experienced employees, the effectiveness of their interaction with each other in the first year will be quite low, and quite a lot of money will be spent on maintaining such a team.

Thus, firstly, we are faced with the inexperience of the project/product management in managing large projects, which is why part of the functionality that seemed possible to implement in 2 years could not be implemented. Thus, if you are taking on a large project and want to recruit a team for this project, you must take into account the low efficiency of the team in the first year of work, otherwise you will then be held accountable for all your promises.

Inexperience in large projects does not allow us to accurately determine the correct time frame for the implementation of a particular functionality.

First stage of software development – this is design (I hope it was in this project). It usually starts parallel to the team gathering. The team forms and details the requirements for the future product, describes the image of the result, and estimates the labor costs according to the agreed technical specifications (TOR). Here comes the first difficulty. When working with the state, most likely you are within the scope of the technical specifications inside and out. Technical specifications for the entire two-year product, and you are forced to follow the waterfall approach (when a complete technical specification for a product has been formed and you need to fulfill all points of the technical specification without the ability to take a step to the right or left), since 90% of government projects are geared towards this, because it is easier to work with. There is technical specification, there is a result, everything is clear and transparent. It seems yes, but it seems not quite.

The waterfall approach is good when you have a clear vision of the final result. For example, you have to build a house, you ask the state for money and say: “I will build such and such a house for so much money, here are the drawings, here are the documents.” The state gives you money, then checks whether the house really matches all the documents provided. Everything is simple and clear. And in this case there cannot be anything else. But projects in industries with the specifics of rapidly developing technologies and very high variability can and should move differently.

In this case, a product approach would be suitable, which, for some reason, the developers of “Smoot” neglected. What is the point: at each stage of development, you must have a finished product that can be given to the user in one form or another.

Typically, project development is divided into several stages:

1. Prototype

2. MVP

3. Revision (there may be several iterations)

4. Completion and release to support/service

At the end of each stage, the developers should have a finished (relatively, of course) product. After the prototype, there is a clickable layout; in this case, layouts of locations, characters, scenes, etc. are possible. After the MVP (minimum viable product) – the minimum functionality that can do at least something from the user’s point of view, in this case this is one mission, one battle scene, i.e. something that the user can do himself. The development stages already involve filling the MVP with new functionality. And after each stage there should be a playable product.

The number of stages of refinement depends on the technical specifications and on the desires of customers and the capabilities of developers.

In a classic product approach there is a backlog (list of requirements for each iteration). After each stage, the backlog is reviewed: new requirements are added, irrelevant ones are removed, each stage is paid for separately, which also reduces the risks of spending a lot of money and getting something unknown.

After each stage, the development result is transferred for testing to users, interested parties (stakeholders), i.e. presented to the public. This is all so that at each point in time it is possible to adjust the direction or correct what you didn’t like and increase user satisfaction with the future product.

Yes, within the framework of custom development for the state or a large corporation, it is difficult to maintain a flexible approach, because In any case, they pay you according to the general technical specifications for the entire product and the first thing you will pay attention to is whether this item has been fulfilled (whether it is needed or not, this, in this case, is the tenth thing).

But even in such conditions, it is possible to apply a product approach. How? It is impossible to write out the technical specifications thoroughly taking into account every nuance, therefore, within each of the requirements, you can find a certain variability and use it. For example, let's take this hypothetical requirement: “The game must have a change of day and night.” It’s a very specific requirement and, in principle, it’s clear what should happen. But there are a lot of ways to implement this: you can dynamically change the time of day so that the sun sets and the moon rises, or you can change day and night by dimming the screen. Each of these descriptions satisfies the requirements of the technical specifications. But from the point of view of user experience, the first option is preferable (naturally it is more expensive, but that’s not the point now). My point is that an experienced RP will be able to move even within the limitations of a flexible approach sitting on two chairs satisfying the requirements of both the government contract and users (for example, at the design stage, creating, for example, private technical specifications to clarify the requirements and varying them from stage to stage)

Conclusion

Judging by the resulting game, “Troubles” was made by professional developers, experts in their field. The mistakes were on the management's side. On the one hand, goal setting, strategic and tactical sense, and inexperience in creating large projects became the reason for the failed game. On the other hand, the government apparatus must also understand the realities of the industry and adapt to it by accepting the rules of the game, adopting best practices and developing new techniques.

Total, what could help make “Smut” better (from the point of view of team management):

1. Product approach to development

2. Close-knit team or allow more time for development (additional year)

3. Flexibility of public administration in financing IT projects

PS: regarding the budget of 490 million rubles in order to remove all questions. This is the normal price
a large project lasting 2 years. Let's use some simple math,
Let's take a team of 30 people, let's take the average salary of a developer 180 thousand rubles (keep in mind that
that the company spends money not only on paying the employee’s salary, but also on various
expenses associated with it: pension fund, healthcare, etc., which increases
the cost of an employee is approximately 3 times), i.e. it turns out 180 thousand330 people *
24 months = 389 million rubles. just for the content of the development team, add it here
operating costs (let's say 10%), administration costs (let's say another 10%),
costs for infrastructure (servers, etc.), the result is 470 million (maximum
roughly half a finger to the ceiling). So, from my point of view, the money went where
it is necessary, the only thing with what efficiency they were spent is another question,
but I already discussed this in the article.