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