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

Мне понадобился канал и я решил реанимировать этот. Примеры приёмов тоже буду закидывать, так что посмотрите, что тут будет (для меня это тоже пока интрига) и решите оставаться ли.

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

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

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

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

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

В этот раз разбирал канонический пример с интерфейсом преобразователя температур между шкалами Цельсия и Фаренгейта для лаборанта Холла из книги Раскина. Любопытно, что в текущие дни весь интерфейс уже схлопнулся бы до голосовой колонки и общения с ней. Лаборант Холл больше не нужен. По крайней мере для перевода температур.

Опубликовал главу про то как ставить вопросы.

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

Закончил главу про ситуацию проектирования. Можно почитать по ссылке и оставить комментарий или вопрос. Буду благодарен за такое участие.

Вообще это место где на моё исследование сильно начинает влиять системно-мыследеятельностная методология.

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

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

К сожалению, глава получилось сложной. Но я пока не вижу способов её упростить.

https://ashapiro.notion.site/1-2-36c7c772eb914b588e6cece4d135b1b4

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

Перед тем как описать другие инструменты схематизации процесса (event storming, service blueprint, наш собственный process mapping) решил сначала зафиксировать метод ключевых действий, который мне повезло сформировать. Сейчас описаны основные элементы, описание процедуры — в процессе написания.

Заходите на огонёк, спрашивайте в комментах Ноушн или здесь, буду рад ответить.

О силе и ограниченности тэгирования

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

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

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

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

Как у Зиснера о писательстве: «Следите за тем, где вы оставили своего читателя. Он всё еще в Америке, а вы уже говорите про Европу».

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

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

Бенджамен Уорф, Обозначение явления и его влияние на действия людей

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

Это произошло во время моей работы в обществе страхования от огня. В мои задачи входил анализ сотен докладов об обстоятельствах, приведших к возникновению пожара или взрыва. Я фиксировал чисто физические причины, такие, как неисправная проводка, наличие или отсутствие воздушного пространства между дымоходами и деревянными частями зданий и т. п., а результаты обследования описывал в соответствующих терминах. При этом я не ставил перед собой никакой другой задачи. Но с течением времени стало ясно, что не только сами по себе эти причины, но и обозначение их было иногда тем фактором, который через поведение людей являлся причиной пожара. Фактор обозначения проявлялся яснее всего тогда, когда мы имели дело с языковым обозначением, исходящим из названия, или с обычным описанием подобных обстоятельств средствами языка. Так, например, около склада так называемых gasoline drums «бензиновых цистерн» люди ведут себя соответствующим образом, т. е. с большой осторожностью; в то же время рядом со складом с названием empty gasoline drums «пустые бензиновые цистерны» люди ведут себя иначе: недостаточно осторожно, курят и даже бросают окурки.
Однако эти empty «пустые» цистерны могут быть более опасными, так как в них содержатся взрывчатые  испарения. При наличии реально опасной ситуации лингвистический анализ ориентируется на слово «пустой», предполагающее отсутствие всякого риска. Возможны два различных случая употребления слова empty: в первом случае оно употребляется как точный синоним слов null, void, negative, inert (порожний, бессодержательный, бессмысленный, ничтожный, вялый), а во втором — в применении к обозначению физической ситуации, не принимая во внимание наличия паров, капель жидкости или
любых других остатков в цистерне или в другом вместилище. Обстоятельства описываются с помощью второго случая, а люди ведут себя в этих обстоятельствах, имея в виду первый случай. Это становится общей формулой неосторожного поведения людей, обусловленного чисто лингвистическими факторами.

Организаторы DUMP поделились записью доклада про Event Storming. Спешу поделиться и с вами. Слайды.

Метод я сам использую около 1,5 лет. Он прост и призван форсировать коммуникацию и понимание в группе.

Медиум как платформа для статей вероятно всё. Куда переезжают, уважаемые дамы и господа?

Показал на схеме в чём сила USM. Из всех инструментов сбора требований, этот оказался самым синкретичным, то есть связывающим в одном месте много планов. В данном случае все компоненты действия (понятие теории деятельности и СМД-методологии). Осталось оформить «языки», в которых делаются еще несколько шагов до реализаций. Пока мы их делаем почти в уме или опосредованно через процедуры инвентаризации (структурные описи) и подбора конструкции из «театра машин».

5 сентябре буду рассказывать об управлении сложностью в продукте на конференции Product Sense. В рассказе будут упомянуты три инструмента, которыми мы пользуемся, два из которых моя разработка — журнал проектирования и дерево гипотез. Третий инструмент заимстован у архитекторов. Но самое главное не инструменты, а выводы. Я обобщил их до нескольких простых правил, которые помогут не растерять знания о сложной системе, которой является любой современный цифровой продукт.

Анонс выступления в ТГ-канале Product Sense