Что, если пользовательские истории не работают? Что, если заказчик не понимает, чего он хочет, а команда тонет в предположениях? Андрей Шапиро  @xraizor — дизайнер интерфейсов и соавтор фреймворка проектирования социотехнических систем — рассказывает о «Карте реализации историй» (КРИ) — практическом методе проектирования, который помогает вытащить смысл из хаоса, превратить знания в структуру и наконец-то начать делать сложные продукты осознанно.

Что такое карты реализации историй и откуда они взялись?

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

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

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

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

Если переносить аналогию с историями на мир IT, то в какой-то момент стало очевидно: большинство ПО делают разработчики — и только они. В итоге накапливался гигантский долг по юзабилити, хотя тогда мы этого слова ещё не знали. Люди просто не понимали, как пользоваться тем, что мы делаем. Так постепенно и зародилось то, что позже назвали UX-дизайном.

Это время — конец 90-х, начало 2000-х — было настоящим кипящим котлом. Технологи, бизнес и пользователи начали друг с другом разговаривать. А это, поверьте, непросто: даже внутри одной команды договориться тяжело, а тут три разных языка. Именно тогда пользовательские истории стали спасательным кругом. Они позволили говорить на общем диалекте, «пиджине»: достаточно простом, чтобы каждый мог объяснить, что хочет — и быть понятым.

Первые пользовательские истории, которые тогда формулировались, были максимально про софт.  Типа: «Я ввожу индекс, и город подставляется сам». Пример из тех времён, который приводил Кент Бек. Такие истории описывали маленькие удобства — микрофичи.

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

Это было прогрессом. Но, как оказалось, структура сама по себе далеко не всегда решает проблему.

За эти годы появилось много разных шаблонов пользовательских историй. Я писал об этом и в статьях, и на вебинарах про User Story Mapping. У каждого шаблона есть своё достоинство: если один не «ловит волну», переключаешься на другой — и сигнал проходит. Это действительно помогало — особенно в команде.

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

Если оглянуться назад, то бурное развитие пользовательских историй шло лет десять, с конца 90-х. И строилось оно вокруг двух опор. Истории помогали быстрее понимать друг друга, и истории организовывали разработку. Истории помогали планировать: оценивать, расставлять приоритеты и выделять релизы. Истории мастерски связывали задачи со смыслами. Поэтому они так надолго закрепились.

Если вспомнить, как всё развивалось — ключевые идеи пришли за первые 10 лет. Кент Бек говорил: «нужно понимать, кто и зачем пользуется» — отсюда и акцент на пользовательских историях. Элестейр Коберн добавил важное: история — это не документ, а общения будущей беседы, повод поговорить, уточнить и договориться.

Потом появились знаменитые три С:
Card — карточка с историей,
Conversation — обсуждение,
Confirmation — подтверждение.

Добавились приёмочные тесты, декомпозиции (вроде INVEST и паттернов Лоренса), и конечно, story mapping от Джеффа Паттона, где истории раскладываются в виде карты. Всё это здорово помогало именно в планировании.

Вот основные вехи в развитии пользовательских историй:

— 1997, Кент Бэк: понимать кто и зачем использует софт через истории

— 1998, Кокберн: «История — это токен, обещание беседы»

— 2001, Рон Джеффрис: Card, Conversation, Confirmation

— 2003, Билл Уейк, Критерии декомпозиции историй INVEST

— 2008, Джефф Паттон, Техника USM организации бэклога из историй

— 2009, Ричард Лоуренс, Паттерны декомпозиции историй

После этих вех ничего принципиально нового с историями давно уже не происходило.

Как я пришёл к Карте реализации историй

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

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

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

Я делился опытом записи историй на практикумах, в том числе на ProductSense, и всё время наблюдал: у кого-то получается писать истории, у кого — нет. Мне стало интересно почему, и я задумался как с этим помочь другим. Именно отсюда берёт начало разработка Карты реализации историй.

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

Если опереться на теорию деятельности, любое осмысленное действие складывается из трёх элементов:
— цели (или смысла);
— ситуации, в которой действие актуально;
— и средств, которые позволяют это действие совершить. Это могут быть инструменты, знания, навыки, что угодно.

Если чуть адаптировать шаблон user story под это, получается примерно так:

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

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

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

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

Я много об этом писал — в том числе в серии статей по user story mapping, где разбирал шаблоны и то, что реально сработало у меня в практике.

А потом мы с коллегами из «Бындюсофт» и других компаний собрались в консорциум исследования интерфейса. И по дороге нас всё чаще стал мучить вопрос: почему так трудно писать хорошие истории?

Трудности написания историй

Мы задавались этим не теоретически — а из практики. Мы сами обучаем дизайнеров, проектировщиков, и каждый раз видим, где они спотыкаются. Нам важно было понять, в чём именно затык — и как с этим можно работать.

Мы часто сталкивались с тем, что новичкам тяжело писать истории. Чтобы понять, в чём именно затык, мы начали разбирать ситуации и искать причины. Постепенно вырисовался список типичных затруднений, с которыми все сталкиваются при работе с пользовательскими историями:

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

Но стоило выйти за пределы очевидного — начинались проблемы. Лаконичные истории переставали «держать» смысл. Их было сложно читать, сложно объяснять, и уж точно — сложно использовать в проектировании.

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

Во-первых, непонятно, что именно описывать. Во-вторых, терминов — тьма. В-третьих, читая такую историю, ты просто не можешь восстановить контекст: что за задача, кто её решает, зачем и как. Лаконичный формат тут бессилен — одно сплошное следование шаблону без смысла.

И тут проявляется слабое место всей модели. Помните «три С»: Card, Conversation, Confirmation? Так вот, с Card может вообще не сложиться — история долго не появляется, потому что идёт сплошное обсуждение, одно за другим. Сам автор подхода трёх С позже признал: да, карточки могут рождаться не сразу. Сначала — разговор, понимание, совместное копание в контексте. Только потом — запись.

Я думаю, всё это началось с того, что мы в ИТ собрали все «низковисящие фрукты». Пока agile применяли к простым задачам — всё работало. Но когда подходи вернулся в корпорации и стал применяться к сложным B2B-системам, стало очевидно: старые методы буксуют.

Во-первых, карточки писались долго. Иногда история и вовсе не формулировалась — только разговоры, обсуждения, штурмы. Во-вторых, даже если история была, третья «С» — Confirmation — давала сбой: разбить задачу на приёмочные тесты оказывалось почти нереально. Белых пятен оставалось слишком много. Индустрия на это отреагировала спайками — исследовательскими итерациями. Но если подумать, сама необходимость много и долго разговаривать с заказчиком уже говорит о пробеле в методе. Длина беседы как показатель зрелости подхода? Не очень.

Беседа — важна, это факт. Но если есть способ сократить её длину без потери смысла — это уже инженерное улучшение. И если можно сократить объём исследовательской итерации — тем более. Именно это и стало для меня вопросом: а можно ли сделать лучше? И как?

Фанатизм «пользовательскости». Истории до сих пор повёрнуты на пользователя так, будто других интересов не существует. Пример: «Я как потребитель хочу чаще получать анонсы акций…» — звучит благородно, но мы же понимаем: это не пользователь просит, это бизнес хочет его закидать пушами.

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

Истории пора принимать любые типы требований. Табуретка Нормана — с её тремя ножками: технология, бизнес, пользователь — до сих пор актуальна. И если мы хотим развивать подход, надо учесть всё, а не тянуть сову на глобус.

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

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

В таких случаях я иногда честно писал в истории: «делать что-то эдакое». Это лучше, чем выдумывать кнопку просто потому, что «надо что-то вставить». История — не только про готовые решения. Она должна уметь удерживать и неопределённость тоже.

Пустая или липовая ценность. Шаблон, как водится, стерпит всё. Иногда встречаешь вот такое: «Я как пользователь хочу применять множественные фильтры, чтобы ограничить область отображаемых данных». И что тут не так?

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

Я это увидел в реальном ТЗ — там были и нормальные истории, но часть явно была написана по принципу: «ну, у нас же список, значит, фильтры нужны». Возможно, и нужны. Но если подходить к этому формально, то в итоге кто-то это будет делать, кто-то за это заплатит, а ценности — ноль. А можно было бы решить совсем иначе.

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

Здесь вспоминается классика: XY-проблема. Человек хочет не быстро разбивающиеся микроскопы, потому что ими забивать гвозди неудобно — надо часто менять. На самом деле ему нужно что-то умеренно увесистое и прочное, чем можно ударять по твёрдым изделиям типа скоб, шпилек, гвоздей, шпильками для соединения двух изделий из мягкого материала. Но пока мы пишем истории уровня «я как пользователь хочу нажимать на кнопку, чтобы что-то происходило», — мы даже не добираемся до сути. Получается «микроскоп» вместо молотка. То есть мы не доходим до реальной задачи.

Истории, к сожалению, по умолчанию не гарантируют, что мы зададимся вопросом: а какую реальную проблему мы вообще решаем?

И еще одна боль: переход от истории к проектированию. Мне это десятки раз говорили: «Окей, мы написали историю, а что дальше? Как перейти к дизайну интерфейса?» Где-то между историей и интерфейсом образуется провал. Часто там возникают неопределённости: кто инициирует действие, как выглядит сценарий, где границы истории.

Например, можно записать общую историю уровня продукта:  «Как спикер я хочу раздавать электронные визитки вместо бумажных, чтобы они не терялись и были актуальны.»
Звучит вкусно, но дальше начинается туман: а что это значит в интерфейсах? QR-код? Нотификация? Приложение? И как это декомпозировать?

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

Сила пользовательских историй

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

Когда мы формулируем историю, даже неидеально, мы запускаем разговор. Команды начинают обсуждать роли, контексты, цели. Начинают понимать друг друга. И это — бесценно.

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

Есть ещё одна важная черта. Как отмечал Мартин Фаулер в предисловии к книге Майка Кона — самая крутая вещь в историях — это возможность отложить решение. Это особенно важно в условиях неопределённости.

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

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

Появление формата рабочих историй

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

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

У рабочей истории структура такая (и чаще всего она фиксируется не в предложении, а в карте):

Это кажется громоздким, но на практике отлично работает. Мы не просто описываем, что сделать в интерфейсе, а разбираем что при этом происходит в деятельности и что меняется — с какими объектами мы работаем, и как. Это очень помогает отделить смысл от реализации и не потеряться в «кнопках».

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

Первый — про поиск работы. Если записывать в виде предложения, история будет такой:

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

Здесь видны все ключевые элементы: цель, ситуация, способ действия и объекты, с которыми ведётся работа.

Второй пример — из промышленности:

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

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

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

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

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

С одной стороны, пустоты как бы подсказывают: «Заполни меня, подумай об этом». С другой — они не блокируют движение, ведь иногда знания просто нет. И это тоже нормально.

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

У любого действия есть:

• Цель — зачем оно совершается (например, минимизировать потери, как в примере с технологом).

• Исходный материал и продукт действия — то, с чем человек работает и что хочет получить на выходе.

• Ситуация и способ действия — в каком контексте и как именно он действует.

• А ещё — орудие или инструмент, то, через что осуществляется действие (это как раз то, что мы в ИТ называем «продуктом» или «решением»).

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

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

Карта реализации историй и её слои

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

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

ЦЕЛЬ НА УРОВНЕ ДЕЯТЕЛЬНОСТИ

        ↓

НОСИТЕЛЬ ДЕЙСТВИЯ (человек: функциональная роль, позиция; система, робот)

        ↓

СИТУАЦИЯ (контекст, в котором возникает потребность)

        ↓

СПОСОБ ДЕЙСТВИЯ (что делает субъект, как действует)

        ↓

ОБЪЕКТЫ ОПЕРИРОВАНИЯ (входы и выходы действия)

––––––––––––––––––––––––––––––––––––––––––––

        ↓

ФОРМА РЕШЕНИЯ (инструмент, интерфейс, сервис)

        ↓

СТРУКТУРА ЭКРАННЫХ БЛОКОВ (как именно организован интерфейс)

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

Теперь разберём каждый из слоёв подробнее.

Цель на уровне деятельности

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

Ключевой вопрос: зачем?

Этот слой карты — цель действия — отвечает на ключевой вопрос: зачем мы это делаем? В примере со складом она формулируется так: «зафиксировать количество товаров на физической палете в цифровом двойнике».

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

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

Носитель действия

Смысл слоя: фиксирует субъекта или машину, кому вменены операции на шаге.

Ключевой вопрос: кем/чем?

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

Ситуация

Смысл слоя: фиксирует описание контекста ситуации, условия входа в неё.

Ключевой вопрос: когда?

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

Способ действия

Смысл слоя: фиксирует процедуру, вариант формы процесса

Ключевой вопрос: как делается?

Следующий слой — способ действия. Это, пожалуй, самый трудный для понимания, потому что он требует абстрагироваться от формы и описать суть поведения. Речь не о том, «какой интерфейс мы делаем» или «какую кнопку жмём», а о принципе действия.

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

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

Объекты оперирования

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

Ключевой вопрос: с чем?

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

В нашем примере:

• На входе у нас — упакованный товар на палете. Это физические объекты, которые надо учесть.

• На выходе — цифровое значение количества упаковок, зафиксированное в цифровом двойнике паллеты.

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

Форма/вариант решения

Смысл слоя: фиксирует образцы типовых технических решений, то чем мы оснащаем шаг.

Ключевой вопрос: с помощью чего?

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

Пример: ручной счетчик с кнопками "+" и "–", использование OpenCV для анализа изображений палет, библиотека React для UI-контролов, доступ только из внутренней сети.

Здесь не нужно регламентировать формат — важно, чтобы было понятно команде. Это своего рода «технический подвал» истории: всё, что понадобится при разработке, но ещё не проектирование UI.

Структура экранных блоков

Смысл слоя: фиксирует UI-блоки для иллюминации и манипуляции и их местоположение

Ключевой вопрос: как организовано?

Это мост между объектами оперирования и будущим интерфейсом. Состоит из двух логических операций: извлечение блоков и их группировка.

Извлечение блоков из объектов оперирования:

• Визуализационные блоки: наименование товара, артикул, количество упаковок.

• Манипуляционные блоки: кнопка "+", кнопка "–", поле ручного ввода

Группировка этих блоков по смыслу. Например, группа «счётчик упаковок» содержит визуализацию и кнопки взаимодействия → потом будет размещена как единый компонент в интерфейсе.

Когда мы прошли все слои — от цели до структуры экранных блоков — у нас появились:

1. Полноценная рабочая история, встроенная в деятельность.

2. Конкретные решения, описывающие реализацию.

3. Предварительный каркас интерфейса, готовый к проектированию.

А вы используете карты реализации историй в своей работе? Поделитесь своим опытом в комментариях.

Материалы

• Канал Карты реализации историй —  t.me/simapping

• Видеобзор Карты реализации историй — https://ashapiro.ru/talks/tpost/zy9c2lp5d1

• Статья о методе — https://ashapiro.ru/articles/sim

• Подкаст с беседой об историях с Юрием Агеевым

• База знаний метода

• Канал автора метода о проектировании — t.me/how2scheme