Андрей Шапиро
Рабочие истории. Системное проектирование с Картой реализации историй

Отзывы первых читателей

Владислав Головач, дизайнер, автор книг о дизайне «Культура дизайна» и «Искусство мыть слона»

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

Ольга Павлова, проектировщик сложных систем, основатель и совладелец «Собака Павлова», автор книги «Я хочу сделать хороший дизайн продукта»

Круто, что ты закопался в методику реализации одного из ключевых отраслевых инструментов и предложил своё цельное видение. Думаю, чем больше мы в профессиональном сообществе обсуждаем разные методы решения задач, тем богаче выбор для тех, кто эти задачи – иногда внезапно для себя – будет решать. И в этом смысле детальный расклад – чудесно, ровно то, что надо. Пусть же пойдёт в работу и  поможет тем, кто нуждается в помощи!

Николай Судников, аналитик, президент IIBA Kazakhstan Chapter

Книга Андрея помогает глубже понять User Story и их ограничения. А также помогает перейти на следующий уровень – начать использовать методику автора – Рабочие истории. Рекомендую для чтения всем, кто работает с требованиями: аналитикам, разработчикам, продактам, тестировщикам, менеджерам.

Антон Григорьев, UX-дизайнер, автор канала UX Notes

Андрей дал всё необходимое, чтобы научиться записывать пользовательские истории в обкатанном за многие годы формате Рабочих историй, лишённом недостатков других форматов. В книге имеются даже примеры бесед с заказчиком, в ходе которых история зарождается и обрастает деталями. Это здорово, так как новичкам часто не хватает понимания, как вообще такую информацию вытаскивают из стейкхолдеров. Внедрение Рабочих историй в рабочий процесс упрощает Карта реализации историй, которой также посвящено несколько глав. Карта собирает все истории вместе и позволяет увидеть полную картину, а кроме того дополняет истории информацией о возможных формах их реализации и составе блоков соответствующего интерфейса. Если бы мне сейчас нужно было фиксировать требования к проектируемым системам в формате историй, я бы выбрал Рабочие истории.

Александр Бындю, методолог, автор книг, владелец ИТ-компании

В книге собраны и систематизированы два десятка лет опыта Андрея, поданные в формате историй и схем. После прочтения – и даже во время! – можно переходить к практике записи историй для своего бизнеса, продукта или проекта.

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

Антон Кожемяко, вице-президент международной ассоциации MATRIZ Official в России, управляющий партнёр Бизнес-ассоциации ТРИЗ

Работа с пользовательскими историями всегда воспринималась сродни искусству. По крайней мере, стройной технологии я до сих пор не встречал. Благодаря большому практическому опыту и серьёзной методологической подготовке Андрей Шапиро сумел максимально системно и развёрнуто распаковать подготовку, структурированное представление и анализ пользовательских историй. Раскрыта ценность и структура инструмента, максимально подробно описана технология работы с ним. Берём на вооружение, классный инструмент!

Алёна Вальтер, дизайнер интерфейса

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

Обилие примеров, разбор типовых ошибок, рекомендации по проверке карты целиком и отдельных её частей – это то, к чему я буду обращаться при построении своих карт. Мне нравится этот инструмент – рекомендую его дизайнерам, которые хотят улучшить качество своей работы. Будь моя воля, я бы запретила проектировать без Карты реализации историй :-)

Вступительное слово

—

Посвящается моему брату Анатолию Шапиро,

умевшему разглядеть красоту в людях

и являвшему в этот мир добросердие

От автора

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

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

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

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

Для проектирования цифровых продуктов я применяю описанный в книге метод в связке с двумя другими: Картой гипотез¹ и Картой процесса-опыта². Первый из них согласует цели со способами их достижения в большой картинке замысла всего проекта. Второй – детально изучает процесс и обслуживаемый им потребительский опыт.

Вместе с тем описанный в книге метод легко может использоваться как самостоятельный. Наличие грамотно записанной рабочей истории как текстовой модели и проектирование в соответствии с ней является для меня маркером профессионализма. Рабочая история – как нить Ариадны: помогает не застрять и найти выход из лабиринта неопределённости сложного проекта. Если у вас уже имеются все необходимые знания для заполнения компонентов рабочей истории, то, сложив и упорядочив их в строгом формате, вы заложите качественную основу для проектирования нужного вам инструмента. Если же знаний не хватает, то шаблон рабочей истории подскажет вам, на какие ещё вопросы важно получить ответы.

Для кого эта книга

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

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

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

В сфере информационных технологий книга будет полезна:

– продуктовым управленцам,

– дизайнерам,

– аналитикам,

– разработчикам программного обеспечения,

– инженерам контроля качества.

Чему вас научит эта книга

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

– строить беседу с заказчиком и командой о требованиях к системам;

– записывать текстовые модели, адекватно описывающие ту часть практической деятельности, для которой вы создаёте системы-инструменты;

– переходить от составленных текстовых моделей к выбору адекватных решений и сохранять гибкость в их выборе;

– строить карты реализации историй и с её помощью организовывать проектирование и внедрение изменений.

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

Как читать эту книгу

Первая часть книги посвящена пользовательским историям, их основным шаблонам, практикам, преимуществам и недостаткам. Пользовательские истории – мощнейший инструмент сбора требований, с которым я работал на протяжении пятнадцати лет. В книге я постарался говорить только о личном опыте и выводах из собственной практики, без повторения того, что уже есть по теме в материалах других авторов.

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

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

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

Благодарности

Участникам Консорциума исследования интерфейса (UIRC): Владимиру Аршукову, Алёне Вальтер, Артёму Кашакову, Алле Тимофеевой, Алексею Янке, – принявшим активное участие в работе над постановкой проблемы записи историй и выявления объектов.

Михаилу Флямеру и Ирине Качеровской – за беседы и путеводительство по системо-мыследеятельностной методологии.

Активным участникам предварительного чтения книги и бесед о её содержании и предлагаемом методе: Андрею Завьялову, Артёму Кашакову, Константину Полуянову, Андрею Степанову, Владиславу Угрюмову, Алексею Янке.

Рецензентам-экспертам, согласившимся прочесть рукопись и значительно улучшить её доступность и понятность читателю: Александру Бындю, Антону Григорьеву, Антону Кожемяко, Михаилу Руденко, Климу Серебренникову, Николаю Судникову.

Введение

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

Другое дело, когда нас просят спроектировать что-то на заказ. Цена ошибки при работе на заказ сильно выше. Когда создаваемое затрагивает жизни множества людей, степень ответственности серьёзно возрастает. Кажется, любой бы мечтал иметь волшебное средство, сокращающее число возможных ошибок.

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

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

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

Главная проблема на пути от замысла к проекту – запутанность, разнородность и разобщённость собираемых фрагментов знаний и требований. Вряд ли заказчик будет говорить всё по порядку и связно. Какие-то вещи он и вовсе умолчит, не вспомнив их или решив, что они не важны. Что-то мы узнаем сильно позже, чем было бы полезно, а значит, придётся перепроектировать. Практически всегда на это нет ни времени, ни денег, а следовательно, не избежать компромиссов, снижающих качество решения.

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

Давайте посмотрим, как использование этой технологии организует жизнь проектировщика.

❦

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

– …Хорошо. Что происходит дальше? – спрашивает проектировщик.

– Дальше уведомление у продавца, – отвечает заказчик.

– Здесь важно написать, кто и как действует. Действует у нас вроде бы продавец.

– Продавец получит мгновенное уведомление.

Проектировщик записывает что-то в странный формуляр:

Н: Продавец

С:

Д: Получает мгновенное сообщение

О:

Ц:

– Так, хорошо. А почему ему это важно?

– Что важно?

– Я услышал так: продавцу важна мгновенность сообщения.

– Ну, как? Он же хочет продать, – улыбается заказчик.

– Да, но почему важна скорость? Пусть, например, получит «медленное» сообщение. Скажем, через час или сутки. Что тогда?

– Тогда он вероятнее всего останется без заказа.

Проектировщик быстро пишет в формуляр рабочей истории:

Н: Продавец

С:

Д: Получает мгновенное сообщение

О:

Ц: Чтобы не остаться без заказа

– А почему он останется без заказа?

– Ну, мы же на рынке – всем нужно быстро! У нас B2B-маркетплейс, наши покупатели – это чаще всего станции технического обслуживания. Им нужно быстрее своих клиентов обслуживать. Когда продавец подолгу не отвечает, сможет ли он поставить товар, поиск продолжается! – выпаливает заказчик. Затем, усмехнувшись, добавляет: – Вы же, небось, когда поступали в университет, документы сразу в несколько подавали. Чтобы наверняка.

Проектировщик переписывает на глазах у заказчика:

Н: Продавец

С:

Д: Получает мгновенное сообщение

О:

Ц: Чтобы выиграть в конкурентной борьбе

– Вот! Именно! Выиграть в конкурентной борьбе. Они и по цене конкурируют друг с другом.

– Хорошо, а как происходит эта борьба? Кто с кем соревнуется?

– Ну, смотри, если мы определили, что товар есть у нескольких поставщиков, то есть продавцов, мы при поступлении заказа от конечного покупателя смотрим предложение – какого продавца выбрать. Там множество критериев: территориальная близость, рейтинг продавца, скорость его реакции, скорость поставки, качество продукции по оценкам потребителей, количество возвратов. Всё это мы смотрим, и вот, скажем, выиграл у нас продавец «Быстрые тяги». Мы ему отправили запрос, он должен его успеть взять.

– Ага, становится понятнее… – проговаривает на автомате проектировщик, чтобы показать, что слушает заказчика, пока дописывает подробности в историю.

Н: Продавец

С: Когда поступает новый заказ

Д: Получает мгновенное сообщение

О:

Ц: Чтобы выиграть в конкурентной борьбе

– …Но всё-таки непонятно: почему нужна мгновенность сообщения? Ведь продавец уже выиграл в конкуренции на площадке.

– Э, не-е-ет… Мы у него отберём заказ и отдадим другому продавцу, если он будет медлить.

– Это через сколько?

– Ну, положим, через полчаса нужно отбирать и отдавать следующему в нашем списке победителей. Пусть конкурируют. Хотя я не вполне уверен насчёт периода. Это нужно будет опытным путём определить.

– То есть, если я верно понял, важно вовремя увидеть, что заказ пришёл, и успеть отреагировать на него?

– Точно!

– Тогда я бы это так записал, наверное:

Н: Продавец

С: Когда поступает новый заказ

Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени

О:

Ц: Чтобы не упустить его, иначе система отдаст его конкурентам

– Да, всё так.

– По технологии мы ещё должны заполнить слой объектов оперирования. Это вещи и данные, с которыми продавец работает на этом шаге.

– Как скажете.

– Я бы записал так. Раз продавцу необходимо успеть отреагировать, то ему важен сам сигнал о поступлении, а также, наверное, время, которое у него есть на его обработку.

– Да. И содержание заказа. Ему надо проверить наличие. Там у него обычно несколько сторонних учётных систем и разных маркетплейсов. Информация о реальных остатках всегда запаздывает. Мы можем продать то, чего уже нет.

– Ага, значит допишем, – печатая, проговаривает проектировщик.

Н: Продавец

С: Когда поступает новый заказ

Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени

О: Работая с сигналом о новом заказе, содержанием заказа и временем на его обработку

Ц: Чтобы заполучить заказ до того, как его отдадут конкурентам – И-1

– Отлично. История готова. Я бы подумал о вариантах её реализации.

– Ну, я же говорил: уведомление.

– Да, теперь мы понимаем, что важно как-то оповестить продавца. С чем сейчас работают типичные продавцы? Что у них есть из оборудования?

– Все сидят в телефонах. Это самое простое. У большинства компьютеры у прилавков, но часто продавец болтается на складе, его надо оповещать и там. Мобила – самый простой вариант.

– Сообщение в чат-боте?

Н: Продавец

С: Когда поступает новый заказ

Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени

О: Работая с сигналом о новом заказе, содержанием заказа и временем обработки

Ц: Чтобы не упустить заполучить заказ до того, как его отдадут конкурентам

–

Р: Сообщение в чат-боте

– Как вариант. Не разоримся на разработке?

– Чат-бота придётся разрабатывать, да. Чуть дороже будет. Можем подавать громкий сигнал, как в «Жизньмарт» или «МакДональдс», когда поступил заказ. У компьютеров на прилавках есть колонки?

– Поставят, если ещё не поставили. Им же важно успевать.

– Тогда основным вариантом будет звуковое оповещение в основном веб-приложении, чат-бот отложим как альтернативу.

– Положим.

Н: Продавец

С: Когда поступает новый заказ

Д: Незамедлительно узнаёт о заказе и оставшемся на его обработку времени

О: Работая с сигналом о новом заказе, содержанием заказа и временем обработки

Ц: Чтобы не упустить заполучить заказ до того, как его отдадут конкурентам

–

Р: 1. Звуковой сигнал в веб-приложении + информация о содержании и временина обработку заказа в перечне входящих заказов

Р: 2. Сообщение в чат-боте

❦

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

ЧАСТЬ I. ИСКУССТВО ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ

1. Истории как накопители знаний

2. Решение проблемы вавилонской башни

3. Вспомогательные практики

4. К следующему шагу развития

Глава 1. Истории как накопители знаний

Две формы хранения знаний в тексте · Переход от сюжетного текста к модели · Важные части текстовой модели поведения · Удержание содержания в слоях фабулы и смысла

—

Единица исторической жизни включает в себя всё, о чём можно рассказать какую-нибудь историю. <…> Каждая из них рождается в своего рода путешествии и описывает какой-то из регионов Мира. <…> Идея путешествия определяет выход за границы обыденного. <…> За любой историей стоит путешествие, любое путешествие выражается в какой-нибудь истории…

Владимир Воловик, «Мышление в мусорной куче»

С самых древних времён множество пересказываемых историй служило невидимой губкой, впитывающей знания о мире. До письменности истории кочевали из уст в уста. Будучи многократно передаваемыми от человека к человеку, они сохраняли в себе самое важное – некоторую структуру жизни или действа.

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

Далее рассмотрим в сравнении сюжетный и бессюжетный тексты, дающие две основные мета-формы историй.

1.1. Истории как сюжетный текст

Вот две типичные истории, раскрывающие детали жизненного уклада людей в области приготовления пищи.

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

Люба обожала итальянскую кухню за вкус и элегантность, но готовила редко. Как только наступал случай – выходной или праздник, когда вся семья собиралась вместе, – она не упускала возможности побаловать себя и домочадцев отменной пастой и итальянским десертом. Так как она готовила от случая к случаю, подробности рецептов в её памяти стирались, и ей с большим трудом приходилось восстанавливать их. На выручку пришёл муж. Он помог Любе организовать запись и систематизировать карточки с рецептами. Так Люба обзавелась собственной картотекой и старательно её пополняла. Картотека разрослась и содержит на сегодня несколько сотен рецептов, помогая Любе время от времени радовать себя и домочадцев итальянской кухней. – И-3

Тексты с сюжетом повествуют о том «как что-то случилось» и составлены из последовательных действий. Сведения в них как будто бы нанизываются постепенно – предложение за предложением, – как наматываются нити и пучки волокон на веретено. Если выделить общее в этих двух повествованиях, получится следующее.

1. Каждый отрывок написан так, что удерживает внимание читателя на одном герое и рассматривает его уникальную ситуацию его глазами.

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

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

4. Каждый отрывок максимально конкретен: не содержит обобщений и описывает в подробностях личные переживания и особенности отдельных людей.

Подобные истории-сюжеты могли бы прекрасно фиксировать результаты отдельных интервью в ходе исследования проблемных ситуаций. Преимущество такой формы изложения в том, что читателю удаётся максимально соприкоснуться с проблемами героев, прочувствовать их проблемы на себе и попытаться их понять по-человечески. Очевидный же минус такого формата текста – его объём. С каждой ситуацией потребуется знакомиться последовательно, как того требует чтение любого текста. И чем подробнее текст, тем дольше и труднее через него продираться.

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

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

1.2. Текстовые модели

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

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

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

Из определения вытекает общая схема любой текстовой модели поведения. Она состоит из таких частей как:

– Модель группы людей

– Ситуация

– Форма поведения/действия

– Смысловое значение поведения/действия

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

1.3. Обобщение сюжетных историй до текстовых моделей

Я намеренно выбрал общую тему для историй-сюжетов выше, чтобы рассмотреть вариативность в какой-то одной области. Представим, что, наряду с Толей и Любой, мы бы встретились и с другими людьми, рассказывавшими нам подобные сюжетные истории. Заметив повторяемость ситуаций, мы бы захотели их объединить, выделив и оставив общее и отбросив все несущественные частности.

История Толи переписалась бы, например, так:

Человек без опыта приготовления еды, когда вынужденно остался без привычного источника пищи, ищет рецепты приготовления конкретного блюда, чтобы утолить голод тем, что хочется, а не абы чем. – И-4

А вот вариант обобщения истории Любы:

Человек, любящий готовить время от времени по настроению, понимает, что для сохранения тонкостей и аутентичности рецептов важна их запись и, когда появляется очередной рецепт, вносит его в картотеку, чтобы позже найти и восстановить в памяти. – И-5

Что изменилось в предлагаемых текстах, если сравнить их с первоначальными историями-сюжетами? Финальные тексты всё ещё рассказывают про те же ситуации, однако теперь они лишены конкретных имён и несущественных для нас деталей. Благодаря этому тексты стали короче, но не потеряли в содержательности. Обобщения сделаны согласно пониманию смысла ситуаций, потребностей людей и их действий в этих ситуациях.

Осмысленное преобразование историй-сюжетов в более ёмкие текстовые модели также разительно сокращает время на их восприятие. Сравните следующую пару истории-сюжета и обобщённой истории.

Через пару минут Кристи предстоит защищать свой проект. В зале сотни инвесторов, расписание насыщенное – по пять минут на выступление. Кристи понимает, что нет времени на обмен бумажными визитками. Перед началом выступления она «открывает» свою электронную визитку. Теперь её визитку смогут взять все желающие, находящиеся поблизости. Кроме того, контактные данные в этих визитках никогда не устареют. – И-6

Спикер, вместо того, чтобы раздавать каждому бумажные визитки, которые теряют актуальность и не вовремя заканчиваются, открывает вещание электронных. – И-7

1.4. Адекватность текстовых моделей

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

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

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

В ходе исследований у рабочей группы копится набор историй-сюжетов отдельных людей. Кто-то должен взять на себя ответственность и труд по их осмыслению и обобщению. Продуктом такого обобщения и становятся текстовые модели.

1.5. Опасность переобобщения

Итак, в поисках закономерностей мы исследуем мир, а затем записываем истории-сюжеты, отвечающие нашим наблюдениям и находкам. Когда Маша и Петя во Владивостоке рассказывают схожие истории с теми, что рассказывают Валентин и Лена из Москвы, мы понимаем, что нашли что-то общее. Вместо четырёх историй мы записываем одну, отбросив незначительное в их вариациях. Схожесть частей историй, например, общие ситуации или общий способ решения задач – основание для обобщения историй.

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

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

– подбираю автозапчасть сам, пользуясь каталогами и собственным знанием автомобиля;

– узнаю поломку у профессионалов, дальше подбираю по названию узла и машине на специальных сайтах;

– делегирую моему другу-автослесарю, он подбирает по ситуации;

– делегирую подбор и покупку станции техобслуживания или автомагазину.

Когда способов становится много, возникает соблазн сократить их многообразие и обобщить несколько историй, сведя их к одной. Однако, объединение принципиально разных вариантов человеческого поведения с целью сокращения их общего числа может нам дорого обойтись. Да, это приводит к излюбленному нашим восприятием упрощению. Но это также снижает адекватность текстовой модели миру. Люди могут в одних и тех же ситуациях из личных предпочтений выбирать разные подходы и инструменты. Предлагая им один подход или инструмент согласно упрощенной текстовой модели, мы окажемся в ситуации, когда нереально будет понять, что же в нашем продукте не так. Другими словами, мы дорого расплатимся за потерю знаний, полученную упрощением.

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

1.6. Содержательность историй

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

Разберём этот момент на примере басни И. Крылова «Лебедь, Щука и Рак». В этой басне повествование ведётся сразу на двух уровнях. На уровне фабулы разворачиваются очень конкретные события. Мы видим конкретных персонажей и их действия. Вот встретились трое и решили перевезти что-то вполне им посильное, но из-за характера конкретных действий так и не могут сдвинуться с места. При этом автором явно вводится и другой уровень – уровень смысла, – где на материале введённой конкретики делается заключение общего вида.

Здесь важны оба уровня. Опусти автор фабулу, и вывод будет не только сух, но и непонятен, потому что всё абстрактное – многозначно в своей интерпретации. Оставь автор лишь повествование без вывода, неясно будет, для чего рассказывался сюжет, на что именно в нём должно быть обращено внимание. Лишь увязывание обоих уровней сохраняет и передаёт нам то, что хотел сказать автор.

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

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

Практические напутствия главы

– Превращайте сюжетные повествования в ёмкий текст, выявляющий главные закономерности поведения группы людей.

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

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

Глава 2. Решение проблемы вавилонской башни

Пользовательские истории как упрощённый язык взаимопонимания разработчиков, бизнеса и пользователей · Классический шаблон: роль, функциональность, основание · Трудности с восстановлением понимания при лаконичной записи

—

Все люди – один народ, у них один язык;

вот они и затеяли такое;

теперь не будет для них ничего невозможного.

Сойдём же и смешаем им язык,

чтобы они перестали понимать друг друга.

Бытие 11:1-9, Новый русский перевод

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

– как понять, что и как нужно сделать;

– как организовать разработку.

2.1. Краткая историческая справка

К концу 90-х персональные компьютеры заняли прочное место в жизни западного общества, придя в каждый дом и на рабочие места в компаниях. Времена, когда вычислительные машины занимали несколько комнат, а то и целые этажи, остались позади. Позади оказались и времена, когда программное обеспечение создавалось по модели каскадного производства, требовавшего внушительного объёма предваряющего проектирования до начала разработки и эксплуатации.

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

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

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

Лаконичное, но ёмкое описание требований в виде коротких историй появилось в беседах разработчиков с будущими пользователями и бизнесом. Рассказывание историй помогало любому включиться в обсуждение требований к будущей системе. То, что рождалось в беседе, фиксировали в виде краткой записи истории. Потребность услышать и понять друг друга стояла настолько остро, что первые истории называли пиджином – общим упрощённым языком, одинаково доступным разным специалистам. Другими словами, появление историй стало мостиком между профессионалами из разных сфер деятельности, думающих и говорящих почти буквально на разных предметных языках.

2.2. Подход пользовательских историй

Пользовательские истории – это вариант текстовых моделей поведения человека. За тридцать лет практики подход широко распространился и зарекомендовал себя главным образом в сфере информационных технологий. Область их применения – взаимопонимание в беседе и планирование разработки.

Приставка «пользовательская» означает, что требования, описываемые историей, рассматриваются исключительно с перспективы людей, которые будут пользоваться разрабатываемой системой.

Прелесть пользовательских историй в том, что они просты для восприятия, потому что схватывают ситуацию и человеческое поведение в ней на привычном нам неформальном естественном языке.

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

Первый вариант текстовой модели пользовательской истории был предложен в 2001 году компанией «Коннекстра». Он широко распространился благодаря активности Agile-сообщества и используется до сих пор. В этом варианте текстовой модели выделяется три важных аспекта:

– роль (role);

– функциональность (feature, requirement);

– основание или мотив, требующий обозначенную функциональность (reason).

Наиболее распространённая современная версия шаблона выглядит так:

Я, как <функциональная роль ИЛИ представитель сегмента целевой аудитории>,

хочу <описание функциональности>,

чтобы <описание выгод и ценности> – Ш-1

Вот несколько типичных пользовательских историй в формате этого шаблона.

Я, как клиент банка, хочу снимать деньги со своего счёта в любой момент, чтобы оставаться свободным в планировании своего времени, а не быть ограниченным часами работы банка. – И-8

Я, как рекламодатель, хочу размещать рекламу только на сайтах выбранных тематик, чтобы захватить желаемую аудиторию и результативно использовать рекламный бюджет. – И-9

Я, как спикер, хочу на время сделать свою контактную информацию доступной всем присутствующим в аудитории, чтобы сейчас не тратить время на раздачу каждому, а впоследствии обеспечить актуальность данных. – И-10

Объём содержания истории может варьироваться в зависимости от масштаба акта деятельности, описываемого ею. Но каждая история обязательно должна затрагивать какие-то действия или их практические особенности. Каждая история должна относиться к практике в физическом мире или цифровом.

Крупномасштабные истории могут описывать целиком цифровой продукт. Например, история И-10 задаёт идею инструмента работы с электронными визитными карточками. В рамку таких объёмных историй попадает многосоставное действие по удовлетворению какой-то одной потребности пользователя.

Истории помельче затрагивают предпочитаемые способы решения конкретных задач. Например, история И-8 описывает предпочтительный способ поведения при решении задачи «получения наличности», а история И-9 уточняет часть инструментария в системе размещения интернет-рекламы.

2.3. Лаконичная запись как повод для беседы

В классике истории записывались на стикер Post-it, чтобы оставаться краткими. Ограниченный размер самоклейки помогал не растечься мыслью по древу. Запись велась в процессе беседы команды со всеми важными заинтересованными лицами. Чтобы избежать фантазий, все участники беседы должны были прийти к соглашению, что зафиксированная история отвечает целям и интересам всех заинтересованных лиц.

Строгий шаблон пришёл в пользовательские истории не сразу, и, к великому сожалению, соблюдается единицами практиков. Ряд авторов [Кон⁶, Паттон⁷], напротив, считают, что придерживаться строгого шаблона необязательно, как не стоит и стремиться к точности формулировок при записи историй. Они утверждают, что запись историй вторична по отношению к обсуждению её содержания.

Такая точка зрения опирается на мнение, что история – это всего лишь знак, обещающий беседу⁸ о ней. С одной стороны, мне симпатична эта фраза-образ. Коммуникация об объекте разработки – важнейшая часть процесса согласованного понимания. В беседе согласуются наименее поддающиеся интеграции компоненты: представления разных людей. Любая, даже мастерски сформулированная в записи история скорее всего потребует разговора для более полного восстановления её контекста и принятия допущений по вариантам её реализации.

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

Вместе с тем наскоро и кратко намеченные истории долгое время процветали и процветают в отрасли. Далее рассмотрим на примерах, с чем они хорошо справляются, а с чем не очень.

2.4. Зона уверенного применения лаконичной записи

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

Вот пример подобной формы записи историй. Перед нами карта историй для пользовательской роли «Слушатель» и разрабатываемой системы онлайн-радио. Карта устроена так, что на самом верхнем уровне слева направо идут карточки крупных потребностей, группирующие истории-шаги по смыслу: Выяснить, что за радио; Слушать музыку. Сразу под ними слева направо идёт слой из последовательности карточек основных «историй»: Послушать эфир, Список возможностей, Сколько слушателей и так далее. Снизу под каждой карточкой с историей расположено её детальное описание. Например, под карточкой «Список передач» в качестве деталей записано: Инф. о передаче, Рейтинг передач.

Посмотрим на основные «истории» в примере и попробуем восстановить их контекст и смысл. Вот, что у нас получается:

Что за радио:

– Послушать эфир

– Список возможностей

– Сколько слушателей

– Какие исполнители

– Список передач

Слушать музыку:

– Управлять звуком (нарисованы пиктограммы паузы, зачёркнутого динамика, ползунка-фейдера и английское слово «bitrate»)

– Узнать, что за песня играет

– Отложить в закладки

– Поделиться песней

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

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

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

Аналогично легко считывается и следующая карта, описывающая работу приложения для просмотра трейлеров к фильмам.

Даже несмотря на то, что шаблон Коннекстры «роль – функциональность – основание» не соблюдён, опущены основания и мотивы, мы можем восстановить понимание, так как хорошо знакомы с предметом. Но что делать, когда такого знакомства нет?

2.5. Трудности в сложных предметных областях

Рассмотрим на контрасте лаконичную запись историй для инструмента раскроя в сфере производства металлоконструкций. Вот перечень записанных историй:

Оптимизация материалов:

– Пользователь видит оптимизацию как таблицу;

– Пользователь видит полный объём материалов, общую длину, общее количество и так далее;

– Пользователь хочет видеть в колонке тип материала;

– Пользователь хочет видеть в колонке тип по каталогу профилей.

Получение данных:

– Загрузка данных в оптимизацию согласно выбранным пользователем маркам;

– BOM изменился. Пользователь хочет видеть изменения с уже имеющимися материалами в оптимизации материалов.

Замена материала:

– Пользователь хочет заменять марки материала;

– Пользователь хочет заменять профили материала;

– Пользователь хочет видеть список возможных замен материала.

Отчёты:

– Пользователь хочет отправить данные в отдел снабжения;

– Получать отчёты по заменам от отдела снабжения;

– После получения отчёта, формировать его и отправлять заказчику.

Давайте попробуем понять, что же здесь имелось в виду. Если читатель не является специалистом в области металлоконструкций, то скорее всего ему трудно будет восстановить смысл происходящего в этих историях. Время от времени автор историй пытается применить куски шаблона: пользователь хочет. Но это не помогает, потому что «пользователь» в сравнении с кем-то из «отдела снабжения» выглядит абстрактно, и из такой записи невозможно понять, кто с кем имеет дело в реальной жизни и по какому поводу. То тут, то там появляются понятия-«чёрные ящики»: BOM, оптимизация, материал. Часть из них являются объектами, с которыми важно работать пользователю системы, а часть – элементы плохо выявленной терминологии. Видны осколки конкретных решений: отчёт, таблица. Вместе с тем совершенно неясно, какие именно данные и почему должны туда попасть.

Это типичный пример неудачи из-за краткой формы записи историй.

2.6. Восстанавливаемость содержания истории

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

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

Но как быть с передачей историй коллеге или вовсе в другую команду? Если коллега или другая команда будут реализовывать задуманное, то от качества понимания ими историй будет зависеть качество конечного решения. Увы, при описанном выше подходе восстановить историю без участников её записи не удастся. Да и сами участники сессий по записи подобных «историй» уже через пару месяцев не вспомнят, о чём шла речь в некоторых карточках.

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

Практические напутствия главы

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

– Строго следуйте шаблону Коннекстры, выявляйте суть полезного действия для пользователя особенно в сложных предметных областях.

Глава 3. Вспомогательные практики

Приёмочные тесты как средство восстановления контекста и определения критериев готовности · Шаблон изменений · Шаблон работной истории, Job Story · Шаблон вопросов · Шаблон утверждений · Заужение естественного языка

—

«Передача знания» – это оксюморон: передавать знания непосредственно как нечто разом данное и очевидное невозможно. «Сейчас я прочту энное количество книг и стану взрослым». Так не бывает. Нужны многообразные усилия, чтобы сформировать свои знания…

Тагир Сафаев, типограф

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

3.1. Практика записи приёмочных тестов

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

Языковая проблема всегда была и остаётся актуальной. Участники команды чаще всего мыслят в волнующих их категориях, употребляют разные языковые конструкции для описания одного и того же и не узнают в описаниях оппонентов того, о чём те рассказывают. Разработчики говорят на своём техническом языке в силу того, что они чаще и больше думают о будущей реализации задачи. Заказчик мыслит и говорит на языке бизнеса. Пользователи объясняются на языке своей специализации в деятельности. Трудно себе представить ситуацию, когда кто-то из них будет подстраиваться под язык другой группы, мастерски следить за разницей терминологий, отмечать разницу в картинах мира участников.

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

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

Эта техника перенесена из разработки через тестирование TDD (test-driven development), одной из практик «Экстремального программирования». До этого подобная техника использовалась в электронике: создавался макет с ожидаемым поведением, в него периодически ставилось «решение», то есть прототип создаваемого элемента, и наблюдалось, что уже срабатывает в схеме, а что ещё нет. Принцип техники предлагает «разматывать» решение задач задом наперёд. Если мы хотим, чтобы такие-то типы банковских карт обрабатывались приложением, то мы сначала напишем на это тест, убедимся в том, что сейчас приложение проваливает этот тест, потому что функциональность отсутствует или деградировала, а затем перейдём к решению конкретной задачи, приводящей к тому, чтобы тест проходил успешно. Эта же практика была перенесена на работу с пользовательскими историями как текстовыми моделями будущей функциональности.

Рассмотрим пример истории и приёмочных тестов на ней:

Я, как схемотехник, хочу вернуться к ранее созданной схеме, чтобы продолжить работу, а не начинать с чистого листа. – И-11

Приёмочные тесты:

– После повторного входа в том же браузере видны схемы, созданные в этом браузере.

– Переход по сгенерированной заранее ссылке возвращает к конкретной схеме. В ссылке содержится всё необходимое, на сервере ничего не хранится.

– После авторизации в сервисе на любом компьютере видны схемы, созданные ранее пользователем.

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

3.2. Практика использования шаблонов

Ещё одна вспомогательная практика в записи историй состоит в более тщательном выявлении контекста за счёт введения структур из хорошо зарекомендовавших себя шаблонов. Форма шаблона предписывает структуру, требующую заполнения, и тем самым направляет мышление.

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

Помимо классического шаблона Коннекстры Ш-1, сообществом методологий гибкой разработки накоплено несколько других интересных форм. Рассмотрим их ниже вместе с примерами.

3.2.1. Шаблон изменений

Вместо того, чтобы <старый способ действия>,

<новый способ действия> – Ш-2

<Новый способ действия>,

тогда как сейчас <старый способ действия> – Ш-2.1

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

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

Вот типичные истории в формате изменений. Обратите внимание, как история И-12 ниже, про покупку рекламы, записанная в классическом виде, превратилась в историю в формате изменений И-13.

Я, как рекламодатель, хочу размещать рекламу только на сайтах выбранных тематик, чтобы захватить желаемую аудиторию и результативно использовать рекламный бюджет. – И-12, вариант в шаблоне Коннекстры

Вместо бесконтрольных трат бюджета выбирает, на какие тематики его потратить. – И-13, вариант в шаблоне изменений

Примеры других историй в шаблоне изменений.

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

Вместо самостоятельного определения приоритетной задачи из кучи, получает наиболее приоритетную, назначенную системой. – И-15

Вместо перезаказа вручную, устанавливает условия автоперезаказа. – И-16

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

3.2.2. Шаблон работных историй, Job Story, из JTBD

Когда <обстоятельства, задающие контекст ситуации>,

Я хочу <мотивация>,

чтобы <ожидаемый результат> – Ш-3

Шаблон работных историй пришёл из практики Jobs To Be Done. Сердцевиной подхода является сосредоточение на выявлении глубинных потребностей и мотивации изучаемой группы людей, в отличие от изучения форм решений, задач и действий этих людей.

«Работа» есть условное обозначение для чего-то, что человек в действительности хочет достичь в определённых обстоятельствах. Эти самые обстоятельства или контекст ситуации гораздо более существенны, чем особенности человека или характеристики используемых продуктов и технологий. При этом «работа» не только относится к какой-то утилитарной функции – она может затрагивать эмоциональные и социальные потребности человека⁹.

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

Шаблон работных историй хорош тем, что вытаскивает два уровня целевых установок изучаемой группы людей. «Я хочу, чтобы выполнялось одно, чтобы в итоге последовало второе» – есть цепочка из двух последовательно соединённых «ради чего».

В случае простоя между задачами я хочу видеть, как изменилось состояние дел, чтобы при необходимости в качестве следующей задачи выбирать наиболее приоритетную. – И-18

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

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

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

3.2.3. Шаблон вопросов

<Вопросительное слово> <объект> <обстоятельство>?

Произошёл ли <факт>? – Ш-4

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

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

Почему же такие истории неизбежны в принципе и не идёт ли здесь нарушения требования не говорить об интерфейсе?

Мне понадобится сделать небольшое отвлечение, чтобы пояснить особенности предметной области человеко-машинного интерфейса. Большая часть информационных систем работает с концепцией цифрового двойника или цифровой тени. Это когда для реально представленного в физическом мире объекта строится его модель. Модель помогает решить задачу управления объектом.

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

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

Но как следить за параметрами виртуальных объектов? На вашей банковской карте нет иллюминатора, через который можно было бы заглянуть внутрь вашего счёта. То, что не дано само по себе или скрыто по тем или иным причинам, нужно каким-то образом сделать видимым. Для прямого описания потока данных в сторону потребителя и служит шаблон историй-вопросов.

Можно было бы записать историю о визуализации так:

Предприниматель видит баланс счёта, что даёт ему понимание сколько свободных денежных средств доступно. – И-20

Но лучше подойдёт запись в форме истории-вопроса, лишённая долгих расшаркиваний с излишними подробностями о пользовательской роли и надуманной ценности:

Сколько денежных средств на счёте? – И-21

Другие примеры историй-вопросов:

В какой срок мне нужно организовать поставку и куда? – И-22

Оператор-логист: Файл принят к парcингу? – И-23

Оператор-логист: Какие строки в файле содержат ошибки и что с этим делать? – И-24

Сколько потенциальных наличных заблокировано в проектах? — И-25

Сколько времени и средств уходит на продажу одному клиенту? – И-26

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

Какой объём спроса остаётся неудовлетворённым по причине, что мы не поняли запроса клиента, а какой по причине, что у нас не было для него предложения? – И-27

Каковы аномальные отличия текущих значений на этапах воронок по отношению к предыдущим периодам? – И-28

3.2.4. Шаблон утверждения

<Объекты> – <новый статус>!

Вот <данные> для <объект>! – Ш-5

Другое направление потока данных – приёмка их от человека в сторону системы. Порой всё действие и состоит лишь в первичном наполнении цифрового двойника или изменении каких-либо данных. Хотя я и рекомендую оставаться на уровне смыслов производимых действий и использовать более полные шаблоны историй, такие истории бывают полезными.

Вот мой номер телефона! – И-29

Эти возвращённые товары я получил! – И-30

Я применяю такие истории на уровне деталей и стараюсь не иметь их на уровне основного сценария в карте историй.

3.3. Практика намеренного зауживания языка

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

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

Жизненный цикл виртуальных объектов и их цифровых двойников

и естественные точки опыта работы с подобными объектами

диктуют способы действия в работе с этими объектами.

Когда вся деятельность и состоит лишь в том, чтобы управлять цифровым объектом, в историях всё чаще появляются глаголы, означающие типичные действия с цифровыми сущностями:

– понять,

– добавить,

– видеть,

– редактировать,

– удалить,

– отменить,

– обнаружить такой-то срез данных.

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

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

Практические напутствия главы

– Если вы применяете именно пользовательские истории, освойте разные их шаблоны – это здорово сэкономит время при сборе требований.

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

– Записывайте приёмочные тесты для каждой истории, чтобы возможно было восстановить общий контекст и конкретику.

– Не допускайте включения названий конкретных элементов пользовательского интерфейса в текст историй.

– Придите к единому закрытому набору глаголов в своей команде для лучшего взаимопонимания.

Глава 4. К следующему шагу развития

Типичные проблемы с пользовательскими историями · Преимущества и недостатки историй как инструмента · Задачи на совершенствование подхода

—

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

Клейтон Кристенсен

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

4.1. Шаблонная липа и проблема молотка

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

Я, как пользователь, хочу применять вторичную сортировку, чтобы управлять ранжированием данных. – И-31 – ПЛОХО

Я, как пользователь, хочу применять множественные фильтры, чтобы ограничить область отображаемых данных. – И-32 – ПЛОХО

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

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

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

Во время ремонтных работ я хочу, чтобы микроскоп не раскалывался так быстро на части, чтобы не приходилось его так часто менять. – И-33

Записавший подобную историю может на этом успокоиться и пойти дальше. Что и сделали написавшие истории И-31-32.

Вместе с тем истинной историей могла бы стать следующая:

Когда необходимо соединить податливые материалы твёрдым скрепляющим – скобами, шпильками, гвоздями или костылями – я хочу орудовать чем-то увесистым, но компактным, чтобы эффективно вгонять скрепляющие элементы и меньше уставать. – И-34

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Бындю А. В.: «Карта гипотез. Как создать стратегию для себя, своей семьи или бизнеса», 2025.

Вернуться

2

Шапиро А. А.: «Карта процесса-опыта. Проектирование услуги через её визуализацию», 2024.

Вернуться

3

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

Вернуться

4

Лотман Ю.М.: «Об искусстве», Москва. Искусство-СПб 1998 г. – 704 с. // Семиотика кино и проблемы киноэстетики // Глава 9. Сюжет в кино.

Вернуться

5

«Кеневин» – фреймворк определения типа рабочего процесса по типу среды, в которой рассматривается проект: хаотичная, запутанная, сложная, простая. ru.wikipedia.org/wiki/Cynefin_framework

Вернуться

6

Кон Майкл, Пользовательские истории: гибкая разработка программного обеспечения, 2019 (год выход оригинала 2004).

Вернуться

7

Паттон Джефф, Пользовательские истории. Искусство гибкой разработки ПО, 2017 (оригинал вышел в 2014).

Вернуться

8

Alistair Cockburn: A story is a token promising a future conversation.

Вернуться

9

Know your customers’ “Jobs to be Done” / C. M. Christensen, T. Hall, K. Dillon, D. S. Duncan // Harvard Business Review. – 2016. – Vol. 94, No. 9. – P. 54–62.

Вернуться

10

Коберн Алистер: «Современные методы описания функциональных требований к системам», 2022.

Вернуться