Темы беседы: 

• Фреймворк - это модель. И у нее есть некие допущения. Эффективность модели и зависит от допущений. 

• Иванов Иван натягивает свой опыт на фреймворк, что же получится?

• Любая стандартизация призвана устранить изменчивость. 

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

• JBTD - для чего его лучше всего использовать.

Кому не подходит вариант статьи, то есть стрим: ссылка на youtube.

Т: Меня зовут Тигран, я автор канала Black Product Owner. У меня есть стартап - это платформа для старшеклассников по профориентации в IT, мы готовим их к поступлению на бюджет в IT-вузы. Работой с продуктами я занимаюсь примерно с 2013-2014 года.

Наша тема сегодня: почему фреймворки не работают.

Говорить будем с Юлией Билинкис — CEO образовательной компании StrategicMove, руководителем образовательных программ в Высшей Школе Бизнеса в ВШЭ, Юля долгое время работала СРО в fintech.Юля ведет телеграм канал Strategic move, а также недавно запустила подкаст Strategic move.

Т - здесь и далее – это автор (сокращение от Тигран), Ю - это гость (вы догадались – Юлия).

Т: Давай сначала определим план нашей беседы, и только потом приступим к ее обсуждению?

Что такое фреймворк

Ю: Для начала дадим определение фреймворку: зайдем от определения продукта и будем говорить о фреймворках применительно к нему. 

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

Продукт как система состоит из взаимосвязанных элементов. Любой продукт можно разложить в виде каких-то элементов. За счет этих элементов и связи между ними достигается цель. В этот момент появляется первая волна фреймворков, которые пытаются разложить продукт на набор элементов. Самый распространенный из таких, это фреймворк связанный с понятием модели Lean Canvas vs Business Model Canvas. Он говорит о том ,что продукт — это не просто вещь в вакууме, а набор взаимосвязанных элементов таких как ценностное предложение, сегмент, монетизация, каналы. Эти элементы взаимодействуют друг с другом для достижения цели. Дальше, каждый из этих элементов может рассматриваться как отдельная система. 

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

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

Тот же Business Model Canvas - хороший инструмент для описания бизнес-модели. Попробуем этот инструмент применить к нашему контексту. 

Тогда фреймворк не работает, потому что применение модели к контексту имеет несколько ошибок, которые допускают люди. Может происходить несостыковка модели и цели. Например, применение Business Model Canvas для того, чтобы понять, что дальше делать в стартапе. Мы не можем с помощью этой канвы ответить на этот вопрос, потому что бизнес-модель — это описание бизнес логики. Она не дает понятия, что делать.

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

Ю: Есть модель и ее применение. Фреймворк — модель, которая показывает логику для достижения целей. Любая модель — это правила, с помощью которых можно что-то сделать или описать. Дальше эта модель “обстукивается” о реальность. Её начинают применять к некоторому контексту, пытаются адаптировать, думают, какие ячейки и чем заполнить, чтобы в них появилась ценность. Многие просто адаптируют готовые бизнес-модели под свой контекст. Модель может прекрасно описывать ситуацию человека, который ее создавал, но при адаптации другими людьми под свои цели часто возникают несостыковки. 

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

Расскажи почему люди это допускают?

Почему фреймворки не работают и как они появляются

Ю: Как фреймворк появляется?

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

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

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

Т: А почему мы считаем, что чей-то опыт и его приложение ценнее нашего? Я часто сталкивался с ребятами, которые говорят: “Только так и никак иначе”. Они не отходят от фреймворка, часто даже боятся адаптировать его под себя и считают что у них проблемы, если фреймворк не до конца им подходит. Почему так происходит?

Почему все пользуются одними и теми же фреймворками

Ю: Каким образом что-то закрепляется как некий доминирующий стандарт?

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

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

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

Почему боимся менять? Потому что доверие к образцу настолько сильное, что может казаться, что нарушим какую-то логику, если будем что-то менять. К самим себе доверие же слабое.

Часто запрос: “Дайте мне шаблон”, присущ джуниор специалистам, которые не уверены в себе. Когда начинаешь расти, начинаешь адаптировать и подстраивать окружающее под свои правила. Стандартизация, как способ повышения эффективности работы, призвана устранить изменчивость. Пока в команде неквалифицированные специалисты, будет запрос на шаблон. Как только команда начнет расти, она начнет отклоняться от фреймворков и создавать что-то свое, уникальное. Важно относиться к любому фреймворку, как к эксперименту и создавать пространство для постоянного улучшения. Это возможно только при разрешении на экспериментирование. Пока команда не дает позволяет себе этого делать, она склонна к использованию чужих фреймворков.

Спиральная динамика и бирюзовость компаний

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

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

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

Разбираем JTBD на примере расшифровки аудио

Ю: Давай поймем, где применять JTBD. Jobs to Be Done — личный фреймворк, был придуман и описан Клейтоном Кристенсеном. По моему мнению, этот фреймворк для первичной сегментации рынка. 

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

С точки зрения продукта, Jobs to Be Done говорит, что людям функционал распознавания аудио не нужен. Jobs to be done — фреймворк который сосредоточен на выявлении недостаточно удовлетворенной потребности в определенном контексте (ситуации). 

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

Jobs to Be Done невозможен без проведения Switch-интервью. В Switch-интервью нужно (1) найти сегмент рынка, который сталкивается с некоторой проблемой, (2) проанализировать существующее поведение клиентов: что ни пытаются сделать при попадании в такую ситуацию,  (3) найти Jobs to Be Done. Исходя из ответов этих людей, формируется представление о сегменте. 

Задаются вопросы: В каком контексте это нужно? Что является триггером? Что за ситуация? Как JTBD сфокусировать на нахождении этой ситуации? 

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

Ю: Давай погрузимся в контекст. Ты на рабочей встрече и страдаешь от того, что на них низкая продуктивность, потому что боишься не сказать что-то важное. Хочешь сделать заметку об этом. Тебе легче записать голосовое, но текст лучше воспринимать и обрабатывать, чем аудио. Возникают контекстные триггеры, на которые ты пытаешься найти решение, улучшающее результат. Дальше начинаешь перебирать решения. Пытаешься найти альтернативу для работы, на которую ты хочешь нанять продукт. Идея JTBD  — найти проблему, для которой клиент имеет недостаточно удовлетворительное решение. Перебирая решения проблемы, понимаешь неудобства и осознаешь, что существует большой сегмент, испытывающий эти неудобства. Потом пытаешься описать этот сегмент через проблемы, с которыми он сталкивается.

Фреймворк JBTD говорит: "Если хочешь описать поведение клиента, используй Job Stories — фреймворк для описания потребности через набор утверждений. Например, когда я готовлюсь к встрече, я хочу зафиксировать свои минутки, чтобы быстро подытожить ожидания от встречи. JBTD— упрощения для понимания этих потребностей.

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

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

Как сделать так, чтобы фреймворки работали

Т: Можно рекомендацию, что делать чтобы фреймворки работали?

Ю: Первое — это здравый смысл. Второе  — ничто не принимать на веру. Здесь полезен тот же научный подход, который можно применять к процессу принятия решений. Нужно экспериментировать с собой и со своим мышлением, осознанно подходить к принятию решений, понять, какой результат хотите получить, зачем вы что-то используете. Очень важно обсуждать это с кем-то, находить обратную связь, учиться не только на своих ошибках, но и на ошибках других людей.

PS спасибо за ваше время, если понравилось, то подписывайтесь на канал https://t.me/blackproduct там регулярно появляются новые стрим с C-level гостями. Телеграм канал Юлии – Strategic move

Спасибо!