Development Management vs Community Project


    This material is inspired by discussions on various specialized resources of the topic - how should production managers behave with their community. On the basis of a long reflection on everything said, this article was born, i.e. quite spontaneously. As always, a small remark. The article does not pretend to any manual on the "how to do it right." Also, the material in no way affects the importance, need and usefulness of PR managers, community managers, etc. And especially not trying to teach them something. Employees on a regular basis involved in the information background and community will be needed anytime, anywhere. Without them, I believe, the development ecosystem is inferior and it is very sad when people try to plug this hole with unprofessional personnel, and "over there with that free junior programmer." But more on that later


    ... Or a little about "why does he even tell us something."
    The item is very important, because often we have a sad situation when a speaker or just an orator shakes his menacingly, talks about how to live, work and in general ... and everything would be fine until you start checking - and on the basis of what experience it is all voiced. Very often - without any basis. Clever thoughts without practical experience, of course, are found in the vast, but they are usually flavored with too much of idealism.

    During my work in the gaming industry, which I love in every way, I had to go to different roles. I wrote reviews of one quality or another (readers, our chief judges, it seems to me, but at least tolerable), was engaged in a community of well-known and not very projects (I want to believe that it was my work that made of unknowns - well-known, but it’s not quite true) and over time began to move towards development by the standard very unpretentious way - assistant to the State Duma, State Duma, co-production, production, etc. Not because it’s better, it’s just different and it’s closer to me in terms of mind and character. We won’t go into transfers - anyone who is interested will find a profile both here and on other resources and will decide for themselves whether to listen to my words or not)

    One way or another, this transition across different areas of the game dev gave an interesting idea of ​​how colleagues and managers give themselves to the players, what methods are correct, effective and useful, and what only damages their reputation ... Let's try to figure out, or rather even discuss a series of observations and approaches to this matter.

    Approach 1. Harsh Reality

    There is an old practice - do not show players until the hour of "X". Community managers rush about their offices, try to take away some kind of art, God forbid, screenshots and come up with everything they can in order to show the audience something tangible. This approach, when the “angry producer of the publisher” without 3 seals and 7 signatures does not allow to disseminate at least some information about the project, is slowly becoming obsolete, but is still inherent in some teams.

    The question of positioning the project in front of audiences came up once again quite recently - at the very early stages of the development of Metal War Online (this is 4 months with an average team of 5-6 people). Then we launched the first version of the site and a small, if not mistaken, not even a skinned forum, and also sent out press releases to well-known / friendly resources. Some users logged in and left, some (many) logged off. In the bottom line, a certain backbone has formed, which will surely remain faithful to the project for a very long time, if due respect for its enthusiasm is shown. At first, we entertained a small but active audience with a bunch of renderings, fake screens, illustrations, etc. with the message "this is how the development process goes." It lasted until

    We crumpled for some time, but then came to the conclusion - it is better to show the players everything as it is, i.e. to immerse them in the harsh reality of the earliest stages of development, and no matter how risky it is to get feedback right away. The very next day, we accepted the players in the current version at that time (between the prototype and early alpha). The functionality was truly modest. For example, you could choose only one of 3 ready-made machines. There was no pumping yet, so there were, for example, three identical Asukas with different towers in the car bar, so that users could compare with which weapon it was more convenient for them to fight.

    It is clear that the interface was not even outlined - but simply a mock-up, sketched out of the bluish dice left after our test project on Unity3D - “Carrier”.

    Fig. 1. Progress interfaces.

    Effects, scene tuning, and left-wing design were also only on RC builds, so I had to ride among the semi-built city level, which, even according to earlier ideas, was balanced for 32 players, subsequently rebalanced to 24, and now it’s completely under reconstruction due to a change battle dynamics ...

    Fig.2. While players were rolling around the open spaces depicted in Fig. 2, work on such settings was going on in the builds of individual employees.

    We let about 60 people into this version of the game. With a stretch, this solution can be called the formation of test groups, but in truth at that time the work and problems were so obvious that there was no special need for testing a large number of unprepared players. Here, it took a long and corrosive time to “pick up” many aspects and systems, so 100 bug reports about a badly standing button would most likely simply distract us .... And if there were doubts about the importance of mass tests at that stage, then these first players turned out to be a big part in shaping the culture of testers, painstakingly arranging topics correctly, grouping similar bugs with tags, etc. Almost all of the first skeleton that got into the game almost by accident are currently alive and extremely active. Then we added a bunch of people almost every month, until after 3 months the more official classic Closed Alpha Tests, Open Alpha Test, ZBT, and finally, more recently, MBT, started. The essence of this text is not in trying to impress someone with numbers, there is nothing to impress, of course, because early to judge the product as a whole ... the importance of thought in another -almost everyone who was ready to wait for the project, but did not understand what exactly to wait for him, was able to go in and see everything - both promising and extremely unsightly . The dropout rate for all the time of such sets in private is minimal, and the loyalty of the players is extremely high. Separately convenient feature - players see the entire progress of the project and give their assessment of what is happening, starting from “you didn’t show the new scene settings so much, but the result wasn’t worth it” or “why didn’t you switch to this style of UI before, now I realized that I didn’t like it in the past. ”

    It can be argued that such feedbacks are not important, one can insist that they should be carried out by unknown focus groups or colleagues. But in reality, you will get the best feedback from people who are interested in the product, not the payment or beer for the service.As soon as the developers themselves the look is usually blurred, and the colleagues in the workshop do not always bring constructive ideas (tested using the same example), your players remain, horrified.

    Why show something obviously doomed to criticism? Well, for example, in order to unexpectedly receive not crushing comments at all, but quite a distinctive construct from Central Asia, to immediately establish contact with her and her future replenishment. Well, if neither the first nor the second comes out at all - maybe it's time to think about the appropriateness of all further development and change something in time?

    Approach 2. Facing the audience

    Once upon a time I worked on one long-term construction of the domestic industry, at that time in the role of a PR manager. I found the whole “movement” many years after its inception, and in terms of working with the audience - in a very poor state. There were several problems:

    • there was no qualified or simply diligent community manager accountable to the management of the studio. There was a fan who seemed to be actively responding to certain questions of certain users of certain resources;
    • The studio managers themselves in every possible way refused to communicate with users. Both from a simple one (apparently due to laziness and a little pathos), and a very branded one, such as interviews and other stories about past saxies-stories;
    • to questions about how the work with the audience is going at all - they nodded to the publisher who knows best, and if nothing is done, then just do nothing and do not need to. The options that the publisher is busy with dozens of projects and physically does not have time to follow everything are somehow not even considered;
    • the general policy of communication was in every way adjusted to “only apologies, only convincing someone on the Internet of wrong” ....

    The result at the time of the start of the work, the state of the community was very sad. There were a lot of fans, but they hid their interviews many years ago and wrote to the official mail, which we all know, as most read. The time of my colleagues at that time was really not enough to cover all resources, topics, etc. related to the project. Everything would be fine, but for the sake of scope, ordinary employees were strictly forbidden to show any activity on any resources, try to communicate with the audience even informally, and even more so to show something. It is probably impossible to imagine a greater information vacuum bordering on open sabotage ....

    Several conclusions could be drawn from this situation, its consequences, and the heavy long search for solutions. Which, it seems to me, is easier to follow and simply not bring the situation to critical.

    Conclusion 1. Give personal (!) Time to your customers.

    It doesn't matter if you have a person in charge of the community or not. If you are working on a project as a small team (even within the framework of a large company), then devote personal time to your clients who you are expecting money from - start at least one closed topic in the forum on your own behalf, in which you inform the latest from the front once every couple of weeks (fig. 3). This will show, if not a bridge between developers and players, then openness to dialogue ... why openness is so limited, everyone will think for himself or ask the community manager. An experienced CM competently substantiates the rare occurrences of “those who have power” and wraps it to the benefit of both those who have it and the project as a whole.

    Fig. 3. Excerpt from the forum with a fairly simple, requiring 10 minutes a week topic “Brief notes of developers”

    Conclusion 2. Reduce the number of excuses

    ... especially in the style of “yes, what can we talk about now, write code, draw pictures”. There is always something to talk about, unless you are sitting at a gambling table in Vegas, trying to increase the development budget recently issued by the investor ... and even then you can wrap up in a great topic for the forum about the leisure of developers who came out for a week's rest after completing a large layer of work. In this case, it’s very convenient to immediately see the layer of work and demonstrate that the players can see that there are people on the other side who need rest after a job well done.

    Conclusion 3. Always show the progress of work

    We all want to show players thousands of great, perfectly licked pictures. Because Few people can provide such a flow of high-tech promotional art, many take the decisive step - do not show anything at all ... It’s much better to look at all the sketches, sketches and rejected handwritings, put them in order and put them into the so-called “work on ...” topics .

    Fig. 4

    At the same forum and VK group MV there are a lot of themes and albums with various stages of work on cars, arenas, guns. We don’t see anything shameful in showing the players which way we went in working on the interfaces, telling us what the difficulties were and why it is better than before, but not as cool as we would like ... Players see what mistakes we made, understand why Now they have what they have, and they believe that if we promise high-quality processing, we will do it once we have done it many times before. The example is relevant for many projects that I had to work with, Metal War is only the most urgent of them at the moment. Your KM personally may not provide such contact with the audience, because it’s not he who forms your plans and evaluates that the team will master and what not.

    Conclusion 4. Try to give clear and most specific answers.

    Many sin with the desire to answer any player’s request as soon as possible “it will be sure, but we don’t know soon / for sure”. And what’s even worse - rushing from side to side, when different players begin to respond differently about, for example, the proposed feature. If you are a production manager to one degree or another (and it’s only about them), then it’s very sinful for you not to know immediate plans for the development of the project, to give lengthy statements and try to please everyone. You are the personification of that same “king-father” who does not know about the riots and if he has come, he will clear everything up, clear everything out ... it’s better to have a clear position and convey it to the players than to rush about in search of a middle ground. As soon as the players notice your insecurity, they themselves will pick it up.In the eyes of your consumers, a team should be the team that almost certainly knows which is better, but listens to various “power fluctuations” and can timely correct the vector of work. They should cheer for you like your favorite football club and forgive minor failures, because you are about to crave a megavina, and even with the active participation of the community ....

    Conclusion 5. Show that the team also consists of living people

    Try to pull on internal resources (of. Forum, of. Group on VK) - artists, game designers, programmers. Let the game designer listen and discuss the planned balance changes with the players. Let the programmer hear everything about the physical model he implemented.
    It is important not to get carried away and not to let things go by themselves. More importantly, do not begin to replace KMov with production employees (more on this below). Developers, whether ordinary or not, must adhere to some basic rules, as well as roughly understand what they can tell the players about and not. The list of prohibitions in our teams is minimal, I would say it’s even simply absent, because Teams have repeatedly shown their adequacy and understanding of the ultimate goal - to make an interesting product for this audience. The ultimate goal of the entire business, of course, is different, but they are usually closely related ...

    Why is this item listed in the article about leadership approach? Yes, just an ordinary KM will not force / motivate your gamediz to go to the forum and really talk with the players. He can offer this, and he will be right, but only the head can allocate time for an employee, especially on some regular basis. In the end - who should be responsible for possible drawdowns according to work plans.

    Conclusion 6. Do not step aside from personal communication

    To be more precise, there will always be sensible and adequate people among the players who want to at least have the opportunity to speak directly with you. At least in the “Estonian chat” mode, but personally. You do not need to carefully hide your contacts or start separate workers, through whom at least your most devoted users can reach you.

    Moreover, try to integrate at least small meetings for discussion into the life of the community. NOT mega parties on holidays, not birthdays of projects and striptease at exhibitions - this is indisputably necessary and very cool, but outside the scope of the topic of the article. It's about much simpler things - select delegates from different user groups and make a Skype conference with them. For example, at Metal War we made such a call with a number of employees after the holidays for a couple of hours. We discussed plans, results of the year and simply congratulated each other “face to face”. You will spend no more than an hour or two a month on such things, but the benefits of such established contact cannot be overestimated.

    If simple, the moral is this - players should be able to at least occasionally raise the issue at the highest level. This will immediately prevent a bunch of small foci of conflict on the forum and other resources. Users should know, even be sure that what is happening is somehow monitored by a lot of leadership and will not allow a mess.

    Approach 3. Communication on external resources.

    Of particular interest are external game resources. Often their manager can be skipped. But if the discussion of the product is still important, then you should become interested in the quality of the dialogue and, possibly, take a personal part in it. Moreover, for some resources this is generally the most effective way, otherwise the conversation runs the risk of quickly becoming a farce with the participation of a dozen or two local trolls - patrons.

    Here you can give long examples and stories from life, but I think everyone understands perfectly well that for any project there is a resource on which they love and wait, and there are those where each news is perceived as a reason for an aggressive discourse. Working with the mood of the audience on such a scale is already more in the competence of professional PR managers. We can distinguish several theses that will be useful to PMs, producers and others like them.

    Thesis 1. You are not here to convince anyone

    Users of many forums are accustomed to guys and girls sent to them to be torn to pieces in an attempt to tell the world about some cool project. The charter is simple: if someone does not believe - you need to convince. If someone does not believe in such a way that he is rude and insulting, one must remain silent, smile and convince again. In theory, this tactic ends with the conviction of an inveterate troll or a nervous breakdown of an unprepared KMa for battle. The probability of the first is extremely low ...

    There is some truth in this approach - yes, you shouldn’t be rude to customers, even if they show the height of inadequacy, and you are the boss of all development. But it’s absolutely worthwhile to say goodbye to the tactics of instructing everyone on the true path and present each opponent as a potential client. The manager’s most effective behavior is to conduct a neutral conversation in general, and respond to criticism with a neutral one, “thanks for your opinion, time will tell”. NO, of course, this is not a universal phrase to reassure activists of the forum. But here the standard template will work - “you are here working out the bread, here and convince me. Not that .... " The trick is that you are not here to convince anyone of anything, not to try to tell why a similar project is bad(this is generally a way out to where) and not even for working off bread. You are here for dialogue - banal, general information. For your own pleasure, if you will. Your project is as it is, you don’t ask for money in advance, you don’t sell a pig in a poke (that is, an unknown game on the disk), you didn’t take players to develop money, etc. Oddly enough, when a forum member realizes that its negative impact is minimal - they will either leave the topic, trying to keep the last word, or disperse completely without borders, after which the administration will cover him for this hyperactivity.

    Thesis 2. A good producer, an evil producer

    Try to avoid what players consider “mood swings.” If you are strict and formal, then follow this style to the end. You don’t have to throw an apology for the mistake and in a minute run into the players with the words that you’re not enough for everything and you have to go into the situation altogether and "get it first". If you really want to play the trick with the good and the bad - communicate on the forum together with KM, choosing one of the roles. As soon as the players feel that it’s easy to break you down to the side of defense, to make you apologize for non-existent damage (your unsuccessful free shit game with anal donate - parry) - you can consider the communication business a failed ... ...

    Thesis 3. The better we are

    Favorite conversations of any forum - “And what are you better than the project X came from company Y?”. My sincere opinion is that there is one right answer to this question, especially from the manager - “by nothing, we are doing a bias on ....”. Especially if your project is still under development. And simply - whatever you think about the product of your colleagues, express your loyalty. The best way to lead the conversation into an uncontrolled channel is to start swinging apart the flight of "competitors" on an external resource, where there will certainly be more than one fan of this project. Nobody has canceled the elementary ethics either - be neutral with respect to the work of your colleagues in the workshop, but if you don’t understand the difficult way of development.
    This thesis has little to do with internal resources, because within them, the dialogue can have a completely constructive connotation - comparisons, improvements, exchange of impressions, etc.

    Approach 3. Who is more free with us?

    As mentioned above, the problem of many managers is an attempt to smear themselves under the "communication of developers with the community." This is expressed in the fact that they do not hire normal PR and Community managers, but they send someone a thread that is not very busy "talking with guys" ... it seems that the representative of the developer, who is aware of everything, also saved money, it’s fresh and useful. It sounds crazy, it works even worse, but it is too common not to mention. Usually, the junior assistant to the senior deputy chief programmer is sent to this execution, as “He has little to do and in general” ... if your developers have little to do - maybe they just aren't needed?

    The result of such a dialogue is often awkward contradictory statements, the absence of any planning, etc. Sometimes, very rarely, the chosen one of the team manages to grab and hold the attention of the audience, but more often an intermediate person is obtained who is too small to “inside”, too “big” to sushyusaksya-indulge with each and really knows too little and has too little experience to bustle in conversations about the plans and aspirations of the team.
    The problems of the approach are also that it is not enough just to palm someone off and hope that you show your proximity to the people, while for some reason you don’t want to see and hear them yourself (otherwise why find intermediaries). The players are by no means stupid and the impostor will figure out quickly enough ...

    Frankly, only one conclusion can be drawn from this situation - nTake KMa, or act as the face of the team. Moreover, saying “hire”, it’s not necessarily about a mega professional with a big salary. To get started, just select one or two of the most appropriate active users and spend N-time on their briefing and monitoring. It cannot be otherwise - either N time or M money. Cunningly, fast and free almost does not work.

    What's next

    Suppose an experienced or not-so-very manager has supplemented his idea of ​​working with an audience with some thoughts from the material above. What next? Everything is set up and will work like a clock? Of course not. If you pay attention, the material is divided into several completely independent blocks with a set of observations. In fact, of course there are much more of them, but the material does not pretend to be a scientific work and does not bear the role of discoverer of some truths. Rather, the above is such a set of reminders, the essence of which everyone knew and applied, but may not be brought together. And what I would like to emphasize once again - do not confuse the communication of the development management with its audience, and the presence of regular, at least responsible for working with the community of people. It is unlikely that your activity and enthusiasm will cover all the necessary aspects of interaction with the players. And this is, in a sense, the service of your product, according to which customers build an idea of ​​what to expect in the future. If you immediately leave a bad impression (slow response, rudeness, inability to resolve any issues, etc.) - then they will leave you, as well as from poor service. And it’s a completely different matter when users see the efforts of the team, the activity of KMs and PR managers, and especially nice - the personal participation of the leadership in the life of the community. We really hope that the material, if it did not reflect the importance of the last component, at least made you think about it. And whether to follow the advice given above or not - everyone will decide for himself. the inability to resolve any issues, etc.) - then they will leave you, as well as from poor service. And it’s a completely different matter when users see the efforts of the team, the activity of KMs and PR managers, and especially nice - the personal participation of the leadership in the life of the community. We really hope that the material, if it did not reflect the importance of the last component, at least made you think about it. And whether to follow the advice given above or not - everyone will decide for himself. the inability to resolve any issues, etc.) - then they will leave you, as well as from poor service. And it’s a completely different matter when users see the efforts of the team, the activity of KMs and PR managers, and especially nice - the personal participation of the leadership in the life of the community. We really hope that the material, if it did not reflect the importance of the last component, at least made you think about it. And whether to follow the advice given above or not - everyone will decide for himself.

    Also popular now: