Если заказчик — редакция

Мой коллега Заур рассказал о разработке проекта по перезапуску медиа-издания. Я же хочу рассказать об особенностях работы менеджера на таком проекте.

С 2007 года я работаю проджектом. Работала в Студии Лебедева, Articul Media Group, работала в основном с крупными компаниями (TНК-BP, Евросеть, ВТБ, Samsung, ОКОИ Сочи-2014). Опыта работы с медиа у меня не было до мая 2012, когда пришла в Ленту.ру и попала в самый разгар проекта по перезапуску. Новая Лента открылась в январе 2013-го. В марте 2014-го, после увольнения главреда, мы перешли в Ведомости, где cейчас готовим перезапуск.

Ниже я обозначу самые важные моменты, с которыми столкнулась при работе с редакциями, выступавшими в качестве заказчика.

ТЗ не будет


ТЗ на разработку в его классическом виде (объемном, неизбыточном, но исчерпывающем) либо не будет вовсе, либо оно будет использоваться исключительно в качестве подставки под кружку. Происходит это потому, что для составления ТЗ, которое может быть полноценным рабочим инструментом для заказчика и исполнителя, нужно время и участие обеих сторон.

Когда заказчик — редакция, ему некогда читать, править и мучительно долго обсуждать увесистое ТЗ. В новостном издании 24/7 редакторам есть что почитать и пописать и без этого. И даже если толстое ТЗ все же имеется, у вас по ходу проекта произойдет такое количество изменений, что оно быстро утратит свою актуальность и станет бесполезным.

Но и совсем без документации вам не обойтись. В Ленте все результаты устных обсуждений я фиксировала в файле -«логе» в следующем формате: вопрос такой-то, обсудили тогда-то, решили делать так-то. Далее — история обсуждений/изменений.

Параллельно задачи проговаривались с разработчиками и фиксировались в таск-менеджере. Это позволяло не упускать из виду вопросы, которые затрагивались мельком и еще не получили финального решения. Сейчас в Ведомостях использую тот же формат файла-лога для документации, касающейся редакционного блока, веду его в wiki на GitHub. После запуска из этих логов составлю описание финальной версии системы, чтобы им можно было пользоваться как справочником.

Коммуникация с участниками проекта


Скорее всего, бОльшая часть общения будет устной и внезапной, а в рабочей группе возможно появление новых участников в любой момент. Обмена задачами в таск-менеджере не будет. Не будет обязательных подтверждений итогов встреч в почте и вовремя начинающихся совещаний.

Причина та же — у заказчика новости 24/7, случиться может что угодно и когда угодно. При такой коммуникации вероятность того, что кто-то из участников проекта знает одно, а кто-то — другое, крайне высока. Поэтому логично свои усилия направить на «синхронизацию» всех участников процесса.

Я делаю это письмами по итогам устных обсуждений, записью в файле-логе, а про что-то просто подхожу и говорю. Тот или иной способ выбираю в зависимости от значимости обсуждаемого вопроса. Если вопрос принципиально важный — конечно, это письмо. А если мелочь — можно просто подойти и сказать, чтобы не заваливать людей письмами, которые им некогда читать. У обычного заказчика со своей стороны есть менеджер, который организует коммуникацию, подтверждает получение писем и т.д., и т. п. А у редакции его нет. С этим надо просто смириться. И не надо редакторов мучать всеми этими «правильными» менеджерскими приемами — делу это только навредит.

Общий знаменатель и баланс


По моему глубочайшему убеждению, одна из важных функций проджекта — это находить «общий знаменатель» между «слишком человеческим» мышлением заказчика (редакции в нашем случае) и слишком схематичным мышлением программистов. Заур приводил пример: нормальный человек не видит трудности в переходе от связи «один к одному» к связи «один ко многим». А если точнее, нормальный человек не видит этого перехода вообще. Программисту же подобное не придет в голову.



В каждом подобном случае, когда заказчик хочет что-то такое, от чего у программиста волосы на голове шевелятся, надо разбираться отдельно. Когда-то перевешивают задачи редакции и тогда надо быть готовым часть готовой работы выкинуть, а другую часть полностью переделать. Когда-то правы разработчики: реализация «хотелок» редакции через неделю воткнется всем вилами в бок. И тогда редакции надо отказываться от таких «хотелок».
Что это означает для менеджера? Для менеджера это означает, что: a) надо вникать и в смысловую и техническую стороны задачи, всегда; b) находить общий знаменатель; c) поддерживать баланс между желаниями редакции и удобством и правильностью разработки, d) уметь объяснить, почему что-то невозможно сделать, а что-то сделать необходимо. При работе с редакцией, выступающей в роли заказчика, это особенно важно, так как самых разных желаний у редакции много. Про это — далее.

«Давайте там сделаем такую одну кнопку»


На проектах, которые живут от месяца до года и не имеют большого архива, обычно не сталкиваешься с «прелестями» так называемой «лоскутной автоматизации». Либо же «прелести» просто не успевают проявиться. Зато они вовсю проявляются на проектах, которые живут 5 и более лет и на которых есть огромный архив.

Что это значит для менеджера? Для менеджера это значит, что в будущем придется тратить время разработчиков на исправление внезапно вылезших «костылей». Вылезут они, скорее всего, в самый неподходящий момент. И это время — расходы, расходы не на производство чего-то ценного, а на латание дыр, которые сами же и проковыряли. Это надо понимать и объяснять риски заказчику каждый раз, когда вас просят сделать что-то подобное.

Не менее важно помнить об этом, когда вы обсуждаете возможную реализацию той или иной задачи с разработчиками. Не все разработчики одинаково дальновидные, и порой согласны сделать костыль «лишь бы уже угомонились все там». В долгосрочной перспективе такой подход доставит всем немало проблем. Есть риск, что у вас получиться монструозная и прожорливая конструкция, для поддержки которой будет требоваться все больше людей. Разработчики же вместо того, чтобы создавать новое и развиваться, будут сидеть, колупаться в костылях, и, что самое неприятное, — скучать. А вы будете понимать, что вот вроде все забиты задачами, работают, делают-делают, а… ничего как-то и не сделали.

Подобная ситуация, мягко говоря, не нова, да и встречается не только в работе с редакциями. Но в работе с редакцией она обостряется тем, что техотдел в издании — обслуживающий отдел, поэтому возможности разрастаться не имеет.

Программист с человеческим лицом


Способность увидеть проблему со стороны простого пользователя, а не со стороны «логов» особенно важна, если вы работаете с редакцией. Капайте разработчику на мозги, объясняйте, убеждайте, что если у редактора проблема и он жалуется (а вы проверили и проблема действительно есть) — то проблема реальна, ее надо решать, даже если в «логах все нормально». Кроме того, иногда разработчику полезно пообщаться с редактором напрямую.

Менеджеру нужно проводить регулярную «воспитательную» работу с командой, чтобы разработчики не закапывались в коде, игнорируя конечного пользователя (как редактора, так и читателя). Код ценен только тогда, когда доволен пользователь.

Привычка делать мануалы


Для решения возникающих у редакции вопросов, помимо человечных программистов, вам потребуются мануалы. Стоит научиться их писать, взяв это за правило. Сделали новый функционал — обновили мануал. Чем больше в редакции ночных/удаленных редакторов, тем нужнее в какой-то момент просто дать ссылку на статью в вики, например. Не важно в каком формате мануал —- скриншот со стрелочками, текст или скринкаст, главное чтоб было понятно. Практиковать написание мануалов на новые функции админки я начала в Ленте, но не довела это до постоянной практики. Реализуем задуманное в Ведомостях.

Итого


Работая с редакцией и другими подразделениями издания (в Ведомостях это еще и коммерческий блок по работе с подпиской), надо делать многое, что, по идее, менеджер делать вроде как не должен. Нужно писать мануалы, чертить схемы бизнес-процессов, успокаивать возмущенных людей по телефону, и прочее, и прочее. Все это потому, что техотдел издания невелик, и у вас не будет армии из проектировщика, технического писателя, бизнес-аналитика и оператора техподдержки. А функции этих людей в каком-то объеме нужно выполнять.

Если заказчик — редакция, то многие стандартные процессы (разработка ТЗ, например) будут происходить иначе, а этапы проекта — в другой последовательности (например, сначала сделают дизайн, а потом, опираясь на дизайн, — структуру проекта). Или не происходить вообще. И это нормально и хорошо, а на выходе дает даже лучший результат, чем вы могли себе представить.

Все дело в том, что редакция — невероятно замотивированный заказчик, им всё очень нужно и если результат нравится — никакое руководство не «завернёт», а главред пробьет свое решение. Это позволяет получить крутой продукт, а не погрязнуть в согласованиях и правках несмелых менеджеров разных звеньев.
Поделиться публикацией

Комментарии 19

    +5
    А теперь замените программистов на строителей, которым редакция заказывает строительство офиса. Пройдет такой подход? Врядли.
      0
      Ладно :)
        +2
        Слово «редакция» на слово «заказчик» можно заменить без потери смысла.
        0
        Раньше тоже сравнивал создание веб сайтов со строительством зданий. Теперь думаю что это сравнение не совсем корректно. Строительство зданий скорее можно сравнивать с созданием дата-центра или настройкой серверов, ну или созданием веб-движка (CMS). Создание веб-сайта это скорее декорация офиса, расстановка мебели, создание витрины: эти вещи постоянно меняются, а здание (основа) остается.
          +2
          Это смотря какой сайт вы делаете. С узкоспециализированными сайтами для которых есть ходовые движки (блог, магазин) — да. Это взять тему и разукрсить под заказчика — декорация.
          Если вам нужно спроектировать что то уникальное вроде скидочного сайта или узкоспециализированной социальной сети: здесь уже проектирование.
          Как и в строительстве: постройка дома это изначально проектирование. Так и здесь все осталось по-прежнему. А если вы принимаете участие в группе, которая занимается декорацией — ведь это не значит, что вся индустрия работает точно так же. Верно?
            –1
            Что-то вы плохо понимаете про постройку дома. При постройке дома точно так же берётся типовой проект и, максимум, подгоняется под рельеф местности. А дальше только декорации. Разница только в том, что типовую CMS легче скопировать — залил на хостинг, настроил и уже летим. А дом по типовому проекту ещё строить надо.
              +1
              Опять таки: типовый проект. Конечно, в наши дни типовое можно встретить гораздо чаще, чем не-типовое, на то и время копирования и масштабирования. Но все таки индивидуальные строения делаются и им отводится гораздо больше внимания, да и отдачи они дают гораздо больше. Нетипичные небоскребы в Батуми, например гораздо выше ценятся, чем типичные многоэтажки. Я к тому, что даже не в сайтах, а в комплексных довольно больших проектах, не редко проектирование и оно востребовано. Сложно наверное представить проект Фейсбука развернутый на какой ни будь CMS, ведь так же? Я не спорю, что есть уже CMS реализующие функционал социальной сети, но например проект по бронированию такси через вебсайт — это уже достаточно нетривиальная задача для обычной CMS.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Мне всегда нравилась метафора с машинами. Во многих предложениях если заменить «сайт» на «автомобиль», особенности разработки сразу становятся понятны всем.

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

              Чертовски просто.
            0
            Капайте разработчику на мозги, «воспитательную работу с командой»… моя плакать. От плохого менеджера веет за версту. Если разработчики закопались в коде — это уже ваш недочет. При наличии манагера, разработчику и вовсе не рекомендуется общаться с заказчиком, чтобы не стать «козлом отпущения».
              0
              Поясните пожалуйста, почему разработчику «не рекомендуется» общаться с заказчиком и почему и как от общения с заказчиком разработчик станет «козлом отпущения»?
                +2
                Предполагаю, что имеется ввиду то, что разработчики как правило не подкованы в деловом общении. В итоге если такой программист сойдётся в переговорах с ушлых заказчиком, умеющим навешать лапшу на уши, то битву программист проиграет. Совсем другое дело — натасканный в переговорах менеджер, который лапшу заказчика ему самому и скормит.
              +2
              делать многое, что, по идее, менеджер делать вроде как не должен. Нужно писать мануалы, чертить схемы бизнес-процессов, успокаивать возмущенных людей по телефону, и прочее, и прочее

              А кто это должен делать, как не менеджер? Правильный менеджер — контактирует с заказчиком, разбирается в предметной области, и предоставляет для конкретных разработчиков «хотелки» в нормализованном виде — схемы бизнес-процессов, диаграммы use-case и прочее. В лучшем случае, проработка этого идет вместе с lead-ом. Если менеджер просто бегает между заказчиком и разработчиками, уговаривая каждого пойти на компромисс — грош цена такому менеджеру.
                +1
                Может пару примеров как были разрулены те или иные ситуации? А то какая-то слишком общая статья.
                  0
                  Описанная вами ситуация с редакцией — это точная копия очень многих малых бизнесов, когда на отдельного менеджера для ведения диалогов с разработчиками просто не выделен бюджет.

                  Ситуация знакома очень. Я её ощущала на себе не раз и сделала один очень важный вывод — работать с подобными заказчиками надо по протоколу, вне зависимости от их занятости и загруженности.

                  Вы описали ситуацию «сверху», но она ничем не отличается от ситуации «снизу». Вот именно эта такая ваша гибкость в работе с клиентами однажды стоила мне отказа в трудоустройстве на вашу должность в одну из лучших студий Москвы.

                  Подстраиваться непременно нужно, ведь мы все живые люди с чувствами и личными убеждениями, но лишь в рамках, строгих рамках ведения проектов.
                    0
                    Прямо как бальзам на душу в плане Вики! Сам сейчас постепенно прихожу к необходимости такие вещи делать. На каких-то проектах организуем такую штуку через Trello, хотя структура, конечно, хромает.
                    Спасибо за идею GitHub. Нужно будет попробовать.
                      +1
                      Одно из преимуществ wiki на GitHub – возможность редактировать файлы локально на компьютере, работая как с репозиторием. Так как менеджеры с терминалом работать не умеют, на помощь приходят настольные приложения для git. В частности, можно скачать GitHub for Mac. Репозиторий с wiki для проекта лежит по адресу git@github.com/username/reponame.wiki.git. То есть к адресу обычного репозитория добавляется суффикс .wiki. Один раз настраиваем, показываем как делать коммиты, кликая вон ту зелёненькую кнопку. И все довольны.
                      –3
                      Переименуйте статью в «Если менеджер проекта морская свинка».
                        –2
                        «Перезапускали» недавно небольшое региональное медиа издание. В общих чертах ситуация похожая.

                        НО, не нужно это преподносить как некую неизбежность, типа если заказчик редакция — даже не пытайтесь.

                        Аргументы «нет времени» звучат смехотворно — ни у кого никогда нет времени, все заняты, в конце концов ИТ специалистам тоже есть что почитать и пописать. У нас время нашлось.

                        ТЗ отсутствовало за ненадобностью. Были чёткие цели редизайна, далее были макеты, далее пожелания редакции и внесение небольших изменений в основном в очень специфичные проекты. Когда все понимают «зачем это всё вообще», и главное дизайнер, правок не так уж много. Далее программистам нужно было «натянуть» вёрстку, они решили что тз для этого им ненужно, хотя для выполнения задачи требовались небольшие изменения в структуре данных. Все «а добавьте сюда кнопочку» оставлялись на усмотрение разработчика, либо делалось сразу, либо откладывалось на потом(после редизайна), и необходимость в большей части этих «хотелок» отпала сама собой, через пару недель, когда редакция полностью «въехала» в новые правила публикации материалов.

                        Все участники очень переживали, что результат не оправдает надежд, долго тянули с выводом в продакшн, смотрели/думали опять смотрели, но в итоге всё прошло достаточно гладко.

                        И главное сейчас я понимаю, что можно лучше, быстрее проще организовать процесс, что это не так уж и сложно как может показаться на первый взгляд.
                        Вы же свой не самый лучший опыт выставляете неким эталоном, чтобы другие какбы равнялись. По крайней мере я так понял посыл статьи.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое