If the customer is a revision

My colleague Zaur spoke about the development of a project to restart a media publication . I want to talk about the features of the manager on such a project.

Since 2007 I have been working as a project. She worked at Lebedev Studio, Articul Media Group, and worked mainly with large companies (TNK-BP, Euroset, VTB, Samsung, OCOG Sochi 2014). I didn’t have experience of working with media until May 2012, when I came to Lentu.ru and got into the midst of a project to restart. New Tape opened in January 2013. In March 2014, after the dismissal of the chief editor, we moved to Vedomosti, where we are now preparing to restart.

Below I will highlight the most important points that I encountered when working with editors who acted as customers.

TK will not be

The development specification in its classical form (volumetric, non-redundant, but exhaustive) either will not exist at all, or it will be used solely as a cup holder. This happens because for the preparation of the TZ, which can be a full-fledged working tool for the customer and the performer, it takes time and participation of both parties.
')
When the customer is the editors, he has no time to read, edit, and painfully long to discuss the weighty TK. In the 24/7 newsletter, editors have something to read and pee without. And even if there is still a thick TK, you will have so many changes in the course of the project that it will quickly lose its relevance and become useless.

But even without documentation you can not do. In Lenta, I recorded all the results of oral discussions in the file - “log” in the following format: the question was this, discussed then, decided to do this. Next is a history of discussions / changes.

In parallel, the tasks were spoken with the developers and recorded in the task manager. This allowed not to lose sight of the issues that were mentioned briefly and have not yet received a final decision. Now in Vedomosti I use the same log file format for documentation concerning the editorial block, I keep it in the wiki on GitHub. After launching from these logs I will compile a description of the final version of the system so that it can be used as a reference.

Communication with project participants

Most likely, most of the communication will be oral and sudden, and new members may appear in the working group at any time. There will be no task exchange in the task manager. There will be no obligatory confirmations of the results of meetings in the mail and in time for beginning meetings.

The reason is the same - the customer has 24/7 news, anything can happen anytime. With such communication, the likelihood that one of the project participants knows one thing, and another - the other is extremely high. Therefore, it is logical to direct our efforts to the “synchronization” of all participants in the process.

I do this by writing a follow-up to the oral discussions, by writing to a file-log, but I just go over something and say something. One way or another I choose depending on the importance of the issue under discussion. If the question is fundamentally important - of course, this is a letter. And if a trifle - you can just come up and say, so as not to overwhelm people with letters that they have no time to read. An ordinary customer, for his part, has a manager who organizes communication, acknowledges receipt of letters, etc., etc. But the editorial board does not have one. With this you just have to accept. And do not be editors to torment all these "correct" managerial techniques - it only hurts the cause.

Common denominator and balance

In my deepest conviction, one of the important functions of the project is to find a “common denominator” between the “too human” thinking of the customer (the editorial staff in our case) and the too schematic thinking of the programmers. Zaur gave an example: a normal person sees no difficulty in moving from a one-to-one connection to a one-to-many connection. More specifically, a normal person does not see this transition at all. A programmer like this does not come to mind.



In each such case, when the customer wants something, from which the programmer has hair on his head, it is necessary to understand separately. Sometime the tasks of the editorial board are outweighed and then you have to be ready to throw out a part of the finished work, and completely redo the other part. Once the developers were right: the implementation of the editorial "hotelok" in a week would put all the forks in the side. And then the editorial office must abandon such "hotelok."
What does this mean for a manager? For the manager, this means that: a) it is necessary to delve into the semantic and technical aspects of the task, always; b) find a common denominator; c) maintain a balance between editorial desires and convenience and correctness of development; d) be able to explain why it is impossible to do something, but something must be done. When working with the editors acting as a customer, this is especially important, since the editors have a lot of different desires. About this - further.

“Let's do this one button there”

On projects that live from a month to a year and do not have a large archive, you usually do not encounter the “charms” of the so-called “patchwork automation”. Or "charms" just do not have time to appear. But they are shown with might and main on projects that have been living for 5 years or more and on which there is a huge archive.

What does this mean for a manager? For the manager, this means that in the future we will have to spend the time of developers on fixing the sudden crutches. They will come out, most likely at the most inopportune moment. And this time - expenses, expenses not on the production of something valuable, but on patching up holes, which they themselves dig. It is necessary to understand and explain the risks to the customer every time you are asked to do something like this.

It is equally important to keep this in mind when you discuss the possible implementation of a particular task with the developers. Not all developers are equally farsighted, and sometimes they agree to make a crutch "if only everyone is settled there." In the long term, this approach will give everyone a lot of problems. There is a risk that you will have a monstrous and voracious design, which will require more and more people to support. The developers, instead of creating new things and developing, will sit, clap their hands on crutches, and, most unpleasantly, be bored. And you will understand that everything seems to be filled with tasks, they work, they do, they do, but ... they haven’t done anything.

This situation, to put it mildly, is not new, but it is not found only in work with editors. But in working with the editors, it is exacerbated by the fact that the technical department in the publication is the service department, so it does not have the opportunity to grow.

Programmer with a human face

The ability to see the problem from the side of the simple user, and not from the side of the “logs” is especially important if you work with the editors. Drip the developer on the brain, explain, convince that if the editor has a problem and he complains (and you checked and the problem does exist) - then the problem is real, it needs to be solved, even if everything is OK in the logs. In addition, sometimes the developer is useful to talk with the editor directly.

The manager needs to carry out regular “educational” work with the team so that developers do not dig in the code, ignoring the end user (both the editor and the reader). The code is valuable only when the user is satisfied.

Habit to do manuals

To solve questions arising from the editorial, in addition to human programmers, you will need manuals. It is necessary to learn how to write them, taking it as a rule. Made a new functionality - updated manual. The more editors of night / remote editors, the more necessary at some point is simply to give a link to an article in the wiki, for example. It does not matter in what format the manual — a screenshot with arrows, a text or a screencast, the main thing is to make it clear. I started practicing writing manuals for admin functions in Lenta, but did not bring it to constant practice. We realize our plans in Vedomosti.

Total

When working with the editors and other divisions of the publication (in Vedomosti, it is also a commercial unit for working with subscriptions), you have to do a lot of things, which, in theory, the manager does not seem to do. It is necessary to write manuals, draw diagrams of business processes, soothe outraged people by phone, and so on and so forth. All this is because the technical department of the publication is small, and you will not have an army from the designer, technical writer, business analyst and technical support operator. And the functions of these people in some extent need to perform.

If the customer is an editorial, many standard processes (development of the TOR, for example) will take place differently, and the stages of the project will be in a different sequence (for example, they will design the project first and then, based on the design, the project structure). Or do not occur at all. And this is normal and good, and the output gives even better results than you could imagine.

The fact is that the editors are an incredibly motivated customer, they really need everything, and if they like the result, no management will “wrap”, and the chief editor will break through his decision. This allows you to get a cool product, and not get bogged down in the approvals and edits of timid managers at various levels.