Спорю с постом «Почему проектный подход больше не работает?»

Пост попался мне в Сетке и у меня бомбануло.
Вот он целиком:

Почему проектный подход больше не работает? 🚀

У нас есть клиенты, с которыми всё началось с одного проекта. Потом подключилась поддержка, развитие, и вот ты оглядываешься — а вы уже работаете вместе 5+ лет. 😳

Казалось бы, всё идёт хорошо: команда знакома с продуктом, клиенту нравится, что у нас вся экспертиза под рукой, а на вникание в процессы не тратится лишнее время. Зачем что-то менять?
❗️Но вот интересный момент: проектный подход в таких случаях уже не работает. Более того, он становится причиной большинства проблем.

📌Почему проектный подход перестает работать?

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

Вот что происходит:

🔹 Потеря знаний.
За 5 лет состав команды неизбежно меняется. Люди уходят, приходят, а вместе с ними уходит и накопленная экспертиза.
🔹Растущая сложность.
Продукт клиента развивается, в нём появляются новые компоненты системы, зависимости, интеграции, требования. А проектный подход слишком жёсткий, чтобы успевать за изменениями.
🔹Изменение приоритетов.
Когда вы планируете один проект, всё более-менее стабильно. Но за несколько лет потребности бизнеса клиента могут полностью измениться. Тут становится очевидно: чтобы развивать такой продукт, нужно работать по-другому.

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

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

📌Ключевые отличия:
• Команда. В проекте может быть временная группа специалистов, а в продукте — стабильная кросс-функциональная команда.
• Цели. Проект нацелен на выполнение конкретного объёма задач, продукт — на достижение бизнес-результатов.
• Процессы. В проекте есть начало и конец, в продукте — циклы постоянного улучшения.

📌Как мы трансформируем команды из проектных в продуктовые?

У меня есть несколько советов, которые показали себя максимально эффективными:

🔹 Создайте единую базу знаний с клиентом по продукту.
Фиксируйте всё: архитектуру, процессы, фичи. База знаний спасёт в случае ухода ключевых специалистов. И заведите туда обязательно клиента — это повысит доверие >и упростит совместную работу. Кстати, за её ведение не стесняйтесь брать деньги: это полезно всем.

🔹Стирайте границы между командами.
Чем больше точек соприкосновения, тем лучше. Приглашайте ключевых сотрудников клиента на свои внутренние церемонии: планирование спринта, координации, ретро. >Это сделает работу прозрачной и укрепит партнёрство.

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

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

🔹Инициируйте воркшопы и церемонии для улучшений.
Включите в свой процесс регулярную задачу: раз в заранее определенный период проводите внутренний воркшоп, на котором команда генерирует идеи по улучшению >продукта. Затем структурируйте предложения и обсуждайте их с клиентом. Это не только прокачает продукт, но и покажет вашу вовлечённость и экспертность.

📌Почему это работает?

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

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

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

И начинается он с кликбейта:

«Почему проектный подход больше не работает?»

Но он работает; утверждение автора сродни следующему: «я купил машину — ходьба пешком больше не работает 🙅‍♂️». Чтобы объяснить, почему конкретно в деятельности автора проектный подход не работает, нужен контекст: что за отрасль, что за клиенты, какие проекты/продукты вы делаете. Тогда — да, можно обсуждать состояние проектной деятельности в конкретной отрасли, или с конкретным типом компаний/заказчиков, и т. п.

«проект — это конкретный объем задач»

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

«когда вы с клиентом вместо годами — проект никогда не заканчивается»

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

«потеря знаний/растущая сложность/изменение приоритетов»

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

«Продукт — это процесс постоянного развития, где главное — ценность для пользователя.»

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

«Проект заканчивается, продукт — никогда»

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

Команда/Цели/Процессы...

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

Переход из проекта в продукт...

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

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

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

«Продуктовый подход — это... возможность построить с клиентом долгосрочное партнерство.»

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

«Клиент видит, что вы не просто выполняете задачи, а действительно заботитесь о его продукте.»

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

Вывод: автору поста было бы здорово получше изучить проектный подход и применяемые в нем методики. Проекты и проектный подход никуда не денутся, по-прежнему работают и в жизни встретятся не раз.
Мне нравятся подходы и инструменты Ивара Якобсона — конкретно под проекты подходит OMG Essence, про него есть доклады на ютубе. Продуктовый подход — сложная штука и сильно отличается от того, что описывает в посте автор.

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

Про книгу «Шум»

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

Основной тезис книги: шум и смещение приводят к ошибкам в суждениях.

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

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

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

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

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

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

Книга очень нравится, прям кайфую.

The Principles of Product Development Flow, пост 7 — очереди и capacity utilization

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

Цитата из предыдущего поста:

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

Рассмотрим два первых принципа — про то, почему очереди вредны и почему с ними никто не борется.

Q1: The Principle of Invisible Inventory: Product development inventory is physically and financially invisible

Очереди в продуктовой разработке невидимы.

На физическом производстве очереди заметны: если перед станком скопились детали на обработку — что-то идет не так. Если партия станков не завершена — это есть в отчетах, и финдиректор может сказать, сколько всего на заводе «незавершенки» (WIP — Work In Progress).

В разработке физических деталей нет. Работа ведется над информацией — схемами, чертежами, спецификациями, тасками, юзер-сторями и прочими эпиками. О том, сколько таких артефактов распихано по джирам и фигмам — финансовому директору точно неведомо. Артефакты такого рода Дон называет DIP — Design In Progress.

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

Q2: The Principle of Queueing Waste: Queues are the root cause of the majority of economic waste in product development

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

Дон рубит сплеча: очереди — основной источник потерь и непродуктивных затрат в продуктовой разработке.

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

Из Q1 мы знаем, что очереди в разработке продуктов невидимы — а значит, никто за ними не следит и никто не старается сократить. Более того, в компаниях, занимающихся разработкой, иногда принято хвалиться размерами своего бэклога — «у нас до следующего января отдел разработки занят».

Во-вторых, очереди создают много непродуктивных затрат.
Источники затрат:

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

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

Поведение очередей

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

Что такое Capacity Utilization

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

Сам Рейнертсен не дает определения, разве что вскользь упоминает:

...capacity utilization is the ratio of two factors, demand and capacity, that are individually hard to estimate.

Мощность, или capacity — это некоторый показатель того, сколько полезной работы ресурс сможет проделать в единицу времени.
Скажем, у программиста в рабочем дне восемь часов; из них час уходит на синки, два часа — на созвоны и встречи, оставшиеся пять часов посвящены работе над продуктовыми задачами. Значит, мощность/капасити программиста — 5 часов. Если он все пять часов работает над одним продуктом, то загрузка его мощности будет 100%.
Если у нас не один программист, а отдел из 10 человек, и 8 из них постоянно заняты в разработке — мы можем сказать, что загрузка мощностей составляет 80%.

В статье Six Myths Of Product Development (HBR, 2012) Рейнертсен и его соавтор Штефан Томске в качестве первого мифа приводят следующий:

  1. High utilization of resources will make the department more efficient.

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

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

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

Правило, однако, не звучит как «всегда держите Х% мощности в резерве». Правило звучит так:

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

Загрузка мощностей (capacity utilisation) обозначается буквой «ро» — ρ и вычисляется следующим образом:

ρ = λ / μ

где λ — интенсивность поступления задач (например, количество задач в единицу времени), а μ — интенсивность обработки задач (пропускная способность ресурса, например, количество задач, которые система может обработать в единицу времени).

Пример 1: Оператор в кол-центре

  • Один оператор может обслужить 10 звонков в час (μ = 10).
  • В среднем поступает 8 звонков в час (λ = 8).
  • Загрузка: ρ = 8/10 = 0,8 (80%)

Ресурс работает с 80%-й загрузкой, что считается безопасным уровнем.

Пример 2: Конвейерная линия

  • Линия может обрабатывать 100 деталей в час (μ = 100 ).
  • Поступает 120 деталей в час (λ = 120 ).
  • Загрузка: ρ = 120/100 = 1,2 (120%)

Система перегружена, что приводит к появлению очередей.

Про детальные правила расчета можно почитать, например, в курсе ШСМ «Рациональная работа» по ссылке.

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

Две ошибки по 10% каждая дают нам в комбинации возможный диапазон загрузки мощностей от 55 до 95%. То есть наш сотрудник то ли наполовину свободен, то ли полностью занят. Если мы будем вычислять очереди исходя из такого широкого диапазона, разница между крайними значениями может составить до 25 раз.

Результат будет точнее, если измерять размер очереди и работу в процессе (WIP). Об этом в следующих постах.

Q3: The Principle of Queueing Capacity Utilization: Capacity utilization increases queues exponentially

С увеличением загрузки мощностей очереди растут экспоненциально.

Высокую загрузку мощностей Дон называет главной причиной роста очередей. За тринадцать лет преподавания он вывел, что средняя компания-разработчик загружает свои мощности примерно на 98,5%.

Кривая зависимости времени цикла от загрузки мощностей для очередей типа M/M/1/∞ выглядит так:

При уменьшении доступных мощностей в два раза очередь тоже растет примерно в два раза. Когда мы увеличиваем загрузку мощностей с 60 до 80 процентов — очереди удваиваются (с 2 до 4), после увеличения загрузки с 80 процентов до 90 — еще раз удваиваются, с 4 до 9.

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

Зная загрузку мощностей ρ для процессов с очередями типа M/M/1/∞, мы можем предсказать следующее:

  1. В каком проценте случаев новая работа встанет в очередь из-за загруженного ресурса: 1 − ρ
  2. Среднее количество элементов в очереди: ρ² / (1 − ρ)
  3. Среднее количество элементов в системе: ρ / (1 − ρ)
  4. Какую долю длительности цикла занимает время нахождения элемента в очереди: ρ
  5. Отношение времени цикла к времени создания добавленной стоимости: 1 / (1 − ρ)

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

Q4: The Principle of High-Queue States: Most of the damage done by a queue is caused by high-queue states

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

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

В таблице представлены вероятности разных состояний очереди M/M/1/∞ при загрузке мощностей 75%.

Вероятность вычисляется по формуле (1 − ρ)ρⁿ

Мы можем увидеть, что вероятность нахождения в очереди двух объектов составляет 75% от вероятности нахождения в очереди одного объекта (14,1% и 18,8% соответственно). При этом нахождение в очереди двух объектов создает двойную стоимость задержки и экономический ущерб от очереди из двух объектов составит 150% ущерба от очереди с одним объектом. Вывод: чем длиннее очередь — тем сильнее увеличивается время цикла и выше ущерб.

Подытожим

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

Что важно знать про поведение очередей:

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

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

Что не так в посте продакт-менеджера?

В одном продуктовом канале прочитал следующий пост:

Вопрос: что не так в финальном утверждении автора?

Начнем с первого спорного утверждения:

Хорошее подтверждение тому, что люди по всему миру примерно одинаковые и хотят похожих вещей/развлечений/цифровых продуктов.

Давайте попробуем среверсинжинирить логику автора:

Люди в Дубае делают снежных ангелов (наблюдение)

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

но все-таки делают — значит, умеют и хотят это делать

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

все люди похожи друг на друга.

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

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

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

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

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

Четвертый серьезный косяк поста — автор на основе единичного наблюдения делает общий вывод. Так нельзя.
«Я один раз видел, как чуваки в Молл оф Эмирейтс делают снежного ангела в специальном павильоне → все люди одинаковы, т. к. делают снежных ангелов».
А если я ни разу не видел, как делают снежного ангела в Дубае — это считается за валидный контр-аргумент тезису «все люди одинаковы»? А достаточно ли одного наблюдения про снежных ангелов, чтобы утверждать, что «все люди это делают, следовательно — похожи»? А откуда мы знаем, что люди за пределами Дубая вообще делают снежных ангелов? — и так далее.

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

Теперь перейдем к финальному предложению:

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

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

Семь серьезных косяков на маленький пост твиттерского формата.

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

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

Теперь кратко, тоже в твиттерском формате, ответим на вопрос из начала поста: что же не так с последним утверждением в посте автора? Вот что: там дается неправильный и вредный совет, обоснованный примерно ничем. Надеюсь, теперь понятно, почему.

Осторожнее с выбором экспертов, которым вы доверяете. Снежных ангелов делать можно, а выводы как у автора в посте — нет.

Подборка постов про экономику

Это подборка публиковавшихся постов про экономику.

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

Бизнес-модель Спотифая: доходы от рекламы и подписок скидываются в общий котел, из которого потом платятся роялти артистам, в соответствии с их долей в общем количестве прослушиваний; в подкасте Мезенцева услышал, что якобы на платформе появились AI-артисты, которые отъедают свою долю из этого общего котла, сокращая доли остальных артистов.

Макдоналдс и трафик в ТЦ: макдональдс не повышает трафик в торговых центрах. Свидетельства очевидца.

Цепочка создания кофе такая: производитель → экспортер → импортер → обжарщики → точки потребления. $1000 долларов за тонну зерна у фермера превращаются в $112 680 на точке потребления.

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

Как обрушить экономику через цепочки поставок: большое исследование, в котором смоделировали всю экономику Венгрии, показало, что для существенного ухудшения экономики достаточно нарушить цепочки поставок всего 32 компаний из 91 000. Эффект домино возникнет при нарушении цепочки поставок ста компаний.

Как работает и чем крут маркетплейс Шейн: быстрое тестирование и выпуск коллекций, маркетинг через тикток и инфлюэнсеров, 6 000 заводов-подрядчиков в Китае.

Книга «Ценовое преимущество»: структура цены в компаниях из рейтинга 1200 Global, влияние изменения цены на изменение прибыли (вы удивитесь, насколько скидка снижает прибыль), три уровня управления ценами. Книжку после этого забросил, но вернусь.

Два поста по книге «Долг» Грэбера:

Экономика невостребованных подарочных карт

Прочитал выпуск The economics of unused gift cards в рассылке The Hustle — хорошо раскрывает кусок прошлого поста про подарочные карты Старбакса.

Ссылка на выпуск: https://media.hubspot.com/the-economics-of-unused-gift-cards

В США часто дарят подарочные карточки. Более, чем у  59% опрошенных в вишлистах — карточки каких-то сетей.

Более 70% карточек будут использованы в течение 6 месяцев после покупки, а в течение года — 78% карточек. От 10 до 19% номинала карточек не будет востребовано (выбрали товар на меньшую сумму), а 6% карточек вообще не будут использованы.

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

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

В США есть закон, предписывающий признавать номиналы невостребованных карт доходом по истечении определенного периода времени (6-24 мес), поскольку тогда с этих сумм можно получить вкусные НОЛОГИ. А некоторые штаты (НЙ, Делавер) вообще протащили законы об изъятии в пользу государства невостребованных активов, в т.ч. денег на подарочных карточках.

Всего за период с 2005 по 2015 было не было востребовано подарочных карт на 45,7 миллиардов долларов.

А вот картина за 2017 год, цифры по признанному доходу невостребованных карт:

Почему карточки не используют? Про них могут забыть, их могут потерять, далеко ехать до магазина/ресторана, чтобы откешить — причин масса.

Когда карточки не забывают использовать — для компаний это тоже выгодно:

  • 75% покупателей выбирают покупку дороже номинала карты, доплачивая собственными деньгами
  • В среднем, покупатели тратят на покупку на 59 долларов больше номинала подарочной карты
  • Покупатели с подарочными картами чаще готовы заплатить полную стоимость товара и не охотятся за скидками
  • 34% покупателей готовы отправиться за покупкой в новые для себя магазины/рестораны, куда они иначе не зашли бы — магазин/ресторан могут получить постоянного клиента
  • Подарочные карты не всегда тратятся за один заход, клиент может вернуться.

В конце заметки разбирается исследование Джоэля Вальдфогеля про разницу воспринимаемой и реальной стоимости подарков.

Обычно одариваемый оценивает стоимость подарка на 10-30% ниже, чем тот стоил дарителю. Это значит, что воспринимаемая ценность подарков обходится экономике в треть стоимости этих подарков, чистые экономические потери составят от 73 до 219 млрд долларов в расчете на этот год — из 730 млрд долларов, потраченных на подарки. В них входят и 17-51 млрд номиналов невостребованных подарочных карт.

Разумеется, рынок в 17-51 млрд долларов много кому не давал покоя, и на свете появились сайты, на которых можно продать невостребованные подарочные карты по цене 60-90% от номинала.

А лучший подарок всем, кроме мамы — наличка, считают экономисты.

Что я узнал-42

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

П. И. Шаликов — «Путешествие в Малороссию. Часть 1», Москва, 1803 ©

Редактор диаграмм последовательностей

https://sequencediagram.org/

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

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

Больше тулзов для моделирования — в посте про схемы из текста.

Как клиенты кредитуют Старбакс

Фейсбук

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

Сколько стоит поезд метро


(Много стоит)

Почему надо быстро

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

Отрывок из книги тут: https://docs.google.com/document/u/0/d/1Iz08_c2IU7TdGNpdjalEIHIZpOP0dOO0v9IA6uYxqQY/mobilebasic

Подписывайтесь на Максима на бусти, много полезного.

Письмо техдира Кайтена

Техдир “Кайтена” пишет письмо про падение сервиса.

❗Честно о сбое Kaiten: записка технического директора

Привет! На связи технический директор Kaiten.

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

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

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

Но сегодня речь не просто о том, что мы «постараемся исправить ситуацию в будущем». Сегодня мы даём конкретное обещание: привести систему к стандартам высокой доступности (99.9X%). И каждый месяц мы будем готовить отчёт о проделанной работе и публиковать его с деталями — что конкретно мы сделали.

Подписывайтесь на наш канал в Telegram, чтобы следить за выходом новых отчётов.

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

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

  1. Зачем в теме письма слово “честно”? Если это подчеркивают, то выходит, что могли рассказать нечестно? И сидели, думали: честно рассказать или соврать? Голосовали. Спорили. Утрирую, само собой, но слово-то есть и оно вызывает всякие мысли.
  1. Абзац про отпуск техдира. Никакого отношения к ситуации эта информация не имеет, зато можно дать волю мнительности: а, ну понятно, техдир только ушел в отпуск — у них все и посыпалось.
    Хотя скорее всего ожидалась реакция в духе “золотой вы человек, Юрий Венедиктович, все отдыхают — а вы трудитесь”.
  1. Перенос вины на нерасторопных подрядчиков — коллег с хостинговой платформы. Выглядит некрасиво, альфы так не поступают. Альфы идут и дрючат подрядчика, пока он не научится нажимать кнопку за пять секунд, а не два часа.


Так не извиняются 🤌🤌

Про теги и гугл кип

Удалил несколько старых тегов в Google Keep и пришел к некоторому заключению.

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

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

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

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

У Google Keep, кстати, для этого не хватает поиска по нескольким тегам.

Письмо от руки

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

Почерк не исправился 🥰

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

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

Use Case 3.0

Ивар Якобсон представил Use Cases 3.0 — следующее поколение юзкейсов. Я писал про предыдущую версию в блоге.

Видос: https://youtu.be/_lv0EeMpu7k
На ВК: https://vkvideo.ru/video2131309_456239145

Методичка доступна по ссылке, онлайн-моделлер тут: https://workbench.ivarjacobson.com/

Начал читать методичку. Существенных отличий от 2.0 немного, зато навели терминологический порядок: сами юзкейсы называют «набором практик» (не фреймворком, не методом); вместо зоопарка из терминов flow of events/scenarios/extensions теперь будет один — extension, это любое отклонение от стандартного успешного сценария; пошаговое описание юзкейса называется «рассказом», narration, — и т. п.
У юзкейса теперь указывается цель, а способ описания «рассказа» не регламентируется.
Добавили десять принципов, стандартные практики, чек-листы к ним.

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

Изучу — отдельный пост сделаю.

Игры

Alan Wake 2 — топчик и хитяра. Сложносочиненный мистический триллер/сурвайвал хоррор, исследующий муки творчества и пользу сотрудничества. Отлично написанный, с клевыми геймплейными находками и нервной боевой системой. В финальной трети игры я переключился на легкий уровень схваток и не пожалел. Отдельный жирный лайк за эпизод-мюзикл.

Cyberpunk 2077 — отличный, когда вкатишься. От сценария я не в восторге, но как экшен с элементами — почти идеальная игра.

Сейчас осваиваю Indiana Jones and the Great Circle и Death Stranding, обе отличные.
Stalker 2 поставил, посмотрел и снес — баги и темнота как у негра известно где.

Кино

«Ловец душ» (Longlegs) — средне, мне не зашел. Все его ругают за разжевывание сюжета в конце, не буду оригинальничать и поругаю за это же. Страшноватое.
«Сталкер» (Strange Darling) — хорошее, хоть и простоватое. Из редкой породы фильмов, которые можно испортить спойлерами.
«Дорога на Арлингтон» — хорошее, теории заговора, бомбы, террористы, Джефф Бриджес в роли школьного учителя.
«Падение империи» — отличное.
«Одинокие волки» — Питт, Клуни, олдскульный боевичок на один раз.
«Серый человек» — Райан Гослинг изображает Джейсона Борна, а Крис Эванс — брутальную версию своего же персонажа из первой части «Достать ножи». Бюджетная версия «Миссия: Невыполнима», разик можно посмотреть.
«Быстрее пули» (Bullet Train) — очень хороший, два раза посмотрел.

Свежие посты

Короче

Подборка постов про управление

Это подборка публиковавшихся постов про управление.

Про айти продукты — как делать продукт без роли аналитика?

Допустим, вы стали CPO. Какие ошибки не допускать на C-level и как не вылететь с позиции?

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

И еще философское — про взгляд дедушки менеджмента Питера Друкера на информационные технологии.

Навеянный сериалом The Bear текст про организацию кухни в ресторане.

Книга про работу на заводе и размышления о производственном менеджменте.

Книга про компанию Pixar — одна из лучших, что я читал про известные компании. Из грязи в IPO, источник состояния Стива Джобса, жесткие переговоры с Диснеем.

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

Хайлайты с вебинара Анны Лубенченко про управление собственным ресурсом. Считайте часы, пользуйтесь помодоро.

Хайлайты с вебинара Алексея Каптерева про фидбек в образовании и бизнесе.

Про управление проектами

Пост про роли, чеклисты, проекты и как их обсуждать.

Обзор отчета CHAOS Report 2018 — факторы успеха в управлении проектами по разработке софта.

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

Пост А. Турханова про вырождение понятия «проект»: раньше «проектами» считались временные предприятия с бюджетом от 20 млн долларов и штатом от 200 человек. Что потом пошло не так?

Проблема использования внешнего мозга

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

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

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

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

Один важный нюанс

Для удобства разделим информацию, хранящуюся в наших хранилищах, на два условных типа: справочные данные и руководства к действию. Справочные данные одинаково удобно хранить и в голове, и в экзокортексе. Телефон друга, адрес хорошего бара в курортном городке, количество БЖУ в порции пасты с креветками — эти кусочки информации одинаково полезны и однозначно воспринимаемы и по памяти, и будучи прочитанными в Apple Notes. Их просто нельзя интерпретировать по-разному.

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

Вот тут нюанс и всплывает. В чем разница алгоритма, запомненного и заученного до автоматизма, и алгоритма из базы знаний? В том, что первый алгоритм — интернализирован. При его выполнении возникает чувство «знакомости», привычности — мы это сто раз делали, мы это умеем.

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

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

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

Поменялся ли как-то за это время мануал? Нет — он и во время обучения был верным, и после освоения навыка остался таковым.

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

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

Ценность алгоритма в голове и вне её

В общем, если «телефон друга» в голове и в Apple Notes имеет плюс-минус одинаковую ценность, то алгоритм в интернализированном и записанном в блокнотике виде ощущается совершенно по-разному.

Вот та самая мысль, из-за которой я решил написать заметку:

Алгоритмы и инструкции, которые хранятся в экзокортексе, при воспроизведении лишены интуитивного ощущения «знакомости» и потому не ощущаются правильными.

Интернализированные алгоритмы — те, которые мы выучили и воспроизводим по памяти, — при выполнении ощущаются знакомыми, а значит — верными. Неинтернализированные алгоритмы из экзокортекса не ощущаются таковыми.

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

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

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

Доверяйте своему экзокортексу

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

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

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

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

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

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

Сила простоты

В прошлом октябре я писал про систему johnny.decimal, которой пользуюсь с прошлого года.

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

Стрелками указаны сущности индекса — Areas, Categories, IDs

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

Работать с j.d, когда система уже настроена, нужно так:

  1. Чтобы внести в систему новую категорию или айдишник — идем в индекс; смотрим, куда подойдет новая категория/новый индекс; определившись — вписываем в индекс новую сущность. Потом уже работаем с хранилищами: создаем где нужно папки, в индексе указываем используемое хранилище.
  2. Чтобы найти требуемый файл — идем в индекс и ищем там нужный айдишник и указание на хранилище, потом идем в хранилище и находим там файл.

Индекс нужно хранить в каком-то доступном, но секюрном месте. И вести его нужно в каком-то софте, пригодном для сценариев 1 и 2.

Ну и вот ниже самые разные варианты с форума j.d:

Кто-то заморочился и запилил (неудобный) специализированный сервис j.d generator:

Сам я сначала хранил индекс в Tana:

Тана хорошая, но у нее нет мобильного приложения; еще она могла стать недоступной из рабочей подсети, а то и вовсе перестать работать в России, как уже сделали ноушн и миро.

Начались поиски: сначала я перенес индекс в Trilium Notes; потом снес его и перенес все в Affine; все было неудобно, поиски продолжались. В какой-то момент я наткнулся на спецификацию индекса от самого Джонни, автора системы j.d, на гитхабе:

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

Теперь индекс лежит в папке 00.00 Индекс на некстклауде и выглядит так:

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

Я внес лишь пару изменений в конфиг Джона.

Во-первых, после айдишников в скобках я указываю коды хранилищ/локаций:

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

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

Здесь должен быть вывод, но его нет.

Что я узнал-41

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

«Словарь Академии Российской. Часть 1. От А до Г.» Санкт-Петербург, 1789 ©
Фото месяца — сгоревший сарай в Васильево, Татарстан

Маленькая, зато своя

После того, как Notion, а за ним и Coda с Miro киданули русских пользователей, стало понятно, что надо переезжать на другие сервисы. Я решил найти себе заметочник в ру-зоне, а в перспективе — вообще слезть с западных сервисов во всех нишах, включая облачные хранилища.

Ничего из саасов мне не приглянулось, а еще чесались руки сделать селф-хостед, пусть и на виртуалке.

Когда-то я уже настраивал себе Shadowsocks для обхода блокировок, так что страшно не было. Я завел себе виртуальный сервер на рег.ру (VPS, 440₽ в месяц с бэкапами), поставил туда селф-хостед-версию Affine по инструкции и перенес записи. Адрес получился некрасивый, вида «айпишник:порт», но все работает.

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

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

Пока не решен минорный вопрос, как привязать адрес вида «айпишник+порт» к субдомену — я хотел повесить некстклауд на cloud.artemushanov.ru, а аффайн — на notes.artemushanov.ru, для пущей красоты и легкости запоминания. С ходу не заработало, надо ковыряться с DNS. Еще нужно купить зонтичный сертификат SSL, чтобы соединение с приложениями работало через https, это я сделаю в декабре.

Steamdeck

Два месяца назад купил себе Steamdeck, и это лучшее игровое устройство в мире для инди-игр и несложных походовых стратегий.

Фотка не моя
  1. Работает от батарейки, играть от сети неудобно из-за расположения гнезда зарядки. Больше 2-3 часов подряд не поиграешь. Ограничивает и дисциплинирует.
  2. Сочетание качества-разрешения экрана и железа оптимальные: дек тянет игры шести-семилетней давности и любое плоское инди. То, что мне нужно — для ААА и прочего у меня есть иксбокс.
  3. Размер оптимальный: это и не айфон, на котором только в метч-три играть, и не ноутбук с «Киберпанком». Можно играть, лежа на диване.
  4. Управление кастомизируется в довольно широких пределах. Можно, немного попотев, настроить нормальные контролы для своей любимой походовой стратегии 2006 года выпуска.
  5. Это идеальное домашнее портативное устройство, как айпад. Таскать его с собой вне доме неудобно — с футляром он занимает места почти как ноутбук.
  6. Игр до-фи-га. Из моей стим-библиотеки на 1000+ тайтлов примерно 200 попадают в категорию «Идеально идут на стимдеке». Из «оранжевой» зоны (идут, но с нюансами) — еще штук триста.

Во что я играл на стимдеке

Список неполный, только самое запомнившееся.

Halls of Torment — клон Vampire Survivors, хороший;
Songs of Conquest — клон «Героев» в более мрачном сеттинге;
Mortal Sin — роглайт-слешер от первого лица с очень странной графикой; поначалу сильно отталкивает и напрягает именно из-за графики, но потом привыкаешь и начинаешь раздавать двуручным мечом направо и налево;
Hades — все знают «Аида», но я его распробовал только на стимдеке;
Shadow Tactics — роскошный клон «Коммандос» в японском сеттинге. Управление адаптировано под консоль/геймпад, играется прекрасно. Особо приятно, что облачный сейв 2017-го года запустился и я продолжил играть с того места, где остановился семь лет назад;
Mortal Kombat Komplete Edition — обожаю эту часть, играю за Сайракса;
Against the Storm — отличная стратегия, клон The Settlers с роглайт-элементами. Есть пауза, поэтому играть с геймпада не так сложно. Курсором можно управлять с правого стика или правого тачпада;
Wall World — инди-аркада с копанием и добычей ресурсов. Такие игры почему-то любят делать на территории России и стран СНГ;
Ctrl Alt Ego — иммерсивный сим от первого лица, хороший и необычный: мы играем за «душу» хакера, которая вселяется в роботов и компьютеры для выполнения заданий;
Caveblazers — вспомнил былое, иногда гоняю, когда хочется чего-то простого и быстрого;
Impaler Gold — арена-шутер, в котором можно вызывать колья из-под земли. Мало контента, но играется бодро;
Kriegsfront Tactics: Prologue — отличная походовая тактика, оммаж Front Mission, который гораздо лучше римейка Front Mission. Буду покупать полную версию.

Купили машину

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

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

«Селтос» этот в предыдущей модификации назывался KX3 и предназначался для китайского рынка. Собирается в Китае, но сборка очень крупноузловая, как я понял.

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

Нарулил пару пабликов, оттуда беру инфу по аксессуарам и запчастям: в телеге, вконтаче.

Видео «Обучение в течение всей жизни. И что с ним не так?»

Ютуб

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

Хайлайты::

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

Прикольные дизайнерские тулзы

  • Игра в кернинг, нужно выставить правильные межбуквенные интервалы
  • Editor — простой графический редактор, работает в браузере

Все с сайта Method of Action.

Стаканы Superfest

Фотка с википедии

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

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

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

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

Не-массовая есть как минимум одна: краудфандинг с предзаказами. Основатели Superfest запустили кампанию на кикстартере, продукт называется Ultraglass, и это бутылка. Вот инфа на сайте компании Soulbottles: https://www.soulbottles.de/en/ultraglass

А вот видео, где обычную и прочную бутылки бахают об пол:

Короче

  • Гитхаб для чеклистов — можно посмотреть и переиспользовать чужие чек-листы, можно создать и пошарить свой
  • «Айфон умеет идентифицировать растения по фото» — в России не умеет, я пробовал (рассылка The Scope #45)
  • Простой онлайн-блокнот — https://typehere.app/
  • Симулятор мыльных пузырей https://oimo.io/works/bubbles/
  • Карта с проекцией тени в течение дня: https://shademap.app/

Decision Patterns, пост 2

Посты про фреймворк Джона Фитча под названием Decision Patterns.

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

В этом посте разберем основы фреймворка и некоторые устойчивые паттерны.

Определения и фундаментальные концепты

Начнем с понимания основы — что же такое этот самый decision:

«Принимаемое решение» (decision) в фреймворке Фитча — это фундаментальный вопрос или проблема, требующие ответа/решения (solution).

Примеры «принимаемых решений»:

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

С этой точки зрения «принимаемое решение» — это составная часть задачи. А сама задача состоит из набора таких «принимаемых решений», вопросов, на которые нужно последовательно ответить. «Принимаемые решения» организуются в Decision Breakdown Structure (DBS), я про нее писал в прошлом посте.

С точки зрения системной инженерии — это следование принципу separation of concerns, мы «распиливаем» домен задачи на отдельные функциональные блоки и разбираемся с ними по отдельности.

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

На примере университета:

  1. Принимаемое решение: нужно выбрать универ для поступления.
  2. Альтернативы: АГТУ, АГУ, МГУ, Бауманка, МФТИ.
  3. Критерии: универ в Астрахани или в Москве; хорошая репутация; есть возможность пройти на бюджет; сильные программы по экономике и маркетингу.

На примере маркетинговых каналов:

  1. Нужно выбрать маркетинговые каналы для рекламной кампании
  2. Альтернативы: РСЯ; контекстная реклама; реклама в видео; размещение у блогеров.
  3. Критерии: бюджета хватит на 60 дней размещения; обеспечит охват в 250 тысяч; можно разместить видео; можно менять креативы раз в две недели; можно оплатить с юрлица.

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

Как принимаемые решения объединяются в паттерны?

В рамках конкретной задачи определяется одно главное принимаемое решение, которое разделяется на несколько принимаемых решений более низкого уровня. Это и есть Decision Breakdown Structure (DBS) — структура/диаграмма разбиения принимаемого решения. Устойчивый набор принимаемых решений, организованный в такую диаграмму, называется «паттерном принимаемых решений» (Decision Pattern).

Далее будет пример такого паттерна — «Дизайн оргспособности» (ОС, Capability Concept). Он будет состоять из номера принимаемого решения, его названия, короткого вопроса и класса принимаемого решения.

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

Номер Название ПР Описание ПР Класс ПР
1. Концепт оргспособности Какова верхнеуровневая архитектура, дизайн или пример имплементации для этой ОС? Один ответ
1.1 Сценарии использования В каких ситуациях или сценариях мы будет использовать ОС? Несколько ответов
1.1.1 Ценностное предложение Какую уникальную ценность предложит новая ОС в этом сценарии? Один ответ
1.2 Ключевые методы Какие методы или комбинации методов обеспечат основу этой ОС? Один ответ
1.3 Архитектура процесса Какую архитектуру, фреймворк или флоу процесса мы используем для разворачивания ОС? Многочастный ответ
1.3.1 Дизайн процесса Как вот эта часть процесса будет работать? Один ответ
1.3.1.1 Инструменты Какой набор инструментов мы используем, чтобы обеспечить эту часть процесса? Один ответ
1.3.1.2 Рабочие продукты Какие РП будут созданы этим процессом? Как они будут доставлены в следующий процесс? Несколько ответов
1.4 Интерфейсы ОС С какими процессами или другими ОС целевая ОС будет взаимодействовать? Несколько ответов
1.4.1 Концепт интерфейса Как эти ОС будут взаимодействовать друг с другом? Как их интерфейсы будут работать? Один ответ
1.5 Оргдизайн Как нам организоваться, чтобы эффективно использовать эту ОС? Кем укомплектуем команду? Какую роль будет играть каждый член команды? Многочастный ответ
1.6 Платформа Какая потребуется инфраструктура (помещения, рабочие центры, оборудование) для обеспечения ОС? Многочастный ответ
1.7 Метрики Какие метрики потребуется отслеживать для новой ОС? Как мы их соберем? Несколько ответов
1.8 Развитие Как мы получим или разовьем эту ОС? Один ответ

Классов принимаемого решения три:

  • «Один ответ» — обычно используется для вопросов вида «Каков/какой/как...», определяет концепты или технологии, выбираем один вариант из какого-то количества альтернатив.
  • «Несколько ответов» — используется для портфолийных вопросов вида «Какие N из набора M мы выберем?», выбираем все подходящие варианты.
  • «Многочастный ответ» — используется для архитектурных выборов, где варианты обычно представлены архитектурными моделями из нескольких связанных элементов. Например: какую оргструктуру выбрать для компании — более плоскую или более иерархичную? Каждый вариант «плоская, иерархичная» — это схема из нескольких элементов.

В принимаемых решениях классов «Несколько ответов» и «Многочастный ответ» у каждой рассматриваемой альтернативы должны быть рассмотрены все принимаемые решения ниже уровнем.

Пример:

1.1 Сценарии использования В каких ситуациях или сценариях мы будет использовать ОС? Несколько ответов
1.1.1 Ценностное предложение Какую уникальную ценность предложит новая ОС в этом сценарии? Один ответ


Если в «Сценариях использования» мы выбрали три сценария из пяти, то «Ценностное предложение» нужно выбрать для каждого из этих трех сценариев.

Понятнее станет, если мы посмотрим на то же самое в виде схемы:

Синие треугольники — обозначение того, что выбрать вариант решения нужно для каждого подварианта

Так же в рамках паттерна составляются списки критериев по каждому вопросу/принимаемому решению.

Вот пример критериев для вопроса «1.1 Сценарии использования»:

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

Конструкция «система должна» не обязательна, критерии/требования вполне могут быть в формате «максимизировать/минимизировать показатель N».
Сколько надо: Фитч пишет, что обычно получается 7-12 критериев на принимаемое решение. Лучшие критерии — измеримые и проверенные временем на ряде проектов: паттерн может и должен эволюционировать после каждого использования.

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

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

Что нам дают паттерны принимаемых решений? Они нам дают возможность выработать шаблонный способ принимать сложные решения. Золото для консультантов и работников «знаниевых» профессий.

Примеры паттернов

У Фитча таких паттернов некоторое количество, приведу примеры из исходной статьи.

System/Product Design
Содержит порядка 100 вопросов/принимаемых решений, наиболее часто применялся самим Фитчем.

Enterprise Strategy
Содержит около 60 вопросов/принимаемых решений, является «материнским» паттерном, от которого потом пойдут плясать продуктовые паттерны, паттерны оргспособностей и прочие.

Service Design
Содержит 25 вопросов/принимаемых решений; принимаемое решение Service Delivery Platform может стать триггером для запуска паттерна System/Product Design

Curriculum/Courseware Design
Содержит около 40 вопросов/принимаемых решений, позволяет спроектировать учебный артефакт от уровня индивидуального онлайн-курса до уровня полного университетского курса.

Выводы

Конец второго поста и конец оригинальной статьи. Подведем итоги.

  1. Фитч нашел способ формализовать и описать сложный домен «принимаемых решений» через понятийный аппарат системной инженерии. Это позволяет разложить принимаемое решение на набор элементов — решаемую проблему, критерии хорошего решения, доступные варианты решения, — и разобраться с ними по очереди. Получился фреймворк для принимаемых решений с основным рабочим артефактом Decision Breakdown Structure.
  2. С помощью фреймворка и набора методов Фитч предлагает создавать паттерны решений — устойчивые наборы принимаемых решений и наборы критериев для конкретных доменов задач. Паттерны можно переиспользовать в разных проектах для решения похожих задач, что особенно ценно для консультантов: у них есть задача алгоритмизировать любые уникальные задачи, чтобы их можно было решать быстрее или силами менее опытных сотрудников.

Дальше буду разбирать статью Фитча «Decision Patterns. So what?» на ту же тему.

Что я узнал-40

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

Цитата выпуска — бобры:

«Письма к приятелю», М.В. Данилов ©

Музыка выпуска:

Названия нот

Музтеоретик

Ноты называются по первым двум буквам первых слов строк в тексте средневекового «Гимна Святому Иоанну» (Ut Queant Laxis). «Ut» со временем стала «Do», потому что вроде бы изменился текст гимна. Или нет.

Живописные маршруты делают богатых богаче

пост Кейси

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

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

Новинки в эргодоксе

Эргодокс — это моя сплит-клавиатура:

Я сто лет не залезал на сайт производителя, потом увидел пост про комбо и срочно пошел пробовать новенькое.

Что я попробовал:

  1. «Комбо» — можно назначать действия на комбинации клавиш. В комбо можно задействовать от двух до шести клавиш, нажимать надо одновременно. На комбо вешается действие какой-то клавиши, комбинация клавиш или макрос — последовательность нажатий или действий. Я сделал себе комбо на копипаст (C+V — копировать, V+B — вставить) и быстрое удаление слов, которое обычно активируется через Ctrl+Backspace/Del. Удаление я повесил на комбинации с тамб кластера «пробел+бекспейс» и «энтер+del» — они на кластере расположены рядом; работать стало гораздо удобнее, но случаются мисклики.
  2. Несколько режимов у любой клавиши: на одинарное, быстрое двойное нажатие и удерживание клавиши теперь можно повесить разные действия или макросы — то есть до трех функций на клавишу; пока что повесил себе на клавиши переключения слоев адресное включение раскладок по нажатию (Ctrl+1 русский, Ctrl+2 английский) и временное включение слоя — по удержанию.
  3. Можно поменять тайминг определения удерживания клавиши в миллисекундах — т. е. указать, когда клавиатуре уже считать, что вы «зажали» клавишу, а не просто тапнули; помогает подстроить переключение под свою скорость набора. Можно повесить на какие-нибудь клавиши функции «накинь/убавь тайминг на 10 мс», чтобы менять в реальном времени, а не через перепрошивку клавиатуры.

Когда нужен мозг — займи руки

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

Отлично работают и не приедаются игры.

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

A Slight Chance of Sawblades

Но CoD была давно, и в карман ее вместе с компом не положишь, а мой мозг и беспокойные руки по-прежнему со мной. Недавно похожий эффект я наблюдал, тыкая во время скучного зум-звонка в мобильную игру A Slight Chance of Sawblades из подписки эпл аркейд. Редчайший пример синергии: внимательно слушал выступающего и запомнил все важные для меня моменты на звонке — и сходу набрал 25+ очков в игре.

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

Сайт про стенографические клавиатуры

Целый сайт, который пишет про стенографические клавиатуры, продает их и кастомизирует.
Мой старый пост про стенографию: https://artemushanov.ru/?go=all/mehanicheskie-klaviatury-post-3/

Организация файлов и заметок с помощью тегов

Я всегда использовал теги для пометки записей и заметок в приложениях и никогда не делал это разумно и осознанно. Со временем тегирование превратилось в легаси-ритуал: я ставил теги, но никогда ими не пользовался для поиска.

На днях я на реддите наткнулся на топик, где обсуждали систему Johnny Decimal (я ей пользуюсь для организации файлов и заметок, писал тут). Юзер Карл Войт написал коммент в духе «Джонни Децимал говно, потому что строгие иерархии не работают, юзайте теги» и дал ссылку на свой пост с подробностями.

В посте Карл пишет, как настроить и использовать систему тегов везде — в файлах, в заметках, в базе знаний. Описывает набор принципов, по которым нужно формировать теги (не более одного слова, использовать генерализацию «теннис, футбол → спорт»), предлагает решение для присвоения тегов файлам (дописывать через двойное тире в конец имени скриптом на питоне, чтобы получалось такое: 2022-01-29 Business Report -- draft internal.pdf).

Пост ботанский, а еще есть видео выступления и диссертация (!) Карла на тему Tag Trees. В общем, чувак серьезно подошел к вопросу.

Если взглянуть рационально — много полезного. Теги могут дополнить строгую иерархию J.D: там система строится из папок, а теги можно использовать для разметки файлов внутри них.

Ну и мое главное открытие: теги должны жить во внешнем индексе и использоваться во всех приложениях.

Любовь к Google Keep

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

Взгляд лениво перетекает с заметки на заметку

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

Сравните с тем, как «сетка» выглядит в Apple Notes:

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

Если гугл убьет Keep, это будет ужасно 😿

Шаблон целеполагания: как правильно формулировать ОКРы

Канал «Борода продакта»

Канал ведет Сергей Тихомиров, автор Product Architecture Framework.

Основа шаблона — понимание цели (Objective) как «целевого состояния» объекта управления. То есть, задача полностью звучит как «перевести объект Икс из состояния А в состояние Б», где объект Икс — то, на что сотрудник может влиять. «Целевое состояние» характеризуется каким-то набором характеристик (Key Results) с нужными значениями.

Примеры правильной формулировки из поста:

  • Увеличить скорость выкатки ценности для потребителей за счет внедрения scrum. Time-to-market сокращен до 4 недель.
  • Снизить отток пользователей BI-продукта за счет добавления новых аналитических шаблонов. Retention rate 2 периода увеличился с 27% до 35%. Переток со старых на новые шаблоны не менее 60% пользователей базы.
  • Увеличить количество активаций, пришедших через VK за счет изменения плейсмента и внедрения новых офферов. Объем активаций увеличился до 2500.
  • Увеличить доходимость до конца курсов студентов за счет добавления тренажеров навыков. Конверсия в завершенный курс 70%. NPS 85%.

Чтобы повернуть направо — поверните налево

Любопытный видос от Veritasium про то, как на самом деле поворачивает велосипед.

Хочется отметить три вещи.

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

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

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

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

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

Игры на иксбокс

Посмотрел шоукейс икбокса — есть интересные позиции:

Новые посты

Короче

  • Зубец на Кремле называется «мерлон»
  • Приложение Minus для мака разом сворачивает все приложения
  • Обслуживание вертолета/яхты/другой лакшери-техники обходится в 10% их стоимости в год (где-то услышал, не проверял)
  • Бесит, что в экселе кнопка «увеличить количество разрядов в числе» находится слева, а «уменьшить...» — справа, каждый раз путаю; должно быть наоборот.
  • TIL-посты теперь будут выходить не ежемесячно, а с рандомной периодичностью — когда наберется наблюдений на целый пост.

Decision Patterns, пост 1

Посты про фреймворк Джона Фитча под названием Decision Patterns.

Люди и решения

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

В постах про отчеты CHAOS Report я наткнулся на важную мысль:

Быстро принять неоптимальное решение лучше, чем долго искать оптимальное решение

«Неоптимальное» — это не «плохое», а скорее «достаточно хорошее», неидеальное, но работающее. Трактовка автоматически тянет за собой вопрос «а как мы определим оптимальность решения?» — то есть, каковы критерии выбора? За короткий абзац стало понятно, что минимальный фреймворк для принятия решений содержит в себе три элемента: проблема, вариант решения, критерии оценки решения.

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

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

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

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

(а) все отлично, так у всех, жизнь сложная

(б) не очень ок с качеством решений.

Напишите выбранный вариант в комментах, приложите копию паспорта. А то вдруг вы бот.

Короче, люди плохо умеют принимать решения по сложным проблемам/задачам. Поэтому нужно научиться раскладывать сложные проблемы на простые составляющие и решать по частям, а для этого нужен какой-то метод. Мне стало интересно, что про это пишут в мире, поэтому я решил поразбираться в домене Decision Making.

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

Зачем это читать (строим базу)

Пишу эти посты в стремлении навести какую-то базу в размышлениях о домене Decision Making: как вообще правильно думать об этом?

Приведу абзац из моего поста про CHAOS Report 2018:

Основной тезис раздела звучит так:

The value of the interval is greater than the quality of the decision.

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

Группа Стендиш предлагает прикольную эмпирическую метрику: проект порождает одно решение на тысячу долларов проектных трудозатрат. Если в проекте на одно решение приходится не одна, а две тысячи трудозатрат — значит, решения принимаются дольше, чем это возможно.

«Решением» здесь может быть любой выбор из какого-то количества альтернатив, способный повлиять на дальнейший ход проекта, его «выхлоп» или метод работы.

А вот цитаты из другого моего поста, про отчет 2020 года:

Good Decision Latency — это когда решения принимаются быстро, а Poor — когда долго (...). Разница поразительная: быстрые решения в десять раз уменьшают вероятность зафейлить проект и почти в четыре раза увеличивают вероятность успешно завершить проект.

...Разница в накладных расходах на принятие решений у команд с High-скиллом и Poor-скиллом примерно десятикратная.

Принимать решения и делать это правильно — выгодно.

В связи с вышеизложенным, у меня родилось несколько аксиом:

  1. Решение всегда решает проблему/задачу
  2. Возможных решений у проблемы/задачи всегда больше одного
  3. Лучше принимать хорошие решения, а не плохие
  4. Лучше принимать решения быстро, а не долго

И несколько важных следствий из аксиом:

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

Джон Фитч, чей фреймворк вынесен в заголовок поста, как раз предлагает метамодель и шаблоны для понимания домена Decision Making. Этот пост — про первую статью Джона, опубликованную в SyEN edition 107, December 2021.

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

Методы рационального мышления

Фреймворк Джона корнями растет из простого четырехчастного фреймворка K-T Rational Process, с которым Джон ознакомился на тренинге в 1986 году:

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

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

Анализ решений (Decision Analysis) — мыслительный паттерн для проектирования будущего: выработки решений под требования стейкхолдеров; методов оценки или сравнения этих решений; выбора курса действий для достижения оптимальной эффективности. Отвечает на вопросы «какое (решение взять)?» или «как (решить проблему)?».

Анализ потенциальных проблем (Potential Problem Analysis) — мыслительный паттерн для обнаружения потенциальных проблем, могущих возникнуть вследствие выбора какого-то решения из предыдущего этапа. Помогает предусмотреть и митигировать риски.

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

Джон изобретает решение-центричную СИ

Спустя годы Джон пришел к собственной модели — «решение-центричной системной инженерии» (Decision-centric Systems Engineering). Выглядит она посложнее, чем предыдущий фреймворк:

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

Слева направо:
Decision Breakdown Structure (DBS) — схема декомпозиции проблемы или задачи на набор понятных вопросов, объединенных в группы; это основа системы:

Requirements — требования к будущей системе; обуславливают критерии для выбора решений.

Decision Analysis — схема принятия решения по каждому вопросу из DBS. В смысловом центре схемы — желтый блок, это Decision, или вопрос, на который нужно ответить. Его берем из DBS.

Слева от него — критерии, которые важно принять во внимание по конкретному вопросу. Они формируются из требований. Цветные блоки справа от желтого блока — список альтернатив, потенциальных способов ответить на вопрос. Каждый такой способ оценивается по эффективности/производительности (Performance) и архитектурной пригодности — для понимания этого рисуются простенькие Architecture models. Модели должны быть с уровнем детализации, достаточным для прикладывания их к критериям и сравнения между собой: Джон несколько раз пишет в статье «no modeling for modeling’s sake».
Иногда, когда того требует ситуация, для оценки применяются физические или матмодели.
Из каждого способа решения растет вправо набор следствий — действий или эффектов, которые случатся, если выбрать этот вариант. Есть петля обратной связи от следствий обратно к требованиям: решения принимаются по очереди, и уже принятые нужно учесть в дальнейших выборах — в формате новых требований.

Планы работ и родмепы — это положенная на таймлайн последовательность действий по реализации принятых в качестве решений альтернатив и по митигации рисков:

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

Образ результата
  1. Делаем DBS — формулируем вопросы:

Команда:

  • Кто будет жарить?
  • Кто будет готовить ингредиенты?
  • Кто побежит в магаз за помидорами, если их не обнаружится в холодильнике?

Архитектура яичницы:

  • Сколько яиц взять?
  • На каком масле жарить?
  • Какую сковороду использовать?

Методы:

  • Как обеспечить нужную степень прожарки?
  • Каков порядок закладки ингредиентов?
  • Как подготовить сыр?

...и так далее.

  1. Оформляем все детали к альтернативам из группы «Архитектура яичницы»:
  • Сколько яиц взять: два (минимум для двух человек); четыре (оптимум); шесть (если сильно голодные)
  • На каком масле жарить: на сливочном; на подсолнечном; без масла
  • Какую сковороду использовать: стандартную; большую
  1. Детализируем пару альтернатив по сковороде:
  • «Использовать стандартную сковороду»: легко реализовать — сковорода лежит в шкафчике рядом; вмещает яичницу на 2-4 яиц, но не на 6; легко мыть, целиком помещается в мойку; оценим перфоманс как «высокий»
  • «Использовать большую сковороду»: реализация сложнее: нужно идти за ней на лоджию, будет тяжело мыть — не помещается в мойку; ворочать ей на плите тоже сложно: занимает больше места, тяжелая; вмещает яичницу на 4-8 яиц, ради двух нет смысла с ней связываться; оценим перфоманс как «средний с минусом»

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

Дальше примерно понятно: определяем «следствия», строим план, реализуем, а потом с аппетитом этот инженерный проект съедаем, урча маянезиком.

Снова про еду получилось, надо что-то с этим делать.

Методология управления решениями

Если элементы из схемы выше упаковать в более крупные группы, то получается методология управления решениями (Decision Management methodology):

Эту методологию Джон преподает на тренингах и воркшопах. Вот список областей, где она, со слов Джона, применяется:

  • New product development
  • Technical proposals
  • Technology insertion projects
  • Portfolio management
  • Strategic capability design initiatives, e. g. transformational or continuous improvement
  • Common/reference architecture development (platform & product line engineering)
  • Innovation framework
  • Feasibility analyses
  • Research and Development (R&D) and Science and Technology (S&T) project management
  • New business/technology incubation
  • Capability, product, technology and platform roadmapping
  • Business ecosystem modeling and design (looking for opportunities)
  • Life coaching

Процессы в методологии:

Plan Decisions — процесс определения списка «выборов» (decisions), которые надо сделать для решения выбранной проблемы; итоговый артефакт процесса — Decision Breakdown Structure из большой схемы, где каждый «выбор» — это вопрос. Далее с помощью DBS строится Trade Study Plan — на русском это что-то вроде «плана исследования компромиссов/альтернативных решений». План содержит порядок, в котором следует принимать решения из DBS, основываясь на приоритетах и логике, а также все меры по поиску и формированию необходимой для этих решений информации. То есть, DBS — это «что» надо сделать, а TSP — «как» это сделать.

Plan Decisions можно использовать не только для «прямой инженерии» (от проблемы к решению), но и для «обратной», или реверс-инжиниринга. Зная, какие альтернативы были выбраны в существующем продукте/сервисе, можно пойти в обратную сторону: попробовать определить, какие решения в компании принимали, когда их выбирали, и какими требованиями руководствовались.

Звучит шизофренично, но вот вам кейс из жизни: крупный маркетплейс с огромным штатом разработчиков и аналитиков, обвешанный бигдатой со всех сторон, нанял консультантов. Для того, чтобы консультанты зареверсинжинирили интерфейс мобильного приложения и определили, какие фичи помогают пользователю, а какие — мешают. На всякий случай напомню, что каждая из этих фич была кем-то придумана, описана, засунута в бэклог, обоснована экономически, а потом реализована, протестирована и торжественно релизнута. Ну или не торжественно, а буднично, если там CI/CD.

Практика реверс-инжиниринга принятых решений (Джон зовет ее Decision Blitz) позволяет вовлечь стейкхолдеров в проект и обнаружить важные штуки:

  • несогласие стейкхолдеров по поводу принятых решений (они видели его по-разному), а следовательно — и по поводу требований, которые следовали из этих решений;
  • подсветить ранее принятые решения (decisions), которые могли бы дать больше ценности стейкхолдерам/проекту, если откатить их и заново рассмотреть.

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

На схеме методологии есть большой процесс Manage Decisions across Domains — он управляет системой знаний на предприятии и осуществляет валидацию, хранение и переиспользование решений на разных проектах. Один из его подпроцессов, Manage Decision Patterns, отвечает за процессы извлечения новой информации из проектов и ее использования для улучшения существующих паттернов.

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

На этом я первый пост закончу — мы примерно на середине первой статьи.

Резюме

  1. Для успеха в проекте и личной жизни нужно уметь быстро принимать хорошие решения;
  2. Чтобы быстро принимать хорошие решения — нужно правильно подходить к этому: изучить проблему/вопрос, декомпозировать на список вопросов, сформировать требования, превратить требования в критерии, к каждому вопросу подобрать несколько вариантов решения/ответа, сравнить их между собой на предмет соответствия критериям, оценить риски и следствия, повторить пока не наступит просветление;
  3. Яичница с жидковатыми желтками лучше хорошо прожаренной.

Блог Джона Фитча: https://decisiondriven.wordpress.com/

Пирамида Минто в продажах

Мой пост из сообщества «Алаверды»

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

Пирамида Минто выглядит так:

  1. «Верхушка»: главный месседж, утверждение или тезис. То, в чем мы хотим убедить собеседника.
  2. Подробности к верхушке — по фреймворку СОВО (Ситуация, Осложнение, Вопрос, Ответ)
  3. Первый уровень пирамиды — поддерживающие аргументы. То, что мы сообщаем в поддержку тезиса, 2-3 штуки. Должны отвечать принципу ВИСИ — «взаимно исключающие, совместно исчерпывающие».
  4. Второй уровень пирамиды — свидетельства в пользу аргументов.
  5. Основание пирамиды — заключение, подтверждающее тезис с помощью аргументов в кратком виде.

Строить пирамиду можно как сверху вниз, так и снизу вверх.

Пример:

  1. Допустим, мы хотим успешно продавать нашу специализированную CRM-систему ALVRD девелоперам. Формулируем тезис: «Наша CRM-система лучше всего подходит для нужд девелоперов». Вот наша верхушка. Подробности пусть будут такие: Ситуация — продажи недвижимости нужно вести правильно, соблюдая правила компании и не забывая про массу обязательных деталей; Осложнение — коммерческая деятельность с недвижимостью устроена сложнее, чем продажи в других сферах, поэтому стандартные СРМ-системы не подходят для автоматизации продаж; Вопрос — как же лучше быть: заказать кастомную разработку или смириться с отсутствием нужных функций в стандартных СРМ-системах?; Ответ — лучше купить СРМ-систему ALVRD.
  2. Формулируем три аргумента. Первый: «За пять лет мы отлично разобрались в подробностях коммерческой работы девелоперов и воплотили эту экспертизу в продукте». Второй: «Пять крупных девелоперов из первой десятки пользуются нашей системой и довольны». Третий: «Нашу систему легко подстроить под любого девелопера или риэлтора с помощью простого редактора».
  3. Формулируем свидетельства в поддержку аргументов:
    Первого: «мы учли все основные виды партнерств и типы продаж, вот список...»
    Второго: отзывы и кейс-стади пяти крупнейших девелоперов/клиентов с акцентом на сильные стороны системы
    Третьего: картинки и описания редактора процессов, кейс «Как это сделано у девелопера Икс»
  4. Основание пирамиды — заключение: «Наша CRM-система изначально проектировалась под коммерческие бизнес-процессы крупных девелоперов, поэтому... (аргументы, свидетельства)».

Как будет выглядеть готовый текст:
«CRM-система ALVRD лучше всего подходит для коммерческой работы крупных девелоперов и риэлторов.
В продажах принято использовать CRM-системы для фиксации лидов и сделок. Это помогает менеджерам не забывать важные вещи и доводить сделки до конца. Однако, в продажах недвижимости есть много специфики: ипотека, необходимость взаимодействовать с банками и регуляторами, обязательная проверка контрагентов и регистрация сделок в Росреестре. В стандартных CRM-системах нет поддержки этих процессов. Как быть? Можно потратить деньги и время и разработать кастомную систему, но это неоптимально — дорого и долго. Можно использовать стандартную CRM-систему и часть сделки вести в ней, часть — в переписке и Excel, но это сильно нагрузит менеджеров. Вместо этого мы предлагаем рассмотреть ALVRD — специализированную CRM-систему для коммерческих сделок с недвижимостью.

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

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

Именно по этим трем причинам мы считаем, что ALVRD — лучшая CRM-система для девелоперов и риэлторов. Мы знаем, как устроена коммерческая работа с недвижимостью, мы поможем подстроить систему под вас, и с нами уже работают лучшие игроки рынка.»

Ранее Ctrl + ↓