Управление задачами в плотном потоке проектов подобно жонглированию. Упал один шар из дюжины — это уже большая проблема. Пытаться поднять — увеличивать риски уронить остальные. Забыть про него — представление будет неполным. И при любом исходе доверие к профессионализму жонглера подорвано.
Проджект-менеджеру еще сложнее. Жонглера ценят за яркое шоу, а труд проджекта должен быть максимально незаметен. Однако часто в обойме проджект-менеджера накапливается такое количество проектов, что постоянные провалы в каждом из них становятся нормой жизни. И его начинают ценить за шоу по поднятию шаров. То есть за потери ресурсов, потраченных на исправление ранее созданных проигрышных ситуаций.
Решение этой проблемы мы видим в использовании корпоративных стандартов моделей управления повторяющимися задачами. Корпоративных — потому что стандарты должны быть разработаны до момента найма проджекта. Менеджер может выбирать оптимальное решение для конкретного проекта/команды самостоятельно, исходя из заранее описанных регламентов, а не изобретать новые правила игры для каждого нового случая.
Основа стандартов — 2 типа документов
Воркфлоу (англ. workflow — «поток работ»)
Если новичок не сможет за 1 минуту разобраться, как устроено взаимодействие между участниками проекта и на какие этапы делится выполнение услуги, перед нами плохой воркфлоу. Хороший документ позволяет профессионалу за 5 секунд понять, на ком именно застрял процесс, если проект вдруг встал.
Регламенты
Регламенты детализируют воркфлоу, описывая, как именно происходит приемка-передача информации/данных/материалов и какая технология стоит за выполнением каждой задачи.
Мы настроили бесперебойную работу в продакшене «Кинетики» в 2 этапа:
Шаг 1. Определяем единый процесс работы |
Ключевые вопросы для формирования единых коммуникационных потоков:
● Какова последовательность работ?
● Кто несет ответственность за каждый этап?
● Какова последовательность коммуникации между сотрудниками/отделами?
● Какие именно происходят коммуникации?
В каждом регулярном процессе задействованы одни и те же специалисты. В коммуникации принимают участие 4 стороны: Специалисты, PM (проект-менеджер), АМ (аккаунт-менеджер) и Клиент. Одна из задач PM — строго следить за этапами производства и последовательностью коммуникаций.
Для наглядного представления взаимодействия мы разбили работу по каждой услуге на блоки:
В схеме используются следующие обозначения:
Реализация воркфлоу через блок-схемы позволяет отразить большое количество информации в сжатом объеме.
Возьмем один фрагмент:
Интерпретация:
- Проджект-менеджер ставит задачу на формирование гипотез (1) стратегу, который совместно с оптимизатором формирует гипотезы и передает их PM через согласование (где PM проверяет соответствие гипотез с брифом).
- PM формирует техническое задание на внесение правок на сайт (2) и передает его стратегу, который совместно с оптимизатором и разработчиками вносит эти изменения (3) через интерфейс VWO (Visual Website Optimizer) и, если есть гипотезы, которые стандартными средствами VWO проверить нельзя, ставит задачу разработчикам на программирование вариации.
- После выполнения задания стратег информирует PM о готовности к запуску, PM проверяет, тестирует вариацию и дает добро на запуск тестирования. Это считается сдачей работ (4).
Детализацию я описал в регламенте: как именно ставить задачи, где брать шаблон для заполнения гипотез, как правильно их генерировать, как тестировать и т.д. Обычно регламентами пользуются новички или джуниоры, а опытные специалисты обращаются только к воркфлоу, т.к. правила работы и технологии им уже известны и находятся в оперативной памяти.
Шаг 2. Ретроспективы. Делаем поток более эффективным |
Большой плюс такой схемы — возможность ретроспективы проектов, когда нужно разобрать сбой или какую-то проблему при ведении проекта. Руководителю отдела или директору в этом случае понятно: кто, что и когда делал, с кем общался. За несколько секунд можно определить, на каком этапе возникла проблема и где следует поправить регламент, чтобы ошибка не повторялась.
То же самое относится и к сотрудникам, принимающим участие в проекте; каждый может быстро вспомнить, где у него возникают проблемы в работе, а руководитель оперативно исправит эти моменты.
Наверняка, у многих есть талмуд (своя wiki), где написано «все то же самое». Это здорово, но ускоренное восприятие информации через схему — весомый аргумент в пользу воркфлоу. Опыт показывает, что, по сравнению с текстовыми записями или mindmap-схемами, такой воркфлоу откладывается в памяти в разы быстрее.
Актуализация воркфлоу и синхронизация бизнес-процессов |
Необходимость в этом возникает в двух случаях:
1. Добавлена или изменена услуга.
2. В существующем процессе найден баг (неточность/неполнота/нарушены этапы).
По последнему пункту актуализация составляет 90% работы.
Для того чтобы это было проще реализовывать, рекомендую следить за строгостью исполнения работ в связке CRM-Воркфлоу-Регламенты-Система управления проектами:
● Названия задач и название процессов должны быть строго одинаковыми во всей связке.
● Вложенность задач/процедур должна точно отражать структуру задач/хранения документов.
Названия и связи (я делаю их стрелками в xmind) помогут быстро увидеть, как изменения в одном элементе повлияли на остальные процессы. В сфере интернет-рекламы такие связи довольно сильны, изменения в составе услуги несут корректировки в бюджетировании, а это влияет на договорные обязательства, прайс и коммуникации между исполнителями.
Баги во взаимодействии будут находить и сотрудники (но лучше на них не надеяться), и вы при аудите выполнения задач и фидбеков клиента. Но стоит выделять только повторяющиеся сигналы/недовольства/пожелания, а не бросаться править процессы по первому звонку клиента, ведь обновление процедур — непростой этап, который делится на:
● Внесение изменений в регламентирующие документы;
● Уведомление об изменениях заинтересованных лиц;
● Контроль внедрения изменений (95% времени).
Зачастую все это требует серьезных временных затрат высокооплачиваемых сотрудников.
Разрабатывая воркфлоу, не стоит забывать о том, что чрезмерная упорядоченность ведет к тому, что на ее поддержание приходится тратить слишком много времени, а значит, и денег.
Ошибки и неточности есть везде и после определенной отметки, борьба с ними обходится дороже, чем потери от них самих. В то же время тотальный контроль – удовольствие дорогое и сомнительное. Понимание того, какой именно объем процедур требует описания, приходит с опытом. Мне для этого потребовался год непрерывной практики, и теперь я постоянно вижу улучшения.
Итак, в управлении повторяющимися задачами важна согласованность работы команды и менеджера проектов. Ключевую роль в этом играют наглядное описание (бизнес-) процессов и удобство работы с этими файлами.