Если заказчик — редакция
Мой коллега Заур рассказал о разработке проекта по перезапуску медиа-издания. Я же хочу рассказать об особенностях работы менеджера на таком проекте.
С 2007 года я работаю проджектом. Работала в Студии Лебедева, Articul Media Group, работала в основном с крупными компаниями (TНК-BP, Евросеть, ВТБ, Samsung, ОКОИ Сочи-2014). Опыта работы с медиа у меня не было до мая 2012, когда пришла в Ленту.ру и попала в самый разгар проекта по перезапуску. Новая Лента открылась в январе 2013-го. В марте 2014-го, после увольнения главреда, мы перешли в Ведомости, где cейчас готовим перезапуск.
Ниже я обозначу самые важные моменты, с которыми столкнулась при работе с редакциями, выступавшими в качестве заказчика.
ТЗ не будет
ТЗ на разработку в его классическом виде (объемном, неизбыточном, но исчерпывающем) либо не будет вовсе, либо оно будет использоваться исключительно в качестве подставки под кружку. Происходит это потому, что для составления ТЗ, которое может быть полноценным рабочим инструментом для заказчика и исполнителя, нужно время и участие обеих сторон.
Когда заказчик — редакция, ему некогда читать, править и мучительно долго обсуждать увесистое ТЗ. В новостном издании 24/7 редакторам есть что почитать и пописать и без этого. И даже если толстое ТЗ все же имеется, у вас по ходу проекта произойдет такое количество изменений, что оно быстро утратит свою актуальность и станет бесполезным.
Но и совсем без документации вам не обойтись. В Ленте все результаты устных обсуждений я фиксировала в файле -«логе» в следующем формате: вопрос такой-то, обсудили тогда-то, решили делать так-то. Далее — история обсуждений/изменений.
Параллельно задачи проговаривались с разработчиками и фиксировались в таск-менеджере. Это позволяло не упускать из виду вопросы, которые затрагивались мельком и еще не получили финального решения. Сейчас в Ведомостях использую тот же формат файла-лога для документации, касающейся редакционного блока, веду его в wiki на GitHub. После запуска из этих логов составлю описание финальной версии системы, чтобы им можно было пользоваться как справочником.
Коммуникация с участниками проекта
Скорее всего, бОльшая часть общения будет устной и внезапной, а в рабочей группе возможно появление новых участников в любой момент. Обмена задачами в таск-менеджере не будет. Не будет обязательных подтверждений итогов встреч в почте и вовремя начинающихся совещаний.
Причина та же — у заказчика новости 24/7, случиться может что угодно и когда угодно. При такой коммуникации вероятность того, что кто-то из участников проекта знает одно, а кто-то — другое, крайне высока. Поэтому логично свои усилия направить на «синхронизацию» всех участников процесса.
Я делаю это письмами по итогам устных обсуждений, записью в файле-логе, а про что-то просто подхожу и говорю. Тот или иной способ выбираю в зависимости от значимости обсуждаемого вопроса. Если вопрос принципиально важный — конечно, это письмо. А если мелочь — можно просто подойти и сказать, чтобы не заваливать людей письмами, которые им некогда читать. У обычного заказчика со своей стороны есть менеджер, который организует коммуникацию, подтверждает получение писем и т.д., и т. п. А у редакции его нет. С этим надо просто смириться. И не надо редакторов мучать всеми этими «правильными» менеджерскими приемами — делу это только навредит.
Общий знаменатель и баланс
По моему глубочайшему убеждению, одна из важных функций проджекта — это находить «общий знаменатель» между «слишком человеческим» мышлением заказчика (редакции в нашем случае) и слишком схематичным мышлением программистов. Заур приводил пример: нормальный человек не видит трудности в переходе от связи «один к одному» к связи «один ко многим». А если точнее, нормальный человек не видит этого перехода вообще. Программисту же подобное не придет в голову.
В каждом подобном случае, когда заказчик хочет что-то такое, от чего у программиста волосы на голове шевелятся, надо разбираться отдельно. Когда-то перевешивают задачи редакции и тогда надо быть готовым часть готовой работы выкинуть, а другую часть полностью переделать. Когда-то правы разработчики: реализация «хотелок» редакции через неделю воткнется всем вилами в бок. И тогда редакции надо отказываться от таких «хотелок».
Что это означает для менеджера? Для менеджера это означает, что: a) надо вникать и в смысловую и техническую стороны задачи, всегда; b) находить общий знаменатель; c) поддерживать баланс между желаниями редакции и удобством и правильностью разработки, d) уметь объяснить, почему что-то невозможно сделать, а что-то сделать необходимо. При работе с редакцией, выступающей в роли заказчика, это особенно важно, так как самых разных желаний у редакции много. Про это — далее.
«Давайте там сделаем такую одну кнопку»
На проектах, которые живут от месяца до года и не имеют большого архива, обычно не сталкиваешься с «прелестями» так называемой «лоскутной автоматизации». Либо же «прелести» просто не успевают проявиться. Зато они вовсю проявляются на проектах, которые живут 5 и более лет и на которых есть огромный архив.
Что это значит для менеджера? Для менеджера это значит, что в будущем придется тратить время разработчиков на исправление внезапно вылезших «костылей». Вылезут они, скорее всего, в самый неподходящий момент. И это время — расходы, расходы не на производство чего-то ценного, а на латание дыр, которые сами же и проковыряли. Это надо понимать и объяснять риски заказчику каждый раз, когда вас просят сделать что-то подобное.
Не менее важно помнить об этом, когда вы обсуждаете возможную реализацию той или иной задачи с разработчиками. Не все разработчики одинаково дальновидные, и порой согласны сделать костыль «лишь бы уже угомонились все там». В долгосрочной перспективе такой подход доставит всем немало проблем. Есть риск, что у вас получиться монструозная и прожорливая конструкция, для поддержки которой будет требоваться все больше людей. Разработчики же вместо того, чтобы создавать новое и развиваться, будут сидеть, колупаться в костылях, и, что самое неприятное, — скучать. А вы будете понимать, что вот вроде все забиты задачами, работают, делают-делают, а… ничего как-то и не сделали.
Подобная ситуация, мягко говоря, не нова, да и встречается не только в работе с редакциями. Но в работе с редакцией она обостряется тем, что техотдел в издании — обслуживающий отдел, поэтому возможности разрастаться не имеет.
Программист с человеческим лицом
Способность увидеть проблему со стороны простого пользователя, а не со стороны «логов» особенно важна, если вы работаете с редакцией. Капайте разработчику на мозги, объясняйте, убеждайте, что если у редактора проблема и он жалуется (а вы проверили и проблема действительно есть) — то проблема реальна, ее надо решать, даже если в «логах все нормально». Кроме того, иногда разработчику полезно пообщаться с редактором напрямую.
Менеджеру нужно проводить регулярную «воспитательную» работу с командой, чтобы разработчики не закапывались в коде, игнорируя конечного пользователя (как редактора, так и читателя). Код ценен только тогда, когда доволен пользователь.
Привычка делать мануалы
Для решения возникающих у редакции вопросов, помимо человечных программистов, вам потребуются манулы. Стоит научиться их писать, взяв это за правило. Сделали новый функционал — обновили мануал. Чем больше в редакции ночных/удаленных редакторов, тем нужнее в какой-то момент просто дать ссылку на статью в вики, например. Не важно в каком формате мануал —- скриншот со стрелочками, текст или скринкаст, главное чтоб было понятно. Практиковать написание мануалов на новые функции админки я начала в Ленте, но не довела это до постоянной практики. Реализуем задуманное в Ведомостях.
Итого
Работая с редакцией и другими подразделениями издания (в Ведомостях это еще и коммерческий блок по работе с подпиской), надо делать многое, что, по идее, менеджер делать вроде как не должен. Нужно писать мануалы, чертить схемы бизнес-процессов, успокаивать возмущенных людей по телефону, и прочее, и прочее. Все это потому, что техотдел издания невелик, и у вас не будет армии из проектировщика, технического писателя, бизнес-аналитика и оператора техподдержки. А функции этих людей в каком-то объеме нужно выполнять.
Если заказчик — редакция, то многие стандартные процессы (разработка ТЗ, например) будут происходить иначе, а этапы проекта — в другой последовательности (например, сначала сделают дизайн, а потом, опираясь на дизайн, — структуру проекта). Или не происходить вообще. И это нормально и хорошо, а на выходе дает даже лучший результат, чем вы могли себе представить.
Все дело в том, что редакция — невероятно замотивированный заказчик, им всё очень нужно и если результат нравится — никакое руководство не «завернёт», а главред пробьет свое решение. Это позволяет получить крутой продукт, а не погрязнуть в согласованиях и правках несмелых менеджеров разных звеньев.
Автор: Gohksen