Текст книги "Молекулярное управление: периодическая система проектных элементов. Свод инструментов проектного управления для создания гибридного подхода на предприятиях"

МЦ – Матриций стейкхолдий (матрица стейкхолдеров)

Фаза реакции: фаза планирования

Область реакции: команда

Валентность (уровень вовлеченности): основные стейкхолдеры

Периодичность: раз в год

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

Матрица стейкхолдеров. PMBoK 7

Для оценки стейкхолдеров существуют две шкалы:

Влияние на наш проект

Отношение к нашему проекту

Матрица стейкхолдеров. PMBoK 6

По итогам анализа стейкхолдеры могут делиться на четыре группы:

1. Те, кто обладает большим влиянием и максимально положительно относится к нашему проекту – это источник наших возможностей.

2. Те, кто очень негативно относится к нашему проекту и обладает максимальным влиянием – это зона рисков.

3. Те, кто плохо относится к нашему проекту, но не имеет влияния – мы на них не забиваем, но держим руку на пульсе.

4. Те, кто хорошо относится к нашему проекту, но не имеет влияния – весьма опасная зона. Если у них нет влияния, их легко переманить на другую сторону – это человеческий фактор. Намного проще переключить в негатив, чем в позитив, поэтому здесь тоже держим руку на пульсе.

Команда должна распределить всех своих стейкхолдеров по такой матрице и решить, что с ними делать (мероприятия для усиления или снижения влияния и изменения отношений). Можно ничего не делать, можно дать ранний прототип или предоставить положительный опыт нашему заказчику, чтобы его отношение ещё больше укрепилось.

Что касается рисков и стейкхолдеров – это две категории документов, которые перетекают из проекта в проект. Единственное, что надо делать, – менять отношение/влияние. Из мероприятий для усиления/снижения влияния/отношения, а также из мероприятий по рискам вы формируете библиотеку действий, решений и практик – список мероприятий, которые можно провести, чтобы проработать стейкхолдеров или риски.

PMI PMBoK6th

Пример матрицы из PMBoK: используется шкала в 8 баллов. Разные размеры и цвет кружочков могут указывать на дополнительные характеристики стейкхолдеров – их значимость, объем инвестиций и т. д.

Стейкхолдеры в проекте: детки в клетке или 300 спартанцев

Не питаю иллюзий, что люди когда-нибудь начнут адекватно общаться.

Что обычно мешает нормально общаться:

1. Лишние стейкхолдеры. Кто все эти люди в проекте, которые стоят в копии писем и никогда не принимают участия в ходе реализации работ? У меня есть проект, в котором можно безболезненно убрать 18 человек из цепочки взаимодействия, и ничего не случится.

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

Проверить, лишний ли стейкхолдер, легко. Задайте несколько вопросов:

Как на него повлияет успешное завершение проекта?

Как на него повлияет неуспешное завершение проекта?

Пострадает ли он, если его не включить в список приглашенных на церемонии?

Пострадаем ли мы, если его не будет на наших церемониях?

Станет ли нам сложнее планировать работы без него?

Повысятся ли риски без него?

Станет ли у нас меньше ресурсов без него?

Станет ли у нас больше ресурсов с ним?

Станет ли нам проще планировать работы с ним?

Будет ли с ним понятнее, что у нас с приоритетами?

Каждый значимый ответ: 10%. Стейкхолдеров со значимостью 0—20% надо исключать. Там все не хитро – они больше мешают, чем помогают.

2. Все очень важные. Под важностью я подразумеваю: «Ну как же, это же Василий Петрович, он 148 лет служит на производстве, без него никак».

У важных персон множество побочных эффектов:

Важные обычно не очень компетентны в рамках современности (провожу ассесмент руководителей с 2008 года, и пока статистика плохая).

Важные обычно очень трусливы и ревнивы. Они не планируют передавать свои знания и опыт, потому что тогда они станут ненужными.

Важные хотят сохранить все как было, потому что важны они только в этих старых условиях. Их сопротивление достигает супер высот.

Важные часто относятся к ветеранам. Чем быстрее их получится убрать от проекта, тем выше шансы на успех.

3. Все очень «заняты».

a. Проблемы с планированием у 80% из нас. Остальные 20% просто забили на это. Какой смысл в стейкхолдере, который вечно занят и не может отреагировать на запрос? Из-за такой занятости простои – обычная история.

b. Загруженный стейкхолдер пропускает церемонии и не принимает участия в важных проектных событиях, а потом запрашивает дашборд на одну страницу за последние 7 лет работ.

c. Такой стейкхолдер даже не ответит полностью на вопрос. Его ответ наверняка прервёт телефонный звонок или подъехавший лифт/такси.

Предупреждайте стейкхолдеров о вовлечённости в проект или просите, а лучше требуйте, чтобы они нашли себе достойную замену. Это лишь один из аспектов. А сколько бессонных ночей бедный РП проводит над матрицей коммуникаций!

Не забывайте, что и вы тоже стейкхолдер. Поэтому сбейте спесь, снимите корону на время, сдуйте щёки и погрузитесь в проект, если он важен и стратегически обоснован.

ЭЙ – Эйзий (матрица Эйзенхауэра)

Фаза ЖЦ: реализация работ

Область применения практики: административная функция

Уровень вовлеченности команды: руководитель или специалист

Периодичность использования: раз в месяц

Матрица Эйзенхауэра

Матрица Эйзенхауэра – инструмент, который используется для управления временем.

Первая область применения инструмента – управленческие практики. Матрица Эйзенхауэра подходит руководителям любого уровня для распределения своих задач. Она может помочь определить задачи для делегирования своим сотрудникам. Техника помогает быстро отсортировать дела на «важные» и «неважные» в бесконечном списке, который у нас с вами есть. Также матрица помогает определить срочные, менее срочные или вовсе не срочные задачи.

Внешне все выглядит просто:

Выпишите свои задачи на неделю.

Ответьте на два вопроса о каждой из этих задач: важна ли она? (да или нет); срочная ли задача? (да или нет).

Распределите задачи по матрице Эйзенхауэра.

Что делать с каждой группой задач?

Вы видите четыре квадранта.

Первый квадрант «А» – внезапные дела, откладывать которые нельзя, и задачи, которые возникли из-за кризисов или форс-мажоров. Это срочные и важные дела. К таким делам относятся критические ситуации на работе, неотложные проблемы, которые появились только сейчас, проекты с горящими сроками. Задачи в этом квадранте стоит выполнять самостоятельно и без отлагательств.

Следующий квадрант «B» – «не срочно, но важно». Задачи в этом квадранте следует планировать как можно тщательнее. Сюда относятся задачи, которым нужно уделять максимум внимания. Здесь есть шанс того, что вы добьетесь своих целей только в размеренном темпе планирования. Сюда относятся текущая работа и задачи, которые есть у вас в рамках проектов и процессов. К этим задачам относятся профилактические мероприятия и любые другие, направленные на улучшение процессов или непрерывные изменения. К этому квадранту также относятся задачи для вас и ваших сотрудников, ориентированные на развитие профессиональных компетенций.

Квадрант «C» – это задачи, которые являются срочными, но не важными. Эти задачи не помогают достичь цели, они иногда мешают сосредоточиться на действительно важном и снижают эффективность. Такие задачи могут быть срочными по причине того, что в них нуждается кто-то другой. Будьте внимательны к этим задачам, делегируйте их, чтобы не отвлекать себя от действительно важных задач. К этому квадранту могут относиться простые дела, но в сжатые сроки – короткие задачи, которые необходимо сделать сейчас, например, ответить на письмо, выполнить просьбу, помочь другим отделам или своим коллегам. Помните, что, делегируя задачи, необходимо регулярно запрашивать обратную связь.

Четвертый квадрант «D» – не важные и не срочные задачи, так называемое «мусорное ведро». К этим задачам относятся приятные дела, которые не приносят пользы. Отдых важен, но он не должен мешать выполнению других задач. Сюда относятся любая второстепенная информация, поглотители времени, разговоры, корпоративные конфликты и прочее, что не влияет напрямую на достижение стратегических целей компании или отдела. Постарайтесь не тратить своё время на подобные задачи в рабочие часы, оставляйте для них легальное время после работы или в рамках обеденного перерыва.

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

Чтобы определить срочность задачи, в первую очередь, обращайте внимание на установленные сроки. Те задачи, у которых есть четкие сроки и последствия от их нарушения, всегда относят к срочным. Те задачи, которые можно переносить бесконечно, относятся к несрочным.

• Распределите задачи по матрице Эйзенхауэра.

• Спланируйте задачи из квадранта «B». Используйте для планирования любую диаграмму (Гантта, линейчатую), либо запланируйте их в свой ежедневник или календарь.

• Составьте список задач, которые нужно делегировать. Определите сотрудников, которым будут делегированы те или иные задачи.

• Посмотрите на задачи из квадранта «D». Выделите на них 30 минут и не тратьте на них больше времени в рамках рабочего процесса.

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

Пример

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

1. Завершить отчет по проекту (дедлайн через два дня).

2. Подготовка к презентации для клиента (дедлайн через неделю).

3. Ответить на письма коллег.

4. Обновить информацию на сайте компании.

5. Провести еженедельное совещание с командой.

6. Участие в корпоративном тренинге по повышению квалификации.

7. Организовать рабочее место.

8. Просмотр новостей в интернете.

9. Помочь коллеге с его проектом (дедлайн сегодня).

10. Подготовить план развития отдела на следующий квартал.

Теперь распределим эти задачи по матрице Эйзенхауэра:

Квадрант A (Срочные и важные задачи)

1. Завершить отчет по проекту (дедлайн через два дня).

2. Помочь коллеге с его проектом (дедлайн сегодня).

Квадрант B (Не срочные, но важные задачи)

1. Подготовка к презентации для клиента (дедлайн через неделю).

2. Провести еженедельное совещание с командой.

3. Участие в корпоративном тренинге по повышению квалификации.

4. Подготовить план развития отдела на следующий квартал.

Квадрант C (Срочные, но не важные задачи)

1. Ответить на письма коллег.

2. Обновить информацию на сайте компании.

Квадрант D (Не срочные и не важные задачи)

1. Организовать рабочее место.

2. Просмотр новостей в интернете.

Теперь спланируем задачи из квадранта B. Для этого можно использовать диаграмму Гантта или календарь:

Планирование задач из квадранта B:

1. Подготовка к презентации для клиента (дедлайн через неделю)

– День 1: Сбор информации и материалов.

– День 2: Создание слайдов.

– День 3: Проверка и корректировка.

– День 4: Репетиция презентации.

– День 5: Финальная проверка.

2. Провести еженедельное совещание с командой

– День 1: Подготовка повестки дня.

– День 2: Проведение совещания.

– День 3: Подведение итогов и рассылка протокола.

3. Участие в корпоративном тренинге по повышению квалификации

– День 1-5: Участие в тренинге (по 2 часа в день).

4. Подготовить план развития отдела на следующий квартал

– День 1: Анализ текущего состояния.

– День 2: Определение целей и задач.

– День 3: Разработка плана действий.

– День 4: Финализация и подготовка презентации плана.

Список задач для делегирования – квадрант С:

1. Ответить на письма коллег – можно делегировать ассистенту или секретарю.

2. Обновить информацию на сайте компании – можно делегировать сотруднику отдела маркетинга или IT-специалисту.

3. Организовать рабочее место – можно поручить офис-менеджеру.

Определение сотрудников для делегирования

1. Ответить на письма коллег – ассистент (Иван Иванов).

2. Обновить информацию на сайте компании – маркетолог (Анна Смирнова).

3. Организовать рабочее место – офис-менеджер (Екатерина Петрова).

ОЧ – Отчетий (отчет о проекте)

Фаза реакции: фаза реализации

Область реакции: административная функция

Валентность (уровень вовлеченности): основные стейкхолдеры

Периодичность: раз в месяц

Помимо формата дорожной карты, существует формат отчёта А3. Он называется «Управление проектом на одной странице». Документ часто используется на этапе инициации и при печати умещается на страницу формата А3. На самом деле, он хорошо читается и в формате А4. Мы печатаем пустые шаблоны, заполняем их на сессиях или мозговых штурмах; такого варианта хватает на одну итерацию. Можно делать как верхнеуровневое, так и детальное планирование.

Отчет А3 (управление проектом на одной странице, пример заполнения)

Формат разработан Кларком Кэмпбеллом. Форму, которую вы наблюдаете, я адаптировала под свои проекты и команды. В документе содержится всё необходимое для мониторинга проекта, планирования или написания выводов в конце отчётного периода.

Что находится в шапке документа:

• указание руководителя проекта;

• цель проекта;

• укороченное название проекта;

• дата создания документа;

• дата старта проекта;

• дата завершения проекта.

Далее начинаем заполнять документ:

Блок 2. Определите цель или цели проекта, сформулируйте их с помощью метода SMART.

Блок 3. Впишите промежуточные результаты из дорожной карты или вехи из диаграммы Гантта или контрольного списка событий. Или просто укажите важные (значимые) промежуточные результаты в ходе проекта.

Блок 4. Декомпозиция. В формате отчёта предполагается верхнеуровневое планирование, однако ничто не запрещает вам удлинить документ и сделать достаточное планирование для управления и анализа.

Блок 5. Выделите наиболее приоритетные задачи. Обычно сюда вписываются задачи из критического пути.

Блок 6. Определите временной шаг для оценки и планирования. Для верхнего уровня используйте шаг в месяц; для более детального планирования – в 2 недели или несколько дней.

Блок 7. Диаграмма Гантта.

Блок 8. Матрица ответственности RACI.

Отчет А3 (управление проектом на одной странице, шаблон)

Вы можете добавить дополнительные блоки. У нас есть блоки 9 и 10.

Блок 9. Основные риски периода.

Блок 10. Основные рекомендации по улучшению на следующий период.

Скачать Отчет А3

МТ – Минтий (пирамида Минто)

Фаза реакции: фаза планирования

Область реакции: развитие

Валентность (уровень вовлеченности): руководитель или специалист

Периодичность: раз в неделю

О пирамиде можете почитать в книге Барбары Минто. Мы используем укороченный вариант – структура для подготовки писем, сообщений, выступлений, презентаций:

1. О чем будет идти речь? (предмет)

2. Какую проблему вы решаете? (вопрос)

3. Каково решение вашей проблемы? (ответ – это и есть главная идея выступления)

4. Какова на данный момент ситуация в этой сфере?

5. Какие существуют трудности?

6. Выявлена ли проблема и решается ли она уже как-то?

Инструмент может быть основой для написания коммерческих предложений, презентаций к бизнес-плану, сообщения об изменениях для персонала компании и т. д.

Структура презентации на основе пирамиды Минто

Пирамида Минто – метод структурирования информации, разработанный Барбарой Минто, консультантом McKinsey & Company. Этот метод помогает эффективно представить информацию, делая её более понятной и убедительной для аудитории.

Основные принципы пирамиды Минто:

1. Главная идея наверху: начинайте с основной мысли или заключения. Это позволяет аудитории сразу понять, о чём идёт речь и почему это важно. Так называемый индуктивный метод размышления.

2. Поддерживающие аргументы: под основной идеей размещаются ключевые аргументы или основные пункты, которые поддерживают главную мысль. Эти аргументы должны быть логически связаны и структурированы.

3. Детали и доказательства: под каждым ключевым аргументом располагаются более детализированные данные, примеры и доказательства, которые подкрепляют каждый из этих аргументов.

Пример применения пирамиды Минто:

1. Главная идея: Компания должна инвестировать в разработку нового продукта.

2. Ключевые аргументы:

Рынок: Существует высокий спрос на этот продукт.

Конкуренция: Конкуренты уже работают в этом направлении.

Рентабельность: Ожидаемая прибыль превышает затраты на разработку.

3. Детали и доказательства:

Рынок: Исследования показывают, что 70% потребителей заинтересованы в этом продукте.

Конкуренция: Три основных конкурента уже запустили аналогичные продукты.

Рентабельность: Финансовый анализ показывает, что инвестиции окупятся в течение двух лет.

ИС – Историй (пользовательская история)

Фаза реакции: фаза реализации

Область реакции: продукт

Валентность (уровень вовлеченности): проектная команда

Периодичность: раз в проект

User stories (пользовательские истории) – это техническое задание. В целом, его можно использовать как шаблон для требований заказчиков или пользователей.

Пользовательская история – формулировка требований и намерений. Пользовательская история не является самым детальным описанием требований, это, скорее, хотелка того, что нужно сделать, чего хотелось бы достигнуть и так далее. Обычно техническое задание пишется отдельно, а уже на основании пользовательской истории разработчики, команда могут спланировать работы и подготовить технический проект. Конечно, мы здесь никогда не увидим каких-то деталей, детализированного описания поведения системы или её технических характеристик, потому что пользовательская история – это требование от пользователя, глубоко не погруженного в технические дебри разработки. Язык пользовательской истории – простой. Позже на основании пользовательских историй, мы, во-первых, создаем бэклог нашего продукта, планируем спринт и идем в разработку.

Принцип INVEST в подготовке пользовательских историй:

Согласно Wikipedia аббревиатура INVEST была разработана в 2003 году Биллом Уэйком как напоминание о том, какой должна быть хорошая пользовательская история. На данный момент этот подход стал стандартом де-факто и активно применяется в проектах с применением SCRUM, Kanban и XP.

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

Пользовательская история должна быть независимой от других пользовательских историй.

Она должна быть обсуждаемой. Заказчик сформулировал свои хотелки в пользовательской истории, но мы должны понимать, что у разработчика может быть альтернативное, более простое или более логичное решение.

Конечно, требование должно быть полезным, должно приносить какую-то ценность нашей системе в целом.

История должна быть оцениваемой, то есть измеримой как в количестве, так и в качестве, или и в том, и в другом.

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

История должна быть тестируемой.

Что делать потом с пользовательскими историями?

С этим уже работают непосредственно разработчики. Они переносят истории на канбан-доску, где набирают задачи в спринт по объему и по приоритетам.

Чтобы историями было удобно управлять, администратор должен регламентировать работу с пользовательскими историями. Это значит, что вы должны прописать следующие три совершенно фундаментальные важные вещи, а все остальное на ваше усмотрение:

Первое – форма пользовательской истории. Эта форма будет в каком-то документе, в Trello или в другом формате.

Второе – легенда, то есть как расставляется приоритет, как определяется размер, в каких единицах и так далее. Это очень важная вещь.

Третье – должно быть описано, каким образом заполняется пользовательская история и как она поступает в разработку. Допустим, от заказчика приходит запрос на изменение от администратора. Ему отправляется форма пользовательской истории, заказчик заполняет её, и пользовательская история возвращается к администратору. Администратор проверяет её на наличие всех необходимых данных и отправляет разработчику с запросом на обратную связь – принимает ли он эту пользовательскую историю или нет. Если разработчик не принимает историю, он должен предоставить четкие комментарии. Администратор, в свою очередь, должен отправить эти комментарии заказчику.

Совершенно точно должна быть указана роль пользователя.

Для администратора это важно, так как вы будете знать, к кому обратиться за уточнениями, и кто будет работать с приемкой результата. Для разработчика важно понимать, кто будет выполнять определенные задачи в этой системе. От роли пользователя может зависеть упрощенная система реализации требований; разработчики могут предложить альтернативные варианты, такие как список ограничений для разных уровней пользователей.

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

Желательно проверять, чтобы были указаны возможность и желание, не просто история «Я хочу», а «Я хочу, чтобы у меня была возможность». Такая формулировка помогает более точно и конкретно обозначить требования.

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

Лицевая сторона карточки

Оборотная сторона карточки, которая используется на ревью или во время тестирования

Хорошая пользовательская история должна содержать указание/обоснование. Разрабатывая шаблон пользовательской истории, вы всегда можете подсказать: «А давайте добавим строку про обоснования, давайте добавим строку с вопросом – какую ценность это добавит нашей системе».

Пример сортировки пользовательских историй в Excel

Пример сортировки пользовательских историй в Excel