Мій колега Заур розповів про розробку проекту з перезапуску медіа-видання. Я ж хочу розповісти про особливості роботи менеджера на такому проекті.
З 2007 року я працюю проджектом. Працювала в Студії Лебедєва, Articul Media Group, працювала в основному з великими компаніями (ТНК-BP, Євросеть, ВТБ, Samsung, ОКОІ Сочі-2014). Досвіду роботи з медіа у мене не було до травня 2012, коли прийшла в Ленту.ру і потрапила в самий розпал проекту з перезапуску. Нова Стрічка відкрилася в січні 2013-го. У березні 2014-го, після звільнення головного редактора, ми перейшли у Ведомости, де зараз готуємо перезапуск.
Нижче я позначу найважливіші моменти, з якими зіткнулася при роботі з редакціями, які виступали в якості замовника.
ТЗ не буде
ТЗ на розробку в його класичному вигляді (об'ємному, невибірковому, але вичерпному) або не буде зовсім, або воно буде використовуватися виключно як підставка під гуртку. Відбувається це тому, що для складання ТЗ, яке може бути повноцінним робочим інструментом для замовника і виконавця, потрібен час і участь обох сторін.
Коли замовник - редакція, йому ніколи читати, правити і болісно довго обговорювати важке ТЗ. У новинному виданні 24/7 редакторам є що почитати і пописати і без цього. І навіть якщо товсте ТЗ все ж є, у вас по ходу проекту відбудеться така кількість змін, що воно швидко втратить свою актуальність і стане марним.
Але і зовсім без документації вам не обійтися. У Стрічці всі результати усних обговорень я фіксувала у файлі - «лозі» в наступному форматі: питання таке-то, обговорили тоді-то, вирішили робити так-то. Далі - історія обговорень/змін.
Паралельно завдання проговорювалися з розробниками і фіксувалися в таск-менеджері. Це дозволяло не упускати з уваги питання, які зачіпалися мельком і ще не отримали фінального рішення. Зараз у Відомостях використовую той самий формат файлу-лога для документації, що стосується редакційного блоку, веду його в wiki на GitHub. Після запуску з цих логів складу опис фінальної версії системи, щоб ним можна було користуватися як довідником.
Комунікація з учасниками проекту
Швидше за все, Більша частина спілкування буде усною і раптовою, а в робочій групі можлива поява нових учасників у будь-який момент. Обміну завданнями в таск-менеджері не буде. Не буде обов'язкових підтверджень підсумків зустрічей у пошті і нарад, що вчасно починаються.
Причина та ж - у замовника новини 24/7, трапитися може що завгодно і коли завгодно. При такій комунікації ймовірність того, що хтось з учасників проекту знає одне, а хтось - інше, вкрай висока. Тому логічно свої зусилля спрямувати на «синхронізацію» всіх учасників процесу.
Я роблю це листами за підсумками усних обговорень, записом у файлі-лозі, а про щось просто підходжу і кажу. Той чи інший спосіб вибираю залежно від значущості обговорюваного питання. Якщо питання принципово важливе - звичайно, це лист. А якщо дрібниця - можна просто підійти і сказати, щоб не завалювати людей листами, які їм ніколи читати. У звичайного замовника зі свого боку є менеджер, який організовує комунікацію, підтверджує отримання листів і т. д., і т. п. А у редакції його немає. З цим треба просто змиритися. І не треба редакторів мучити всіма цими «правильними» менеджерськими прийомами - справі це тільки зашкодить.
Загальний знаменник і баланс
На моє глибоке переконання, одна з важливих функцій проджекта - це знаходити «спільний знаменник» між «занадто людським» мисленням замовника (редакції в нашому випадку) і занадто схематичним мисленням програмістів. Заур наводив приклад: нормальна людина не бачить труднощі в переході від зв'язку «один до одного» до зв'язку «один до багатьох». А якщо точніше, нормальна людина не бачить цього переходу взагалі. Програмісту ж подібне не прийде в голову.
У кожному подібному випадку, коли замовник хоче щось таке, від чого у програміста волосся на голові ворушиться, треба розбиратися окремо. Колись переважують завдання редакції і тоді треба бути готовим частину готової роботи викинути, а іншу частину повністю переробити. Колись праві розробники: реалізація «хотілок» редакції через тиждень встромиться всім вилами в бік. І тоді редакції треба відмовлятися від таких «хотілок».
Що це означає для менеджера? Для менеджера це означає, що: a) треба вникати і в смислову і технічну сторони завдання, завжди; b) знаходити спільний знаменник; c) підтримувати баланс між бажаннями редакції та зручністю і правильністю розробки, d) вміти пояснити, чому щось неможливо зробити, а щось зробити необхідно. При роботі з редакцією, яка виступає в ролі замовника, це особливо важливо, оскільки різних бажань у редакції багато. Про це - далі.
«Давайте там зробимо таку одну кнопку»
На проектах, які живуть від місяця до року і не мають великого архіву, зазвичай не стикаєшся з «принадами» так званої «клаптикової автоматизації». Або ж «принади» просто не встигають проявитися. Зате вони щосили проявляються на проектах, які живуть 5 і більше років і на яких є величезний архів.
Що це означає для менеджера? Для менеджера це означає, що в майбутньому доведеться витрачати час розробників на виправлення раптово вилізлих «милиць». Вилізуть вони, швидше за все, в найбільш невідповідний момент. І цей час - витрати, витрати не на виробництво чогось цінного, а на латання дірок, які самі ж і проковиряли. Це треба розуміти і пояснювати ризики замовнику кожен раз, коли вас просять зробити щось подібне.
Не менш важливо пам'ятати про це, коли ви обговорюєте можливу реалізацію того чи іншого завдання з розробниками. Не всі розробники однаково далекоглядні, і часом згодні зробити милицю «аби вже вгамувалися всі там». У довгостроковій перспективі такий підхід принесе всім чимало проблем. Є ризик, що у вас вийде монструозна і ненажерлива конструкція, для підтримки якої буде потрібно все більше людей. Розробники ж замість того, щоб створювати нове і розвиватися, будуть сидіти, колупатися в милицях, і, що найнеприємніше, - нудьгувати. А ви будете розуміти, що ось начебто всі забиті завданнями, працюють, роблять-роблять, а... нічого якось і не зробили.
Подібна ситуація, м'яко кажучи, не нова, та й зустрічається не тільки в роботі з редакціями. Але в роботі з редакцією вона загострюється тим, що техвідділ у виданні - обслуговуючий відділ, тому можливості розростатися не має.
Програміст з людським обличчям
Здатність побачити проблему з боку простого користувача, а не з боку «логів» особливо важлива, якщо ви працюєте з редакцією. Капайте розробнику на мізки, пояснюйте, переконуйте, що якщо у редактора проблема і він скаржиться (а ви перевірили і проблема дійсно є) - то проблема реальна, її треба вирішувати, навіть якщо в «логах все нормально». Крім того, іноді розробнику корисно поспілкуватися з редактором безпосередньо.
Менеджеру потрібно проводити регулярну «виховну» роботу з командою, щоб розробники не закопувалися в коді, ігноруючи кінцевого користувача (як редактора, так і читача). Код цінний тільки тоді, коли задоволений користувач.
Звичка робити мануали
Для вирішення питань, що виникають у редакції, крім людяних програмістів, вам потрібні мануали. Варто навчитися їх писати, взявши це за правило. Зробили новий функціонал - оновили мануал. Чим більше в редакції нічних/віддалених редакторів, тим потрібніше в якийсь момент просто дати посилання на статтю у віки, наприклад. Не важливо в якому форматі мануал - - скріншот зі стрілочками, текст або скрінкаст, головне щоб було зрозуміло. Практикувати написання мануалів на нові функції адмінки я почала в Стрічці, але не довела це до постійної практики. Реалізуємо задумане у Відомостях.
Разом
Працюючи з редакцією та іншими підрозділами видання (у Відомостях це ще й комерційний блок по роботі з передплатою), треба робити багато чого, що, по ідеї, менеджер робити ніби як не повинен. Потрібно писати мануали, креслити схеми бізнес-процесів, заспокоювати обурених людей по телефону, та інше, та інше. Все це тому, що техвідділ видання невеликий, і у вас не буде армії з проектувальника, технічного письменника, бізнес-аналітика і оператора техпідтримки. А функції цих людей в якомусь обсязі потрібно виконувати.
Якщо замовник - редакція, то багато стандартних процесів (розробка ТЗ, наприклад) будуть відбуватися інакше, а етапи проекту - в іншій послідовності (наприклад, спочатку зроблять дизайн, а потім, спираючись на дизайн, - структуру проекту). Або не відбуватися взагалі. І це нормально і добре, а на виході дає навіть кращий результат, ніж ви могли собі уявити.
Вся справа в тому, що редакція - неймовірно замотивований замовник, їм все дуже потрібно і якщо результат подобається - ніяке керівництво не «заверне», а головний редактор проб'є своє рішення. Це дозволяє отримати крутий продукт, а не загрузнути в узгодженнях і правках несміливих менеджерів різних ланок.