Исполнитель может отклонить задачу, если не понимает ее важности для компании
Андрей Чумаченко, сооснователь и управляющий партнер агентства перформанс-маркетинга Netpeak, ведет тематический телеграм-канал Sad But True об опыте в управлении, организации рабочих процессов и маркетинге (личный опыт):
Операционная деятельность и вообще вся текучка в практически любом рабочем процессе почти всегда может быть оптимизирована, а иногда даже полностью автоматизированна. Когда начинаете думать про заработок, то понимаете, что лучше разово потратить время и деньги на оптимизацию процесса, чем на бесконечный найм персонала. Чтобы понять, что можно оптимизировать, нужно разложить по пунктам весь процесс (чуть ли не поминутно) по максимально большому количеству кейсов и найти, что можно убрать/ускорить/улучшить.
Систематизация
Для того, чтобы задачи выполнялись хорошо, они должны быть систематизированы. Мы используем в работе ПланФикс – платформу для создания своей собственной системы управления.
Внутри департамента мы создаем разные шаблоны постановки задач, в зависимости от процессов. Но в целом, чтобы поставить задачу сотрудникам департамента маркетинга, нужно ответить на три вопроса и заполнить блоки:
- Зачем нужно сделать эту задачу;
Когда это поле появилось в теле задачи, я выделял около получаса каждый день, блокируя и отменяя задачи – многие постановщики пропускали этот пункт или аргументировали «кто-то сказал, что пора бы уже это сделать». После полутора месяцев борьбы мы донесли важность первого блока как до постановщиков, так и до исполнителей. То есть, исполнитель может отклонить задачу, если не понимает ее важности для компании и считает, что трата времени будет нецелесообразной.
- Что нужно сделать – подробный чек-лист с пунктами, которые должны быть сделаны или отмечены;
- DOD – definition of done, то есть, что именно должно произойти, чтобы считать задачу выполненной.
Ограничения
Конечно, такие системы не работают без ограничений. Первое из них – итерации – временные рамки, на которые делятся блоки работы.
Мы начинали с месячных итераций, потом сократили до двухнедельных и сейчас остановились на недельных, ведь чем короче итерация, тем гибче команда.
Итерация формируется следующим образом: рабочая неделя состоит из 5 рабочих дней по 8 часов, то есть, 40 часов – одна итерация. 5 часов в неделю (1 рабочий час в день) мы оставляем на чай/кофе/перекуры и еще столько же на отчетность, коммуникацию и обучение. По факту остается 30 часов на рабочие задачи.
На покере сотрудник с тимлидом разбирают пакет новых задач и оценивают их в формате «на эту задачу мне нужно будет 3 часа, эту я смогу сделать за 12, а эта слишком затратная по времени и ее лучше разбить на несколько недель». Блок оцененных задач руководитель набрасывает в итерацию (в эти самые 30 часов) и расставляет приоритеты.
В общем, мы пришли к тому, что недельная итерация – это идеальная продолжительность для выполнения задач. Суть итерации в том, что сотрудник фокусируется только на взятых задачах и не берет ничего нового. И, конечно, когда итерация длилась месяц, куча новых и важных задач либо простаивала, либо врывалась в итерацию, нарушая весь процесс. С неделей таких случаев стало сильно меньше и, соответственно, значительно повысилась гибкость работы.
Еще одна штука, которую мы сделали – скрыли новые задачи от сотрудников. У команды задач всегда больше, чем времени на их выполнение, и их бесконечное количество демотивирует самим своим существованием. Поэтому сейчас в рабочем пространстве отображаются только те задачи, которые тимлид набросал в итерацию. Все остальные сохраняются в бэклоге.
В конце каждой итерации происходит ретро (это сокращение от «ретроспектива»), на котором оценивается работа по задачам текущей итерации, также в формате обсуждения. Например, одну из задач сотрудник не выполнил потому, что другие заняли больше времени: неправильно оценили или чеклист был неполный и пришлось искать дополнительную информацию / общаться с постановщиком. Такие углы тимлид должен стачивать на следующую итерацию и, если задачи прилетают нечеткие, – стоит обсудить это с постановщиком.
Отчетность
Когда в команде несколько человек – отчетность в целом и не нужна, ведь я и так всегда знал, кто чем занимается.
Но когда нас стало уже более 15 человек (и при этом некоторые работали из Киева и Харькова, а я руководил процессами из Одессы) – вопрос нельзя было откладывать.
Сейчас у нас есть еженедельные отчеты по итогу итерации в ПланФиксе и отчеты, которые готовят руководители команд и отправляют в закрытый телеграм-канал.
Этот канал общий и крайне желательный к чтению для всей команды – я за синергию, поэтому считаю, что пиарщики должны знать, что делает команда дизайнеров, а дизайнеры быть в курсе, какой контент мы опубликовали на внешних площадках.
Когда-то, в рамках эксперимента, я спрашивал ребят «что ты сделал за месяц такого, о чем не стыдно рассказать маме?». Чуть позже этот эксперимент превратился в ежемесячную задачу для каждого сотрудника. Суть в том, чтобы поделиться завершенными за месяц задачами, которыми ты по-настоящему гордишься. Не просто перечислить все задачи, а субъективно выделить те, которые заставляют чувствовать себя более крутым специалистом.
Синергия
Синергия переплетается с отчетностью, но разберем подробнее.
Мы проводим ежедневные стендапы – встречи, которые запустили до того, как все ушли на самоизоляцию, а последний год такой формат стал как никогда актуальным. Ежедневно команда собирается на 10-15 минут перед обеденным перерывом и рассказывает, что каждый успел сделать вчера и что планирует сегодня.
Есть другой формат встреч – один на один, которые провожу я, как CMO, и тимлиды. Мы говорим о работе, но не о задачах. Я перевоплощаюсь в психолога, а сотрудник может выговориться: что достало, почему выгорает, что драйвит и т. п.
Раз в квартал мы собираемся на встрече 360 и тимлиды делятся победами своих команд. А раз в полгода проводим стратегические сессии, на которых обсуждаем самые важные задачи и тактику того, как можно достичь нужного нам результата.
Делегирование
Все задачи сначала падают на тимлида, после чего попадают в итерацию сотруднику. Путь задачи можно представить в формате воронки и разделить на три блока:
- Backlog – место, в котором собраны абсолютно все задачи:
- любая задача, независимо от того, кто постановщик и какая из команд департамента маркетинга будет исполнителем, попадает в статус новой;
- следующий статус, после того, как тимлид забрал задачу в свой бэклог – ожидает декомпозиции от TL. Процентам 30 задач нужна декомпозиция –разбивка одной большой задачи на 3-4 поменьше;
- ожидает оценки – статус, который задача получает после декомпозиции и в скором времени, после покера, таска будет в работе;
- когда задачу оценили, она переходит в статус готовой к итерации.
- После бэклога задача попадает в работу:
- первый статус – требует действия исполнителя;
- если сотрудник со своей стороны все сделал, но DOD не достигнут, нужно перевести таску в статус «Требует действия третьей стороны». Можно привести пример с публикацией на внешней площадке: сотрудник подготовил текст, отправил в СМИ и договорился о публикации, но материал еще не вышел.
- Финальный этап – проверка:
- после того, как исполнитель посчитал, что достиг DOD, он переводит задачу в статус «Требует действия постановщика» и переводит в «Выполненная», или возвращает в работу, если считает, что нужны доработки;
- выполненные задачи проверяются с тимлидом и завершаются.
Опытному менеджеру все равно, каким отделом заниматься – он везде наведет порядок. Отличие опытного менеджера не в том, что он лучше знает, какие изменения вносить. Ведь зачастую все изменения – очевидные, понятные и адекватные. Фишка в готовности их вносить и умении делать от начала до конца.
Публикации в разделе Дискуссии в формате «Колонка» отображают мнение исключительно автора текста, указанного в начале статьи. Позиция автора колонки может не совпадать с точкой зрения редакции Hubs. Издание оставляет за собой право публиковать мнение других авторов по изложенным в данной статье темам.
