Управление задачами в плотном потоке проектов подобно жонглированию. Упал один шар из дюжины — это уже большая проблема. Пытаться поднять — увеличивать риски уронить остальные. Забыть про него — представление будет неполноценным. И при любом исходе доверие к профессионализму жонглёра подорвано.

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

Решение этой проблемы мы видим в использовании корпоративных стандартов моделей управления повторяющимися задачами. Корпоративных — потому что стандарты должны быть разработаны до момента найма пиэма. Менеджер может выбирать оптимальное решение для конкретного проекта/команды самостоятельно, исходя из заранее описанных регламентов, а не изобретать новые правила игры для каждого нового случая.

Основа стандартов — 2 типа документов

Воркфлоу (англ., workflow — «поток работ»)

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

Регламенты

Детализируют воркфлоу, описывая, как именно происходит приемка-передача информации / данных / материалов, и какая технология стоит за выполнением каждой задачи.

Я настроил бесперебойную работу в продакшне «Кинетики» в 2 этапа:

Определяем единый процесс работы

• Какова последовательность работ?Ключевые вопросы для формирования единых коммуникационных потоков:

• Кто несет ответственность за каждый этап?

• Какова последовательность коммуникации между сотрудниками/отделами?

• Какие именно происходят коммуникации?

В каждом регулярном процессе задействованы одни и те же специалисты. В коммуникации принимают участие 4 стороны: Специалисты, PM (проект-менеджер), АМ (аккаунт-менеджер) и Клиент. Одна из задач PM: строго следить за этапами производства и последовательностью коммуникаций.

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

Реализация воркфлоу через блок-схемы позволяет отразить большое количество информации в сжатом объеме.

Интерпретация:

— Проект-менеджер ставит задачу на формирование гипотез (1) стратегу, который совместно с оптимизатором формирует гипотезы и передает их пиэму через согласование (где пиэм проверяет соответствие гипотез с брифом).

— Пиэм формирует техническое задание на внесение правок на сайт (2) и передает его стратегу, который совместно с оптимизатором и разработчиками вносит эти изменения (3)через интерфейс VWO и, если есть гипотезы, которые стандартными средствами VWO проверить нельзя, ставит задачу разработчикам на программирование вариации.

— После выполнения задания стратег информирует пиэма о готовности к запуску, пиэм проверяет, тестирует вариацию и дает добро на запуск тестирования. Это считается сдачей работ (4).

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

Ретроспективы. Делаем поток более эффективным

То же самое относится и к сотрудникам, принимающим участие в проекте; каждый может быстро вспомнить, где у него возникают проблемы в работе, а руководитель оперативно исправит эти моменты.Большой плюс такой схемы — возможность ретроспективы проектов, когда нужно разобрать сбой или какую-то проблему при ведении проекта. Руководителю отдела или директору в этом случае понятно: кто, что и когда делал, с кем общался. За несколько секунд можно определить, на каком этапе возникла проблема и где следует поправить регламент, чтобы ошибка не повторялась.

Наверняка, у многих есть талмуд (своя wiki), где написано «все то же самое». Это здорово, но ускоренное восприятие информации через схему — весомый аргумент в пользу воркфлоу. Опыт показывает, что, по сравнению с текстовыми записями или mindmap схемами, такой воркфлоу откладывается в памяти в разы быстрее.

Актуализация воркфлоу и синхронизация бизнес-процессов

1. Добавлена или изменена услуга;Необходимость в этом возникает в двух случаях:

2. В существующем процессе найден баг (неточность / неполнота / нарушены этапы).

По последнему пункту актуализация составляет 90% работы.

Для того, чтобы это было проще реализовывать, рекомендую следить за строгостью исполнения работ в связке CRM-Воркфлоу-Регламенты-Система управления проектами:

• Названия задач и название процессов должны быть строго одинаковыми во всей связке;

• Вложенность задач / процедур, должна точно отражать структуру задач / хранения документов.

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

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

• Внесение изменений в регламентирующие документы;

• Уведомление о изменениях заинтересованных лиц;

• Контроль внедрения изменений (95% времени).

Зачастую все это требует серьезных временных затрат высокооплачиваемых сотрудников.

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

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

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