Как стать автором
Поиск
Написать публикацию
Обновить

Context. Гибридный метод организации проектов и рабочих процессов

Время на прочтение9 мин
Количество просмотров2.4K

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

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

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

5 принципов Context

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

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

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

  4. Процессы на рельсах

  5. 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-планирование

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

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

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

Sequence
Sequence

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

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

Workflow
Workflow

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

Subproject
Subproject

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Timeview
Timeview

Что делать

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

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

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

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

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

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

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

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

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

Example of dynamic chain
Example of dynamic chain

К примеру:

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

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

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

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

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

Example of branch in chain
Example of branch in chain

К примеру:

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

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

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

Что делать?

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

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

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

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

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

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

4. Процессы на рельсах

Порядок и организация процессов – основа любого бизнеса. Компании – это системы. Успешные компании – это системы организованные лучше других. В этом принципе говорится о подходах к построению операционных процессов и постановке их на рельсы. О точности и следовании сценариям, оценке эффективности, автоматизации и контроле.

Ключевые вопросы:

  1. Исключение персональных интерпретаций – через точный порядок действий 

  2. Организация процессов – через интеграцию задач в сценарии

  3. Автоматизация процессов – через настройки триггеров, условий, действий

  4. Движение структурированных данных – через поля/формы в задачах

  5. Улучшение координации – через объединение задач, данных и исполнителей

  6. Использование лучших практик – через шаблоны, сценарии, кейсы

  7. Отслеживание эффективности БП – через context-driven analytics

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

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

Context-driven analytics (CDAD)
Это in-work анализ данных или событий, при котором на интерпретацию результатов и принятие решений влияет конкретный контекст. Учитываются не только статистические данные или факты, но также Почему, Когда и при Каких условиях. Подход применяется менеджерами – для управленческих решений, в т.ч. оперативных, командой – для ретро и футуроспектив. CD аналитика превращает сухие цифры в истории, на основе которых принимаются более комплексные и взвешенные решения.

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

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

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

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

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

  • In-work оценка и решения — делается/принимается в процессе работы на разных уровнях

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

Теги:
Хабы:
+6
Комментарии0

Публикации

Ближайшие события