Котоламповые истории, часть 1. Процессы работы в контент-проектах

Часть первая из трилогии по процессной организации работ со статейниками.

А вы уже пустили свои сбережения, время и нервы в очередной статейник? Да, я тоже. Незаметно для всех, но заметно для некоторых тему со статейниками последние годы не педалировал только ленивый. Курсы одни выпускают каждый раз по армии ребят, которые клепают в промышленных масштабах.

Лично марафоны не проходил, поэтому не могу сказать ничего плохого, и ничего хорошего про них. Возможно поэтому, я в свое время столкнулся с оптимизацией схемы работы (на марафонах это дают, не знаю). Вопрос “а как?” знаком каждому. Как выстроить работу так, чтобы и процесс был, и ответственность понятна, и результат всех устраивал.

Чтобы сделать статейник было понятно, что кто-то должен писать статьи, кто-то их публиковать, кто-то подгонять семантику, а кто-то отвечать за все остальное. Четкое разграничение работ – залог успеха. В свое время Г. Форд поднялся именно на этом.

Ясли вебмастера

Лет 5-7 назад, все складывалось очень просто. Есть я. Есть биржи копирайтинга с персоналом. Ты даешь задачу – получаешь результат – его оплачиваешь – сам публикуешь на сайт – профит.

Если ты веб-одиночка, то такая схема вполне имеет место. Делаешь – получаешь результат. Если что-то не устраивает – сам виноват.

Но это происходит до поры до времени. Ты начинаешь лениться, демотивироваться. Однотипные работы наскучивают, появляется необходимость расти и развиваться.

И тогда – ты начинаешь де-ле-ги-ро-вать. Брать в команду людей, которые бы закрывали эту потребность. Схема вроде есть, процесс описан. Ты ставишь человека, чтобы он делал то, что недавно делал ты.

Вопросы масштабирования

Ладно. Вроде бы ты уже не просто вебмастер, а ра-бо-то-да-тель. Крутой парень (девушка). У тебя есть человек, который, скорее всего, называется контент-менеджер, который что-то делает, а ты ему платишь. Не важно, сдельно или фикс, либо еще как то. Часть “твоих кровно заработанных” идут твоему работнику. Это нормально, но начинаются мысли из разряда “нужно масштабироваться, чтобы зарабатывать еще больше”. И тогда веба может просто понести, вследствие чего все может схлопнуться. Проектов все больше. Человек, которого ты раньше взял, уже не тянет такой большой объем. И ты набираешь еще людей, отчего доходы опять снижаются, но ты тешишь себя мыслями, что строишь большую корпорацию и это нормально.

Скоро до тебя доходит, что работа напоминает больше хаос, чем рабочий процесс. Только вот ты не учел (откуда ты знал?), что когда работаешь с 1 человеком, вроде все ок. А когда их появляется несколько – система начинает шататься: кто-то зафейлил дедлайн, опубликовал говно, или не вовремя сдал семантику, отчего сотрудник простаивает.

Проще говоря, ты начинаешь терять деньги. Если от этого волшебная таблетка? Считаю есть. Нужно верно выстраивать процессы.

Первые шаги

В тот дождливый день, озарение пришло само. И тут вышла картинка ниже:

И мы перестроились под эту схему. Но реалии жизни дали другую картинку – отлично работает, когда менеджер (руководитель) один и его зона ответственности – весь проект. И плохо, когда зон ответственности – несколько. Грубо говоря, при не успешном проекте не понятно – то ли семантика кривая была и темы подобраны не верно, то ли статьи в целом не отвечают потребностям пользователей и поисковых систем. Все, приплыли. С кого спрашивать? Не понятно. Все держать под тотальным контролем? Но как, если проектов много, статей много, на каждый нужно зайти – посмотреть – оценить – дать втык ответственному лицу. Ад.

И тогда я пошел гуглить. Вопрос стоял так:

“Как сделать свою редакцию, с блекджеком и нормальным контентом, чтобы при это не потерялась управляемость и можно было иметь точки контроля?”

А как у них?

Все читали эпиграф к статье? Если нет, то вернитесь. Потом обратно. Гипотеза была следующая: “Наши процессы в целом похоже на газетные издания. А как это все построено у них?”

Я нашел несколько форумов и статей по предметной теме. Одна из статей была вообще хороша.

Пару схем приведу сюда цитатами:

Редакция как предприятие состоит из творческого коллектива редакции, который занимается выпуском издания, и вспомогательных служб. Возглавляет редакцию генеральный директор, который отвечает перед собственником издания за его прибыльность. В подчинении у генерального директора находится главный редактор, который руководит творческим коллективом редакции. Творческий коллектив в зависимости от его численности может иметь плоскую или пирамидальную структуру. При плоской структуре все журналисты напрямую подчинены главному редактору, при пирамидальной между главным редактором и журналистами появляются промежуточные звенья. Разновидности пирамидальной структуры – однолинейная, многолинейная, штабная и матричная. В однолинейной структуре происходит жесткое разделение по отделам, в многолинейной редакторы отделов имеют прямой выход на всех журналистов, в штабной большинство журналистов подчиняются только редактору отдела, однако для освещения сложных тем, требующих совместной работы журналистов из разных отделов, создаются временные рабочие группы – штабы. Матричная структура предусматривает двухуровневую систему подчинения сотрудников редакции. Первый, вертикальный уровень соответствует однолинейной модели, когда журналисты подчиняются редакторам отделов, редакторы отделов – главному редактору. Второй уровень является продукториентированным, а руководители этого уровня также подчиняются главному редактору. При централизованной организации работы над материалом один и тот же журналист выполняет все этапы работы над статьей – поиск темы, сбор информации и написание текста; при децентрализованной же эти операции выполняются различными сотрудниками. Координация и контроль работы творческого коллектива редакции осуществляются через систему планерок и дедлайнов. Планерка – это собрание руководства редакции. Дедлайн – это время сдачи материала, полосы либо издания в целом.

Очень хорошая тема – брать информацию с форумов. Там мы можем посмотреть как реально работает тот или иной механизм. Если повезет – подскажут подводные камни.

С форума издателей про структуры редакции:

Корры сбрасывают материалы редактору, фотографы соответственно фотографии, редактор читает текст и отправляет на доработку или кидает версталам, версталы отбирают фотки и верстают полосы, есть вариант, что сначала верстальщиками делается «рыба» или полурыба это когда есть текст, а фотки нет или наоборот . Печатаем полоски на бумажку отдаем корректорам, корректора приносят правку, вносим, опять корректорам, пока совсем чистая не станет. Затем в pdf и в типографию.

и еще:

Журналист набирает текст и сохраняет на так званом СЕРВЕРЕ в папке Robota. Все фотки которые приходят сохраняются в папке FOTO. Реклмама отдельно в папке REKLMOD в папках по месяцах распределена. Раз в пару месяцев делается архив этих папок и сохраняется в папке ARXIV. Все что печатается печатается с названиями файлов их пути на сервере. Все материалы с фотографиями и рекламой отдаются ответств секу и он красиво складывает это все дело в папочку с названием страницы на которой все это дело нужно сверстать. Верстала берет папку и закидывает на страницу. Печатает в двух экземплярах — один редактору второй в корректуру. После вычитки двух экземпляров делается еще одна правка и снова в корректуру. Потом последняя правка и на пленку (кальку или pdf)

А как надо?

Обмозговав полученную информацию, я понял, что ребята придумали agile почему бы не попробовать внедрить одну из схем у себя. Такая, многолинейная структура с элементами штабной, натянутой на реалии веба. Т.е.

У нас есть:

1. Редактор проекта, который подбирает темы, знает вверенный ему проект от А до Я
2. Копирайтеры, которые ищут материал и выдают готовые статьи + проводят работы по подбору фото
3. Эксперты\корректоры\специалисты, которые улучшают статью или проверяют ее на наличие фактологических ошибок
4. Верстальщик (или контент-менеджер) – тот, кто публикует статьи и наводит порядок в ее верстке. Придает красивости.
5. Глав.ред, который проводит контроль над системой. Определяет стратегию развития, обсуждает планы с редакторами и дает живительный пендель, когда нужно (редактору, конечно же).

То, что я написал в этой статье – несколько лет работ. Считайте вы сейчас сэкономили пару лет своей жизни.

В теории то, конечно, красиво. А как это все запустить в работу? И как, собственно, контролировать то как? Это будет в следующих частях.

Выводы

1. Масштабирование – это нормальный процесс любого бизнеса
2. Делегировать надо с умом. Стройте сначала процессы, потом делегируйте
3. Что подходит для малой команды, возможно не подойдет для большой
4. Контроль – полезен. Им нужно пользоваться. Вопрос как этот контроль проводить.