[БЕЗ_ЗВУКА] Как определить цепочки, то есть как перейти от потребностей или решений к цепочкам. Для этого используется такой инструмент, как use cases. Use case — это способ использования, как клиент, у него возникает потребность, и как он потом её решает. Use cases очень активно используются при создании новых продуктов. Очень много в use cases есть инструментов, о которых мы поговорим с вами сейчас. Для того чтобы писать use cases, вы должны как раз посмотреть на последовательность действий и условий, в которых клиент пытается решить свою проблему, с какими объектами он взаимодействует, как он взаимодействует с вашим продуктом, как он взаимодействует с окружающими объектами, как он удовлетворяет потребность сейчас, какие аналогичные продукты используются. Вот это вот всё знание, описание всей этой действительности, оно необходимо для создания use cases. И наука создания use cases, она достаточно древняя, то есть ещё в период создания системы массового обслуживания, создания заводов, создания сервисов больших люди озаботились тем, как описывать сценарии использования и как создавать те продукты, которые будет полезны для клиентов. Один из интересных инструментов — это service blueprint. Это описание, оно большое используется для сервисов, не для продуктов, а для услуг, например, получение кредита в банке. Это некий процесс, и этот процесс, он состоит из нескольких точек касаний, взаимодействий, когда вы подаёте заявку, когда вы оформляете документы, когда вы получаете кредит, то есть есть некий процесс, эти действия пользователя, через который вы проходите. Это действия вас как пользователя, но при этом банк тоже действует, действия какие-то совершает. Причём есть действия, которые вы видите непосредственно, когда с вами общается агент банковский, или действия, которые проходят за кулисами, вы их не видите, но их нужно делать. Собственно, service blueprint как раз описывает эти уровни, то есть есть процесс, действия пользователя, есть действия на переднем крае, то есть что здесь делает система на стыке как бы взаимодействия с пользователем, при этом есть уровень закулисных действий, которые клиент не видит, но которые тоже должны. И эти действия, они как специальные для этого случая, так и могут быть какие-то более общие обслуживающие процессы, которые действуют на заднем плане. Это вот service bluebrint. Другой взгляд на ту же самую картину называется customer journey, когда мы описываем точно так же шаги, действия пользователя. У нас есть действия за кулисами, но у нас ещё добавляется ещё одни слой, который отвечает за удовольствие или неудовольствие пользователей. Как мы помним, наша задача — привести пользователя из грустного состояния неудовлетворённой потребности к прекрасному состоянию решённой, удовлетворённой потребности, решённой проблемы, которая является решением. Но в ходе самого процесса, в ходе цепочки действий, у нас могут быть неприятные какие-то части, например, заполнение, если мы подаём с вами заявку на кредит, нам необходимо заполнить какие-то бумажки, нам необходимо собрать документы. Это не самая приятная деятельность — и удовлетворённость наша может падать. Более того, мы с вами как клиенты можем бросить вообще использовать этот продукт. Если мы видим, что в банке, в который мы обращаемся, слишком тяжело, слишком долго всё делается, мы можем просто по ходу использования продукта бросить его и пойти в другой банк. Точно так же с использованием программного обеспечения. Если клиент становится несчастным, пока он пытается выполнить свою задачу, он просто бросает использовать этот продукт. Или если мы даже используем тот же самый картонный стаканчик, и этот картонный стаканчик может у нас из рук как-то вывалиться и расплескать кофе нам на штаны, это тоже неприятный может быть шаг процесса, который необходимо конструктивным образом изменить. И customer journey как раз фокусируется на слое удовлетворённости или неудовлетворённости пользователя в ходе выполнения задач. Наконец, третий слой и третий уровень, на который мы можем обратить внимание, это фичи, это то, что мы должны с вами создать, запрограммировать, для того чтобы клиент мог пройти по этому пути. И Джефф Паттон предложил интересный подход, когда он разделил, не просто выделил фичи, то есть функции продукта, которые помогают клиенту выполнить шаг нашего use кейса, но и выделил свои, разделил свои по версиям. То есть мы говорим, что в первой версии продукта мы не делаем все фичи, мы не делаем все функции, мы делаем только минимальный набор тех функций, который нам нужен, для того чтобы пройти полностью всю цепочку. На второй версии продукта мы добавляем новые фичи, в третей версии мы добавляем ещё фичи, ещё функции добавляем. То есть у нас возникает по сути некий план разработки продукта, как мы стартуем с минимального набора функций, и как мы дальше наращиваем функции для того, чтобы клиент прошёл полностью всю цепочку.