Павел Шерер, продюсер, аналитик, продуктовый методолог IT-решений, обратил недавно внимание на метод Карты реализации историй (КРИ). Павел не только прочёл статью, но и написал экспресс-рецензию в своём телеграм-канале. Я благодарен Павлу за внимание к методу Карты реализации историй. Отмечу сначала две самые важные вещи, которые стоит учитывать относительно данной рецензии, а затем разберу отдельные тезисы.
Первая вещь, это отсутствие практики работы с методом. Как заметил сам Павел в нашей переписке, на момент написания рецензии им не было составлено ни одной карты реализации историй, то есть был исключён момент понимания через практику. Понимание метода построено исключительно из чтения статьи. Представьте себе, что кто-то, будь он даже методологически подкован, составил бы своё представление о CJM или USM только по текстовому описанию практики. Это выглядело бы достаточно странным. Как в анекдоте про еврея, который сложил своё представление о Битлз по тому как их песни ему напел другой еврей.
Я в первую очередь практик, и за КРИ стоит как миниму год активной практики 8 дизайнеров нашего дизайн-цеха в проектах в различных предметных областях. Кроме этого это 15 лет практики применения USM. Я обожаю истории и USM и поэтому с трепетом подхожу к их рефлексии и доработкам. До перехода к созданию своей версии метода я практиковал строгую запись по шаблонам пользовательских историй, выявлял в семинарской работе и преподавании, какие истории хорошо работают, а какие плохо, в каких ситуациях и почему. Об этом я подробно писал в серии перечисленных ниже статьей, а также в черновике книги о рабочих историях и эволюции карты историй.
- Руководство по User Story Mapping. Обзор и форматы историй
- Руководство по User Story Mapping. Построение карты и фасилитация
- Руководство по User Story Mapping. Чистка требований и критика метода USM
- Критика метода User Story Mapping
- Апология USM, авторский диалект и вспомогательные практики
Если вам больше подходит смотреть видео, то лучше всего я это разобрал в эфире на канале Системный подход.
Вторая вещь касается того, что Павел рассматривает метод как единственное средство анализа и проектирования, хотя метод таким никогда не задумывался, и применялся в связке нескольких методик. Как было замечено ещё Бруксом, знание о программном обеспечении многомерно, а значит мы вынуждены работать с набором, множеством проекций на плоскость, а не единственной. Так и с КРИ. Это метод, которым детально снимаются требования к инструменту, помогающему на каком-то фрагменте жизни какому-то человеку или важному в деятельности. Таково назначение этого метода, и никакого другого.
Например, как USM, так и КРИ, не лучшим образом берут процесс. Хоть истории в них и укладываются в логике следования, это делается скорее для нашей лучшей навигации по ним, потому что человеку всегда проще ориентироваться в упорядоченных по какой-то закономерности структурах. Однако, если нам важно рассмотреть ветвление в процессе по каналам течения информации или по сложной логике, ни USM, ни КРИ не подойдут. Для этого в нашем комплексе проектирования используется Карта процесса-опыта, коллеги могут применять BPMN, IDEF0, EPC, блок-схемы или что-то ещё.
Метод КРИ как и любое инструментальное средство имеет своё назначение и лучше его применять в тех областях, где он работает хорошо. Он универсален относительно предметной области, потому что основан на универсальной схеме акта деятельности из системомыследеятельностной методологии. Однако его лучше применять в ситуациях, когда вам нужно подобрать или разработать конкретный инструмент для какого-то участка жизнедеятельности. Другие части пазла проектного знания нужно добирать другими методами.
Мы с Александром Бындю, как авторы методов, на каждом шагу при рассказе о конкретном методе оговариваемся, что наши карты (Карта гипотез, Карта процесса-опыта, Карта реализации историй) входят в комплекс проектирования социотехнических систем. Мы твердим, что невозможно построить весь корпус продуктового или проектного знания только по одной из них. Нет королевской карты. Одна отвечает за работоспособную стратегию большого действия. Другая за работоспособный процесс, с учётом опыта всех участников. Третья за подбор адекватных средств для людей на местах в процессе.
Кроме этих трех карт у нас ещё есть небольшой ворох схем и специальных построений, которые тоже бывают крайне важны в проектировании целого. Однако эти три карты мы используем всегда, вот уже 8 лет, потому что они показали максимальную эффективность.
Теперь я прокомментирую конкретные высказывания из рецензии Павла.
Сильные: 1. <...> Здесь, конечно, имеет смысл уточнить, что user story вообще не решает проблему потребности, только задачи. С потребностями лучше справляется job story.
Павел здесь прав, только он здесь умалчивает, что в КРИ идёт работа с рабочими историями, а не с пользовательскими. Рабочие истории — это текстовая модель поведения человека, а в её основе лежит акт деятельности. В бизнесах с ней описывается действие, а в жизни простых людей ею хорошо снимается потребности и поведение в ситуациях.
Вы можете продолжать пользоваться JTBD для построения исследований и выявления потребностей, а всё найдённое прекрасно зафиксируется как в Job Story, так и в рабочей истории КРИ. Кстати, в книге для различения я перевожу Job Story как работные истории, чтобы их отличить от рабочих. Рабочие истории Карты реализации историй относятся к деятельности, поэтому так названы.
Слабые: 1. Тема хорошо работает на уже сформированной бизнес-модели. Если вы — динамичный стартап и ваши метрики определяются в процессе анализа и проектирования, то «чистая» цель вам попросту недоступна. А если корректируются цели, метод по каскаду распадается и карта устаревает уже через спринт.
Здесь возможно произошла ошибка трактовки функционального места «Цели действия». В рабочей истории цель действия отвечает на два вопроса: «зачем вообще» что-то делается и «зачем именно так». Первое создаёт связь с деятельностью как целым, второе давит на способ действия и заставляет выбрать подходящий.
Да, история или часть карты может распасться в любой момент. Это произойдёт в любой момент как только появились новые знания, противоречащие прошлым. Так это же великая добродетель! Если ставить в приоритет спокойствие команды разработки, то тогда, конечно, развал главного смысла производства очень неприятен и нежелателей. Но продолжив без коррекции, вы зароете деньги, а после и демотивируете команду — никто не любит работать в стол.
Если же Павел понял всё верно и говорит о том, что часто нужна проверка боем, перед доскональным изучением, то это дело каждой отдельной продуктовой команды или компании. Скажу здесь лишь своё отношению к такому поиску по-живому без предварительных прикидок. Мне в этом отношении нравится как это сформулировал Пётр Щедровицкий в цикле лекций о мышлении:
Не стоит в рефлексии рассчитывать, что ваша исходная гипотеза имеет хоть какое-то отношение к реальности, но она должна быть, и она должна быть достаточно артикулирована, чтобы вы потом могли подвергнуть ее критике и изменить. Карл Поппер выражает ту же самую мысль в своем определении знания: знание — это то, от чего мы отказываемся, то, что фальсифицируется, то есть имеет такую структуру, в которой присутствует то, от чего мы отказываемся и то, что сохраняем. Если такой структуры нет, то это не гипотеза — Пётр Щедровицкий
Другими словами, если вы не запишете даже ерунду в структуру рабочей истории или в то, что вы будете использовать у себя вместо неё, то после эксперимента вы не получите знание. Нечего будет откидывать, если вы ни на что не сделали ставку. Так можно экспериментировать бесконечно, несясь как тот лось, которого ведёт судьба.
2. Метод держит в фокусе деятельность, а не истинные потребности людей. Всё равно придётся пилить CJM и другие карты опыта. Это значит, что вы устанете синхронизировать эти документы при малейшем изменении любого фактора.
Павел предположил, что КРИ не держит в фокусе потребности. Вероятно перекос в сторону историй с кооперацией вышел из-за того, что их больше всего в статье. Это вскоре исправится в методичке и книге. Для выявления и записи потребностей у карты есть целых четыре слоя: цель действия, носитель действия, ситуация и способ действия. Это помогает зафиксировать всё то, что было в Job Story, которая прекрасно выявляет потребность, и даже больше.
Теперь о том, что «придётся делать CJM». Разумеется придётся. Мы для этого делаем Карту процесса-опыта, которая объединила и развила CJM и Service Blueprint. Как я писал выше для разных вещей нужны разные представления. Нет ни одной карты, способной снимать в своём двухмерном изображении весь корпус знаний.
Про тезис о том, что «вы устанете синхронизировать», остаётся только вздохнуть. Это примерно такой же довод как переживать о том, что рабочий чертёж при новых подробностях со стройки в очередной раз изменится в нескольких проекциях и потянутся изменения в сопутствующих схемах. Это вообще-то часть деятельности проектировщика холить и лилеять командные схемы.
3. Каркас экранов создаётся слишком рано. Да, это не UI в финальном его виде, но все мы знаем, что дизайнеры мыслят картинками. После того, как конкретный лайаут зафиксировался в их нейронных цепочках, он останется там навеки. И никакие исследования потом этого риска не снимут.
Здесь ошибка понимания. Никаких каркасов экранов в КРИ нет. Есть слой со схемой состава. Слой структуры UI это не пространственной структура экранов, а сугубо структурно-смысловая.
Логика движения от истории к макетам при работе с картой такова.
- Выявить объекты оперирования
- Перевести объекты оперирования в информационные, часто с обогащением их свойств
- Разметить информационные объекты на чисто визуальные и интерактивные
- Объединить общие по смыслу объекты в группы. Группам дать смысловые имена
- Если возможно на этом этапе, дать смысловым группам местоположение в имеющейся системе, но чаще всего это дело будущих этапов проектирования.
Причём, если у вас нет каких-то знаний пока, то вы и оставляете пробел в карте. Как только фрагмент знаний найден, возвращаетесь и заполняете его. Это может наступить как через час, день, так и через месяцы — сильно записит от вашей ситуации.
Относительно «фиксации лэйаута в нейронных цепочках». Не знаю о чьём опыте говорил Павел здесь, возможно это флешбэки его работы в корпорациях типа Атома, где он работал, быть может он пояснит подробнее этот момент, я напишу про КРИ.
Технология Карты реализации историй целиком и полностью про то, чтобы всегда, абсолютно всегда подвергать сомнению конечные формы реализации. Именно для этого весь каскад держится разобранным на части, но связным. Это система для размышления и беседы о том, что же мы делаем и почему именно так.
У нас с КРИ работает вся команда, от дизайнера до продуктового управленца. Поэтому кто бы там во что ни влюблялся на уровне макетов, продуктовая культура работы со смыслами потребует это растворить.
4. При большом бэклоге доска становится нефункциональной. Нет прямой связи историй с KPI, нет явного инструмента синхронизаций (а синхронизация Holst/Miro с таск-трекерами — ебля ещё та, поверьте). Так что на реально большом проекте вы будете тратить целого проджекта или двух на синхронизацию доски и трекеров. Классический USM проще, поэтому и синковать его не так сложно.
Для связывания двух вещей достаточно двунаправленной ссылки. Что в Миро, что в Холсте нам хватало ссылки с карточки на доске на карточку в трекере и обратно. При обновлении содержания эти ссылки не слетают.
Никакого отдельного «проджекта» в компании Бындюсофт нет, мы функцию управления успешно распределяем вот уже 13 лет по команде. У заказчика в гибридных командах, где есть мы и разработчики заказчика — тоже никаких дополнительных позиций не выделялось.
Довод про удобное линкование USM совершенно нелепый. Что там, что здесь одинаковые карточки, на которые можно делать ссылки. Неясно какую конкретно проблему тут увидел Павел.
5. Фасилитация, кривая обучения и избыточность на маленьких фичах. Объединил это в один пункт, потому что метод реально сложный. На мелкой хрени типа «добавить оплату через Х» он избыточен. Для полного его понимания и эффективного применения не достаточно просто скинуть статью. Ну и без грамотной фасилитации карта, как я уже сказал, устареет буквально через спринт.
Метод, конечно же, сложнее, чем USM, потому что он способен изучить и взять бо́льшую сложность. Это как минус, так и плюс. Тут никуда не денешься, к сожалению.
Лаконичных материалов в виде методички пока не достаёт, действительно. Над этим идёт работа, не всё сразу. Сейчас уже есть хорошо показавшая себя методичка по Карте процесса-опыта. Вот и здесь предстоит сделать что подобное.
Про «добавление мелкой хрени» мы с Павлом не сходимся идеологически. Я считаю, что всё требует осознания, а Павел, вероятно, некоторые вещи готов заносить «как есть». Я с таким подходом категорически не согласен, потому что так упускается шанс подумать о вариативности замены, а значит сокращения времени и ресурсов — проблема, которая стоит абсолютно всегда.
Я считаю, что думать полезно даже про элементарное. Потому что ничего «элементарного» в продуктах, как правило, нет. Если вы что-то добавляете в продукт по инерции, по отраслевому шаблону или так сказать на «эспертизе», как само собой разумеющееся, то вы уже трубоукладчик в сформировавшейся области. Такое подойдёт, пожалуй, только в случае догоняющего копипаста, когда вы добавляете функции ради гигиенической нормы, потому что, ну, у всех же так. Где-то здесь всё «продуктовое» закончилось.
Есть ещё недостатки, типа сложностей с инкрементальной поставкой и перебором upfront-аналитики, но и так получился лонгрид, телега мне тут пишет минусы в количестве символов
Здесь не поясняется, что не так с инкрементальностью. Никакой проблемы с инкрементальной поставкой у нас, как практиков метода, нет. Здесь Павел судить не может, так как метод не применял.
Если вы не смотрели историю развития метода, коротко отмечу, что я бережно перенёс из USM всё важное и полезное. И, разумеется, я не могу обойти вниманием одну из ключевых особенностей USM — работу с декомпозицией историй и планирование релизов. Здесь пока голословное заявление впроброс. Без аргументации не принимается.
Про «перебор с upfront-аналитикой». Ну, ребят. Перебором в аналитике был RUP. Когда всё анализировалось и проектировалось заранее, писались толмуды спецификаций. Как продолжение изначального подхода с пользовательскими историями, рабочие истории предлагают более строгий универсальный шаблон к заполнению. В нём, ну вот ничего не лишнего, по моему личному опыту. Если на что-то из него нельзя сейчас ответить, значит нет и понимания.
Если мы можем потратить 10 минут на запись одной истории, и заключить, что ясность найдена, когда есть все важные знание и сделаны все допущения, или получить понимание, что куча пробелов, то я не считаю это большими трудозатратами.
такая карта не может быть опорным артефактом комплексного проектирования продукта
По иронии судьбы практика стоит против этого голословного утверждения. Такие ИТ-стройки международная WMS и система организации внешне-экономической деятельности Лемана Про, система проведения соревнований аккробатического рок-н-ролла, высоконагруженная и многослойная система расчёта и настройки тарификации OZON строились вокруг КРИ, КПО и КГ. Конечной детальной картой всегда является КРИ или USM. Так как я ювелирно использовал USM, то и замену сделал без расплескивания важнейшего. Три карты стали прекрасным граничным объектом — объектом, объединяющим работу множества команд со специалистами, говорящими на разных предметных языках.
❦
Я благодарен Павлу за внимание к методу и первый разбор. Все приведённые мной выше аргументы были предъявлены им его аудитории. Это создаёт поле для обсуждения метода и его критики. Буду рад продолжить дискуссию, лучше о практике и с конкретными примерами. Ваши вопросы, примеры и критика помогают развивать подход.