3 заметки с тегом

управление проектом

Мы это уже согласовали

Делаем сайт, например. Изначально решили, что цитаты клиентов будут курсивные и с отступом. Согласовали пробную страницу, сделали еще 10 по согласованному шаблону, показываем клиенту. Или арт-директору. Или сами смотрим и понимаем:

С курсивом плохо смотрится, и отступ плохой, надо точно без отступа, а по поводу курсива надо смотреть.

Первая инстинктивная реакция на эту фразу — «Но мы уже это согласовали!». Перевод: «Мы уже показывали вам этот дизайн, вы его уже утвердили, что ж вы раньше нам не сказали? А теперь мы потратили столько времени, чтобы сделать эти 10 страниц, и что теперь, нам всё заново делать? Ну уж нет...»

Это плохая реакция: мы здесь заботимся только о себе. Очевидно, что в продукте проблема, но мы её игнорируем, чтобы сделать себе удобнее. Это не по-партнерски.

Как сделать по-партнерски

Нормальных реакций может быть две:

Взять и переделать. Стиснуть зубы, взять дополнительное время и исправить проблему. Желательно не сразу на всех одиннадцати страницах, а хотя бы на парочке самых проблемных; согласовать это решение, и тогда уже доделывать в остальных. Решение слабое, но хотя бы партнерское.

Договориться по-другому. Например, мы понимаем, что если сейчас всё переделывать, то мы не успеем выпустить сайт вовремя, поэтому пострадают все. Как тогда решить проблему? Есть ли способ сделать это немного по-другому, но в срок? Или неидеально и тупо, но супербыстро? Или отложить на второй этап? Или как-то прикрыть? Зависит от нюансов. Представьте такие варианты:

Мы можем это исправить, но чтобы успеть к сроку, нам придется отключить отступ не только у этой цитаты, но еще и вот тут, тут и там. То есть вообще отступов не будет. Вот быстро накидали вариант, как вам?

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

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

Еще есть третья стратегия — сразу структурировать работу так, чтобы всё было подвижно. Если верстаете — то на стилях. Если рисуете интерфейс — то тоже на стилях и относительных величинах. Чтобы потом в одном месте поменял цвет, и все кнопки перекрасились. Это обычно требует больше времени и сил, чем сразу нарисовать пиксели, но это всегда окупается в долгосрочной перспективе.

А вот говорить «Мы же это согласовали» — это крайнее паскудство. Не делайте так.

2019   управление проектом

Сначала поручи, потом делай

Вот вам задачка: придумать, напечатать, подписать и разослать 1000 поздравительных открыток. На задачу две недели. Сегодня пятница, задача начинается в понедельник.

Параметры задачи:

Открытка формата А5, печать цифровая или офсетная

На оборотной стороне нужно напечатать поздравления клиентам, выгрузку сделать из ЦРМ

Дизайн открытки и текст поздравления согласовать с боссом

Оплатить через бухгалтерию

Ваши ресурсы: дизайнер, программист, бухгалтер, босс, секретарь, текстовый редактор

Ваши действия?

Редакторы, с которыми я работал, обычно поступят так:

  1. В понедельник утром напишут текст поздравления, отправят согласовывать с боссом
  2. После этого отправят текст дизайнеру и попросят на его основе сделать макет
  3. Дождутся, пока дизайнер согласует с боссом макет
  4. Начнут искать типографию
  5. Получат счет
  6. Сходят в бухгалтерию и оплатят
  7. Получат тираж
  8. Прийдут к программисту и попросят напечатать на тираже с обратной стороны поздравление с подстановкой имен из ЦРМ
  9. Поручат секретарю купить конверты и разослать открытки почтой

Вот этот же план на схеме:

Все события происходят по цепочке

Это провальный план. В нём всё происходит по цепочке и укладывается впритык. Он сработает только в идеальных условиях — а в реальности идеального не бывает. В реальности будет так:

  1. Текст вы написали
  2. Дизайнер занят другими задачами, поэтому возьмется за макет только в четверг
  3. Босс согласует макет в пятницу
  4. В пятницу вечером типографии не отвечают на звонки, поиск и получение счета затянется до вторника
  5. Счет придется переделать из-за ошибки в реквизитах.
  6. Бухгалтерия будет согласовывать счет три дня. Наступит пятница.
  7. Тираж уйдет в работу в понедельник третьей недели, отгрузят тираж в среду
  8. Программист скажет, что сделать выгрузку сможет не раньше понедельника. Все выходные вы вручную печатаете поздравления на 1000 открыток.
  9. Понедельник четвертой недели вы проводите за поиском нужного количества конвертов. Ни у кого столько нет.
  10. В среду открытки улетают почтой.

Визуально :

Все задачи растянулись, проект удлинился

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

Как правильно

Товеровский меня однажды научил такому принципу: сначала нагрузи других. Это значит, что в любой составной задаче сначала нужно дать работу всем остальным участникам процесса, и только потом пилить свою часть.

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

С боссом и дизайнером: договориться о встрече, чтобы обсудить задачу и понять ожидания.

Дизайнеру дать задание на дизайн еще до встречи с боссом.

Программисту поручить написать скрипт, которым он будет печатать поздравления на обратной стороне и адреса на конвертах.

Секретарю поручить собрать список возможных типографий со сроками и ценами.

Секретарю поручить заказать конверты.

Тогда план проекта будет выглядеть так:

Все задачи идут параллельно

А в реальности будет так:

Все задачи растянулись, но благодаря параллельности проект закончился вовремя

Вывод:

Сначала поручи, потом делай сам

Как это сделать

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

  1. Еще до начала проекта составьте план: что и как должно произойти, в какой последовательности, что от чего зависит, а что можно запараллелить.
  2. Всё, что можно запараллелить — запараллельте.
  3. Всё, что можно поручить другим — поручите.

И только теперь открывайте свой текстовый редактор.

Управление проектом — это работа. Не какое-то побочное действие, которое можно выполнять фоном. Кто-то всегда должен управлять проектом. Если у вас нет менеджера, то менеджер — вы.

Тут слышатся возгласы:

— Но я же редактор, а не менеджер!

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

— Нет, управлять проектом — это не моя функция!

А чья? Кто еще будет отвечать за успех проекта, если не вы? Кто отвечает за провал?

— А мне проще сначала всё сделать самому, а потому уже управлять другими.

А это ошибка. Вы потеряете время, а других не нагрузите. Проект разъедется и провалится.

— Давать задания другим сложно!

Всё так.

— Если у кого-то что-то не получится сделать вовремя, это не моя проблема

Нет, ваша. И вы это знаете. Вы же редактор.

2016   управление проектом

Согласовать — ваша работа

Итак, вы написали хороший текст. Сидели над ним целый день, копались в фактах, по десять раз переписывали, навели инфостиль. Вам нравится этот текст. Это хороший текст.

Отправляете клиенту. В ответ — замечания:

Если вы неопытный писатель, то в этот момент вы садитесь исправлять текст по замечаниям. Отправляете переделанный вариант. Клиент отвечает новой порцией замечаний:

Три раунда спустя текст выглядит так, будто на нем слетали в начало двухтысячных:

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

См. также статью о согласовании с чиновниками

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

Если после замечаний клиента
получилось говно,
то виноваты в этом вы.

Вот почему:

I. Клиент не писатель

Естественно, клиент будет советовать говно: он же не знает, как написать хорошо. Это знаете вы. Клиент потому вас и позвал — чтобы вы сделали классно. Вы же столько лет учились писать.

II. Клиент знает, о чем писать

Естественно, что у клиента будут замечания к тексту. Он же знает тему гораздо глубже, чем вы. Все эти годы, пока вы учились писать, он продавал холодильники. Он знает о них все. Вы никогда с первого раза не охватите все, что он хочет рассказать.

III. Клиент не знает, как донести

Естественно, клиент не хочет, чтобы у него на сайте висела плохая статья. Но и ваш первый вариант не подходит — не хватает информации. Клиент пытается письменно донести до вас свои пожелания — но он не умеет этого. Он же вас позвал как раз для этого — письменно доносить мысли. 

Короче:

Комментарии клиента не значат, что нужно писать именно так. Расшифруйте, что клиент имеет в виду, и напишите это нормально. 

Как только это понимаешь, работа меняется. Ты больше не бодаешься с клиентом, что «в лучших традициях» — плохая фраза. Ты звонишь и спрашиваешь: «Олег, а расскажите, почему вы хотите тут фразу „в лучших традициях“? Я подозреваю, что там интересная история»

И Олег расскажет, что холодильники — их семейный бизнес с 1910 года. И что он знает о холодильниках больше, чем все продавцы Медиамаркта вместе взятые.

— О, а расскажите что-нибудь такое, чего не знают продавцы Медиамаркта?
— Ну, смотрите. Видите тут изоляционную резинку? Думаете, это просто так? Ан нет...

И наступает время удивительных историй, каждая из которых может стать поводом для новой отличной статьи.

А вот плохой сценарий:

— Олег, какая тут история?
— Да никакой, просто хочется показать, что мы давно работаем
— Ясно. А как у ваших конкурентов с возрастом?
— Примерно так же, как у нас, все открылись в начале двухтысячных
— Как же мы их победим тогда? Что вас отличает с точки зрения опыта?
— Ну, не знаю
— Я переживаю, что этот же текст любой ваш конкурент возьмет себе и это будет правда про него. Давайте что-нибудь такое найдем, чего ни у кого нет, кроме вас
— А, ну вот: в 2007 году, прямо в разгар кризиса, мы наладили совершенно космическую систему поставки... 

И снова время удивительных историй.

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

Это и есть согласование

Согласование помогает сделать то, что клиенту нужно, не допуская попутного говна в работе.

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

Менеджер не может согласовать замечания с клиентом, потому что он не пишет. Он не знает, где хорошая история, а где — плохая. Он не знает ничего о синтаксисе и пользе, о штампах, эмоциях, структуре и заголовках. Менеджер не знает, как правильно.

Только вы знаете, как правильно. Согласовать — это ваша работа, и ничья больше.

Клиентская работа — это не ад

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

А получить замечания к тексту — это не ад. Нужно просто перестроить мозги. Это не клиент-идиот портит вашу работу, это писатель-идиот не слушает клиента.


P. S. Согласование настолько важно, что его в Школе редакторов проходят сразу в двух дисциплинах: переговорах и управлении. В переговорах Синельников учит разбираться в проблеме клиента и искать его боль. В управлении Товеровский учит не раздувать бюджет проекта и не брать на себя лишнее. Набор в школу открыт до 1 декабря. Сейчас в школе учатся 67 редакторов.