Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости…
У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning, включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектах и операционке мы по себе знаем о чем все также плачут менеджеры — о большей координации, взаимодействии, точности, данных и времени.
Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.
5 принципов Context
Консолидация контекста
Локальное планирование
Систематизация изменений
Процессы на рельсах
Context-driven аналитика и решения
1. Консолидация контекста
Context-driven management
Сегодня в PM и управлении процессами все чаще используют гибридные подходы, совмещая адаптивность и структурность. Потому что работа с одной стороны становится динамичнее, с другой – требует порядка. Соntext – гибрид, который совмещает гибкий и точный подходы через принципы Сontext-driven:
Консолидация – люди, задачи и информация объединяются локально
Гибридность – в управлении совмещаются адаптивность и точность
Структура – задания структурируются релевантно условиям
Контекст – контекст сохраняется и используется
Соntext вводит новую форму гибкости на локальном и проектном уровнях. В отличие от других методов, подход к ведению проекта может меняться в зависимости от условий. Если, к примеру Waterfall – действовать точно, Agile – действовать гибко, то Соntext – действовать контекстно.
New concept in PM
Cоntext вводит новое понятие в менеджмент – Чейн – группа задач/встреч, направленных на выполнение задания. Чейны – пространство задач, сущность, которая существует параллельно с задачами, как более комплексное задание или воркфлоу. Их функция в объединении ресурсов: участников, задач, коммуникаций и контекста – чейны как и задачи могут быть в списках, досках, на Ганте, со статусами, дедлайнами, приоритетами, метками и типами, связанными между собой и другими задачами.
Концепт чейнов можно принять за парент-чайлд связи, или группировку задач по меткам, типам, эпикам. Фактически, чейны – это способ визуализации (и навигации) командных заданий, целей, воркфлоу. Контекст в них – больше чем связанные задачи и атрибуты, это также:
- встречи
- история
- чаты, а/в звонки
- согласования
- ветки
- план и структура
- интерфейс
- внутр/внешн акторы
- формы, страницы, таблицы
- дополнения, изменения, версии
- автоматизация, сценарии
- шаблоны, фреймворки
Гипотеза и решение:
1. Большая часть заданий и воркфлоу – командные.
– Чейны это место и способ визуализации командной работы и взаимодействий.
2. В большую часть заданий вовлечены другие участники: менеджер, другие исполнители или отделы, внешние акторы etc.
– Чейны сохраняют целостность и доступ к данным для всех участников.
3. Большая часть работы – динамический процесс: задачи, обсуждения, правки, дополнения, версии, варианты, согласования.
– Чейны систематизируют изменения и взаимодействия.
4. Координация – слабое место в проектах и процессах.
– В чейнах объединяются люди, данные, план и контекст.
К примеру:
Фидбек от клиента и серия доработок по задаче
Работа над макетом в цепочке действий и согласований
Несколько задач связанных по смыслу/теме
Комплексное задание с несколькими участниками
Задание выполняемое по фреймворку, плану, сценарию
Анализ конкурентов, маркетинговое исследование etc.
Context планирование
В Context’е проект, как и в классических подходах, делится на этапы, которые состоят из Недель (рабочая неделя). В Context’е проект, как и в классических подходах, делится на этапы, которые состоят из Недель (рабочая неделя). В них планируются задачи/чейны, в зависимости от контекста:
Точно – на весь этап, когда есть четкие сроки и условия (подобно Waterfall)
Гибко – в начале каждой Недели, когда нужна адаптивность (подобно Agile)
Гибридно – когда часть этапа или Недели планируется точно, часть гибко
При гибком и гибридном планировании в начале каждой Недели оценивается предыдущая и уточняются приоритеты на следующую.
Внутри Недель планируются как одиночные задачи, так и связанные задачи, которые объединяются в чейны. Между чейнами и задачами могут возникать связи и зависимости, например блокеры или триггеры для действий. Длительность Чейнов зависит от задач в нем. Это может быть как чек-лист в течение дня, так и маркетинговая кампания на несколько месяцев. В длительных – задачи могут находиться на разных Неделях. Хорошей практикой является планирование чейнов, которые не выходят за рамки проектного этапа.
В операционных процессах, например, аккаунтинге или продажах, подход другой. Так как это продолжающиеся подпроекты без точного времени окончания и с планом действий, планирование происходит внутри самих чейнов – шаги в них это и есть этапы (П. 2 - Подпроекты).
Подход к планированию и ведению проекта может меняться в процессе. Подход к локальной организации задач – тоже адаптивный. Такая смарт-организация позволяет выбирать вариант, который максимизирует пользу для проекта в конкретных условиях.
Context connected
Каждый исполнитель постоянно меняет контекст. Это отнимает время на поиск данных, переключение, погружение, коммуникации. Чтобы вникнуть быстро – нужна полнота и связность данных, нужен целостностный контекст. Чейны по своей сути – локальные центры контекста, где каждый участник видит свою задачу и все что с ней связанно: другие задачи, исполнителей, обсуждения, информацию, статусы, сроки, взаимодействия, историю. Цель – максимальная доступность контекста и коллаборация.
Коммуникации – важная часть контекста. Связанные задачи и встречи объединяются в чейны – как запланированные, так и динамические. К примеру:
идет работа над серией задач – и они завершаются встречей
работа над документом ведется в серии задач, встреч и согласований
после встречи в чейне продолжаются связанные задачи/допвстречи
Что делать
Использовать чейны как еще один уровень организации задач
Консолидировать ресурсы и контекст вокруг локальных целей
Использовать гибридную смарт-организацию для ведения проектов
Объединять в чейны связанные задачи и обсуждения
Примеры чейнов
2. Локальное планирование
В Context’е параллельно проектным планированием, используется локальное.
Chain-планирование
Это подход к организации заданий, где задачи связываются в чейны и отображаются как план действий. В ряде рабочих кейсов чейны в разы уменьшают микроменеджмент, улучшая координацию и согласованность в команде. Участники имеют доступ к контексту, лучше понимают логические связи между задачами и роли в заданиях – свою и других.
Сценарии использования чейнов зависят от условий заданий:
Цепочка – последовательные задачи, встречи, согласования. Может планироваться наперед, иметь сроки, при этом сохраняет гибкость и возможность дополнений. Может иметь заголовки для групп задач. Например: работа над документом, макетом, заданием, когда обсуждение и утверждение происходит пошагово с разными участниками.
Связка — группа задач, встреч, согласований где первична контекстная связь между задачами, последовательность может быть, но не обязательна. К примеру, подготовка мероприятия, анализ конкурентов, исследование рынка, параллельное тестирование etc.
Воркфлоу — сценарий действий с условиями “если-то” и триггерами. Используется в процессах с типовым списком действий, может иметь SLA. Например, клиентская заявка на продукт/услугу: создается цепочка задач на нужный отдел, сценарий меняется в зависимости от типа запроса и данных.
Подпроект — комплексное задание, в котором есть свойства проекта: цель, длительность, этапы, план, задачи, сроки, участники. К примеру аккаунтинг клиента, маркетинговая кампания, анализ конкурентов, запуск лендинга, обучение/тренинг.
Хорошей практикой в работе команды является использование чейнов-шаблонов – частые кейсы и задания, где важен план действий сохраняются как фреймворки и сценарии. Например, тестирование, онбординг, обработка фидбека, заявки etc.
Ключевая тактика Context’а – не уходить в овер-менеджмент, когда времени на организацию уходит больше, чем на выполнение задач. Когда это необходимо, команда ставит одиночную задачу, когда необходимо – объединяет задачи/встречи в чейны.
Преимущества чейнов
1. Исключение персональных интерпретаций – через точный порядок действий
2. Уменьшение дискоммуникаций – через объединение участников вокруг заданий
3. Быстрый доступ к информации – через связность контекста в одном месте
4. Улучшение координации – через организацию связанных задач в структуры
5. Создание сценариев бизнес-процессов – через условия и автоматизацию
6. Использование лучших практик – через шаблоны, фреймворки, кейсы
.
Timeview-планирование
В большинстве случаев инструменты планирования – прерогатива менеджера, в Context’е работа со временем ведется в том числе исполнителями. Timeview планирование – это подход к локальной организации задач/встреч на таймлайне, который совмещает точность и гибкость. Визуально это похоже на zoom-in Gant для каждого исполнителя.
Задачи и встречи ставятся участниками на недельный период, персонально или с менеджером:
в течении дня, без точного времени, выше – приоритетнее
c временем начала без времени окончания
c временем начала и конца, когда это необходимо
Назначение timeview-планирования:
визуализировать время как измеряемый и ограниченный ресурс
сопоставлять временной ресурс с объемом работ и приоритетами
дать исполнителям инструмент тайм-менеджмента и самоорганизации
разделять с командой ответственность за сроки и приоритеты
Что делать
Организовывать задачи начиная с локального уровня
В зависимости от сценариев, связывать задачи разными способами
Совмещать адаптивность и точность, учитывая контекст
Работать с задачами во временном представлении
Развивать в команде культуру тайм-менеджмента
3. Систематизация изменений
Динамические чейны
Множество заданий – не закрываются действиями одного исполнителя, а требуют участия других: команды, клиента, менеджера, других отделов, внешних акторов. Работа над задачей или заданием часто – это путь, в процессе которого происходят оперативные рабочие правки, дополнения, обсуждения, ведется работа над версиями и вариантами. Возникают дополнительные задачи, согласования, встречи, ставятся связанные задачи и планируются следующие встречи...
Но на практике все это не систематизировано – разрознена связанная информация, коммуникации, зависимости, ответственности, история. В Context’е команда связывает рабочие процессы в динамический чейн, сохраняя целостность. Изменения сохраняют контекст и становятся структурированными.
К примеру:
Клиент вносит изменения в задание – менеджер связывает новую задачу с предыдущими. Все участники остаются в контексте
После встречи связанные задачи продолжаются в чейне. Сохраняется целостность процесса
Исполнитель ставит допзадачу на другой отдел – в чейне контролируются сроки, статусы, исполнители
Ветки – отклонения от планов
В процессе работы также возникают отклонения от планов, проблемы, блокеры, ошибки, непредвиденные/нестандартные ситуации. В Context они визуализируются в ветках. При необходимости от задач или встреч участник или менеджер создает ответвления – одна или цепочка задач, встреч, согласований. Отклонения от планов становится более наблюдаемыми, анализируемыми, управляемыми, системными.
К примеру:
Задача не выполнена в срок из-за блокеров – нехватки данных или необходимости согласований. Это визуализируется в ветке доп.задач и взаимодействий
Аккаунтер ведет клиента по сценарию и в процессе от него возникают нестандартные запросы на другой отдел — эти задачи/взаимодействия ведутся им в ветке
Один из исполнителей допускает ошибку и задерживает выполнение задания. Обработка этой проблемы ведется в бранче
Что делать?
Связывать изменения и правки с исходной задачей/заданием
Объединять дополнительные задачи/встречи/звонки в единую нить
Вести в цепочках работу над версиями, вариантами и согласованиями
Фиксировать отклонения визуально, чтобы их можно было отслеживать
Конец первой части.
4 и 5 принципы опубликуем в следующей части. Коротко об их содержании:
4. Процессы на рельсах
Порядок и организация процессов – основа любого бизнеса. Компании – это системы. Успешные компании – это системы организованные лучше других. В этом принципе говорится о подходах к построению операционных процессов и постановке их на рельсы. О точности и следовании сценариям, оценке эффективности, автоматизации и контроле.
Ключевые вопросы:
Исключение персональных интерпретаций – через точный порядок действий
Организация процессов – через интеграцию задач в сценарии
Автоматизация процессов – через настройки триггеров, условий, действий
Движение структурированных данных – через поля/формы в задачах
Улучшение координации – через объединение задач, данных и исполнителей
Использование лучших практик – через шаблоны, сценарии, кейсы
Отслеживание эффективности БП – через context-driven analytics
Продолжение следует...
5. Context-driven аналитика и решения
Context-driven analytics (CDAD)
Это in-work анализ данных или событий, при котором на интерпретацию результатов и принятие решений влияет конкретный контекст. Учитываются не только статистические данные или факты, но также Почему, Когда и при Каких условиях. Подход применяется менеджерами – для управленческих решений, в т.ч. оперативных, командой – для ретро и футуроспектив. CD аналитика превращает сухие цифры в истории, на основе которых принимаются более комплексные и взвешенные решения.
Основные принципы CDA:
Пассивный сбор данных — информация фиксируется в процессе работы
Интеграция контекста — учет контекстных факторов: бизнес, временных, событийных, клиентских, технических, операционных
Динамическая интерпретация — в разных условиях те же метрики означают разное
Фокус на действии — анализ предлагает решения, релевантные возможностям и целям
In-work оценка и решения — делается/принимается в процессе работы на разных уровнях
Продолжение следует...