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

Из этой точки зрения следует другая точка зрения — что в работе, в рабочем контексте, нужно давать новичкам совершать ошибки, даже стремиться к этому, и тогда они быстро научатся правильной работе. Марк Цукерберг, не последний человек в мире, даже ввел рабочее мотто «move fast and break things» в одной экстремистской организации.

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

Википедия:

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

Словарь Ожегова:

Неправильность в действиях, мыслях.

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

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

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

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

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

Тут есть пара важных допущений.

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

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

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

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

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

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

Предположу, что дело в экономической близорукости. Если в штат наняли 10 сотрудников, то это десять источников ошибок, каждый со своим характером и особенностями. За каждым надо отследить ошибки, объяснить, в чем отклонение от нормы, и описать правильный курс действий. Это МНОГО работы. Это дорого.

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

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

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

А Цукерберг в 2014 поменял мотто на «move fast with stable infrastructure». Интересно, почему?

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

Поговорили с Динарой про продуктовый подход, путаницу в терминах и понятиях вокруг него и всякие другие околопродуктовые и околопроектные штуки.

Релевантные посты:

• https://artemushanov.ru/?go=all/reynertsen-post-2/
• https://artemushanov.ru/?go=all/reynertsen-post-3/
• https://artemushanov.ru/?go=all/primenenie-ekonomicheskogo-freymvorka-reynertsena/
• https://artemushanov.ru/?go=all/primenenie-ekonomicheskogo-freymvorka-reynertsena-video/

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

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

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

Я в очередной раз посмотрел — в этот раз как исследователь — на Обсидиан, Emacs OrgMode и еще несколько инструментов, и понял, как устроены все заметочники.

Как устроены заметочники

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

Аутлайнеры — workflowy, dynalist, roam research, tana.inc — используют формат буллет-листа с возможностью бесконечной вложенности. Единицей контента обычно считается буллет, и на него уже наворачивают фич кто во что горазд. Тана, например, умеет прикреплять к буллетам поля, с помощью которых можно как-то этот буллет формализовать: присвоить тип, дату, еще чего-то. После этого из таких буллетов можно строить таблички. Вот как выглядит карточка книги из моей таны:

Поля автоматически возникают у любого буллета, помеченного тегом #book

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

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

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

Про Обсидиан и так все знают, поэтому сегодня мы говорим о первом варианте.

Один файл для всего

В дополнение к вышеописанному добавлю, что все-таки хотелось понять — насколько минимальным может быть сетап для задач и заметок?

В упомянутом посте «Сила простоты» я писал:

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

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

Почему файл всего один

1. Для облегчения поиска и снижения когнитивной нагрузки. Мне не нужно создавать отдельную заметку/файл для каждой встречи, задачи или проекта — всё живет в одном файле и мгновенно ищется полнотекстовым поиском VSСode.
2. Для простоты синхронизации. Файл лежит на гитхабе, ничего не весит и доступен с любого компа.

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

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

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

Как устроен файл

Ну раз у нас маркдаун, то можно навести некоторую иерархию. У меня она такая:

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

VSCode умеет показывать структуру файла по заголовкам, по ней можно сориентироваться.

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

- [ ]

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

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

Панель с поиском слева

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

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

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

И чо, удобно?

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

Единственная штука, которую очень хочется, это возможность менять режим отображения в файле, скрывая часть строк. Речь не про collapse/expand, это VScode умеет, пусть и только с мыши, я скорее про режимы отображения из OrgMode. Там можно было комбинацией клавиш циклически переключать вьюшки: показать всё, показать только задачи, показать только напоминалки, показать только заметки. Тогда можно продолжать вести записи в хронологическом порядке (единственный приемлемый для меня способ), но быстрее находить требуемое через нужную вьюшку.

Первый пост здесь: https://artemushanov.ru/?go=all/pro-knigu-shum/

Собрал заметки из канала в общий пост.

Про суждения (judgements)

Как они выносятся: эксперт изучает задачу/кейс, отмечает важные детали и опускает неважные, делает вывод — и выносит суждение.

1. Важность или незначительность деталей при вынесении суждения определяются интуитивно, если нет руководства или методики;
2. Эксперт не будет анализировать достаточность информации в задаче/кейсе и вынесет суждение на основе доступных данных — если к тому нет прямого указания;
3. Стремление к когерентности (последовательности, цельности) заставляет экспертов выносить суждение, даже если задача/кейс криво сформулированы и данных для вывода недостаточно;
4. Стремление к когерентности заставляет подгонять факты и логические шаги под зарождающийся вывод и следующее из него суждение, вместо устранения логических коллизий;
5. Любой эксперт может объяснить логику, по которой он вынес то или иное суждение, но почти всегда эта логика уязвима либо на уровне построения, либо на уровне аргументов.

Есть еще такой интересный вывод, подрезал у кого-то из западных рецензентов:

Суждение — это результат измерения, в котором инструментом послужил мозг

Это отсылает нас к книге, которую я всегда всем советую — «Как измерить все, что угодно» Дугласа Хаббарда. Там описывается практика калибровки экспертов для определения диапазонов допустимых значений.

Шум в индивидуальных и групповых решениях

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

См. видео On These Questions, Smarter People Do Worse

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

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

Мудрость «внутренней толпы» в 2-3 раза менее точна, чем настоящая мудрость толпы, но точнее единственного вынесенного суждения. Чтобы максимизировать ее точность, нужно придерживаться такого алгоритма:

1. Вынести суждение
2. Подождать 2-3 дня (сбросить контекст)
3. Вынести суждение еще раз, исходя из предположения, что первое суждение было неверным.
4. Взять среднее арифметическое первого и второго суждений.

Матмодели против экспертов

Дальше там, конечно, полнейший разнос.

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

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

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

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

1. Устранится изобретательность эксперта, т. е. его способность менять набор оцениваемых факторов в зависимости от кейса;
2. Устранится внутриэкспертный шум.

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

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

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

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

Например, эксперты составляли прогноз успешности соискателей на выбранной должности. По их мнению, точность прогнозов составляла 75-80%, то есть из 10 нанятых сотрудников восемь работают так же хорошо, как предполагали эксперты.

По факту точность оказалась в районе 28% (r=0,28) 💀.

Это мой текст с одного коллективного блога, ему примерно два года.

Иногда встречается такое утверждение:

«есть объективная правда и субьективная»

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки:
Ютуб
ВК
Рутуб

Мое понимание продуктового подхода:

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

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

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

Серии

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

Серия постов про книгу Рейнертсена The Principles of Product Development Flow. Книга рассказывает о том, как правильно разрабатывать продукты — на что обратить внимание, где сэкономить, как правильно выстроить управление. Потрясающе полезная и емкая, подойдет для разработки продуктов в любых доменах — от завода консервов до разработки ERP-систем.

Околоайтишное

Обзор статьи «A guide for finding product-market fit in B2B» Ленни Рачицкого со статистикой и графиками о том, как крупные компании свой ПМ-фит искали.

Продуктовый фреймворк Аркадия Морейниса — какие «альфы» (объекты внимания) нужно учести при выборе ниши и разработке продукта, в каком порядке действовать. Это авторское видение, скорее теоретическое, но во многом выглядит и звучит разумно.

Про джобс-ту-би-дан:
Применение Jobs To Be Done для адаптации учебного курса, неплохой пример подхода к конкретной прикладной задаче.

Подкаст Podlodka №337 — Поиск целевой аудитории — Иван Замесин рассказывает про свой подход к поиску ЦА и формирование ценности в виде снижения транзакционных издержек на исполнение клиентского «джоба».

Видео «Теория и практика Jobs to be Done» — как проводить JTBD-исследования, опыт агентства UXSSR.

Пост «Что нужно клиенту — дрель или дырка в стене?» — заочно дискутирую с Евгением Казначеевым про иерархию JTBD.

Прочее

Что не так в посте продакт-менеджера? — длинно и нудно комментирую короткий и бестолковый пост продакт-менеджера.

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

Короткий абзац про пасту Campotti, которую авторы придумали примерно с тем же мотивом, что и Дэн Пашман: улучшить опыт употребления.
Цепочка создания кофе — supply chain кофе, от плантации до кофейни у вас за углом. С цифрами и ценами.

Пообщались с Динарой Камоловой — обсудили управление процессами и всякие связанные штуки.

Смотреть на других ресурсах: на Ютубе, на ВК, на Рутубе.

Основные инсайты:

1. Блок-схема — не единственный способ репрезентации процесса; еще есть табличный вариант (SIPOC) и структурированный текст
2. Основная ценность стандартизованных процессов — снижение вариабельности при достижении того же результата
3. Переход на процессное управление нужен для масштабирования и снижения издержек
4. Три полезных вопроса при обнаружении отклонений: есть ли стандарт (для этой операции/процесса)? Соблюдался ли стандарт? Адекватен ли стандарт?
5. У процессов есть пререквизиты (обязательные условия для старта) и выходные метрики — эффективность, результативность, удовлетворенность
6. В первую очередь нужно моделировать и разбирать те процессы, которые во-первых задействованы в цепочке создания ценности, во-вторых — затрагивают несколько бизнес-юнитов.

Упоминаемые книги:

• «Выход из кризиса» — У. Деминг
• The Principles of Product Development Flow — Donald Reinertsen (серия моих постов)
• «Как измерить все, что угодно» — Дуглас Хаббард
• «Система разработки продукции в Toyota» — Лайкер, Морган

Ссылка на доску, на которой мы рисовали: https://app.holst.so/share/b/76ca188e-4b23-4174-b888-205ae27b2eff

Канал Динары про процессный подход: https://t.me/DK_ProcessThinking

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

Лексикон городского и сельского хозяйства. Часть 6 — Москва, 1837 ©

Бионические шрифты

В Бюро Горбунова совет про бионические шрифты: https://bureau.ru/soviet/20250211/
Это способ представления текста в таком виде, когда начало слова пишется полужирным, а вторая половина слова — обычным. Полужирные части образуют в тексте визуальные якоря, по которым прыгает взгляд читателя. Якобы так текст читается быстрее.

На этом сайте есть расширение для хрома: https://bionify.xyz/
На этом — несколько приложений: https://bionic-reading.com/#

В 2021 году я писал про пару модификаторов текста — один из них перекрашивает текст для ускорения чтения, другой, напротив, осложняет чтение для лучшего запоминания: https://artemushanov.ru/?go=all/chto-ya-uznal-v-sentyabre-2021/#beeline

Как пилить эксельки

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

Чтобы эту неурядицу устранить, рекомендую два простых приема:

1. Все параметры, участвующие в вычислениях, вынести в отдельные ячейки и поименовать. В формулах не должно быть просто чисел — только параметры. Тогда таблица будет состоять из пары областей: параметры и вычисления, разобраться будет проще.
2. Завести changelog на отдельном листе и вписывать туда все вносимые изменения. Поменялись данные и нужно пересчитать? — поменяли, пересчитали, записали в свободной форме в ченджлог. Убрали часть расчетов? — ок, записали в ченджлог с мотивировкой. Так вы вспомните, что и когда происходило с экселькой, даже если вы каждую версию в отдельный файл сохраняли.

В чем неправ Максим Дорофеев?

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

Максим утверждает, что для эффективного решения задач нужно:

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

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

Terms of Use сотен компаний для референса

https://www.tosabout.com/

На ресурсе по ссылке собраны Terms of Use нескольких сотен компаний/продуктов из разных отраслей, от Эпла до Майнкрафта. Они удобно расфасованы по категориям, по каждому документу есть оценка по трем секциям: “хорошие” пункты, “плохие” и “уродливые” (good, bad, ugly, да).

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

Пожелания к разработчикам приложений

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

1. Переделывая иконку приложения под новогоднюю тему — оставляйте ее узнаваемой. Узоры, еловые ветви, шарики и новогоднее настроение не радуют, если они мешают мне найти нужный апп за секунду.

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

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

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

Умер Девид Линч

Первым фильмом Линча для меня был «Малхолланд Драйв». Я был юн, неопытен и от увиденного у меня капитально сорвало крышечку. Года три или четыре назад я был в Москве, и мы небольшой компанией ходили на ретро-показ МД. В зале была в том числе молодежь, что меня удивило. У молодежи тоже сорвало крышечку: пара из парня и девушки, услышав, как мы обсуждали фильм (некоторые из нашей компании смотрели его впервые), обратились с просьбой объяснить, что они только что посмотрели.

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

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

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

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

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

Покойтесь с миром, Дэвид, спасибо вам.

Посидел в «Сетке» и понял

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

Потому что меня БЕСИТ писать длинные тексты с телефона. Если можно не писать — не буду писать. Ничего не могу с этим поделать.

Сетка именно такая: там можно писать длинные посты (редкость в наше время), но нельзя зайти с компа.

Пишущая машинка

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

Нашел на Авито Olivetti ET Personal 540 ii и съездил посмотреть.

1. Бахает она при печати сильно, причем звук такой, будто электроразряд какой-то.
2. Клавиатура нормальная, стандартная, кроме буквы «Ё» и того факта, что цифры печатаются с шифтом, а знаки препинания и прочие проценты — без; навыки слепой печати работают, раскладка стандартная.
3. Много странных клавиш по бокам, все они похожи на Tab, но другие. Вроде бы они нужны для управления набором «в память», когда печать идет на однострочном дисплее, на нем же правится, а потом отправляется в работу и автоматом печатает строку уже на бумаге.
4. Двуязычная, это большой плюс. Механических пришлось бы купить две штуки: с кириллицей и латиницей
5. Слепая печать получается даже если вы ей не владеете: набираемую строку тупо не видно. Ну ладно, видно верхний край букв. То ли надо высоту стула подбирать, то ли привыкнуть, то ли машинка бракованная.
6. Умеет стирать набранную на бумаге последнюю строку (!), если не была переведена каретка — по памяти запечатывает буквы белой краской.

Расходники — ленту и т. п. — можно купить до сих пор.

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

Покупать передумал.

Рыбный экотеррорист

Ссылка на оригинал

Потрясающая история. Некоторый чувак за двадцать лет (с 1964 по 1984) поменял озёрную и речную фауну Новой Зеландии, нелегально привозя и выпуская на волю рыбу из Британии — по причине «пипец в НЗ скучно рыбачить». Вел подробный дневник с описанием своих злодеяний. Его арестовывали, изымали рыбу, потом отпускали — а он снова брался за свое.

Ты не рыбак, ты не поймешь.

Увидел в канале Евгения Казначеева.

Практические улучшительства

https://practicalbetterments.com/

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

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

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

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

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

© practicalbetterments.com

Другие лайфхаки:

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

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

Принцип единого источника в конструкторе договоров

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

Или не в ворде, без разницы.

Death Stranding

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

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

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

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

Но два раза ходить — ни за что. Только лох два раза ходит.

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

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

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

Ближе к финалу меня настигло прозрение: Death Stranding по смыслу и посылу похожа на Вангеров, одну из лучших игр в мире (Кранк 😿). Там мы тоже курьеры, возим жизненно важные грузы между городами-эскейвами и восстанавливаем связь между мирами, пока остальные отсиживаются под землей.

Indiana Jones and the Great Circle

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

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

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

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

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

Свежие посты

• Подборка постов про экономику: https://artemushanov.ru/?go=all/podborka-postov-pro-ekonomiku/
• Новый пост по Рейнертсену, про очереди: https://artemushanov.ru/?go=all/the-principles-of-product-development-flow-post-5-ocheredi-i-cap/
• Два поста в новой рубрике «спорю с интернетом»: один про псевдоэкпертный пост-филлер продакта, второй про странный заход «проектный подход больше не работает»
• Пост про книгу «Шум» Канемана и соавторов: https://artemushanov.ru/?go=all/pro-knigu-shum/
• Пост про экономику невостребованных подарочных карт: https://artemushanov.ru/?go=all/ekonomika-nevostrebovannyh-podarochnyh-kart/

Короче

• Кликер с популярными способами прокрастинировать: https://neal.fun/stimulation-clicker/
• Очень плохие постеры к фильмам: https://deadly-prey-gallery.myshopify.com/products
• Антон Гладкобородов сделал «ноушн для математических записей». Считать пока не умеет, только записывать, но делает это удобно. Если скопировать оттуда формулу или выражение — можно вставить в любой другой редактор как латекс: http://corca.app/
• Прунинг — процесс отмирания нейронов у людей в подростковом возрасте. С этим связывают утрату детских воспоминаний (у новорожденных примерно вдвое больше нейронов, чем у взрослых)
• Пост Евгения Казначеева про книгу Sweating Bullets, о разработке и выходе на рынок PowerPoint: https://t.me/qetzal_1up/1156
• Чатгпт без впн: https://duckduckgo.com/?q=DuckDuckGo+AI+Chat&ia=chat&duckai=1
• Китайская нейросетка от, кажется, алибабы, не хуже дипсика: https://chat.qwenlm.ai/
• Бесплатные математические инструменты: https://www.geogebra.org/
• Онлайн-тулза для диаграммы Sankey: https://sankeymatic.com/build/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

upd. второй пост: https://artemushanov.ru/?go=all/esche-pro-knigu-shum-danielya-kanemana/

🔬 Это пост с разбором очередной части книги Дона Рейнертсена 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, влияние изменения цены на изменение прибыли (вы удивитесь, насколько скидка снижает прибыль), три уровня управления ценами. Книжку после этого забросил, но вернусь.

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

• Блокчейн — орудие сатаны: финансовый смысл греха, уничтожение долговых записей и блокчейн на службе сатаны
• Еще про «Долг» — МВФ, меновой экономики никогда не было, как в Китае изобрели налоги.