Журнал проектировщика

Инструменты проектирования

Фото Владимира Аршукова

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

Материал впервые опубликован в Sense32

Проблемы проектирования систем

Мы рассеяны, мечемся и не следим за целым

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

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

Обычная последовательность действий при этом такова.

• Обнаружить себя мечущимся
• Остановиться или намеренно замедлиться
• Перейти в режим журналирования — выложить все проблемы, гипотезы решений, противоречия, задачи, идеи на бумагу, доску или поля макета
• Удостовериться, что роение в голове остановлено и можно двигаться дальше

Предельная сложность

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

У меня когда-то был разговор с одним очень известным человеком (не буду называть фамилию), который во время аварийной ситуации вручную вывел реактор из закритического состояния. Много времени прошло, это уже пожилой человек с орденами и медалями. Я спрашиваю: «Как?» Он ответил: «Я моделировал в голове, что происходит с реактором». Так вот, сейчас нет человека, который может смоделировать в голове, что происходит в сложной системе. Технические системы по степени своей сложности вышли за пределы интуиции инженеров-конструкторов. П. Г. Шедровицкий, из интервью Эксперту.

Коммуникационные потери

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

К современному инженеру предъявляется больше требований, нежели к инженеру прошлого или позапрошлого века. Он должен знать сценарный анализ и уметь описывать взаимодействие инженерной системы и всех сред, в которые она погружена, не исключая, архитектурную, правовую, культурную среды. Он работает с полным жизненным циклом системы от стадии проектирования до стадии утилизации. Ему вменено экономить ресурсы, время, деньги и внимание руководства. От него требуют уникальной коммуникативной грамотности <…>. «Инженерная онтология. Инженерия как странствие», В. Никитин, С. Переслегин и другие

Я убеждён, что проектная группа обречена на осознанное накопление и структурирование знаний о создаваемой системе или провал. Потому что потери при передачи знаний о системе между участникам сделают работу неэффективной или вовсе остановят проект.

Журнал проектировщика как решение

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

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

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

Задачи журнала

Итак, задачи журнала:

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

Этапы работы с журналом

Журнал останется свалкой, если не организовать размещение, извлечение и чистку.

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

Формат «журнала»

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

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

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

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

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

Что делать если журнал разросся. Особенно неудобно работать с длинным перечнем или сплошным текстом. Здесь важно не терять быстрого доступа к любой из категорий, иначе инструмент начнёт мешать. По счастью в наши дни есть много инструментов для структурирования информации. Нам доступны всевозможные группировки за счёт построения иерархий со схлапыванием групп или образованием деревьев страниц или списков — например, Notion и Worflowy, соответственно. Доступны средства тегирования и динамической сборки документов по тегу — Airtable. Экспериментируйте в поиске своего лучшего формата.

Категории журнала

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

• Ситуация, сценарий
• Проблема, нежелательный эффект
• Задача
• Идея
• Противоречие
• Критерий готовности / успешности
• Договоренность
• Цель

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

Примеры категорий в журнале на основе Notion

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

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

Ведение журнала на примере

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

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

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

• Каким будет канал подачи кодов выдачи? Будут ли дублирующие каналы? #задача
• Как быть с частичной выдачей при выдаче кода? Если выдавать одному Покупателю все его товары и заказы разом одним кодом, ускорится выдача — будет меньше очередь, но будет затруднена или невозможна частичная выдача. Если выдавать по одному, то вопросы частичной выдачи решается, но Покупателю придётся оперерировать кучей отдельных кодов и замедлится работа продавца. #противоречие
• Покупатель оплатил, неделю или больше его нет, кто и как вернёт ему деньги? #проблема
• Что если код потерялся? Какие альтернативы, когда Покупатель уже находится в поле? #проблема

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

• Каналы подачи кодов: СМС (ссылка на макет) и ЛК Покупателя, страница заказов. #договоренность
• Добавить в кабинет покупателя код выдачи. #задача
• Если код утерян Покупателем или не подходит, Продавец выпускает ещё один код на тот телефон, что указан в заказе. Система позволяет выпустить три кода (СМС) после чего не дает выдавать полчаса. Не более трёх попыток ввода на каждый код, после них система предлагает выпустить новый код. #договоренность

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

Литература

• Дэнниел Канеман, Думай медленно… решай быстро
• Марк Форстер, «Сделай это завтра и другие секреты тайм-менеджмента»
• В. Никитин, С. Переслегин и другие, Инженерная онтология. Инженерия как странствие,
• Г. П. Щедровицкий, Программирование научных исследований и разработок, глава 4 «Концепция программирования»