Что имеет в виду человек, когда говорит "нужно принять решение" или "я принял решение"?

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

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

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

Хоба - и у нас появился пригодный к рациональному десижн мейкингу трехчастный фреймворк:
1. Решаемая проблема или задача
2. Набор вариантов для решения
3. Критерии, позволяющие нам отличить хорошие варианты от плохих

Если вы не держите эти три компонента в голове, когда нужно принять важное решение, - вы примете его интуитивно. Это не всегда плохо, но иногда это прям плохо.

А ниче тот факт, что вместо реплая на свое же сообщение с уточнением опечатки можно просто нажать "↑" и исправить исходное сообщение?

Блог на сайте этого не узнает:
- мы пили водку в Ёлках-Палках на Белорусской
- в итоге мы не попали на самолет в Астрахань
- при этом мы с несданным багажом добежали до гейта, проскочив досмотр с криками «опаздываем, разойдись-поберегись» и НАС ПРОПУСТИЛИ С ОГРОМНЫМ БАУЛОМ В ОБХОД РАМОК, но на самолёт нас с этим баулом не пустили
- вынужденно ночевали у Вани С., наконец познакомились вживую
- поехали назад на поезде, и Макс чуть и на него не опоздал, я буквально силой удерживал проводницу от взмаха семафором, пока он бежал от ларька с сигаретами, перепрыгивая тележки и группы людей.

https://music.yandex.ru/album/7611873/track/53306416?ref_id=81DE601E-1687-4722-925B-82CC95D2DCB9

Иногда я.музыка как вдруг бах - и посоветует годноту.

Песня 1970г.в., если что.

ИИ окончательно заменяет нас, вакансий осталось на 2-3 месяца 😰

(На скриншоте - Otter.ai, описывающий результат обсуждения презентации для крупного партнера, Сап там никак не фигурировал, темы обсуждались другие)

…Хочу разобраться, как факторы успешности из отчетов CHAOS ложатся на системную схему OMG Essence. В каких областях находятся, к каким альфам относятся, и так далее. Хочется научиться понимать, какие из факторов используются на отдельно взятом проекте, а какие - нет.

В какой альфе системной схемы проекта сидит Decision Latency?

Decision Latency - это метрика, разница во времени между моментом идентификации необходимости принять решение и моментом принятия этого решения. Чем меньше эта разница, тем лучше.

Можно разложить DL на три составляющие:
1. Идентификация необходимости принять решение. Возник риск, появилась проблема, либо необходимость в некоем действии, нужно выбрать дальнейший курс действий.
2. Анализ ситуации. Прежде чем принимать решение, мы должны обеспечить минимальный набор для него. В этот набор входит формулировка проблемы или задачи (что решаем), набор критериев для определения решения (как решаем) и набор альтернатив, из которых мы будем выбирать (что выберем в качестве решения). Для сложных решений можно еще спрогнозировать будущее в случае выбора каждой из альтернатив - на что повлияет выбор, что будет затронуто и т.п.
3. Принятие решения - когда мы, используя результаты анализа ситуации из п.2, выбираем одну из альтернатив и выстраиваем дальнейший курс в соответствии с ним.

Cоответственно, у нас есть три метрики - Capture Latency, Analysis Latency, Decision Latency, они измеряются в днях. Все вместе тоже называется Decision Latency.

Способы повлиять на эту метрику лежат в альфе "метод" (way of working на картинке ниже), но затрагивают все остальные - необходимость принять решение может возникнуть в рамках любой из альф. Поэтому рабочей схемой кажется разработка общего подхода к принятию решений с адаптацией под конкретные ситуации.

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

- An identification number
- The project phase
- A descriptive title
- The risk/issue/decision status
- Probability
- Impact
- Owner and assigned team
- Date assigned or recognized
- Next action date
- Resolution date
- And any related risks/issues/decisions

Решений в каждой области приходится принимать много, поэтому их принятие нужно децентрализовать (у нас же аджайл) и делегировать на тот управленческий уровень, на котором их предстоит применять, либо действовать в зависимости от значений Probability и Impact.

Про децентрализацию много пишет Рейнертсен, а "решениям" как двигателю проекта посвящен фреймворк Decision Patterns Джона Фитча.
———
Ссылочки на посты про отчеты CHAOS:
https://artemushanov.ru/?go=all/otchet-chaos-report-2018/
https://artemushanov.ru/?go=all/otchet-chaos-report-2020/

Системная схема OMG Essence - мой доклад про фреймворк из 2019, ютуб

Инвайт на браузер Comet от Perplexity: https://perplexity.ai/browser/claim/XZ35NYVNDR

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

Какое-то время назад я узнал, что у жонглеров есть своя текстовая нотация, которая описывает порядок бросков и ловли предметов; называется siteswap.

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

Вы только посмотрите:
https://juggle.fandom.com/wiki/Siteswap
https://www.reddit.com/r/juggling/comments/y37boz/siteswap_explorer/
http://www.siteswap.org/

Они там все чокнутые.

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

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

Посидели на троих - с бренд-директором Димой Васильченко и процессным менеджером Динарой Камоловой (@DK_ProcessThinking).

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

В дальнейшем напишу структурированный пост и разложу все по полочкам уже текстом.

Ссылки на другие платформы:
- https://vkvideo.ru/video-232921620_456239017
- https://youtu.be/tOXybnkIqd0
- https://rutube.ru/video/10d5c71ee562c3d0ec05cf86b99960de/

Астрахань би лайк:

Проект должен быть небольшим

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

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

Маленькую и простую систему проще провести через приемку (v&v) после завершения разработки, чем большую. С ней связано меньше стейкхолдеров, ей нужно меньше возможностей (я про альфу) для согласия и бай-ина всех интересантов.

Если пойти от обратного - может ли быть маленьким проект по разработке большой и сложной системы? Я не могу себе такого представить.

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

Грамотный и опытный спонсор проекта

Спонсор проекта - это стейкхолдер, внешняя проектная роль. Он не часть команды, он - представитель заказчика (внешнего или внутреннего). Спонсор ставит цель, формирует и поддерживает видение проекта, обеспечивает внешние ресурсы (от денег до доступа к decision making unit).

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

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

Планета сделала свой оборот, стало больше дел и заметок - я вернулся к бумажному блокноту и BuJo.

Удивительно, но блокнот (и вообще запись от руки) стабильно выигрывает у простых цифровых инструментов. У меня много знакомых, кто вообще не готов пользоваться цифровыми тудушками.

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

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

Нас срубает спать ещё из-за конкретных процессов в митохондриях — энергетических станциях наших клеток. Клетки уводят свои генераторы на техобслуживание.

Ещё одна работа про сон.

Во время бодрствования накапливается избыток пакетов с энергией — АТФ. Много таких пакетов в клетке — хорошо с точки зрения запаса энергии, но плохо с точки зрения образования свободных радикалов. Они стрёмные.

Во время сна клетки чинят свои митохондрии и восстанавливают метаболический баланс.

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

Сравнивали две группы мушек: тех, кто хорошо выспался, и тех, кого лишали сна на 12 часов (аккуратно встряхивая их пробирки).

Дальше из полученной кашицы секвенировали РНК одиночных клеток. Прочитали активность всех генов в каждой отдельной клетке мозга. Сосредоточились на очень маленькой группе нейронов (около 20), которые, играют ключевую роль в управлении сном. Это нейроны дорсального веерообразного тела.

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

Самый прикол в том, что АТФ не падает, а растёт! При бодрствовании сонные нейроны подавляются другими системами мозга. Они неактивны и почти не тратят энергию. Однако, поскольку весь организм бодрствует и питается, митохондрии в этих нейронах продолжают производить энергию. Избыток АТФ засоряет дыхательную цепь переноса электронов в митохондриях. Электроны начинают "протекать" и соединяться с кислородом, образуя активные формы кислорода. А они уже повреждают белки, липиды и ДНК.

Давление сна — это сигнал о том, что в ключевых сонных нейронах накопился метаболический дисбаланс, который приводит к самоповреждению клеток.

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

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

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

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

Сон — окно для этого ремонта.

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

Работу подсказал @vadikgo

--
Вступайте в ряды Фурье!
— А вот сейчас вы наблюдаете знаменитые египетские пирамиды, которые…
— Товарищ экскурсовод, а правда, что верблюд может не дышать три минуты?
— Нет, неправда.
— Лёха! Лёха! Отпускай его! Отпускай!

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

А можно ли отделить метод от предмета? Продавать нормальный продукт, используя инфобизнесменские методы продажи?