[БЕЗ_ЗВУКА] [БЕЗ_ЗВУКА] Всем привет. В этом видео мы с вами посмотрим, как именно мы можем нарезать наше видение продукта на небольшие, но ценные для нашего заказчика кусочки или поставки этого продукта. Зачастую для заказчика, не знакомого с Agile, который раньше так не работал, бывает сложно согласиться с такой вот поэтапной поставкой продукта. Он приходит к нам и говорит: мне не нужно по кусочкам, вы мне сразу сделайте нормальный продукт, и когда он будет готов, я его начну использовать. Но как мы уже, надеюсь, поняли, разработать в таком режиме действительно продукт, который будет решать проблему пользователя, практически невозможно. Возникает вопрос: как именно мы должны разрезать продукт, чтобы каждая отдельная часть несла для заказчика ценность? Я вам расскажу про такой инструмент, который называется карта пользовательских историй, или user story mapping по-английски. Это такой инструмент, который позволяет взглянуть на наш продукт и его функции через призму целей нашего пользователя и сценариев его поведения. Я буду рассматривать этот инструмент на примере, который я уже использовал в предыдущих видео, а именно на примере приложения для заказа такси. Давайте для начала определим роль нашего пользователя. Назовем ее пассажир. Какова роль пассажира? Предположим, что она звучит так: попасть из точки А в точку Б, из адреса отправления в адрес назначения. Я должен здесь сказать, что в карте пользовательских историй рекомендуется использовать физические артефакты, например, флипчарт, маркерную доску либо даже стену, на которой мы будем размещать стикеры. Выпишем нашу роль и цель нашего пользователя — пассажир, попасть из точки А в точку Б — на стикерах и расположим на флипчарте. Теперь разместим под этими стикерами последовательность действий нашего пользователя, которые он выполняет для того, чтобы достичь своей цели. Итак, предположим, что сначала пользователь заказывает такси, выходит на улицу, находит машину, которую он заказал, садится в нее, доезжает из адреса отправления в адрес назначения и оплачивает поездку. Теперь возьмем первое действие, у нас оно звучит так: заказать такси. И выпишем, какими способами в нашем продукте пользователь мог бы выполнить это действие. Здесь важно понимать, что чем больше мы таких возможностей выпишем, тем лучше. Итак, я выписал три: например, пользователь может указать адрес отправления и адрес назначения просто текстом. То есть наше приложение может автоматически определить адрес отправления с помощью GPS в телефоне, а вот адрес назначения пользователь может указать на карте. Теперь последовательно пройдемся по всем действиям пользователя и в каждом из них выпишем возможные функции, как именно пользователь может решить, то есть выполнить это действие на нашем продукте. Следующее действие звучит так: выйти на улицу, когда машина приедет. Как человек узнает, что машина приехала? Например, он может получить уведомление о том, что машина подъезжает. Либо он может видеть на карте, где именно едет такси. Третий способ — он может, например, принять звонок от водителя, который сам ему позвонит, когда будет подъезжать. Следующее действие — это найти машину и сесть в нее. Как наш пользователь может определить эту машину? Например, увидеть в приложении номер, цвет и марку автомобиля, либо посмотреть, где находится машина на карте. Следующее действие — это непосредственно доехать из точки А в точку Б. Что может делать пользователь в это время? Например, он может видеть маршрут движения на карте, либо видеть пробки по маршруту движения, либо видеть расчетное время прибытия в адрес назначения. И последнее действие — это оплатить поездку. Предположим, что он может сделать это двумя способами: например, оплатить наличными и оплатить банковской картой в приложении. Итак, повторюсь, что вот эти действия называются в оригинале actions, или действия пользователя. А те функции, с помощью которых пользователь может эти действия выполнить, называются по-разному: options, user tasks, или по-простому — задачи пользователя. Будем называть их функциями нашего продукта. Итак, теперь отсортируем функции в каждом экшне, отдельно в каждом столбике, по такому принципу: чем ценнее для пользователя эта функция и чем проще при этом в реализации для нашей команды разработки, тем выше эта функция будет расположена на нашей карте. Пока по мнению владельца продукта, а в следующих видео я покажу более формальные методы для оценки этих функций. Итак, у нас получилось так, что сверху оказались такие функции: то есть для заказа такси пользователь просто указывает адрес отправления и назначения текстом, затем выходит на улицу, когда машина приехала, он просто путем того, что водитель ему сам позвонит, когда подъедет. Пользователь видит номер, цвет и марку автомобиля в приложении. Когда он едет уже непосредственно в такси, он может видеть расчетное время прибытия в пункт назначения. И оплачивает поездку наличными непосредственно водителю. Вот, собственно, набор вот этих функций, которые просты в реализации, но при этом несут ценность нашему пользователю, называются ходячим скелетом нашего продукта, или walking skeleton по-английски. То есть если мы их реализуем в нашем продукте, то наш продукт уже будет покрывать полностью сценарий поведения пользователя для достижения его цели — добраться из точки А в точку Б. Соответственно это мы должны выпустить в первом релизе нашего продукта, чтобы проверить, вообще насколько этот продукт отвечает потребностям наших пользователей. Остальные же функции мы можем аналогичным образом нарезать в последующие релизы, в последующие поставки нашего продукта. Вы спросите: а где же здесь часть функций для таксиста? И будете совершенно правы — для таксиста мы сделаем точно такую же карту. Подведем итог: карта пользовательских историй — это инструмент для проектирования нашего продукта с учетом того, кто есть наш пользователь, какая у него цель и какие у него сценарии достижения этой цели. Этот инструмент также позволяет нарезать наш продукт на небольшие и ценные кусочки, для того чтобы выпускать продукт последовательно — итеративно и инкрементально. В следующем видео мы рассмотрим более подробно методы оценки пользовательских историй в бэклоге. [ЗВУК]
