Ильшат Габдуллин

Анонсы постов этого блога публикуются в тг-канале: https://t.me/igabdullin_blog

Пост по второму разделу курса «Практическое системное мышление» («Воплощение и описание системы»)

Продолжаю проходить онлайн-курс «Практическое системное мышление».

Пост по первому разделу курса.

Из задания ко второму разделу:

Убедитесь, что в вашем рабочем проекте в конечном итоге создаётся физическая система, а не просто какое-то описание. Что изменится в физическом мире, если ваш проект закрыть прямо сейчас, чего в физическом мире не будет существовать без результатов вашего проекта? Напишите об этом пост в порядке мышления письмом.

Про детали рабочих проектов тут рассказывать не могу, но попробую рассказать примеры подходов, которые использую при разработке чего-то нового в наших продуктах (занимаемся разработкой ИТ-систем для ИБ).

Так как в первую очередь надо понять, что изменится в реальном мире, то один из моих любимых вопросов: что будет если ничего не будем делать? Дальше, как правило, идет цикл из уточняющих вопросов, чтобы докопаться до «мяса» (конкретных примеров из жизни, из которых можно выявить решаемую в надсистеме проблему/неустроенность) — а после, либо собеседник сам замечает абсурдность своей идеи (часто из-за оторванности от физического мира), либо вскрывается что-то очень ценное.

Мои любимые ответы:

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

Еще из любимых вопросов: «Вот допустим сделали, давай теперь представим как придем к заказчику и будем ему это „продавать“. Или представим (в идеале напишем) маркетинговую листовку/пресс-релиз/лендинг». Эффект такой же — либо понимаем абсурдность идеи, либо выявляется что-то ценное. Если после прочтения такой листовки/пресс-релиза/лендинга идея не покажется сильной — значит, что-то не так. Еще хорошо смотреть на него и спрашивать себя или собеседника: как думаешь, вот за это <список из выдуманного пресс-релиза> заказчик будет готов заплатить хоть сколько-то? Почему?

Про пресс-релиз подсмотрел у Amazon (подробнее про это в пятой главе книги Working Backwards: Insights, Stories, and Secrets from Inside Amazon) и вот первый пресс-релиз Amazon, построенный по этому принципу. А тут немного на русском.

Что еще показалось важным во втором разделе:

  • Как думать о компьютерных программах (как о физических объектах, приносящих пользу в момент эксплуатации и что наши обязанности не заканчиваются написанием кода и его проверки на тестовом сервере) — это надо всем нам, айтишникам, вбивать в голову еще с универа. Очень советую почитать (доступ к тексту бесплатный, нужно просто зарегистрироваться)
  • Про моделирование объектов в ИТ-системах (они должны адекватно отражать объекты физического мира) и как это потом кратно снижает сложность добавления новых функций и поддержку систем. Развернуто про это написано в книге Chris Partridge «Business Objects — Re-Engineering for Re-Use» (ссылка в сноске №100 на этой странице)
  • «Аналитик» vs Инженер — один что-то описывает и делает документы-бумажки (рекомендации), а второй думает о том, как довести систему от задумки до эксплуатации в надсистеме (и вывода из эксплуатации) — то есть меняет мир. Речь не про должности, а роли! Тот, кто имеет в названии должности слово «аналитик» может вполне себе выполнять инженерную работу.
  • Инженерный взгляд на обучение людей как на изготовление где-то у них в мозгу мастерства (которое возьмет на себя управление в нужной проектной ситуации)

2023W8&9 Log

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

Племянник (12 лет) увидел фотки скелетов динозавров из музея и спросил: «а вдруг они в музее всё это придумали и просто сделали кости из пластмассы?». А отличный вопрос! Действительно, как объяснить так, чтобы человек понял и поверил и при этом, желательно, ограничившись мысленным экспериментом без поездки в палеонтологическую экспедицию? Вероятно, должен быть какой-то элемент доверия к объясняющему и внятная аргументация с усложняющимися, находящими отклик из личного опыта, причинно-следственными объяснениями (не в духе «солнце встает потому, что так устроил тот, кто создал этот мир». — иначе он же потом и будет объяснять свои поступки аргументацией такого же типа). Это актуально не только с детьми и динозаврами, но и со взрослыми. Особенно, когда взрослый верит в какую-нибудь теорию заговора или прочую чушь и все аргументы опровергает словами «мы этого не можем доказать, мы этого не видели, не можем знать наверняка».

***
Понравилось видео С. Савельева, где он приводит примеры сложного поведения животных и их индивидуального обучения и изменчивости. Если хотите удивиться, какие чудеса бывают в животной природе — рекомендую. Вот ссылка сразу с таймкодом (хотя в самом начале тоже интересно). Примеры:

  • бобуины воруют у людей щенков, выращивают из них собак и использую их как люди для своих целей: для охраны и пр
  • мелкие муравьи не могут забрать пищу у больших хищных муравьев, но с помощью палочки промакиваеют b[ еду и уносят палочку с собой (чтобы потом съесть с нее то, чем она успела пропитаться)
  • рыба брызгун брызгает в фотографию того человека, который давал ей еду (то есть научается распознавать человека даже на фотографии)
  • треска приспосабливает датчик, который вешали на нее для наблюдений, чтобы с помощью него дергать за веревку (чтобы получить еду)
  • рыбы цихлиды запоминают результаты боев самцов и используют это знание, чтобы выбирать себе противника послабее (кто проиграл больше всего боев), когда бой дойдет до них. При этом, если наблюдатель пропустил какой-то бой, то он аппроксимирует все схватки, которые увидел раньше и использует это для выбора
  • рыба групер кооперируется с муреной или осьминогом для совместной охоты (межвидовые взаимодействия!)
  • примеры ментальной презентация событий у животных (моделирование событий!), чтобы понимать что произойдет в ближайшее время. И это проявляется даже у высших насекомых.

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

***
В этом видео c С. Ураловым понравилось объяснение почему важно читать книги, чтобы не попадать под влияние промывания мозгов. Если в двух словах: тренировка памяти, чтобы связывать отдаленные причинно-следственные цепочки. И в целом понравилось все интервью (там про когнитивные войны).

Картинка дня: я всегда это знал, просто слово подобрать не мог


За картинку спасибо HakunaNatata. Открыла ящик Пандоры, у этой картинки может быть бесконечно много прикольных подписей :)

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

Или всякие бытовые/рабочие ситуации:

  • как собака, все понимаю, просто сказать не могу
  • вот ты сейчас рассказал, а я все это давно знал, просто слова подобрать не мог
  • продакт команде:
    • я тут бизнес кейсы принёс для новой фичи
    • вот вам концепция нового продукта! (если не всматриваться, то со стороны выглядит похоже на что-то осмысленное) А дальше пусть аналитики всё детализируют и распишут в ТЗ
  • это я на каком-то совещании, где ничего непонятно, но все с умным видом что-то обсуждают
  • мычание в уме — когда ленишься записывать на бумагу свои мысли, но думаешь что тебе всё понятно

А вот для тех, кто в теме (Канемен, ШСМ):

  • мысли в моей голове (вид со стороны), когда забыл как включать S2 и не знаю о том, что такое мышление письмом :))
  • я прошел Практическое системное мышление не выполняя упражнений. «Все понятно», но сказать кроме того, что «книжка очень интересная, про системы» ничего не могу

2023W6-7 Log

Дописал пост по первому разделу ПСМ. Писал долго (неделю), но систематично, каждый день. «Чистого» времени получилось тоже неприлично много: в будние дни тратил минимум час, в выходные мог просидеть и по 4. Будем считать это издержками на освоение новой непривычной деятельности. И дальше, наверное, будет уходить меньше времени. Хотя подозреваю, что столько же или больше, просто будет увеличиваться сложность тем (терминами Дойча — «сложность вычислений»).

В одном из постов студента ШСМ заметил, что некоторые проблемы у нас схожи — хочется идти дальше по материалу, а не тратить дни/недели на написание постов. Нашел компромисс (такой себе, но хоть так) — продолжать продвигаться по материалу следующего раздела, но каждый день хоть по чуть-чуть готовить пост по предыдущему разделу. В некоторые дни читать материал не успевал, поэтому приходилось читить, чтобы в Aisystant не слетел непрерывный период — делал фейковое действие в архивных курсах (я ведь в этот день занимаюсь курсом — пишу по нему пост!). Как идея для развития Aisystant в ШСМ — учесть этот сценарий (Юли Чайковской предложила учитывать «помидорки» в статистике активности — отлично подходит для решения этой проблемы).

Как писал? В процессе чтения делал заметки нескольких видов:

  • что-то вроде конспекта (называю его «опорный конспект»), в котором пытаюсь сжато своими словами выразить основные мысли и цепочки рассуждений автора. На всю книгу/курс просто одна большая заметка, со структурой заголовков, повторяющих заголовки книги (заголовки добавляю по мере чтения). Понятно, что «основное» выделяет текущий я и не факт, что через месяц или год я бы выделил такое же (ведь будет больше понимания каких-то других тем, которые могут как-то соотноситься с этой и это может кардинально изменить восприятие). В чем замечаю пользу такого подхода: лучше удерживает внимание на текста; иногда, когда смотришь на заметку по подразделу вот так, с высоты (как на схему, которую можно охватить) ловятся «инсайты» (которые тоже записываю! см. следующий пункт) и материал понимается лучше; аналогично можно охватить и всю книгу после прочтения. Ведение такого конспекта увеличивает время и выглядит как костыль (А.И. не поощряет конспекты), но пока продолжаю эксперимент. Может быть, со временем и тренировками, в нем не будет необходимости.
  • если в процессе чтения или при формулировании мысли автора своими словами пришли какие-то идеи, свои мысли или вопросы, то записываю их в ту же заметку. Чтобы не запутаться, где мысль автора, а где мои, свои отмечаю специальной меткой и эту метку выделяю заливкой, чтобы потом быстро находить (использую сокращение «мсл» — чтобы потом быстрее искать и чтобы не мешалось, если захочу найти в заметках слово «мысль», которое используется не для пометки своих мыслей). Плюс в наличии «опорного конспекта» еще в том, что свои мысли встраиваются к в контекст материала курса.
  • если мысль автора показалась особенно интересной, то коротко формулирую её, делаю в виде отдельной заметки и уже там описываю своими словами более детально, дополняю всем, что приходит в голову в процессе написания, плюс стараюсь понять и записать почему эта мысль так зацепила — часто в результате таких размышлений возникают связи с другими заметками. Выглядит такое выделение мысли в отдельную заметку примерно так, как Justin DiRose показывает в этом видео — где он выделяет абзац и создает из него страницу.

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

Пример «прикольного», как иногда кардинально меняется текст в процессе написания. Про бесполезность определений и глоссариев сначала с умным видом написал о том, как надо описывать концепты (вместо словарных определений) и чуть-чуть примеров из опыта. Перечитал и понял, что это получился кривой конспект материала учебника, а лучше, чем автор я не перескажу. Плюс, по заданию как раз конспекты в постах и не нужны. Взял вкропления личных примеров из текста и начал разворачивать исходя из них. И дальше оно как-то само пошло. Субъективный критерий (но не во всех случаях применимый), что что-то пошло как надо — текстом начинает хотеться поделиться с другими.

***
Сходил в Манеж на выставку «ДК СССР». Случайно, просто шел прогуляться на Красную площадь, заметил вывеску и не смог не зайти.

Смотрел через призму того, насколько важная функция у домов культуры (и самой культуры!) была в раннем СССР. И как её целенаправлено использовали — ставили конкретные задачи. Фотография — создать образ нового рефомированного общества (и даже целые жанры создавались), детская книжная иллюстрация  — показать практическую деятельность людей и используемые в ней машины и оборудование (по факту — готовить трудового человека), объяснить назначение бытовых предметов и пр. Как писал Макаренко (он говорит в контексте воспитательных колоний, но суть такая же):

«А я должен сделать не паровоз и не консервы, а настоящего советского человека, а наробразовские идеалисты требуют не меньше как „человека-коммуниста“»

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

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

фотки можно листать, там несколько штук

***
Еще из культурно-развлекательного: сходили на новый Аватар. Не скажу, что я в восторге, но целом — понравилось (не зря же три+ часа пролетели незаметно и даже не возникло мысли уйти с сеанса или что фильм затянут).

***
Из домашнего: доделал подсветку на кухне. К MVP добавлен инкремент к виде оставшихся двух секций (про первую часть и почему вообще решил делать — рассказывал тут). Провел эксперимент: выключил её в процессе готовки и всяких других кухонных дел. Эксперимент показал, что подсветка — крайне необходимая штука, без нее как в кромешной тьме :) Как раньше без нее готовили — непонятно.

Пост по первому разделу курса «Практическое системное мышление» («О мышлении»)

Как уже писал — начал проходить свежую версию онлайн-курса «Практическое системное мышление» (ПСМ). Одна из важных практик при освоении материала курса — мышлении письмом (см. заметку), поэтому, честно выполняю задание по первому разделу — написать пост по пройденному материалу.

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

Так как это пост по первому разделу, то опишу в нем и ожидания от курса в целом. С 2018 года это у меня уже где-то 4-5 проход по курсу разных версий: 2018, 2019, 2020, и текущий версии 2023. Всё как говорит Анатолий — каждый раз читается почти как новый курс.

В этот проход хочу глубже понять про почти революционное заявление об отсутствии требований (требования vs концепция использования и концепция системы), уточнение понятия архитектуры, безмасштабность, неустроенности между системными уровнями как причина роста сложности (эволюции?) систем. Эти вопросы будут подробнее раскрываться в курсе Инжерении, но для «пологого» входа в тему, думаю, ПСМ отлично подойдет. И, скорее всего, будет еще много интересных открытый, о которых сейчас не могу предположить. Тем более, Анатолий в каждой новой версии курса дополняет и улучшает объяснения старых понятий (в этом плане даже книга 2018 года в ядре своем не потеряла актуальность, просто там меньше примеров и объяснения более сложные для понимания).

Про бесполезность определений и глоссариев

Раньше, когда читал всякие сложные-умные и непонятные определения какого-то термина (особенно, что касается рабочих ИТ-шных тем), думал, что причина их непонимания была во мне (отчасти, конечно, это так).

Чтобы понять о чем я — посмотрите любой «глоссарий» в каком-нибудь ТЗ. Вот первый попавшийся при беглом гуглинге пример:

CASE-технологии — системы автоматизированного проектирования (САПР) для процессов и (или) программного обеспечения их поддержки. CASE-технологии являются программными инструментами, в которых автоматизированы те или иные методы (методологии) анализа, проектирования и разработки.
(источник)

Безусловно, о терминах (а точнее — о концептах, которые за ними стоят) надо договариваться. Но хорошо бы это делать так, чтобы не запутать друг друга еще больше. Как? Точно не с помощью глоссария.

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

  1. Кто-то, кто не глубоко погружен в контекст, читает «ТЗ», встречает там множество новых для него терминов и говорит: «ничего не понятно, сделайте глоссарий, потом поговорим!»
  2. «Так принято у нас в компании». Или это требования какого-нибудь ГОСТа, которого мы придерживаемся (особенно, когда документы делаются для гос.заказчиков или крупных организаций, где «по регламентам» глоссарий обязателен чуть ли не во всех документах
  3. Автор документа верит, что глоссарии — это добро и они должны быть всегда. Этот случай похож на предыдущий, только тут это делается по собственной воле. Обычно, это добросовестно заблуждающиеся специалисты, которые хотят, но не знают хороших методов как сделать лучше. Или специалисты из старой школы, которые привыкли писать формальные «заумные» документы и думают, что без них вся разработка встанет и никто никакой системы не разработает — но по факту эти документы никто не читает в силу их бесполезности (или крайней сложности вычитать из них что-то полезное), в основном они нужны для галочки при подписании актов выполненных работ с заказчиками (чтобы подписать акт, заказчик должен увидеть тонны макулатуры, на которой написано «ТЗ на разработку ...» и с красивой ГОСТовской чертежной рамочкой на титульном листе).

Во втором случае автор документа пишет обтекаемые, дежурные формулировки, чтобы к ним не было вопросов. Или пишет сложно, заумно, чтобы человек на том конце подумал, что он не очень умный и поэтому лучше промолчит, чем задаст «глупый» вопрос.

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

А вот в первом случае, где действительно есть задача добиться общего понимания (и даже есть конкретый человек, в какой-то роли, которому содержимое этого документа зачем-то нужно), картина очень интересная.

Вот, автор сделал глоссарий и просит того, кто его требовал, провести ревью документа еще раз. Тот читает, задает автору много вопросов. Проходит несколько итераций: в комментах в Confluence, в переписках в почте, на множестве встреч и пр. То есть автор лично вводит этого человека в контекст, «обучает», доносит мысль огромным количеством коммуникаций. По результату автор немного меняет формулировки (они стали лучше, но все еще неудовлетворительные). Тот, кто задавал вопросы перечитывает их и, так как у него в голове уже сформирована картина, вопросов уже не имеет — ему кажется, что в целом новые формулировки ок. Но следующий же человек, который будет читать этот документ в первый раз — задаст еще миллион вопросов, потому что не поймет о чем идет речь. Цикл повторится. Формулировки уточнятся, но все равно останутся как минимум неудовлетворительными. Или хуже — их перестанет понимать, тот, кто читал предыдущую версию. Как так происходит?

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

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

  • делать описания, где концепты (выраженные каким-то термином) употребляются в контексте с другими концептами и по этому описанию понятно как они друг с другом соотносятся. Иначе, это как учить иностранные слова только по их прямому переводу, без контекста, не пытаясь смотреть примеры предложений, в которых это слово используется. Объяснения станут длиннее. Но договориться, донести мысль и убедиться, что мы правильно друг друга понимаем станет проще. Нейросетка собеседника будет тренироваться использованием терминов в соответствующих контекстах.
  • приземлять примерами использования
  • не переобощать. Собака — это животное. Но если для передачи смысла важна специфика именно собаки, нельзя оставлять «животное»
  • понимать, что каждый смотрит на систему под призмой своего ролевого интереса. Разным ролям нужно найти ответы на свои вопросы и поэтому ничего универсального и короткого сделать не получится (конечно же, речь про хоть сколько-то сложные темы).
  • ввязываться в споры «о терминах» с кем-то только если мы и наш собеседник хотим как-то изменить мир (к лучшему), что-то сделать, воплотить в реальность. А не ради «истины».

Рекурсивность и фрактальность

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

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

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

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

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

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

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

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

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

Почему сложно переучиваться (контринтуитивным, фундаментальном вещам)

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

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

Последовательное увеличение сложности задач

Сразу браться применять системный подход на сложных задачах — плохая идея. Нужно увеличивать сложность проектов постепенно. Анатолий предостерегает: часто студенты сходу берут сложные системы, думая, что они простые. Например софт. Как писал выше, в случае с софтом мы не просто «внедряем ИТ-систему», а меняем организацию, вместе с людьми (потому что ИТ-системы поддерживают деятельность организации) — а это огромная сложность, так как организация — это следующий за личностями системный уровень, то есть ещё более сложный (нужно понимать неустроенности/frustrations, возникающие между людьми и организацией, организацией и окружающими её сообществами, а также обществом в целом).

Анатолий рекомендует примерно такую последовательность для укрепления владения системными концептами: сначала какую-то «железную» систему, потом себя, потом небольшие команды, дальше — организации. И уже силами этих организаций менять что-то в их окружении (и тут, видимо, тоже надо последовательно увеличивать сложность и масштаб того, что меняют эти организации). Вот эта мысль про то, что залезаешь в организацию как в аватар и им меняешь что-то уже более масштабно — показалось интересной с точки зрения личного стратегирования на разных горизонтах планирования. Но меняешь не просто «что-то», а сначала находишь целевую систему в её окружении, выявляешь её функции — и это сильно помогает продвинуться в том, как именно надо проектировать/перепроектировать организацию. Вспомнилась идея Вячеслава Мизгулина про то, что процесс проектирования резко ускоряется, когда начинаешь правильно использовать функциональные модели. Это в контексте проектирования железных систем, но тут плюс-минус такая же ситуация. На мелком масштабе нарабатываешь понимание подходов (ЦС, окружение, системы создания, практики и пр) и дальше с этим идешь в более крупные масштабы.

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

Неустроенности между разными системными уровнями

Примеры из учебника:

  • вирус и организм. Появляется иммунная система, убивает вирус. Вирус мутирует — обманывает иммунную систему. И так на усложнение.
  • мемовирусы — информация, которая распространяется в людях и меняет их поведение. Например, в более агрессивную сторону.

Мои попытки найти примеры:

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

«Требований» больше нет

В первом разделе тема еще не раскрыта, но то, что было сказано — пока не вызывает противоречий. А даже наоборот — описывает то, что действительно происходит в жизни, задает более точные объекты внимания вместо слишком размытых «требований», которые каждый в проекте понимает по-своему. Концепция использования, концепция системы, архитектура, рабочая документация с описанием, достаточным для изготовления и пр.

По моему опыту, путаница в основном в скачущих (а часто вообще не выделяющихся) системных уровнях — «требованиями» называют всё. Разработчикам нужно описание решения на уровне, максимально близким к тем, под которые они пишут код. Другим ролям — то, что по уровню «крупности» ближе к непосредственному оператору системы. Третьим — автоматизируемые «бизнес»-процессы в организации (и их проблемные места). Четвертые, говоря «требования», ожидают, что «аналитик» найдет техническое (и не только) противоречие, решит изобретательскую (инженерную) задачу и опишет конкретное решение. Причем попытки разделить на «бизнеc»-, «системные»-, «технические»- ситуацию не улучшают, потому что под теми же «бизнес»-требованиями каждый снова ожидает увидеть что-то свое. А универсального определения нет, потому что надо рассматривать системные уровни — а они уникальные в каждом проекте (какое-то обобщение, скоре всего, можно придумать, но только после того, как члены команды будут понимать концепт системных уровней).

Просто короткие мысли

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

2023W5 Log

Диспоузер (из прошлой заметки) потянул за собой другую проблему — мало света над раковиной и плохо видно, когда собираешь по всей раковине в диспоузер отходы для перемолки). Поэтому пришлось делать следующий шаг «очумелых ручек» — подсветку кухонной рабочей зоны, в том числе раковины. Пошел не простым путем с готовыми модулями, а решил взять по частям набор для светодиодной подсветки: алюминиевый короб, нормальный блок питания, светодиодную ленту, акустические провода с сечением 0.7. Готовые соединители не брал, расчехлил паяльник. Проект будет реализовываться минимум в два этапа, каждый с оконченной ценностью (аджайл!). Сегодня сделал подсветку над раковиной и подготовил электроразводку, дальше доделаю остальные части рабочей зоны.

В остальном же, диспоузер идеально справляется с теми юзкейсами, под которые его и планировал (писал тут). Отличный инструмент.
***

Физическая активность — на удивление стабильно, уже месяц. 4-5 раз в неделю без фанатичных нагрузок. Хорошо переключает голову после рабочего дня и, субъективно, прибавляет энергии. На «лестнице» теперь почти не хожу — перешел на беговую дорожку (только не бегаю, а быстро хожу с контролем пульса и делаю 2-3 минутные беговых интервала). Хочу найти нормальные материалы по пульсовым зонам, но пока всё что нашел — либо от бегунов-фанатиков, которые стремятся «растянуть сердце» (и получить в будущем проблемы), либо сомнительной квалификации «тренеры по бегу», либо те, кто зазывает к себе на прием, чтобы дать индивидуальные рекомендации. Поэтому, чтобы не наломать дров хожу в основном в зоне пульса, не доходящей до границы аэробного режима (по часам Huawei Watch Fit 2) и пара 2-3 минутных интервалов в аэробном и анаэробным режимах. Турник — стабильно 10 раз в первый подход (начинаю прям ощущать мышцы спины, которые включатся в работу), во второй-третий подходы получаются 4-5 повторений. Брусья — в первые дни мог делать только на тренажере со снятием веса, то сейчас спокойно 10-12 повторений на обычных брусьях с полным собственным весом. В бассейн так же — через тренировку, но там скучно, поэтому просто проплываю 200 метров и завершаю.
***

Решили попробовать кофемашину с капсулами Nespresso Original (такие маленькие алюминевые). Капсул выбор сильно больше, они есть в любом Дикси/Пятерочке. Сам аппарат взял от суб-бренда Xiaomi — Mijia Capsule Coffee Machine (S1301) — и по цене нормальный, и дизайн компактный-приятный, и функционально такой же, как у «брендовых» моделей аналогичного класса. Старая кофемашина с капсулами Dolce Gusto уже на последнем издыхании, но честно отработала где-то 10-11 лет. Из отличий — надо привыкать к объемам порции (максимум можно настроить 180 мл на порцию, но надо экспериментировать с капсулами, вероятно, не каждую можно «проливать» так много).
***

Последнее время проникся лекциями историка Егора Яковлева (его проект «Цифровая история»). Особенно по темам раннего Союза, про Ленина и Сталина (спасибо Ю.Б. за историческое просвещение и интерес к теме истории и не только).

В этом ролике с Егором Яковлевым понравилась мысль про догматизм. Между теорией/идеологией и реальной жизнью есть разрыв, поэтому нельзя всегда слепо следовать «догме» теории — это может привести к фатальным последствиям. Кажется, это прям популярная проблема команд, которые осваивают практики scrum — начинают бескомпромиссно выполнять все ритуалы (по форме). Хотя важнее уловить суть (не форму, а содержание) и маневрировать, иногда упуская не важные на текущий момент элементы формы.

2023W4 Log

Начал проходить свежую версию онлайн-курса «Практическое системное мышление». В планах пройти по всей линейке новых и обновленных курсов Анатолия: Методология, Системная инженерия, Системный менеджмент, Образование для образованных, Как учить образованных — так что это займет слот non-fiction литературы минимум на полгода.
***

Написал заметку про книгу Нормана «Дизайн привычных вещей». Интересный опыт, так как получилось похоже на то, о чем писал Аренс в «Как делать полезные заметки»: ни на одном шаге не приходилось делать сверхусилий: сначала просто делал заметки во время прочтения (основные идеи автора своими словами и свои мысли, которые возникли при прочтении книги), потом из этого набора заметок сформировал черновик поста, потом вычитал и внес финальные правки. Причем, если не записывать свои мысли и идеи по ходу чтения (а это не сложно и не долго!), то потом далеко не факт, что получится их вспомнить (или придется долго прокрастинировать, так как сесть писать чистого листа будет сложно — а скорее всего просто никогда этим не займешься). Когда же все записано, то просто читаешь это, прикидываешь основные моменты, которые хочешь донести и делаешь из этого план черновика (он обязательно поменяется и это нормально), дальше развиваешь и дополняешь мысли из этого плана, связывая с какими-то другими мыслями (в этом и прелесть публичной заметки — для себя бы так не напрягся), а местами просто копируешь текст из заметок, которые делал в процессе чтения книги.

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

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

Пригодилась заметка про OKR — на работе попросили дать комментарии по поводу прошедшего тренинга. Просто копипаст + небольшие правки под контекст вопроса — 10-20 минут времени и готово, ведь все мысли уже обдуманы. Мышление письмом и личный экзокортекс — отличная штука.

***
Вчера установил на кухню диспоузер (измельчитель пищевых отходов). Пришлось повозиться, но все получилось.

Мои основные юзкейсы:

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

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

Диспоузер взял фирмы Bone Crusher, среднюю модель BC-810. Хватило бы и самой начальной (BC-610), но в отзывах пишут, что из-за особенностей конструкции одного элемента (молоточка) в измельчительной камере, диспоузер начинает забиваться и плохо перемлывать. Проблема решается простой механической чисткой или закидыванием в камеру металлической гайки — мне норм, но не хочу заставлять этим заниматься Лену, когда меня нет дома (плюс можно остаться без работающего слива в раковине на кухне). Думал про старшую модель BC-910, там чуть мощнее и быстрее двигатель и есть магнитный уловитель металлических предметов, но по отзывам этот уловитель можно поставить только на тонкие раковины (в основном стальные) и он слабый, поэтому показалось, что отличия между 810 и 910 только маркетинговые и решил не переплачивать 10 тыс.

***

Продолжая каршеринговую и китайско-автомобильную тему прошлой недели: прокатился на новеньком Cherry Tiggo 4 — ощущения, как от KIA Rio X-Line: минимальный необходимый уровень комфорта есть, но ощущения как от бюджетного автомобиля — коробка подергивает, элементы интерьера как у машин 2010-х. В этом плане HAVAL JOLION показался больше похожим на Audi Q3 (пару лет назад тоже катался на такой в каршеринге), только с небольшими проблемами с эргономикой в салоне.
***

Илья Бирман выпустил новую версию Эгеи (использую как движок для этого блога). Обновился. Пока кажутся непривычными новые шрифты в стандартной теме.

Книга «Дизайн привычных вещей» — Дональд Норман

Бумажный экземпляр второго издания (справа) у меня был уже лет 6, но прочитать от корки до корки всё никак не доходили руки. Несколько лет назад начинал читать, уловил идею про то, что продукт должен подсказывать как им пользоваться и отложил. Но в декабре решил-таки прочитать полностью, тем более на Литресе как-то по акции покупал самое свежее, аж 2018 года, издание от МИФа (с очками на обложке, слева на картинке).

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

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

Взаимодействие человека с продуктом — это коммуникация, аналог коммуникации между людьми

Только наш «собеседник» — это не очень умная, но зато послушная железка (что заложили — то и сделает). Чтобы коммуникация была успешной и приятной, создатели железки должны заложить в нее, кроме основной функции, еще и то, чтобы она учитывала наши человеческие особенности.

Вспоминается мысль, которую услышал у Дорофеева:

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

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

А еще у нас, людей, ограниченная рабочая память (пресловутые «семь плюс/минус два» объекта внимания), крайне изворотливый мозг, который стремится как можно меньше тратить энергии и избегает попадания в неудобные ситуации, а если попадает — то включает готовые автоматизмы (не всегда уместные). И много чего еще. Как следствие — при взаимодействии с системой мы совершаем ошибки или неточные действия. Когда коммуницируем между людьми такое обычно демпфируется: если человек нас не понял, то задаст вопрос, попытается договориться, подскажет пример с собственного опыта и пр. А машина — сама так не умеет.

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

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

Нужно делать хорошую коммуникацию — звучит хорошо. А делать-то что?

Семь концептов от Нормана

Это объекты внимания, которые нужно удерживать при разработке системы. В книге кроме этих семи концептов были и другие (например, 7 этапов действия или ошибки и промахи) — кому интересно, рекомендую про них прочитать в самой книге.

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

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

Означающее
Если не получается сделать возможности очевидными для восприятия, то нужно как-то обозначить возможность (и антивозможность). Означающее гарантирует наглядность, позволяет донести фидбек понятным образом. Если оглядеться, то весь мир состоит из таких подсказок! При этом означающее — не всегда текст. Пример: наклейки-кружочки на стеклянных дверях (обращают внимание, что впереди стекло и через него надо пытаться пройти насквозь). Или пример Нормана: вертикальная полоска на двери, которая показывает с какой стороны нужно толкать дверь.

Фидбек
Когда всегда есть информация о результате действия пользователя и текущем состоянии системы. Сделал действие — легко понял новое состояние системы. Система дает понять, что обрабатывает запрос. Фидбек — информация, которая нужна, чтобы понять что произошло по результатам действия. Достигается за счет отображения на устройстве того, какой эффект этой действие вызвало (не всегда на экранах или текстом, но и звуком, каким-то ответным движением и пр. Например: звук заведенного мотора в автомобиле — если будет слишком хорошая звукоизоляция салона, его можно не услышать и подумать, что машина не завелась).

Пример системы с плохим фидбеком из моего опыта: дверной звонок — повесил у входной двери беспроводную кнопку (от умного дома Aqara). Курьеры нажимают на нее, не видят и не слышал фидбек (пальцем чувствуют, что кнопка щелкнула, но не слышат звук звонка в квартире, а кнопка не дает никакой информации о том, что она действительно сработала). Проходит 3-5 секунд, они думают, что ничего не произошло и начинают стучать по двери (а это жутко раздражающий громкий шум) — они получили фидбек и уверены что жильцы квартиры их услышат.

Другие примеры плохого фидбека:

  • Пешеходный светофор и кнопка для пешеходов — замечал, что ожидающие зеленого света пешеходы нажимают ее по 10 раз. Даже если у нее загорается лампочка, что запрос принят. У них нет информации о том, через сколько секунд загорится зеленый свет (не на каждом пешеходном светофоре такое есть в связке с кнопкой), при долгом ожидании людям начинает казаться, что если они нажмут кнопку еще 10 раз, это ускорит включение зеленого света.
  • Кнопка вызова официанта в кафешках (хочется 10 раз нажать потому что не знаешь — приняли вызов или нет, хотя лампочка на кнопке загорается).

Хороший фидбек — мгновенный и информативный. Он дает понять, если что-то пошло не так и что нужно делать. И его не слишком много (он уместный и по важным вещам, иначе отключат и пропустят важное).

Концептуальная модель
Модель того, как именно работает система. Хорошо, если внешний вид системы дает всю информацию, чтобы понять концептуальную модель (полезную для цели пользователя, но возможно упрощенную). Это дает понимание и ощущение контроля ситуации, по ней можно хоть как-то прогнозировать то, как будет вести себя система. Пример: руль колеса автомобиля. Концептуальная модель объяснит как работа элементов управления влияют на транспортное средство (руль через ряд механизмов связан с передними колесами и когда крутишь его влево — они поворачивают влево и при движении это приводит к повороту машины влево). Или педаль газа — нажал сильнее, двигатель увеличит обороты и это приведет к большему ускорению автомобиля.

В системном подходе концептуальной модели соответствует понятие функциональной схемы.

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

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

Еще один пример плохой проекции: регуляторы конфорок в плитах. Люди их путают чаще, чем кажется. Я сам недавно включил не ту, которую хотел, а ту на которой стояла тарелка (которая там просто стояла для удобства складывания на нее лопатки для перемешивания). Естественная проекция в этом случае была бы такой, где связь регулятора и управляемого им объекта очевидна — то есть когда ручки управления конфорками выстроены не в ряд (не всегда спасает даже рисунок рядом с каждой ручкой — каждый раз надо прикладывать ментальные усилия!), а в таком же пространственном расположении, как сами конфорки (два ряда по две ручки, а не один ряд по четыре).

Ограничения
Когда система не дает просто так сделать то действие, которое делать в данный момент либо нельзя, либо нежелетально. Норман приводит пример полицейским мотоцикла из Лего — все детали спроектированы так, что любой поймет как их сопоставить друг с другом, даже без инструкции. За счет разных видов ограничений (физических, культурных, семантических). Физические ограничения: переднее колесо в несоответствующую ему заднюю вилку, рулевую колодку не в переднюю часть корпуса. Это упрощает использование, потому что снижает количество возможных комбинаций. Просто не получится сделать неподходящее действие. Пример культурного ограничеия: синюю фару физически можно поставить на место фары ближнего/дальнего света, но в культуре принято, что синий — это цвет проблескового маячка у полицейских, поэтому мы без проблем понимаем что ставить его надо на место мигалки. Пример семантического ограничения: человечка мы не посадим лицом назад, потому что понимаем — в этом нет смысла.

Еще примеры ограничений (не из книги):

  • кнопка SOS в некоторых современных автомобилях (где есть ЭРА Глонасс): чтобы избежать ложных срабатываний (например, хочешь включить освещение в салоне, а попадаешь в кнопку SOS и вызываешь оператора 112), делают откидную кнопку-ограничитель, как в фильмах, где показывают пилотов истребителей, которые перед тем, как выпустить снаряд сначала должны открыть крышечку над кнопкой выпуска снаряда).
  • вилка USB-A — вставить её неверно не получится, она и разьем имеют ограничители, но их невозможно заметить. Я постоянно путаю сторону, но придумал эвристику — если разьем, куда вставлять вилку расположен горизонтально, то вилку нужно вставлять стороной, где два квадратных отверстия наверху:

В софте можно придумать массу аналогий: деактивировать кнопку, действие которой не разрешено выполнять с текущими параметрами (и объяснять почему и что нужно сделать, чтобы она стала активной!), не позволять выбрать значение неподходящего типа и пр.

Если от пользователей продукта нет обратной связи про его неудобство — это не значит, что все хорошо

Заговор молчания — когда мы понимаем, что проблема в нас, но молчим, потому хотим скрыть чувство беспомощности и вины (и что люди о нас плохо подумают).

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

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

Напоминания как «потенциальная» память

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

Норман говорит, что потенциальная память — это когда нужно вспомнить о какой-то информации в будущем. Память будущего — способность планировать и способность представить себе сценарии будущего. Как вспомнить о том, что через неделю в 18:00 у меня встреча с друзьями? Напоминание календаря — это Норман называет потенциальной памятью. А то, как я это напоминание устанавливаю (думаю о будущем сценарии) — память будущего (где я буду в этот момент? Что я могу придумать сейчас, чтобы это помогло вспомнить о встрече позже?).

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

Но напоминалки — это не обязательно стикеры на бумажках или в тудуйнике. Можно использовать «естественные» напоминания. Обещал принести кому-то из друзей книгу? Положить ее у входной двери и перед выходом на работу не забыл взять с собой.

Просто короткие и прикольные тезисы в кучку:

  • Хороший дизайн — незаметный. Просто делает свою работу и никого не раздражает.
  • Дизайн системы, которой удобно пользоваться, начинается с того, что мы выявляем каким образом выполняются те задачи, которые эта система должна выполнять. А еще более правильно — когда мы понимаем сценарий использования и в зависимости от того, на каком этапе сценария находится пользователь — адаптируем всё под удобство выполнения этого сценария.
  • Требования к продукту, которые люди нам прямо озвучивают часто ошибочны. Более точно их можно определить наблюдением за людьми в их естественной среде. Подробнее эта тема раскрывается у Фитцпатрика в «Спроси маму» и Риса в Lean Startup

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

2023W3 Log

Дочитал «Дизайн привычных вещей» Нормана. Слот для non-fiction литературы освободился и уже понятно чем он будет занят — как раз вчера Анатолий обновил курс «Практическое системное мышление». В общем, начинаю марафон по обновлению в мозгу дисциплин интеллект-стека до самого актуального состояния.

Провели небольшое UX-исследование по одному из продуктов. Гипотезу, ради которой затеяли это исследование, успешно подтвердили, решение по доработке — тоже. Но вот в одном из основных сценариев продукта выявили неочевидные проблемы с UX. Оказывается, очень полезно даже при таких небольших быстрых исследованиях проверять не только точечные места, которые затрагивает проверяемая гипотеза, но и добавлять в прототип ответвления c экранами, которые используются в основных сквозных сценариях продукта. Респондент делает задание и при этом может зайти в эти разделы (по стандартной привычке, как он это делает в жизни при работе с системой) и там открывается целое поле для наблюдений и выявления новых проблемных мест.

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

Физическая активность — уже вторую неделю занимаюсь достаточно стабильно, примерно 4-5 раз в неделю без каких-то ударных нагрузок. «Лестница» ~100 этажей в среднем темпе, подтягивания на турнике, брусья, подъемы ног и через тренировку добавляю еще бассейн (минут по 10-15). Добываю оксид азота, плюс хорошо переключает голову после рабочего дня. Весы Huawei scale 3 pro показывают хорошую динамику: процента общего жира снизился на 3% (программа Huawei Health пишет, что текущее значение 15% — идеальное) и на 1 балл понизился показатель висцерального жира (я уже думал у весов какая-то бага, потому что показатель висцерального жира месяц (с самого момента как купил эти весы) не двигался даже на десятую долю, а он, похоже, определяет только с шагом в единицу). В общем динамика есть, продолжаем дальше :)

Прокатился сегодня на новеньком каршеринговом HAVAL JOLION 2022. Очень приятные впечатления. Хорошая по управляемости, по динамике, ничего не дребезжит, неровности дороги съедает нормально, салон приятный. Очень быстро оттаивает от льда лобовое стекло, прям непривычно быстро. Расход топлива по пустой утренней воскресной Москве — 7.5 л/100 км (поездка 30 км). Есть правда нюансы с эргономикой:

  • Рычажки управления светом и дворниками скрываются за рулем — основные сценарии (поворотники, омывайка, моргнуть светом) выполняются легко и привычно, но если нужно чуть-чуть изменить параметры (чувствительность автодворников, режим переднего света и пр), то пока не выучишь всех положений регуляторов, менять их на ходу почти нереально — надо остановиться и немного повернуть руль, чтобы стало видно обозначения. Например, если по какой-то причине отключен свет (а в каршеринговой машине нельзя быть уверенным, что он оставлен в положении auto), то на ходу это проверить и поменять очень сложно (да, надо проверять всё до начала движения, но это не повод делать плохую и небезопасную эргономику).
  • Переключение коробки в режим manual shifting (когда передачами можно управлять лепестками на руле) выполняется при нажатии лепестка. То есть случайно нажал, машина переключилась на какую-нибудь 3 скорость и дальше едет только на ней. Попробуй на ходу в чужой непривычной машине догадаться как включить автоматический режим обратно. А если не знаешь что это такое и что такие режимы вообще существуют — так вообще беда. Похожая проблема есть в Ниссанах — там переключение в manual режим производится смещением ручки коробки влево, находясь в положении Drive — лично видел, как водитель случайно зацепил этот переключатель, машина начала реветь, не ехала (на второй-то «передаче») и в такой стрессовой ситуации найти решение еще сложнее.
  • Управление печкой/системой вентиляции практически полностью вынесено на дисплей, причем я не понял как сделать так, чтобы окно с настройками вентиляции не скрывалось автоматически через несколько секунд — не успеваешь даже сориентироваться и понять куда жать, чтобы сделать то, что хочешь (изменить точки обдува, уменьшить-увеличить скорость потока и пр). В движении пользоваться небезопасно (и не всегда можно все настроить заранее до начала движения). Хотя может это моя олдскульность — если включить автоматический режим, то все будет работать как надо и туда вообще не нужно лезть.

В общем китайцы начали делать годноту. Еще пара поколений — и будет вполне себе на уровне (да и сейчас удивительно неплохо, правда не знаю что у них по живучести и обслуживанию). Называли бы они свои бренды как-то более «благородно» для уха (и без ассоциаций с дешевой китайщиной) — цены бы не было. Хороший пример — Geely. Если не знаешь что это китаец, то почти не догадаешься.

Закончилась пробная подписка на Caramba Switcher. Кажется, что удобства от нее все-таки больше, чем она же вызывает страданий. Для сравнения — за последние пару лет делал несколько подходов к Punto Switcher и не смог выдержать с ним больше нескольких часов, а с Caramba протянул две недели и когда её отключили понял, что у меня уже сформировались автоматизмы — пишу не обращая внимания на язык раскладки и жду пока текст автоматом преобразуется в правильный; привычка переключать раскладку одинарным нажатием на шифт и преобразовывать выделенный текст (или последнее слово) двойным нажатием на шифт. Пожалуй, куплю подписку.

Что дает мышление письмом и зачем писать заметки

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

Дисклеймер: все что тут описано — не мои собственные идеи, а вольная компиляция идей из разных источников. В основном из книги Зонке Аренса «Как делать полезные заметки» и из блога А. Левенчука: например, отсюда и отсюда).

Усваивать знания из книг/учебников/статей

Читаешь большую книгу или статью на какую-то новую тему и думаешь: как это всё запомнить и применять на практике? Оказывается, суть не в запоминании, а том, что нужно понять ключевые мысли/идеи и связать их с другими знаниями в голове. Дальше, когда в жизни возникает ситуация, в которой попадаешь в нужный контекст — оно каким-то магическим образом всплывает в голове само (иногда не всплывает, но с таким подходом шансов сильно больше). Для простых идей такое осмысление чужих текстов можно сделать в голове, а для сложных — требуется цепочка размышлений. И нигде, кроме как на «бумаге», такое не провернешь — не хватит внимания и возможностей рабочей памяти (наверное, есть редкие гении, которые могут). Такой своеобразный «майнинг» токенов мыслей с помощью карандаша и бумаги (более продвинуто: компьютера с установленным Obsidian), причем часто оказывается, что ключевых идей в больших книгах не так много, просто они циклично повторяются на всём протяжении книги разными словами, в разных контекстах, с разными взаимосвязями с другими идеями.

Когда понимаешь идею — почти не требуется усилий для запоминания. Вот только есть нюанс: запоминание — это всего лишь бонус. Основное же — это то, что шаг за шагом, постепенно, меняется мышление. То есть вместо парадигмы накопления знаний на передний план выходит идея смены образа мышления (Аренс про это говорит так: становиться другим человеком, с другим образом мышления). Обдумываешь прочитанное, пытаешься отрендерить на свои ситуации и проекты, анализировать через это свой опыт, проводить цепочки сложных рассуждений — и меняется твой образ мышления. И такое обдумывание становится возможным с помощью внешних инструментов.

Польза для здоровья

Хочется, чтобы было как на рисунке Б.

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

В общем, думать — полезно :) а написание текстов позволяет подолгу сосредоточенно думать.

Ранее Ctrl + ↓