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

—

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

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

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

От автора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

❦

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

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

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

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

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

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

Н: Продавец

С:

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

О:

Ц:

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

– Что важно?

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

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

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

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

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

Н: Продавец

С:

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

О:

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

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

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

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

Н: Продавец

С:

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

О:

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

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

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

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

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

Н: Продавец

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

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

О:

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

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

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

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

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

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

– Точно!

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

Н: Продавец

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

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

О:

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

– Да, всё так.

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

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

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

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

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

Н: Продавец

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

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

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

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

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

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

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

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

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

Н: Продавец

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

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

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

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

–

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

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

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

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

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

– Положим.

Н: Продавец

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

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

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

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

–

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

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

❦

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

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

—

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

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