Когда в процессе решения сложной задачи проектирования объем информации начинает «съедать» вас и становится предельным, необходимо структурировать работу и детали проекта. Андрей Шапиро, арт-директор и партнер в Byndyusoft, рассказал о журнале проектировщика — инструменте, который помогает структурировать процесс проектирования, не размывать фокус и получить на выходе подробное описание проекта.
Проблемы проектирования систем
Рассеянность и неспособность уследить за целым
Мы постоянно отвлекаемся от цели и забываем важную информацию. Или увлекаемся чем-то — просто потому, что какая-то идея кажется нам интереснее остальных. Наш ум не всегда собран, и мы можем метаться между старой и новой информацией, от одной мысли к другой. В такой момент мы перестаем следить за целым и его границами. Или, как любит говорить один мой коллега, «не держим рамку задачи». В итоге мы можем увлечься и незаметно сойти с выбранного пути, а это повредит направленному проектированию.
Чтобы обуздать ментальные метания, я рекомендую записывать в единый реестр всё, что появляется в ходе размышления. Это избавит от необходимости удерживать большой объем информации в голове, а значит, освободит когнитивный ресурс (см. опыты Канемана).
Обычная последовательность действий при этом такова:
- Понять, что наш ум начал метаться, а мы увлеклись чем-то в ущерб проектированию.
- Остановиться или намеренно замедлиться.
- Перейти в режим журналирования — выложить все проблемы, гипотезы решений, противоречия, задачи, идеи на бумагу, доску или поля макета.
- Удостовериться, что ум успокоился и можно двигаться дальше.
Предельная сложность
Существует предельная сложность, которую способен воспринять конкретный человек — и она у всех разная. Любой человек, который занимается проектированием, замечает: растет сложность системы → ощущается нехватка когнитивных способностей, то есть мозг просто не может справиться с обработкой и систематизацией информации. А раз системы в современном мире становятся всё более сложными, то и методики работы с этой сложностью лучше внедрять еще на старте проектирования.
У меня когда-то был разговор с одним очень известным человеком (не буду называть фамилию), который во время аварийной ситуации вручную вывел реактор из закритического состояния. Много времени прошло, это уже пожилой человек с орденами и медалями. Я спрашиваю: «Как?» Он ответил: «Я моделировал в голове, что происходит с реактором». Так вот, сейчас нет человека, который может смоделировать в голове, что происходит в сложной системе. Технические системы по степени своей сложности вышли за пределы интуиции инженеров-конструкторов.
П. Г. Шедровицкий, интервью «Эксперту»
Коммуникационные потери
Кроме индивидуальных потерь существуют и групповые. Современные продукты обычно разрабатываются командами — предельная сложность и необходимость как можно быстрее внедрять изменения в продукты просто не оставляют шансов индивидуальным разработчикам создавать конкурентоспособные решения.
К современному инженеру предъявляется больше требований, нежели к инженеру прошлого или позапрошлого века. Он должен знать сценарный анализ и уметь описывать взаимодействие инженерной системы и всех сред, в которые она погружена, не исключая, архитектурную, правовую, культурную среды. Он работает с полным жизненным циклом системы от стадии проектирования до стадии утилизации. Ему вменено экономить ресурсы, время, деньги и внимание руководства. От него требуют уникальной коммуникативной грамотности…
«Инженерная онтология. Инженерия как странствие», В. Никитин, С. Переслегин и другие
Я убеждён: проектная группа либо начнёт осознанно собирать и структурировать знания о создаваемой системе, либо обречёт себя на провал. Потому что потери при передаче знаний о системе между участникам сделают работу неэффективной, а то и вовсе остановят проект.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Журнал проектирования как решение
Что происходит, когды мы пытаемся решить в голове задачу с предельной сложностью:
- мы постоянно пытаемся переформулировать её и найти правильный результат,
- мы отсекаем то, что от нас не требуется прямо сейчас,
- мы старательно удерживаем в голове то, без чего не обойтись на следующему шаге — когда будет применяться наше решение.
Это важно для фокусировки и «удержания рамки задачи» — чтобы вдруг не перефантазировать. И в то же время это похоже на бесконечный цикл, в котором мы сначала пытаемся построить и проверить модель, потом формируем другую модель, чтобы скомпрометировать предыдущую, а потом пробуем заново переосмыслить исходную задачу. Однако в таком потоке мыслей легко заблудиться и растерять важные вводные.
Именно в такой ситуации я использую журнал проектировщика. Суть метода: необходимо специальным образом организовать и структурировать запись всех мыслей, которые возникает в процессе решения задачи. Это помогает решить обозначенные выше проблемы: высвободить когнитивный ресурс, не запутаться, сформировать структуру, которая будет направлять и фокусировать мыслительный процесс.
Такой журнал не только отлично подходит для индивидуального решения задач, но и создает основу для работы группы проектировщиков. Конечно, чтобы вести его, придется обговорить подходы и методы категоризации. А ещё вести журнал одному проще — групповой формат потребует большей строгости.
Журнал проектировщика — авторская компиляция из разных методик. Например, я взял некоторые подходы из метода организации работы Форстера в «Сделай это завтра» (фокус, неотвлечения, входящие) и у Щедровицкого в концепции программирования (иерархированные списки, категоризация). Эти идеи уже существовали, но я объединил и выкристаллизовал их в журнале проектирования — и наши дизайнеры его успешно применяют на практике.
Задачи журнала
- Высвободить когнитивный ресурс проектировщика, выгрузить из памяти всё, что мешает размышлять в нужном направлении.
- Придать строгую логическую структуру процессу проектирования — обычно это выглядит как набор иерархий причинно-следственных цепочек или структур проектируемых объектов.
- За счет строгости получить прозрачный механизм движения от проблем к задачам, от вопросов к ответам, от противоречий к их разрешению.
Этапы работы с журналом
Журнал будет похож на свалку идей, если не организовать правильное размещение и извлечение записей, регулярную чистку. Я выделяю четыре этапа работы над журналом:
- Первичное складирование. На любом этапе работы всё, что приходит в голову, выгружается в условное пространство — что-то вроде папки «Входящие» в электронной почте. В этом процессе лучше просто фиксировать все новые мысли и не утруждать себя размышлениями. Важнее всего обеспечить беспрепятственную поставку в это место.
- Сортировка. Переформулируем выгруженные мысли и раскладываем их по категориям.
- Проверка записей. Закрываем все сложные моменты проектирования, проверяем и убеждаемся, что решение соответствует необходимым критериям и снимает проблемы.
- Чистка журнала. Перенос отработанного материала в хранилище знаний по проекту или продукту. К этому моменту часть вопросов превращается в ответы — обычно это предварительно сформулированные допущения или постулаты относительно устройства системы.
Формат журнала проектировщика
Изначально всё, что происходило в процессе проектирования, заносилось в один документ в хронологическом порядке — отсюда и название «журнал проектировщика». Но практика показала: хронологический порядок не приносит пользы — и даже вреден, когда информации слишком много. Искать нужную информацию по всему журналу весьма затруднительно, поэтому необходимо присваивать записям определенные категории — это важный элемент методики.
Я успел опробовать несколько форматов и инструментов. В основном все они отличались дихотомией «дробный — цельный». Отдельные записи удобны и полезны тем, что они изолированы и самодостаточны. Благодаря этому их проще воспринимать и изучать, но теряется общая картина. А большое цельное полотно текста хотя и наглядно показывает количество нерешенных вопросов и связи между ними, но усложняет работу — особенно с ростом объёма журнала. Классическое противоречие.
Пока не существуют магических средств для быстрой сборки дробной информации из совершенно разных мест, поэтому приходится развивать дисциплину и договариваться о приемлемых форматах выгрузки мыслей. Например, я иногда пишу заметки на полях макетов — если вам удобно, используйте этот способ.
На изображении — заметки о проблемах, которые я обнаружил, пока размышлял над деталями макета. Я аккуратно сгруппировал их под заголовком «Проблемы» и вынес слева от макета. К некоторым из них мне в голову сразу пришли варианты решений — их я собрал в «Гипотезах».
И тут включается дисциплина: важно регулярно собирать в единую проектную документацию все клочки мыслей и наброски, которые вы оставляете то здесь, то там. Я переношу в журнал допущения или постулаты — те ответы, которые получились после переплавки руды задач, проблем и вопросов.
Со временем журнал разрастается и работать с ним становится неудобно — особенно когда это длинный перечень или сплошной текст. На этом этапе развития журнала важно сохранять скорость доступа к любой категории — иначе инструмент перестанет помогать и будет только тормозить проект.
По счастью, у нас есть множество инструментов для структурирования информации — в них можно группировать записи с помощью разнообразных иерархий: распахивающиеся списки иерархий, дерево страниц или списков. Хорошие примеры — Notion и Workflowy. Также существуют средства тегирования и динамической сборки документов по тегам — например, Airtable. Экспериментируйте в поиске своего лучшего формата.
Пример организации иерархий в Notion
Пример организации иерархий в Workflowy
Категории журнала
Это элемент вашей личной системы, в особенности, если вы работаете командой. О категориях важно договориться — на старте проекта или по ходу работы. Я обычно работаю с такими категориями.
- Ситуация, сценарий
- Проблема, нежелательный эффект
- Задача
- Идея
- Противоречие
- Критерий готовности / успешности
- Договоренность
- Цель
Привожу их в том порядке, в котором они обычно появляются у меня — от неопределенности до законченного решения. Я специально поставил «Цель» на последнее место. Да, чаще всего всё начинается именно с того, что мы её выявляем, но она кристаллизуется и превращается в конечную цель, которую все участники процесса проектирования понимают одинаково, на довольно поздней стадии работы над проектом.
В ранних версиях я использовал категорию «вопрос», но пришел к выводу, что вопрос — это не столько удобная категория для журнала, сколько удобный формат. У вас может быть вопрос к себе как к проектировщику, который четко определяет задачу на проектирование определенной части системы. Например, как будет выглядеть этот экран, если информация ещё не появилась в системе?
Вопросом можно ёмко сформулировать и задачу на исследование: Как именно разные поставщики организуют сборку товаров? Или проблему: Что делать, если участники не регистрируют события в системе? Вопрос может быть обращён к стейкхолдерам или экспертам в предметной области. В общем, вопрос помогает направить размышления. Кстати, если на вопрос долго не появляется ответ, меняйте его. А если вопрос не направляет и не фокусирует, значит, пришло время пересобрать его или перепроверить предпосылки его появления.
Пара слов про категорию «Идея». Практически всегда, идея — это гипотеза. Опытный проектировщик знает: свежая идея может выглядеть очень заманчиво и даже одарить автора выбросом эндорфинов. Но единственный метод, который помогает оценить идею — это попытка включить её в текущий ландшафт проекта. На этом этапе большая часть прекрасных идей терпит неудачу.
Ведение журнала проектировщика на примере
Для примера возьмем отдельную задачу в процессе проектированию цифрового сервиса (маркетплейса), который помогает покупателю найти продавца и обезопасить сделку. Мы подключимся к проектированию, когда уже сформированы пользовательские сценарии и разберем эпизод выдачи предоплаченного товара. Он включает в себя такие сценарии:
- Когда заказ готов, покупателю приходит код выдачи. Он необходим продавцу для фиксации завершения сделки и разблокировки оплаты и вводится в специальное поле программы в пункте выдачи заказов.
- Продавец идентифицирует покупателя по ФИО или номеру телефона, после этого приносит товары для осмотра.
- Покупатель осматривает товары из своего заказа, убеждается, что это те самые позиции, которые он заказал, и с ним всё в порядке. После этого он сообщает код выдачи продавцу.
- Продавец вводит в систему код выдачи, который ему сообщает покупатель, и маркетплейс понимает, что пора перевести деньги покупателя продавцу.
Рассмотрим весь эпизод и набросаем вопросы, которые определят направление для дальнейших размышлений. В списке вопросов сразу отметим тегами категории из журнала:
- Каким будет канал доставки кодов выдачи? Будут ли дублирующие каналы? #задача
- Как быть с частичной выдачей при отправке кода? Если выдавать покупателю все товары и заказы под одним кодом, ускорится выдача и очередь будет меньше. Зато частичная выдача затруднится или будет невозможна. Если же выдавать товары или заказы по одному, то с частичной выдачей все будет в порядке, а вот покупателю придется оперировать сразу несколькими разными кодами — к тому же это замедлит работу продавца. #противоречие
- Заказ оплачен и уже приехал в пункт выдачи, а покупателя нет неделю или больше — кто и как вернет ему деньги? #проблема
- Что будет, если покупатель потерял код, но уже находится в пункте выдачи? Есть ли альтернативные способы получить заказ? #проблема
По ходу принятия решений, вопросы будут заменяться допущениями и постулатами — результатами договоренности с командой и зазкачиками, а также новыми задачами и появившимися проблемами:
- Каналы отправки кодов: СМС (ссылка на макет) и ЛК покупателя, страница заказов. #договоренность
- Добавить в кабинет покупателя код выдачи. #задача
- Если покупатель потерял код или код не подходит, продавец снова отправляет код на телефон, указанный в заказе. Система позволяет выпустить три СМС-кода подряд, а после этого блокирует выдачу товаров из заказа на полчаса. На каждый код дается три попытки ввода — если код три раза введен неправильно, система предлагает отправить новый код. #договоренность
Когда на все вопросы найдутся ответы, сценарии обогатятся и трансформируются в подробную проектную документацию.
Литература
- Даниэль Канеман «Думай медленно… решай быстро»
- Марк Форстер «Сделай это завтра и другие секреты тайм-менеджмента»
- В. Никитин, С. Переслегин и другие «Инженерная онтология. Инженерия как странствие»
- Г. П. Щедровицкий «Программирование научных исследований и разработок», глава 4 «Концепция программирования»
- Блог Андрея на Medium
- Личный сайт Андрея с записями его выступлений на конференциях и презентациями
