If the customer is the editors

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

Since 2007 I have been working as a project. Worked at Lebedev Studio, Articul Media Group, worked mainly with large companies (TNK-BP, Euroset, VTB, Samsung, OKOI Sochi-2014). I did not have experience with the media until May 2012, when I came to Lenta.ru and was in the midst of a restart project. A 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 a restart.

Below I will outline the most important points that I encountered while working with editorial offices that acted as a customer.

TK will not be

TK for development in its classic form (volumetric, redundant, but exhaustive) will either not exist at all, or it will be used exclusively as a stand for the mug. This happens because compiling a statement of work, which can be a full-fledged working tool for a customer and an executor, requires time and participation of both parties.

When the customer is the editorial office, he has no time to read, edit and painfully discuss the weighty TK. In the 24/7 news publication, editors have something to read and pee without. And even if you have a thick TK, so many changes will occur during the project that it will quickly lose its relevance and become useless.

But you can’t do without documentation at all. In the Tape, I recorded all the results of oral discussions in a file - “log” in the following format: the question is such and such, discussed then and then, decided to do so and so. Next is the discussion / change history.

In parallel, tasks were talked out with developers and fixed in the task manager. This made it possible not to lose sight of the issues that were briefly touched upon and have not yet received a final solution. Now in Vedomosti I use the same format of the log file for documentation regarding the editorial unit, I bring it to the wiki on GitHub. After starting from these logs I will make 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 verbal and sudden, and new participants may appear in the working group at any time. Task manager will not exchange tasks. There will be no mandatory confirmation of the results of meetings in the mail and at the time of starting meetings.

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

I do this by letters following the results of oral discussions, by recording in a log file, but about something I just come up and speak. I choose this or that method depending on the significance of the issue under discussion. If the question is fundamentally important - of course, this letter. And if it’s a trifle, you can simply come up and say so as not to flood people with letters that they have no time to read. An ordinary customer, for his part, has a manager who organizes communication, confirms receipt of letters, etc., etc. But the editorial office does not have it. You just have to put up with it. And do not torment editors with all these "right" managerial techniques - this will only do harm.

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 editors in our case) and the too schematic thinking of programmers. Zaur gave an example: a normal person does not see difficulty in moving from a one-to-one relationship to a one-to-many relationship. And more precisely, a normal person does not see this transition at all. A programmer would never think of such a thing.



In each such case, when the customer wants something that makes the hair on the head of the programmer, you need to understand it separately. Once the editorial tasks are outweighed and then you have to be ready to throw out part of the finished work, and completely redo the other part. Once the developers were right: the implementation of the "Wishlist" of the editorial office will be thrust into the side with a pitchfork in a week. And then the editorial office must abandon such “Wishlist”.
What does this mean for a manager? For the manager, this means that: a) one has 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 the convenience and accuracy of development; d) be able to explain why something is impossible to do and something needs to be done. When working with the editorial office, acting as a customer, this is especially important, since the editorial office has a lot of different desires. About it - further.

“Let's make that one button there”

On projects that live from month to 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 manifest themselves. But they are manifested with might and main on projects that live 5 years or more and which have a huge archive.

What does this mean for a manager? For the manager, this means that in the future, developers will have to spend time on fixing suddenly “crutches”. They will most likely come out at the most inopportune moment. And this time - expenses, expenses not on the production of something valuable, but on patching holes, which they themselves were digging. This must be understood and the risks explained to the customer each time you are asked to do something similar.

It is equally important to keep this in mind when you are discussing the possible implementation of a particular task with developers. Not all developers are equally visionary, and sometimes agree to make a crutch "if only everyone had settled down there." In the long run, this approach will cause many problems. There is a risk that you will end up with a monstrous and gluttonous structure, which will require more and more people to support. Instead of creating new things and developing, developers will sit, bathe in crutches, and, most unpleasantly, be bored. And you will understand that everyone seems to be clogged with tasks, they work, they do, they do, but ... they somehow didn’t do anything.

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

Human face programmer

The ability to see the problem from the side of a simple user, and not from the "logs" is especially important if you are working with the editorial staff. Drop the brains on the developer, explain, convince that if the editor has a problem and complains (and you checked and the problem really exists), then the problem is real, it must be solved even if everything is fine in the "logs". In addition, sometimes it’s useful for the developer to chat with the editor directly.

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

The habit of doing manuals

In order to solve issues arising at the editorial office, in addition to human programmers, you will need manuals. It is worth learning to write them, taking this as a rule. Made a new functional - updated the manual. The more night / remote editors there are in the editorial office, the more necessary it is at some point to simply give a link to the article on the wiki, for example. It doesn’t matter in what format the manual is — a screenshot with arrows, text or screencast, the main thing is to make it clear. I began to practice writing manuals for the new admin features in the Ribbon, but I did not bring this to constant practice. We realize our plan in Vedomosti.

Total

When working with the editorial staff and other departments of the publication (in Vedomosti this is also a commercial unit for working with subscriptions), you need to do a lot of things, which, in theory, the manager shouldn't do. You need to write manuals, draw business process diagrams, reassure indignant people over the 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 of a designer, technical writer, business analyst and technical support operator. And the functions of these people to some extent need to be performed.

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

The thing is that the editorial board is an incredibly motivated customer, they really need everything and if they like the result, no management will “wrap it up”, and the editor-in-chief will break through his decision. This allows you to get a cool product, and not get bogged down in the approvals and corrections of timid managers of different links.