Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… 

У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning, включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. 

Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

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

4 принципа Context

1. Консолидация контекста

2. Локальное планирование

3. Систематизация изменений

4. Context-driven аналитика и решения
   

1. Консолидация контекста

New concept in PM   

Cоntext вводит новое понятие в менеджмент – Чейн – группа задач/встреч, направленных на выполнение задания. Чейны – пространство задач, сущность, которая существует параллельно с задачами, как более комплексное задание или воркфлоу. Их функция в объединении ресурсов: участников, задач, коммуникаций и контекста – чейны как и задачи могут быть в списках, досках, на Ганте, со статусами, дедлайнами, приоритетами, метками и типами, связанными между собой и другими задачами.

К примеру:

• Фидбек от клиента и серия доработок по задаче

• Работа над макетом в цепочке действий и согласований

• Несколько задач связанных по смыслу/теме

• Комплексное задание с несколькими участниками

• Задание выполняемое по фреймворку, плану, сценарию

• Анализ конкурентов, маркетинговое исследование etc.

Context-driven management

Сегодня в PM и управлении рабочими процессами все чаще используют гибридные подходы, совмещая адаптивность и структурность. Потому что работа с одной стороны становится динамичнее, с другой – требует порядка. Соntext – гибрид, который совмещает гибкий и точный подходы, развивая идею context driven.

Context-driven подход базируется на четырех принципах:

• Консолидация – люди, задачи и информация объединяются локально

• Гибридность – управление объединяет адаптивность и точность

• Структура – задания структурируются релевантно условиям

• Контекст – контекст сохраняется и используется

Context планирование

В Context’е проект, как и в классических подходах, делится на этапы, которые состоят из Недель (рабочая неделя). В Context’е проект, как и в классических подходах, делится на этапы, которые состоят из Недель (рабочая неделя). В них планируются задачи/чейны, в зависимости от контекста:

• Точно – на весь этап, когда есть четкие сроки и условия (подобно Waterfall)

• Гибко – в начале каждой Недели, когда нужна адаптивность (подобно Agile)

• Гибридно – когда часть этапа или Недели планируется точно, часть гибко

При гибком и гибридном планировании в начале каждой Недели оценивается предыдущая и уточняются приоритеты на следующую.  

Внутри Недель планируются как одиночные задачи, так и связанные задачи, которые объединяются в чейны. Между чейнами и задачами могут возникать связи и зависимости, например блокеры или триггеры для действий. Длительность Чейнов зависит от задач в нем. Это может быть как чек-лист в течение дня, так и маркетинговая кампания на несколько месяцев. В длительных – задачи могут находиться на разных Неделях. Хорошей практикой является планирование чейнов, которые не выходят за рамки проектного этапа.

В операционных процессах, например, аккаунтинге или продажах, подход другой. Так как это продолжающиеся подпроекты без точного времени окончания и с планом действий, планирование происходит внутри самих чейнов – шаги в них это и есть этапы (П. 2 - Подпроекты).

Соntext вводит новую форму гибкости в проектах, которая отталкивается от задач. Если, к примеру Waterfall – действовать точно, Agile – действовать гибко, то Соntext – действовать контекстно. Подход к ведению проекта может меняться в процессе. Подход к локальной организации задач – также адаптивный. Такая смарт-организация позволяет выбирать вариант, который максимизирует пользу для проекта в конкретных условиях.

Context connected

Каждый исполнитель постоянно меняет контекст. Это отнимает время на поиск данных, переключение, погружение, коммуникации. Чтобы вникнуть быстро – нужна полнота и связность данных, нужен целостностный контекст. Чейны по своей сути – локальные центры контекста, где каждый участник видит свою задачу и все что с ней связанно: другие задачи, исполнителей, обсуждения, информацию, статусы, сроки, взаимодействия, историю. Цель – максимальная доступность контекста и коллаборация.

Коммуникации – важная часть контекста. Связанные задачи и встречи объединяются в чейны – как запланированные, так и динамические. К примеру: 

• идет работа над серией задач – и они завершаются встречей

• работа над документом ведется в серии задач, встреч и согласований

• после встречи в чейне продолжаются связанные задачи/допвстречи

Что делать

• Использовать чейны как еще один уровень организации задач

• Консолидировать ресурсы и контекст вокруг локальных целей

• Использовать гибридную смарт-организацию для ведения проектов

• Объединять в чейны связанные задачи и обсуждения

Примеры чейнов

2. Локальное планирование

В Context’е параллельно проектным планированием, используется локальное.

Chain-планирование

Это подход к организации заданий, где задачи связываются в чейны и отображаются как план действий. В ряде рабочих кейсов чейны в разы уменьшают микроменеджмент, улучшая координацию и согласованность в команде. Участники имеют доступ к контексту, лучше понимают логические связи между задачами и роли в заданиях – свою и других.

Сценарии использования чейнов зависят от условий заданий:

Цепочка – последовательные задачи, встречи, согласования. Может планироваться наперед, иметь сроки, при этом сохраняет гибкость и возможность дополнений. Может иметь заголовки для групп задач.  Например: согласование документа, когда обсуждение и утверждение происходит пошагово с разными участниками.

Связка — группа задач, встреч, согласований где первична контекстная связь между задачами, последовательность может быть, но не обязательна. К примеру, подготовка мероприятия, анализ конкурентов, исследование рынка, параллельное тестирование etc.

Воркфлоу — сценарий действий с условиями “если-то” и триггерами. Используется в процессах с типовым списком действий, может иметь SLA. Например, клиентская заявка на продукт/услугу: создается цепочка задач на нужный отдел, сценарий меняется в зависимости от типа запроса и данных.

Подпроект — комплексное задание, в котором есть свойства проекта: цель, длительность, этапы, план, задачи, сроки, участники. К примеру аккаунтинг клиента, маркетинговая кампания, анализ конкурентов, запуск лендинга, обучение/тренинг.

Хорошей практикой в работе команды является использование чейнов-шаблонов – частые кейсы и задания, где важен план действий сохраняются как фреймворки и сценарии. Например, тестирование, онбординг, обработка фидбека, заявки etc.

Ключевая тактика Context’а – не уходить в овер-менеджмент, когда времени на организацию уходит больше, чем на выполнение задач. Когда это необходимо, команда ставит одиночную задачу, когда необходимо – объединяет задачи/встречи в чейны.

Преимущества чейнов

1. Исключение персональных интерпретаций – через точный порядок действий  
2. Уменьшение дискоммуникаций – через объединение участников вокруг заданий
3. Быстрый доступ к информации – через связность контекста в одном месте
4. Улучшение координации – через организацию связанных задач в структуры
5. Создание сценариев бизнес-процессов – через условия и автоматизацию
6. Использование лучших практик – через шаблоны, фреймворки, кейсы
.

Timeview-планирование

В большинстве случаев инструменты планирования – прерогатива менеджера, в Context’е работа со временем ведется в том числе исполнителями. Timeview планирование – это подход к локальной организации задач/встреч на таймлайне, который совмещает точность и гибкость. Визуально это похоже на zoom-in Gant для каждого исполнителя.

Задачи и встречи ставятся участниками на недельный период, персонально или с менеджером:

• в течении дня, без точного времени, выше – приоритетнее

• c временем начала без времени окончания

• c временем начала и конца, когда это необходимо

Назначение timeview-планирования:

• визуализировать время как измеряемый и ограниченный ресурс

• сопоставлять временной ресурс с объемом работ и приоритетами

• дать исполнителям инструмент тайм-менеджмента и самоорганизации

• разделять с командой ответственность за сроки и приоритеты

Что делать

1. Организовывать задачи начиная с локального уровня

2. В зависимости от сценариев, связывать задачи разными способами

3. Совмещать адаптивность и точность, учитывая контекст

4. Работать с задачами во временном представлении

5. Развивать в команде культуру тайм-менеджмента
   

3. Систематизация изменений

Динамические чейны

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

Но на практике все это не систематизировано – разрознена связанная информация, коммуникации, зависимости, ответственности, история. В Context’е команда связывает рабочие процессы в динамический чейн, сохраняя целостность. Изменения сохраняют контекст и становятся структурированными.

К примеру:

• Клиент вносит изменения в задание – менеджер связывает новую задачу с предыдущими. Все участники остаются в контексте

• После встречи связанные задачи продолжаются в чейне. Сохраняется целостность процесса

• Исполнитель ставит допзадачу на другой отдел – в чейне контролируются сроки, статусы, исполнители

Ветки – отклонения от планов

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

К примеру:

• Задача не выполнена в срок из-за блокеров – нехватки данных или необходимости согласований. Это визуализируется в ветке доп.задач и взаимодействий

• Аккаунтер ведет клиента по сценарию и в процессе от него возникают нестандартные запросы на другой отдел — эти задачи/взаимодействия ведутся им в ветке

• Один из исполнителей допускает ошибку и задерживает выполнение задания. Обработка этой проблемы ведется в бранче

Что делать?

1. Связывать изменения и правки с исходной задачей/заданием

2. Объединять дополнительные задачи/встречи/звонки в единую нить

3. Вести в цепочках работу над версиями, вариантами и согласованиями

4. Фиксировать отклонения визуально, чтобы их можно было отслеживать

Конец первой части.

4 принцип опубликуем в следующей части. Коротко о его содержании:

4. Context-driven аналитика и решения

Context-driven analytics (CDAD)

Это быстрый inwork анализ данных или событий, при котором на интерпретацию результатов и принятие решений влияет конкретный контекст. Учитываются не только статистические данные, но также Почему, Когда и при Каких условиях. Подход применяется менеджерами – для управленческих решений, в т.ч. оперативных, командой – для ретро и футуроспектив. CD аналитика превращает сухие цифры в истории, на основе которых принимаются лучшие решения.

Основные принципы CDA:

• Пассивный сбор данных — информация фиксируется в процессе работы

• Интеграция контекста – учет контекстных факторов: бизнес, временных, событийных, клиентских, технических, операционных

• Динамическая интерпретация – в разных условиях те же метрики означают разное 

• Фокус на действии – анализ предлагает решения, релевантные возможностям и целям

• Оперативные решения – принимаются в процессе работы в т.ч. на локальном уровне

Продолжение следует.