Фреймворк в бизнесе что это

Обновлено: 06.07.2024

Сравнительная таблица фреймворков стратегического планирования

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

Инструмент стратегического планирования	Шаг 1. Миссия, видение, ценности	Шаг 2. Формулирование стратегии	Шаг 3. Описание стратегии	Шаг 4. Каскадирование стратегии	Шаг 5. Реализация стратегии
Система сбалансированны показателей	+	++	+++	+++	+++
OKR	+	+	++	++
Hoshin Kanri (Хосин Канри)	+	++	++	++	+
MBO	+	+	++	++
Three Horizons (Три горизонта)	+	++	+
SWOT+S	+++	+
VRIO	+++	+
7-S	+	+++	+
PESTEL	+++	+
GAP-анализ (анализ разрывов)	++	++
Пять сил по Портеру	+++	+
Анализ Парето	++
Анализ ограничений	++
Модели приоритизации	++

Несмотря на то, что оценка вклада достаточно субъективна, мы видим, что с концептуальной точки зрения существует два типа фреймворков:

Фреймворки реализации стратегии. В и числе Система Сбалансированны Показателей (ССП) для общей стратегии и упрощенная система OKR для решения конкретны задач.
Фреймворки формулирования стратегии. SWOT, Three Horizons, Анализ разрывов, PESTEL и так далее, которые помогают организациям генерировать новые идеи (этап 2 процесса стратегического планирования). Большинство подобны фреймворков также помогают описать эти идеи на конкретны диаграмма (шаг 3 стратегического планирования), но не дают рекомендаций по каскадированию и выполнению стратегии.

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

Понимание стратегического планирования

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

Шаг 1. Определите цели высшего уровня. На этом этапе организация определяет свою миссию, видение, базовые ценности и стратегические приоритеты.
Шаг 2. Формулирование бизнес-гипотезы. Следуя идеям, сформулированным в шаге 1, мы теперь можем сосредоточиться на более специфически целя, которые помогли бы нам реализовать миссию.
Шаг 3. Описание стратегии. Любую стратегию лучше всего фиксировать в письменном виде. На этом шаге мы используем стратегические карты и сожие методы для описания стратегии.
Шаг 4. Каскадирование стратегии. Недостаточно просто иметь стратегию высшего уровня. Нам нужно найти способы донести ее до все бизнес-подразделений, команд и отдельны лиц.
Шаг 5. Реализация стратегии. На этом этапе мы сосредоточимся на плана действий и показателя эффективности. В процессе реализации стратегии мы также узнаем что-то новое и будем использовать эти знания на шаге 2.

В уроке 3 бесплатного курса стратегического планирования мы разбираем различные бизнес фреймворки для определения стратегии. Вот полное видео урока:

Фреймворки реализации стратегии

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

Фреймворк Системы Сбалансированны Показателей (ССП)

Это один из самы популярны бизнес-инструментов, особенно в стратегическом планировании. Эта концепция эволюционировала от системы измерения (показателей “сбалансированны” с точки зрения разны перспектив) до признанного фреймворку реализации стратегии.

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

Фреймворк OKR

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

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

Хосин Канри (Hoshin Kanri)

Фреймворк Хосин Канри поож на OKR и BSC:

Фреймворк нацелен на непрерывное совершенствование (цикл “Планирование-действие-проверка-корректировка”)
Подчеркивает важность согласования и обсуждения стратегии (Catchball)
Предполагает отслеживание эффективности сотрудника

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

Они должны располагаться в порядке важности
Они должны быть измеримыми
Они должны быть реалистичными
Они должны соответствовать политике организации
Они должны быть совместимыми друг с другом

На этапе описания стратегии фреймворк проигрывает в выразительны способностя ССП или Хосин Канри, но на уровне реализации стратегии его простота приобретает особую ценность.

Фреймворки формулирования стратегии

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

Три Горизонта (Three Horizons) McKinsey

Фреймворк Three Horizons McKinsey решает задачу инновационного планирования. В нем предлагается определить приоритетность инновационной деятельности в соответствии с тремя временными рамками (горизонтами)

Сейчас.Что-то, что организация должна делать сегодня, например, внедрять инновации в свою основную деятельность.
Ближайшее будущее. Инновации, направленные на решение проблем в зоне комфорта.
Будущее. Сосредоточение внимания на потенциально опасны тенденция.

Фреймворк эффективен при формулировании стратегии, особенно если речь идет об инновационной стратегии.

SWOT+S

Классический Фреймворк SWOT помогает анализировать позицию компании с четыре точек зрения: Сильные стороны, Слабые стороны, Возможности и Угрозы. План действий по SWOT-анализу:

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

С помощью фреймворка SWOT+S мы можем конкретизировать SWOT-анализ, фокусируясь на различны проекция его компонентов. Например, вместо того, чтобы просто говорить о сильны сторона, мы смотрим на силу с разны перспектив: клиента, внутренни процессов, инноваций, финансов.

Такой подод также облегчает использование результатов SWOT-анализа для дальнейшего описания стратегии на стратегической карте K&N.

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

Фреймворк 7-S

Можно ли использовать фреймворк 7-S вместе с ССП? Выводы 7-S могут естественным образом привести к формулированию бизнес-целей, которые отображаются на стратегической карте. Вот что сказал на эту тему Роберт Каплан (Robert Kaplan), один из авторов концепции ССП:
Я считаю, что ССП не только прекрасно совмещается с системой 7-S, но и может повысить ее эффективность.
Роберт Каплан в “Как Система сбалансированны показателей дополняет модель 7-S МакКинси.” [1]

PESTEL

PEST или анализ PESTEL относится к анализу внешни факторов. Что это за факторы?

Политический
Экономический
Социальный
Тенологический
Экологический
Правовой

Выводы анализа PESTEL могут использоваться на этапе формулирования стратегии в процессе стратегического планирования, либо в качестве материала для други бизнес-инструментов, таки как, например, SWOT, либо самостоятельно, в качестве целей на стратегической карте, которые направлены на решение конкретны задач.

Пять сил по Портеру

Система пяти сил занимается вопросами анализа конкурентов. Вместо фокуса только на конкуренции система предлагает построить сперва модель конкурентов, рассмотрев и через призму пяти сил:

Существующие конкуренты
Новые игроки
Рыночная сила потребителей
Рыночная сила поставщиков
Заменители

При создании стратегии неободимо найти факторы конкуренции в контексте каждой из эти сил и сформулировать соответствующую стратегию.

Воспользуйтесь бесплатным планом для доступа к 30 шаблонам ССП, включая Five Forces.

Есть другие системы стратегического планирования, которые помогут вам при анализе конкурентов.

При сравнении с системой SWOT, фреймворк пяти сил предлагает более последовательный подод к анализу конкурентов, в ней анализ начинается с построения модели конкурентов.
По умолчанию в системе пяти сил не учитывается время; имеет смысл использовать ее вместе с системой Тре горизонтов.
Во фреймворке Пяти сил используется подод от общего к частному. В некоторы случая может быть более эффективно перейти от частного к общему (система VRIO).

Проверьте более подробный сравнительный анализ в статье о Пяти сила.

Анализ Парето

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

Ресурсы, неободимые для проверки некоторы гипотез, и
Ожидаемые выгоды от успешной проверки гипотезы (достижение бизнес-целей)

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

Анализ ограничений

Анализ ограничений
План реагирования в условия ограничений
Обновление системы для выполнения плана реагирования
Обновление ограничений
Возврат к шагу 1

Анализ разрывов

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

Вот как анализ разрывов помогает на различны этапа процесса стратегического планирования:

На этапе формулирования стратегии, анализ разрывов поможет найти верное направление для улучшений, основываясь на исторически результата
Во время описания стратегии, результаты анализа разрывов представляются в виде показателей и разрывов (разница между текущим значением показателя и целевым значением)
На этапе реализации стратегии, понимание того, где наодится разрыв (на основе данны показателей), помогает быстро принять корректирующие меры

Модели приоритизации

Формулирование стратегии – это процесс выбора, а выбор – это анализ альтернатив и расстановка приоритетов.

В стратегическом планировании базовая приоритизация осуществляется посредством следующи инструментов:

SWOT-анализ: приоритетные цели являются результатом сопоставления сильны сторон и возможностей или превращения слабостей и угроз в сильные стороны и возможности
Gap-анализ: приоритетными являются цели с наибольшим абсолютным весом и наибольшими несоответствиями в производительности
Анализ Парето: предлагает сконцентрироваться на 20% самы многообещающи целей, однако не объясняет, как выделить эти цели
Стратегические темы ССП: являются приоритетами высшего уровня для остальны стратегически целей

Упомянутые модели являются исодной точкой приоритизации на стратегическом уровне. При переоде на операционный уровень (например, к развитию продукта) нам требуются иные инструменты, способные подсчитать значение приоритета.

В отдельной статье мы рассмотрели некоторые популярные модели приоритизации. Мы также дали несколько конкретны примеров для пользователей BSC Designer.

В контексте стратегического планирования эти модели могут войти в набор инструментов для формулирования стратегии. В сравнительной таблице мы можем поместить и в столбец Этапа 2.

Программное обеспечение для стратегического планирования

В зависимости от модели стратегического планирования изменяется неободимость в автоматизации. Приведем некоторые соображения об эффективном использовании средств автоматизации.

Общие принципы

В каки случая программное обеспечение для стратегического планирования может помочь

Запишите и визуализируйте миссию, видение, ценности, приоритеты

Сочетайте идеи, используя различные шаблоны и бизнес-фреймворки (как обсуждалось выше)

Отобразите бизнес-цели на карте
Свяжите KPI действия и результата с бизнес-целями
Укажите для показателей базовые и целевые значения
Согласуйте инициативы с целями и KPI
Создайте стратегические карты

Назначьте ответственны за цели
Установите связи между системами показателей

Обновите стратегические карты, бизнес-цели, загрузите свежие данные в KPI
Автоматизируйте расчеты ССП, включая весовые коэффициенты, производительность, прогресс, годовые значения (YTD)
Отслеживайте реализацию через KPI (производительность, динамика, стоп-сигналы)
Добавьте комментарии о прогрессе KPI
Визуализируйте производительность на dashboard-а
Разошлите уведомления об изменении индикаторов команде

Программное обеспечение BSC Designer

В каки случая BSC Designer может быть полезным в контексте автоматизации:

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

Выводы

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

В этой статье мы проанализировали наиболее популярные фреймворки для стратегического планирования и обсудили лучшие области и применения.

Действительно, у программистов давно различаются подходы библиотек и фреймворков. Если ваша собственная программа вызывает какие-то стандартные функции -- это библиотека. А если стандартная программа вызывает ваши собственные нестандартные функции -- то эта стандартная программа называется фреймворком. Впрочем, даже не все программисты задумываются над этими различиями. Объясню попроще: или кто-то создает Совершенный Мир, и ваши творения включаются в этот мир как составные части -- это и будет использование фреймворка (объемлющей системы). Альтернативный сценарий: демиур-системописец вы сам, а внешние умельцы будут вами вызываться по потребности -- это использование библиотек (чужого опыта).

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

Хорошо известными фреймворками являются разнообразные "управления" -- проектами, качеством, сервисами, знаниями. Все эти фреймворки описывают, как устроена организационная жизнь в целом -- а ваши конкретные и зависящие от вашей предметной области производственные операции вы выполняете "внутри" этой общей схемы. Иногда фреймворки оформляются как стандарты (например, ISO 20000 -- управление IT-сервисами, или ISO 9000 -- управление качеством), но более часто фреймворки оформляются всякими Body of Knowledge (например, ITIL как Body of Knowledge для стандарта ISO 20000, или PMI PMBoK). Знание фреймворка или соответствие организации работе по фреймворку проверяется разными сертификационными организациями, и поэтому верный признак фреймворка -- это (R) в конце его названия: PMI PMBoK(R), PRINCE2 (R), ITIL(R) и даже Kaizen(R).

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

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

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

Зачастую за понятием «фреймворк» кроется методология проектной работы — инструмент, помогающий командам оценивать актуальность продукта для рынка и реализовывать сложные бизнес-проекты. А еще — генерировать больше полезных идей, которые действительно будут востребованы клиентами. Своим опытом внедрения фреймворка Jobs to be done в крупной B2B-компании (и разработки с его помощью проекта для HR) с нами поделился Юрий Бранковский, продакт-менеджер с успешным опытом работы в компаниях Planner 5D, VCV, Mego.travel.

Юрий Бранковский
Продакт-менеджер, ментор и член жюри хакатонов Emerge и Epam engineering jam

— Фреймворк — это программа или методология, облегчающая разработку и объединение различных частей одного большого или сложного проекта. Ниже я расскажу, как мы внедряли фреймворк Jobs to be done (далее по тексту — JTBD) для B2B-компании, которая занималась разработкой специальных видеоинтервью. Этот продукт был необходим для эффективной работы HR-отделов, поскольку отчасти заменял классические собеседования в компаниях, что позволяло:

Сократить время специалистов на скрининг-интервью кандидатов
Увеличить количество кандидатов, которых может охватить один рекрутер
Получить больше информации о соискателе уже на начальных этапах подбора.

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

Несмотря на то что продукт — видеоинтервью при подборе кадров — выглядел понятным, при попытке создания персон мы поняли, что их количество получалось слишком большим. А если пробовали объединять персоны — портрет пользователя выходил чересчур собирательным и неправдоподобным.

Выяснилось, что HR используют видеоинтервью по-разному, на разных этапах и для разных вакансий. Так мы поняли, что метод создания персон не подходит для решения этой конкретной задачи.

Поэтому мы решили применить фреймворк Jobs to be done, который использует, в частности, компания Intercom, также работающая в B2B-сегменте.

Jobs to be done — это теория о поведении пользователей, которая помогает понять, как и почему люди принимают решение (например, о первой покупке). С помощью JTBD мы можем делать прогнозы о востребованности продукта (или его фичей — ключевых особенностей) на рынке. В основе метода лежит необходимость правильно сформулировать задачу пользователя (покупателя) и определить, насколько фича продукта подойдет для ее решения.

Пример. Видеоинтервью является удобным инструментом для решения задачи первичного скрининга кандидатов по сравнению с очным (оно требует присутствия кандидата и занимает больше времени) или телефонным интервью (вы не видите кандидата).

Задачи те же, а инструмент для рекрутера — новый. Но если инструмент подходит рекрутеру по ряду параметров, то он готов его приобрести.

Задачи, которые должны быть сделаны на этапе разработки продукта

1. Поймите, почему вообще ваш продукт «нанимают»?

Для этого есть шаблон ответа:

Пользователи «нанимают» ваш продукт, чтобы выполнить работу [описание] каждый [частота], когда [контекст]. Другие приложения для выполнения этой работы [описание], но ваш продукт всегда получит работу [название], потому что [причина].

2. Найдите истинных конкурентов

JTBD позволяет глубже рассматривать конкурентов, так как определяет их не по сегменту или персоне, а именно по «работе», которую выполняет продукт.
Не ищите конкурентов по принципу соревнования в смежных или одинаковых категориях.

Ищите тех, кто решает те же самые задачи, что и ваш продукт.

Ваши конкуренты «прячутся» в трех категориях:

3. Задайте вопросы пользователям

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

Вот как он может выглядеть:

Какой инструмент вы использовали перед тем, как купили «приложение»?
Расскажите о «старом решении». Вы можете вспомнить, как хорошо оно работало?
Как изменилась ваша работа после покупки приложения?
Вы были вовлечены в процесс покупки? Кто еще, кроме вас, принимал решение?

Эти вопросы позволят лучше понять контекст использования инструмента — как вашего, так и конкурентов.

4. Определите четыре силы

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

Импульс происходящего: «Мы не успеваем просмотреть всех кандидатов за отведенный период времени. Нам приходится увеличивать период подбора»
Тяга нового решения: «Если мы приобретем сервис интервью, который позволит просматривать больше кандидатов, мы сможем сократить время подбора и качество кандидатов»
Сила беспокойства от того, что может случиться: «А что если новый инструмент не будет интегрирован так хорошо, как нам хочется? Мы попробовали уже три инструмента, и ни один не справился хорошо»
Сила принадлежности к тому, что уже есть, к прошлому: «У нас уже настроены воркфлоу и интеграции, и будет болезненно настраивать все заново».

5. Продумайте переключение на продукт для клиентов компаний

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

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

Что мы сделали:

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

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

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

6. Проработайте период размышления клиента (Consideration set)

В процессе принятия клиентом решения о покупке существует период размышления — время между «активным» и «пассивным» взглядами. Активный связан с расстройством от использования старого продукта, а пассивный — с неуверенностью, что новый продукт решит задачу.

Есть вопросы, которые помогают понять, в каком конкретно состоянии находится пользователь в этот период:

Когда вы принимали решение о приобретении старого продукта, вы изучали, какой инструмент подходит для вашей компании лучше?
Вы были единственным, кто искал решение в то время?
Где вы впервые услышали об инструменте, которым воспользовались?
Можете вспомнить, как вы пришли к решению заплатить за инструмент?
Во время поиска вы или кто-либо другой пробовали другие инструменты? Какие?
Кто принял решение использовать инструмент? Эти люди еще работают в компании? Какие у них роли сегодня?
Сколько прошло времени с начала поиска, прежде чем вы купили старый продукт?
Когда компания начала использовать продукт?

Что мы сделали:

1. Прописали четкие вопросы для клиентов.

2. Для менеджеров по продажам разработали список «железных» аргументов по каждому вопросу.

3. В CRM прописали конкретные скрипты, которые использовали, чтобы помочь клиенту принять решение о покупке.

7. Сделайте обоснование выбора

Итак, первой из причин для выбора JTBD стало преимущество перед методом «персон».

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

Третьей причиной стала проблема — ранее мы не могли проводить количественные исследования (что характерно для многих B2B-продуктов).

Изображение предоставлено героем статьи

Да, продукт изначально был нацелен на рекрутеров. Но среди них были:

Нанимающие менеджеры (рекрутеры)
Директоры по подбору персонала (HR)
Лица, принимающие решения о выделении бюджета (ЛПР).

Одновременно концентрироваться на всех было невозможно — мы бы потеряли фокус в разработке. И тут фреймворк нам снова помог: он позволил компенсировать недостаток количественных исследований за счет возможности проводить интервью с клиентами и не тратить на это много времени.

Внедрение фреймворка JTBD в компании

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

Что мы для этого сделали:

1. Заручились поддержкой стейкхолдера. Объяснили ему, для чего нужен фреймворк и как он поможет разработке продукта, достижению метрик. В частности — что использование фреймворка будет полезным ввиду долгого цикла продаж продукта (условно говоря, вы можете понять, что клиент продлил контракт благодаря какой-то фиче только спустя год после ее релиза, когда перезаключается договор).

2. Взяли преимущества JTBD из «обоснования выбора» и использовали их в качестве аргументов при презентации фреймворка сотрудникам.

3. Проговорили с командой процесс добавления нововведений и объяснили их причины. Это сделали, поскольку внедрение фреймворка связано с определенной шаблонизацией Product Requirements Document (PRD) — документа с требованиями к продукту (аналог технического задания).

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

5. Переписали задачи из бэклога. Так мы показали преимущества JTBD-разработчикам и объяснили на конкретных примерах, как это работает. Вдобавок тем самым мы провели дополнительный груминг (причесывание бэклога).

6. После определенного периода «обкатки» провели митап, на котором рассказали про фреймворк всей компании и раскрыли этапы процесса создания Job Story (истории) и в дальнейшем — фичи продукта. Это сняло окончательные вопросы и синхронизировало разработку и продажи.

А вот как мы использовали фреймворк при работе над проектом.

Внедрение Job Stories

В процессе работы над проектом каждую задачу мы называем Job и прописываем ее путь-формулу, которая называется Job Story. Вот как выглядит ее структура:

[ Когда _____ ] [ Я хочу _____ ] [поэтому мне необходимо _____ ].

Для того чтобы задача выполнялась максимально четко, на каждом этапе Job Story добавляем фокусировку:

[Когда ____ (фокусируется на ситуации)], [Я хочу ____ (фокусируется на мотивации)], и [поэтому мне необходимо ____ (фокусируемся на результате)].

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

Когда мы поняли ситуацию, в которой столкнулись с проблемой, требующей решения, поняли мотивацию к ее решению и выяснили, какова выгода — мы стали увереннее в том, что создаем ценный для клиентов продукт. Вдобавок эти истории можно использовать в отделе продаж для создания контраргументов, скриптов и работы с разными сегментами пользователей (рекрутеры, директоры HR и ЛПР).

Настройка процесса работы

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

Смотрели, как на данный момент люди решают проблему (какую работу для этого выполняют).
Определялись с Job Story, которая исследует причины, беспокойства и мотивацию относительно того, что пользователи сейчас делают.
Предлагали решение, которое выполняет эту работу.

Задача в трекере может выглядеть следующим образом:

Какую проблему мы решаем и почему
Job Story
Как мы измеряем успех (результат)
Что необходимо сделать (список работ заполняется совместно с разработчиками).

При этом в заголовке задачи мы сразу прописывали Definition of Done (DOD) — критерии, которые определяют, сделано ли то, что было целью разработки. Для чего также использовали Job Story.

Пример. DOD пользователь может сделать то-то и то-то согласно макетам.

Изображение предоставлено героем статьи

Дизайн на основе Job Story

Наличие подробного описания помогает и во взаимодействии с дизайнером, который получает больше контекста и может даже представить работу клиента. Например, вот как может выглядеть дизайнерское видение функционала анкеты (если смотреть со стороны пользователя-рекрутера):

Изображение предоставлено героем статьи

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

У каждого продукта есть три уровня использования. Например, когда после интервью с пользователем возникла идея сделать персонализированный лендинг вакансии, этот кейс мы разложили на три уровня:

1. Useful. Что именно я делаю, когда использую конструктор страниц?
Я создаю персонализированное описание, добавляю фото офиса и видеозапись с рассказом генерального директора о нашей компании и о продукте.

2. Usable. Какой результат от использования?
Персональный лендинг, который подробно описывает вакансию и улучшает отношение к бренду.

Таким образом, алгоритм настройки процесса работы выглядит так:

Презентуем фреймворк стейкхолдерам
Презентуем фреймворк команде и коллегам
Создаем шаблоны для упрощения процесса проведения job interview
Создаем шаблоны PRD
Регулярно проводим интервью с клиентами и собираем обратную связь от менеджера продаж (в идеале — уже в формате Job Story)
Регулярно наблюдаем за тем, как пользователи применяют наш продукт (например, мы сами подбирали персонал при помощи видеоинтервью, смотрели скринкасты клиентов, наблюдали, как рекрутеры используют продукты конкурентов).

Заключение

Фреймворк JTBD подходит для использования в B2B-продуктах, так как позволяет работать с разными сегментами пользователей и фокусироваться на проблемах, которые решает для них продукт.

Как и любой фреймворк, JTBD требует внедрения и оптимален, когда вся компания мыслит в одном контексте. Если это так — менеджеры продаж присылают вам готовые Job Story (что ускоряет процесс проверки гипотез и сбора обратной связи), а разработчики мыслят проблемами, а не фичами.

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

Стандартный фреймворк для управления проектами можно разбить на три большие части:

Жизненный цикл проекта. Ключевое различие между методологиями Waterfall и Agile заключается в том, что эти фреймворки включают в себя разные жизненные циклы. Например, фреймворк Waterfall состоит из пяти стандартных фаз:
Подготовительный этап
Планирование
Исполнение
Контроль
Завершение

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

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

Руководство PMBOK описывает фреймворк как базовую структуру для понимания сути управления проектами. Менеджеры проектов выбирают фреймворк, который больше всего подходит для их проекта или команды. Мы объясним, как выбрать соответствующий фреймворк для проекта в разделе Е.

В чем разница между методологией и фреймворком?

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

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

Б. Что общего у Agile-фреймоворков?

Agile-методология управления проектами — это подход к управлению проектами, использующий четыре главных ценности и 12 принципов организации проектов. Agile-фреймворки разработаны для поддержки этих ценностей и принципов.

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

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

В. Фреймворк Scrum

Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.

Как и в случае других Agile-фреймворков, Scrum использует итеративный подход к управлению проектами. Методология Scrum предписывает разбить проект на спринты длительностью от одной до четырех недель. Каждый спринт заканчивается созданием работоспособной версии черновика продукта.

Короткие итерации, свойственные методологии Scrum, позволяют команде последовательно создавать работающий конечный продукт.

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

Scrum считается достаточно простым и гибким, но его трудно освоить из-за трех главных ценностей:

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

Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:

Владелец продукта. Владелец продукта в ходе выполнения проекта — это человек, представляющий интересы клиента. Он имеет право решающего голоса в отношении конечного продукта. Задача владельца продукта заключается в том, чтобы обеспечить понимание требований, функционала и приоритетов, а также воплотить в жизнь все эти аспекты.
Scrum-мастер. Scrum-мастер ответственен за организацию ежедневных совещаний, улучшение взаимодействия в команде и повышение продуктивности. Разница между менеджером проектов и Scrum-мастером состоит в том, что последний стремится быть лидером-служителем. Роль менеджера Agile-проекта часто включает в себя и обязанности Scrum-мастера. Однако он может делегировать эти обязанности участнику команды, который хорошо знает Scrum и обладает организаторскими способностями.
Команда разработки. Команда разработки — это ваша проектная группа. Обычно это самоорганизующийся и межфункциональный коллектив. Команда включает в себя всех сотрудников, необходимых для проектирования, производства, тестирования и выпуска финального продукта.
Scrum-команда. Scrum-команда состоит из команды разработки, Scrum-мастера и владельца продукта.

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

Бэклог продукта. Бэклог — это список задач и требований, которые должны быть выполнены применительно к конечному продукту. За создание бэклога и управление им отвечает владелец продукта.
Спринт. Спринт — это период времени для выполнения набора задач из бэклога. Длительность спринтов должна быть одинаковой. Обычно это две недели, хотя спринт может длиться от одной до четырех недель в зависимости от потребностей команды и проекта.
Планирование бэклога. Планирование бэклога (иногда его еще называют планированием спринта) — это определение задач в бэклоге, которые нужно включить в каждый из спринтов.
Бэклог спринта. Часть бэклога, назначенная текущему спринту.
Ежедневный Scrum. Проектная группа встречается каждый день, чтобы обсудить ход работ за последние сутки, ожидаемый прогресс за следующие сутки и возникающие проблемы. Обычно такие встречи называются ежедневный Scrum или стендап и длятся около 15 минут.
Ретроспектива. Каждый спринт должен заканчиваться обзорным совещанием, которое называется ретроспектива. Команда рассматривает свои достижения и обсуждает возможности что-то улучшить в ходе следующего спринта.
Scrum-доска. Scrum-доска помогает участникам команды видеть бэклог спринта и управлять им. Доска может быть настоящей или виртуальным инструментом в системе управления проектами. Обычно на доске есть три столбца: «К исполнению», «В работе» и «Выполнено». По мере выполнения объектов из бэклога они перемещаются по доске из одного столбца в другой. Поэтому все видят, что им нужно делать в следующем спринте и как продвигается работа.
Артефакт. Бэклог продукта, бэклог спринта и инкремент продукта — это три артефакта Scrum в проекте. Бэклог продукта и бэклог спринта отражают работу, которую нужно сделать, а инкремент продукта — это часть продукта, которую команда создала в ходе текущего спринта.

Г. Другие популярные Agile-методики управления проектами

Хотя Scrum — одна из самых популярных Agile-методик управления проектами, это не единственный доступный для вас вариант. Вы можете задать себе вопрос: что представляет собой Agile-планирование и какой фреймворк следует выбрать? Вы можете выбрать любую из пяти других Agile-методологий управления проектами:

1. Kanban

Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.

Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.

Kanban помогает выявить препятствия и лишние затраты, а также снизить время ожидания.

2. Экстремальное программирование (XP)

Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.

Однако фреймворк XP опирается на принципы проектирования и включает 12 основных приемов, специфичных для сферы разработки программного обеспечения. Это следующие приемы:

Игра в планирование
Частые небольшие релизы
Приемочное тестирование клиентом
Простота проектирования
Парное программирование
Разработка через тестирование
Рефакторинг
Непрерывная интеграция
Коллективное владение кодом
Стандарт оформления кода
Метафора системы
40-часовая рабочая неделя для программистов

3. Функционально-ориентированная разработка (FDD)

Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.

Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:

Разработка общей модели
Составление списка необходимых функций системы
Планирование работы над каждой функцией
Проектирование функции
Реализация функции

4. Метод разработки динамических систем (DSDM)

Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.

Этот фреймворк основан на восьми основных принципах:

Фокус на потребностях бизнеса
Своевременная поставка
Сотрудничество
Постоянно высокое качество
Инкрементный подход на прочном фундаменте
Итеративная разработка
Постоянное и четкое взаимодействие
Демонстрация контроля

5. Crystal

Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.

Является ли бережливое управление проектами (Lean) Agile-фреймворком?

Хотя Lean часто вносят в список Agile-фреймворков, это отдельная методология. Lean и Agile часто группируют вместе, потому что их ценности во многом совпадают. Например, и для Lean, и для Agile важна способность легко адаптироваться к изменениям.

Устранение потерь
Повышение качества
Создание знаний
Отсроченные обязательства
Быстрая поставка
Уважение к людям
Полная оптимизация

Д. Определение эпика Agile

В Agile-методологии управления проектами эпики — это «крупные истории пользователей».

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

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

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

Еще один важный термин — это «тема». Тема — это набор историй пользователей, которые связаны между собой или могут быть отнесены к одной категории. Например, если вы планируете строить дом, то можете сгруппировать все электротехнические требования в одной теме, а требования к качеству строительных конструкций в другой.

История, эпик и тема — это термины, которые используют многие Agile-команды, чтобы упростить обсуждение и планирование бэклога продукта. В бэклоге продукта может оказаться требование, слишком масштабное, чтобы назначить его одному спринту, но если вы обозначите его как эпик, каждый участник поймет, что его нужно разбить на части, прежде чем помещать в бэклог спринта.

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

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

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

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

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

Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.

Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка

Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?

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

Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).

Оцените объемы проекта. Большой длительный проект может быть трудно разбить на двухнедельные спринты. Но если его размах трудно определить и он может расти, то Agile, скорее всего, лучше подойдет, чем более традиционный фреймворк.
Определите движущие факторы проекта. Очень важно знать экономическое обоснование проекта и его ценность для организации. Какие преимущества он даст вашей компании?
Составьте представление о ключевых целях клиента, ожидаемых результатах и приоритетах проекта.
Выявите все факторы, цели, результаты и приоритеты проекта, на которые могут повлиять различные методологии. Например, если ваша цель — максимальная экономичность, возможно, вам подойдет бережливая методология Lean. Если клиент рассчитывает получить подробную документацию, правильным выбором может стать FDD.
Составьте список возможных методологий, подходящих для вашего проекта, и расставьте их по порядку на основе критериев, выявленных на прошлом этапе.
Выбирайте фреймворк, подходящий для большинства факторов, целей, результатов и приоритетов. Если какие-то результаты важнее остальных, можете расставить приоритеты, чтобы не упустить самое важное. Вам нужно выбрать фреймворк, который даст наилучший результат с наименьшим риском.
Выбрав фреймворк, отслеживайте его эффективность. Суть всех Agile-методологий заключается в гибкости и адаптивности. Если выбранная вами методология не дает желаемого результата, следует модифицировать или даже заменить ваш фреймворк.

Ж. Бесплатные инструменты для управления Agile-проектами

Все, что вы используете для управления Agile-проектами, является Agile-инструментом для управления проектами. Самый простой пример — это доска со стикерами, но и многие сложные цифровые инструменты также позволяют работать с Agile-фреймворками, такими как Scrum и Kanban.

Читайте также: