Управление проектами через workflow. Как наладить производство в два шага

Артем Первухин

Продакшн-директор KINETICA

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

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

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

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

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

Регламенты

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

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

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

● Какова последовательность работ?

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

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

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

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

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

В схеме используются следующие обозначения:

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

Возьмем один фрагмент:

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

• Проджект-менеджер ставит задачу на формирование гипотез (1) стратегу, который совместно с оптимизатором формирует гипотезы и передает их PM через согласование (где PM проверяет соответствие гипотез с брифом).
• PM формирует техническое задание на внесение правок на сайт (2) и передает его стратегу, который совместно с оптимизатором и разработчиками вносит эти изменения (3) через интерфейс VWO (Visual Website Optimizer) и, если есть гипотезы, которые стандартными средствами VWO проверить нельзя, ставит задачу разработчикам на программирование вариации.
• После выполнения задания стратег информирует PM о готовности к запуску, PM проверяет, тестирует вариацию и дает добро на запуск тестирования. Это считается сдачей работ (4).

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

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

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

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

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

1. Добавлена или изменена услуга.

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

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

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

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

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

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

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

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

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

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

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

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

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

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