Блоги: заметки с тегом моделирование

The Principles of Product Development Flow, пост 5 — применение экономического фреймворка (видео)

Артем Ушанов — Sat, 18 May 2024 10:26:33 +0500

🔬 Это пост с разбором очередной части книги Дона Рейнертсена The Principles of Product Development Flow. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу pdflow.

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

00:00 Вступление
01:07 Как устроена табличка
08:37 Кейс первый: вводим СОК, сокращаем возвраты
11:28 Кейс второй: сертифицируем, чтобы увеличить продажи
13:18 Кейс третий: заменим кабель на более дешевый
16:04 Кейс четвертый: китайский завод
17:34 Кейс пятый: добавить кабель лайтнинг
19:05 Заключение

upd. залил на vk

и рутуб:

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

Поиграть с цифрами можно тут: https://docs.google.com/spreadsheets/d/1mKWzrGmZW8DzepJd6QN8yXwMJhiZxoK3GUB6Zl9cbAc/edit?usp=sharing

Как маленькому бутику потягаться с «Зарой»?

Артем Ушанов — Fri, 10 May 2024 13:59:03 +0500

Артем Ушанов:

Никак, это кликбейт.

Hribernik, K., Arabsolgar, D., Canepa, A., & Thoben, K.-D. (2019). Applying Product Usage Information to Optimise the Product Lifecycle in the Clothing and Textiles Industry. Communications in Computer and Information Science, 73—95. doi:10.1007/978-3-030-16134-7_7

Прочитал доклад «Applying Product Usage Information to Optimise the Product Lifecycle in the Clothing and Textiles Industry».

Доклад интересный, но чтобы его полностью понять — пришлось порыть интернеты на предмет контекста и деталей в фешн-индустрии.

Компания Dena Milano, небольшой бутик одежды в Милане, хочет сократить срок вывода на рынок новых коллекций. Один из способов сделать это — проектировать новые коллекции и отдельные изделия с учетом информации об использовании продукции (Product Usage Information, PUI). Это понятие из дисциплины Lifecycle Management, управление жизненным циклом продукта/изделия/системы. Сначала — теория.

Жизненный цикл продукта

Разделяют три основных фазы жизненного цикла:

BOL — Beginning Of Life, начало ЖЦ — проектирование, изготовление, логистика и т. п.
MOL — Middle Of Life — эксплуатация, обслуживание, ремонт
EOL — вывод из эксплуатации ⚰️.

Сбор PUI относится к средней фазе, MOL.

Зачем нам это PUI нужно, особенно для выпуска новой коллекции?

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

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

Крупные производители пользуются прогнозами WGSN (подкаст 99pi про них — очень интересно), мелкие справлялись как-то сами, в том числе Дена Милано.

Запас для маневра гораздо больше у тех, кто двигается быстро. Фаст-фешн игроки вроде Зары/Индитекса, Юникло, Шейна, (про который я уже упоминал) научились выпускать коллекции часто, до двух раз в месяц, быстро избавляться от остатков, держать цены на приемлемом уровне — и оставаться прибыльными. Жизненный цикл коллекции сокращается до нескольких недель, а правильный прогноз плюс грамотная дистрибуция позволяют минимизировать остатки. Но так было не всегда — до 70-х годов двадцатого века цепочка поставки выглядела иначе.

Как развивалась дистрибуция

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

Стандартная цепочка поставки в середине прошлого века выглядела так:

производитель выпускает товар
крупный оптовик закупает товар у производителя
мелкий оптовик закупает товар у крупного
розница закупает товар у мелкого оптовика
потребитель покупает товар в рознице

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

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

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

Ах да, фешн.

До 70-х годов крупные ритейлеры — магазины, торговые центры, — закупали одежду у производителей и продавали через свои сети. Они не могли контролировать, что и в каком виде произведут фабрики, и просто закупали то, что считали подходящим.
В семидесятых это стало меняться. Одним из пионеров фастфешена был Лекс Векснер (Lex Wexner), основатель сети магазинов женской одежды The Limited, который решил, что сам будет выяснять, чего хочет клиент, и заказывать это у производителей — а не закупать то, что производят.

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

Возвращаемся в наше время.

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

Задача же Дены Милано — научиться быстро проектировать новые коллекции без подписки на WGSN и миллиардных продаж фастфешена с тонной аналитических данных.

Как же это сделать? Узнаем в следующем посте, если я когда-то за него сяду. Этот пост я начинал писать два года назад, только что случайно обнаружил в черновиках и решил выложить как есть :-)

Как изучать новую предметную область

Артем Ушанов — Fri, 03 May 2024 00:19:00 +0500

Артем Ушанов:

Два месяца назад я пришел работать в компанию-девелопер, в дирекцию по цифровой ипотеке. Область для меня новая: ни со стройкой, ни с финансовыми продуктами я раньше не работал. Нужно разбираться.

«Разобраться» для меня означает следующие шаги:

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

Еще про грубую сетку в посте «Как читать сложную книгу»

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

Грубой сетки достаточно, чтобы понять общие очертания объектов в домене

Грубую сетку я себе построил путем чтения статей и просмотра видосов на тему ипотеки и всяких сопутствующих штук — их в рунете навалом.

Сложилась вот такая картинка:

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

Изучив и поняв вышеописанное, я сформулировал для себя задачу дирекции: сделать процесс покупки квартиры в ипотеку максимально удобным для клиента и максимально прибыльным для компании.

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

Дальше пошла более подробная работа над доменом. Для нее я использую несколько инструментов.

Три списка — Факты, Оценки, Термины.
В «Факты» попадают факты и наблюдения, которые мне встречаются на созвонах или в переписке. К примеру, из фразы «комиссия у зеленого банка охереть высокая!» можно выделить два факта: «комиссия зеленого банка N%» и «комиссия у зеленого банка выше, чем у других». Составление списка фактов помогает понять, какие события и явления в рамках домена значимы, а какие — нет.
В список «Оценки» попадают оценки некоторых фактов, выраженные членами команды или внешними людьми. Сочетание одного факта и набора разных оценок к этому факту помогает понять, какие есть конфликты и в чем их причины, а также примерные роли тех, кто эти оценки высказывает. Пример: из высказывания «М. сказала: комиссия у зеленого банка охереть высокая!» м можем сделать предположение о роли М. и о важных для нее вещах.
В список «Термины» я пишу все слова, словосочетания и устойчивые выражения, которые встречаю на встречах или вычитываю из разных источников.
Списки составлять просто: услышал новый факт или незнакомое словосочетание — записал в список. Перечитал журнал, увидел там термин — переписал в список.
Периодически списки нужно перечитывать и грумить — убирать оттуда нерелевантные термины, дописывать пояснения. Рано или поздно начнут прорисовываться понятные связи между некоторыми элементами списков, туман войны начнет рассеиваться.

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

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

Схема процесса в одном из проектов

В итоге я пришел к простой базовой мета-модели по этому проекту:

Базовая мета-модель в проекте с партнерским банком

«Актор» — участник процесса
«Шаг процесса» — некое действие, цель которого создать или развить РП
«Рабочий продукт» — артефакт, который должен быть создан для продвижения или завершения процесса
«Инструмент» — то, что используется на определенном шаге или в отношении РП акторами

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

Скриншот записи из журнала

Альфы OMG Essence — проектные объекты и области, которые нужно отслеживать. Про фреймворк я рассказывал на конференции пять лет назад.
Факты, люди и термины вполне естественно раскладываются по альфам и подальфам проекта. Структурирование проектной информации по альфам помогает хранить описание в компактной форме, быстро понимать проектные проблемы и принимать меры.

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

Что нужно клиенту — дрель или дырка в стене?

Артем Ушанов — Fri, 20 Oct 2023 00:24:11 +0500

Артем Ушанов:

Евгений Казначеев в своем канале написал пост про иерархию «работ» с т.з. JTBD. Вот выдержка:

«Пользователю не нужна дрель, ему нужна дырка в стене. Но в то же время дырка в стене нужна, чтобы повесить картину. А картина нужна, чтобы было красиво и не стыдно было гостей привести. А красиво нужно, чтобы... Это матрёшка, „да там черепахи до самого низа“. Тут иногда человек даже теряется — „с чем же мне работать? до каких „самых настоящих работ“ мне идти?“

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

И вот важная мысль — работать с этой иерархией можно на любом уровне.»

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

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

Цели (и деятельности) уровня «Do» (ду) работают на выполнение целей уровня «би», т. е. их выполнение должно помочь достижению «би». При этом важно, что успех или неуспех «ду»-целей не всегда определяет успех/неуспех «би»-целей. «Ду»-цели достигаются выполнением «программ».

Для достижения целей уровня «ду» выделяются отдельные «последовательности», или цели моторного уровня.

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

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

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

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

Би-цели — самые устойчивые, ду- и моторные цели легко меняются. Хотят всегда именно би-целей!

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

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

К примеру, «сделать дырку в стене» может «сверлитель» (роль) с использованием дрели и сверла по бетону, практика — «сверление стен».

Если мы прыгнем на уровень выше, то там задача «повесить картину» (считаем, что место определено), роль — «проектировщик размещения картины», практика — «подбор метода размещения картины»; возможные решения — дырка в стене и крючок, липучка от 3М, полочка под картину.

Если идем еще выше, то роль — «проектировщик интерьерных решений» (решения определены, нужно их правильно разместить), практика «определение оптимального места под картину», возможные методы решения — там, сям, над кроватью, между шкафами, и т. п.

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

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

Работать действительно можно на любом уровне, но лучше работать на том, на котором вы можете обеспечить результат — т. е. владеете нужными практиками и ресурсами.

Все-таки охватывать несколько системных уровней сложно: более верхний уровень определяет практики для более нижних, и их кратно больше.

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

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

В-третьих, если клиент (а мы тут все-таки исходим из схемы “делаем продукты для клиента”) уже выбрал какой-то уровень, на котором он ищет конкретное решение или исполнителя, то переубедить его бывает сложно.

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

А там и софт продали.

Ситуация была несколько нервная: мы действовали против своих интересов в краткосрочном периоде в пользу теоретического понимания пользы клиента.

Но такой кейс у меня один, а клиентов было больше.

Что я узнал в сентябре-2023

Артем Ушанов — Sun, 01 Oct 2023 19:21:20 +0500

Артем Ушанов:

Это ежемесячный пост формата «Today I Learned» — в нем я перечисляю интересные новости, цитаты или факты, попавшиеся мне за месяц. Темы произвольные.

Фото месяца — живописное дно канавы в Сремских Карловцах

ML-Короткометражка Backflip

https://backflip.training/

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

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

Стекло — не жидкость

Притча о том, что нельзя полагаться только лишь на когерентность истории.

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

Правдоподобно ли звучит? Ну как-то контритуитивно, но в целом да. Будем ли мы проверять факты и делать выводы на основе собственных наблюдений? Обычно — нет, но сегодня сделаем исключение.

Достаточно погуглить исходный тезис «стекло это жидкость» с частицей «не» в нужном месте — примитивно проверить на фальсифицируемость, — и вуаля: десятки публикаций с детальным опровержением этого мифа — например, эта.
Цитата оттуда:

«Потребуется миллиард лет, чтобы всего несколько атомов в стекле вообще сдвинулись с места».

Короче, стекло — не жидкость. Но и не стандартное твердое вещество — другая молекулярная структура.

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

Вывод: не стоит определять истинность утверждения исключительно на основе связности приводимых фактов. (От создателей «если человек громко уверенно говорит — он прав»).

Проектирование магазинной тележки

Рассказ в блоге «Бюро»

В «Бюро сервисного дизайна» повторили кейс IDEO и спроектировали новую тележку для «Пятерочки».

Сценарии и контексты:

Опыт пожилых людей
Опыт гостей с детьми
Совместная покупка несколькими людьми в одну тележку
Поведение в зоне касс
Выезд с тележкой за пределы магазина
Возврат тележки в магазин

Основные критерии, по которым оценивалась новая тележка: легкость мойки; легкость маневрирования; удобство складывания-доставания продуктов и организация их размещения; легкость посадки/изъятия ребенка.

Что поменяли: материал корзины и узор сетки — стало прочнее, легче мыть; добавили дополнительные ручки по бокам и спереди тележки, основная ручка теперь не прокручивается; добавили разделитель в корзине; переделали сидушку для ребенка — дырки для ног сделали крупнее, спинку удобнее; добавили крючок для сумки и полочку с подстаканником; тележка стала выше — дно подняли на 7,5 см, ручку на 3,5 см. И самое важное — пофиксили колеса. Оказывается, у многих металлических тележек они несъемные, и если колеса вышли из строя — меняется вся тележка.

Картинка из блога «Бюро»

Whimsical — рисовалка схем с ChatGPT

https://whimsical.com/

Случайно наткнулся на сабж — очередной моделлер с поддержкой ChatGPT, способный по промпту построить майндмеп или флоучарт.

Работает шустро, не требует промежуточного кода, как в Mermaid, — сразу рисует. Есть свой плагин для ChatGPT — т. е. можно попросить чат сгенерировать тебе схему, он отправит запрос в Whimsical и вернется с картинкой.

Но всего два формата для генерации — маловато.

Reminder про отдых

Привожу целиком:

DRAMMA. Качественно отдохнуть можно не только на курорте и не только в «высокий сезон». Главное — собрать воедино шесть ингредиентов идеального отпуска, которые определила в ходе полевых исследований психолог Джессика де Блум. Итак, вам понадобятся: D (дистанцирование)— отстранитесь от стрессовых ситуаций и стимулов; R (релаксация) — найдите расслабляющую атмосферу; А (автономия) — создайте ощущение полного контроля, чтобы только вы решали, кому и чему посвятить свое время; два M (мастерство и meaning, то есть смысл) — выберете для себя осмысленное и/или полезное, но не обременительное занятие, например, изучите историю места, где отдыхаете, или освойте скалолазание. И наконец, A (аффилирование) — чувство принадлежности: делайте все это с партнером, другом или в компании. Мы бы еще добавили в этот коктейль немного воды: смотреть на открытую воду, слушать ее, купаться в ней, просто быть возле нее — очень полезно для психического здоровья. Подробнее.

Марина Корсакова про книжку «Чек-лист» Атула Гаванде

Обзор в Телеграфе Марины

Марина со свойственной ей менеджерской въедливостью разбирает (хорошую) книжку Атула Гаванде «Чек-лист...». Я поминал книжку и чеклисты в посте про роли.
Хайлайты:

Чек-листы помогают спасти от катастроф с помощью рутины; а появились они сначала в авиации, потом в медицине — куда попали из авиации
Дисциплинированный проход по пунктам чек-листа дает вот такие результаты за год — «...предотвращены 43 инфекции, 8 смертей и сэкономлены 3 миллиона долларов...»
И вот такие: «...В итоге — сэкономлено 175 миллионов долларов, спасено 500 жизней: так оценивают в Синай-Грейс итоги применения „карточек с пятью вопросами“...»
Чек-лист позволил группе Van Halen научиться проводить «...большое шоу даже на третьесортной площадке»
На кухне тоже работает: «Отказ от чек-листов = ошибки и потеря качества и темпа»
Снова медицина: «если чек-лист предписывает дать медсестре представиться и предложить ей задать вопросы, такая медсестра чаще обнаруживает проблемы и предлагает решения, она проявляет больше активности»
Требования к чек-листам: только самое важное или то, что часто забывают; 5-9 пунктов — оптимально; если чек-лист получается большой — нужно разбить его на разделы; формулировки должны быть простые и четкие: прочитал — сделал; чек-лист может и должен меняться

Предок буханки

Звался Willys Jeep Forward Control, производился с 1956 по 1965 гг.

Привет, потомки

А буханку до сих пор делают.

Презентации в воркфлови

https://blog.workflowy.com/instant-presentations-in-workflowy/

Такие вот примитивные презентации — просто по порядку показать все буллеты, — они вроде бы не нужны как отдельный продукт, а вот в качестве фичи в уже существующем — пускай будут. В прошлом til я писал про ia presenter, который умеет примерно то же самое, но стоит денег и не умеет быть аутлайнером — на таких условиях проще бесплатной workflowy пользоваться.

Emoji Kitchen

Если загуглить emoji kitchen, на странице результатов появится виджет для перехода в редактор эмодзи; совместив два любых эмодзи можно получить новую — см. примеры:

Паста из бронзовых фильер долгой сушки

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

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

Купил. Варить нужно долго — 12-15 минут. Паста и правда получается отличная: на нее липнет соус и она прекрасно жуется. Целых два критерия от Дэна Пешмана соблюдены. Рекомендую 🤌🍝

Клон голоса в Eleven labs

https://elevenlabs.io/speech-synthesis

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

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

Test-11labs.mp3

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

«Союз» выпустил бюджетный микрофон

Прикольный ролик:

«Бюджетный» он относительно остальных микрофонов компании — стоит 50 000 ₽.

Короче

ГОСТ советского пломбира: https://istmat.org/files/uploads/55065/gost_119-52_morozhenoe.pdf
Идеальное снотворное — мужчина мягким голосом читает пользовательское соглашение инстаграма zzzuckerberg.com
3500+ калькуляторов на все случаи жизни
Гугловский портал Gamesnacks с кучей казуальных игр — https://gamesnacks.com/

Минутка рекламы

Обо всех новых постах я всегда пишу в телеге, о больших постах — в инсте и остальных соцсетях.

Как принять сложное решение? Метод анализа иерархий

Артем Ушанов — Fri, 19 May 2023 20:22:16 +0500

Артем Ушанов:

Я могу легко выбрать из двух вариантов: если на витрине два вида бу́реков — с мясом и с зеленью, я возьму второй; если с сыром или с зеленью — уже сложнее, скорее всего тоже возьму второй. Тут один простой критерий: с зеленью мне больше нравится на вкус.

Сложнее будет, если мне надо выбрать перекус: взять бурек? Или купить питьевой йогурт? Или поесть супа? Питьевой йогурт — полезно, но надо идти до супермаркета и стоять там в очереди. Бурек — вредно, но вкусно, и пекарня по пути. Супа хочется, и это полезно, но надо идти в кафе, заказывать, ждать, есть, просить счет, ждать, платить...

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

Любители поесть всегда решают такие кейсы с помощью метода анализа иерархий (МАИ).

Как мы офис выбирали #

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

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

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

Далее я внес в табличку все варианты помещений под аренду из моего списка. Все варианты нужно было оценить по каждому критерию. Самые удобные — которые можно выразить числами: цена, площадь, этаж. Менее удобные — которые сложно выразить какими-то опциями. Как оценить транспортную доступность? Оценивали в итоге по адаптированной шкале Ликерта — от «очень удобно добираться» до «совсем неудобно добираться».

Дальше мы просто считаем условные баллы по каждому варианту и по итогу берем победителя.

Что хорошего в таком подходе?
1) Он позволяет математически выразить проблему сложного выбора и решить ее тоже математически; это снижает зависимость от эмоций в процессе и дает понятный алгоритм на будущее
2) Он демократичен; можно попросить заполнить матрицу всех причастных (семью, коллег), после чего агрегировать результаты и вывести победителя; сомневающимся в результате можно объяснить логику и показать расчеты, т. е. все прозрачно и проверяемо
3) На уровне ответов на вопросы — метод реально простой. Любому человеку гораздо легче ответить на вопрос «что лучше — А или Б?» много раз подряд, чем пытаться выбрать из ряда альтернатив сразу по всем критериям.
4) Можно сохранить результат со всеми промежуточными шагами в эксельке и пересмотреть спустя годик; возвращаться к принятым решениям и анализировать их спустя время — хорошая практика.

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

1000minds и смена работы #

Три года назад я нашел такую софтину — кажется, через википедию и случайно. Называется она 1000minds и сделали ее два профессора из Новой Зеландии.
Когда я решил сменить работу в конце 2020, я использовал 1000minds для оценки потенциальных вакансий, потому что опять-таки столкнулся со сложностью выбора.

1. Выбор критериев.
Я выделил следующие:

С вариантами оценки пришлось пофантазировать

2. Сравнение критериев
Система может примерно подсчитать, сколько сравнений нужно сделать, чтобы составить модель весов.

Ну а потом система начинает предлагать варианты:

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

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

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

Погоняв нас по таким сравнениям, система выстраивает модель весов.

Есть много разных вьюшек, в т.ч. такая — так выглядела бы модель в экселе:

Получив модель весов, можно начинать вносить кандидатов.

3. Оценка альтернатив
Каждый кандидат получает название и оценивается по всем критериям

После внесения всех кандидатов получаем такой вот дашборд:

Дальше просто: при появлении нового кандидата просто вносим его в систему, оцениваем критерии и смотрим, в какое место общего рейтинга он попадает.

На скриншоте выше финальный вид дашборда — в компанию наверху списка я и устроился в итоге.

1000minds довольно гибкий. Веса можно в любой момент пересчитать, не теряя данные — просто заново пройти trade-offs. Появился новый критерий? Ок, вносим его в систему и опять-таки заново проходим trade-offs.
Можно создавать модель весов коллективно. При создании проекта в системе указывается его тип — «опрос» мы делаем или «решение». Если мы сделали «опрос», то можно оформить критерии, опубликовать опросник, выдать ссылку респондентам и получить в итоге модель весов не одного человека, а коллектива. Если бы в примере с выбором офиса я использовал 1000minds, я бы так и поступил, чтобы учесть мнения всех коллег.

Кейсы #

Что можно оценивать с помощью МАИ?

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

Кейсы посложнее:

Подбор кандидатов на вакансию в компании. Тут придется пораскинуть мозгами — как формализовать критерии, как оценивать по этим критериям кандидатов; а загнать эти штуки потом в систему — дело техники
Приоритизация бэклога — по модели impact-effort или более сложной; альтернативами считаем фичи/юзер стори
Оценка потенциальных фичей с помощью пользователей; из JTBD, CJM или Value proposition canvas выделяем критерии, потом пробуем построить модель весов на группе пользователей;
Выбор модулей для продукта, особенно при анализе решений сторонних поставщиков;

Важно правильно поставить задачу и формализовать критерии. Можно почитать книгу «Как измерить все, что угодно», там описываются методы квантификации неквантифицируемого.

Ссылки #

Матрица приоритизации — https://www.kpms.ru/Implement/Qms_Prioritization_Matrix.htm
Метод анализа иерархий — http://sewiki.ru/Метод_анализа_иерархий
Анализ компромиссов — http://sewiki.ru/Анализ_компромиссов
Матрица решений — https://untools.co/decision-matrix
Сайт 1000minds — https://www.1000minds.com/
Упрощенный инструмент от разработчиков 1000minds — https://meenymo.com/
Альтернативный сервис Ruminate, пока не пробовал — https://ruminate.io/
Внеклассное чтение: «приоритЕзация» или «приоритИзация»? — Мел
Внеклассное чтение: краткое изложение книги «Как измерить все, что угодно» — https://4brain.ru/blog/как-измерить-все-что-угодно/

Рисовалки схем из текста

Артем Ушанов — Tue, 15 Nov 2022 03:17:51 +0500

Артем Ушанов:

В этом тексте есть пасхалка на тему старых квестов

Мне периодически приходится по работе делать какие-то схемы и диаграммы. Для простых схем «на бегу» я использую Миро или Фигджем, они клевые и удобные. Но для диаграмм, в которых важно соблюдать какую-то нотацию (пусть и не строго), или с которыми нужно работать регулярно, такие сервисы подходят плохо.

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

🤖 Кстати: мы сделали телеграм-бота, который рисует схемы по описанию. Получить ранний доступ можно тут.

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

Больше всего мне нравится Mermaid. Умеет рендерить разные диаграммы (список тут), есть онлайн-редактор с возможностью экспортнуть в виде картинки или кода, хорошая документация.

Схемы здесь тоже не строго формализованные, можно связывать элементы как угодно, но по коду легче проверить или организовать корректность построений. Зато типы связей, ярлыки, кратность задаются текстом, что в сто раз быстрее, чем шарить мышью по меню.
Поддерживать и апдейтить легче, чем в миро, особенно если правильно организовывать код и не лениться писать комменты к нему.
Выгрузку элементов из кода можно делать с помощью любого regexp-сервиса, я пользуюсь regex101.

Вот пример схемы (flow diagram):

А вот код, из которого она сгенерирована:

graph TD
    A[Christmas] -->|Get money| B(Go shopping)
    B --> C{Let me think}
    C -->|One| D[Laptop]
    C -->|Two| E[iPhone]
    C -->|Three| F[fa:fa-car Car]

Мне не очень нравится нотация для стрелочек — они рисуются псевдографикой:

classA --|> classB : Inheritance
classC --* classD : Composition
classE --o classF : Aggregation
classG --> classH : Association

Это неудобно — приходится печатать редко используемые символы, да еще и помнить, что там чего значит, и полярность не напутать. Я бы предпочел сокращения или целые слова вместо псевдографики.
Автокомплит странно работает: пытается подсказывать штуки, которых нет в моем коде, а которые есть — не подсказывает.

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

Ну и модная тема — можно дать ChatGPT текстовое описание и попросить сделать из него код mermaid.

upd. У мермейд появился полноценный сервис со встроенным чат-гпт, так что автосоздавать схемы стало еще проще — но за деньги.

Кроме мермейда можно попробовать kroki и простенький flowchart.fun (без нотаций, просто схемы со стрелочками); есть еще отличный Plant UML, но для него vscode надо ставить, а мне лень.

Еще два шажочка к идеальному моделлеру:

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

Замыленная часть схемы — то, что не попадает под фильтры вьюшки

Whimsical умеет создавать диаграммы не по нотации, а быстрым промтом через чат-гпт. Работает просто магически:

Ссылки и референсы (периодически обновляется)

Сайт от Terrastruct (создатели движка D2) со сравнением четырех движков рендера кода в схемы: https://text-to-diagram.com/
Miro теперь тоже умеет встраивать мермейд-диаграммы.
В копилку софта для диаграмм: https://sequencediagram.org/. Рисует рендером из псевдокода, как Мермейд. Умеет делать только один тип диаграмм — диаграммы последовательностей, зато есть киллер-фича: на готовом рисунке можно мышкой перетаскивать элементы. Порядок строк в коде после этого тоже меняется. Таким образом, можно быстро накидать псевдокодом диаграмму, а после уточнения, если потребуется поменять порядок шагов — сделать это мышкой.