Еще раз поговорим про факторы успешности проектов, с большим упором на теорию задержки решений. Пост loosely based на моем выступлении в декабре 2025, слайды оттуда же.

Decision Latency

Контекст: Стендиш груп (про которую я уже писал в контексте их отчетов CHAOS) в 2015 году ввели понятие «выигрышной комбинации» — набора факторов, которые могут быть предикторами успеха проекта. Я разбирал их в посте Факторы успешного проекта × OMG Essence.
В 2018 они ввели в обиход понятие Decision Latency (задержка принятия решений) и одноименную теорию, с общим мотто:

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

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

Из отчетов группы следует, что если в проекте решение принимается примерно за час — вероятность успеха такого проекта уже в районе 58%, без учета прочих факторов. Если же решение принимается пять часов или более — вероятность падает в три раза, до 18%.

«Задержка решения» — это интервал времени между моментом возникновения потребности в решении и моментом, когда решение принято и исполнитель может продолжить работу.

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

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

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

Короткий импровизированный спич со слайдами из другого выступления:

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

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

Один из вариантов трекера решений

Выигрышная комбинация и влияние на задержку

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

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

«Король» — это эмоциональная и проектная зрелость заказчика (Emotional Maturity / The Good Place — два фактора). Если в компании заказчика зрелые процессы, то можно обсуждать проблемы, можно быстро принимать решения, подход к решению таких вопросов чаще децентрализованный, чтобы делегировать решения на более низкие уровни не упираться в загруженность и когнитивный ресурс ключевых лиц.

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

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

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

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

Ну и наша «десятка» — гибкий процесс. Использовать короткие итерации, быстро получать обратную связь, быстро находить и исправлять ошибки. Среди указанных факторов он самый слабый, но при этом использующие его команды чаще успешно завершают проекты: шанс на успех проекта 42% против 13% у практикующих Waterfall.

Если посмотреть сводные данные из отчетов CHAOS, то увидим следующее: успешных проектов с эджайлом — 42%, проблемных — 47%, провальных — 11%; с вотерфолом успешных 13%, проблемных 28%, провальных — 59%.

Выводы

Что хочется подчеркнуть. Из пяти «карт» две сильнейших — на территории заказчика. Из этого два важных следствия:

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

Настаивайте на уменьшении скоупа: разработку одной большой системы лучше распилить на 3-4 проекта и делать их последовательно.

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

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

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

Трек месяца — Eraser by HVOB:

Воспоминания о Персии 1834—1835 — Ф.Ф. Корф ©

Заработок на зэках

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

Первый тип — это b2g, госконтракт на оказание услуг в учреждениях ФСИН. Государство платит, услуги оказываются заключенным, содержащимся в учреждениях.

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

Красивая схема, необычная. Но будто бы уязвимая.

Иллюстрация «пространства решений»

Когда-то давно написал пост про две стратегии решения задач — алгоритмическую и брутфорс.

А недавно мне попалась статья BREAKTHROUGH THINKING WITH TRIZ FOR BUSINESS AND MANAGEMENT: AN OVERVIEW, и там есть отличная иллюстрация того, что я пытался выразить в посте.

Очень странно, что я не вспомнил про ТРИЗ, когда писал пост — это ведь по сути портфель алгоритмических стратегий.

Еще про Decision Patterns

На рутубе на меня случайно выпрыгнуло видео, где Джон Фитч рассказывает про Decision Patterns (мои посты про фреймворк). Кто и зачем его туда загрузил — не знаю, но спасибо ему.

В видео — самые основы, но есть интересное, чего я не увидел в статьях. Например, что четыре базовых паттерна мышления (Situation Appraisal, Problem Analysis, Decision Alanysis и Potential Problem Analysis) Джон взял из книги The New Rational Manager.

Гарнитура Plantronics

Мой хардвер-стек для звука незамысловат: sony wh-1000xm3 для офиса, wf-1000xm4 для использования на ходу. Мне не хватало хорошей гарнитуры для общения на ходу — сони вф хорошие, но в них я обычно слышу собеседника лучше, чем он меня.

Почитал, поизучал, купил себе специализированную гарнитуру Plantronics Poly 5200 UC.

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

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

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

Гарнитура JLab GO Work Wireless 2nd Gen

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

Как ускорить анимацию дока в макос

Я переехал с конфигурации «Макбук эйр плюс монитор 27 дюймов» на конфигурацию «Мак-мини плюс монитор 34 дюйма» и перенес док на правый бок экрана, а потом и вовсе спрятал его.

Один минус: у него раздражающе медленная анимация появления.

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

defaults write com.apple.dock autohide-delay -float 0; killall Dock

Можно немного замедлить, чтобы осталась анимация:

defaults write com.apple.dock autohide-time-modifier -float 0.15; killall Dock

Вернуть к дефолту:

defaults delete com.apple.dock autohide-time-modifier; killall Dock

Resident Evil: The Village

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

Два раза не повторяю, два раза не повторяю — updated

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

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

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

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

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

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

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

Когда я максимально эффективен

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

У меня есть три типа ситуаций, в которых я могу быть МАКСИМАЛЬНО эффективным:

1. Готовлюсь уезжать (в командировку, в отпуск, куда-то)
2. В командировке по делам
3. Вокруг кошмар и кризис, все бегают и хватаются за голову

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

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

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

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

Во-первых, можно считать «вещью» турникет, оборудованный софтом компании (которые затем составляют набор/set/collection турникетов парка). Это самый очевидный вариант, который выделяется так: ищем физический объект, который выполняет какую-то функцию и приносит тем самым пользу. Физический объект — турникет с софтом, функция — отслеживаемый контроль доступа к аттракциону или парку (предоставляем доступ оплатившим и отказываем в доступе не оплатившим). Турникет обеспечивает контроль доступа и без этого софта; конкретно этот софт даёт характеристику «отслеживаемости» — можно отследить, кому и когда был предоставлен доступ. Посетителю парка (с уникальным ID) выдается карта (с уникальным ID), карта используется во время визита в парк, можно отследить, какими аттракционами пользовался, в каком порядке (те простроить клиентское путешествие по парку), потом на основе данных сделать выводы о том, как парку увеличить доход с посетителя. Польза — возможность увеличить доход с посетителя.

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

Получаем софт как «нашу вещь» и «турникет с софтом» как целевую вещь. Продаём софт для турникетов, покупатели платят за софт. Всё? Как бы не так...

Ну и далее по ссылке: https://t.me/selfdiscipline/111

У нее же про пользу (https://t.me/selfdiscipline/103):

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

Старый девиз на латыни

Евгений Казначеев предложил в своем канале перевести любую фразу на латынь.

Я написал ему:

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

Он ответил:

Antea maiora defecimus
Точно прям мне на текущем уровне пока не перевести. Эта фраза применено про то же, переводится как «прежде мы терпели неудачу в большем».

Динамические поворотники

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

Книга Ольги Павловой

У Ольги Павловой («Собака Павлова» — разрабатывают сложные интерфейсы) вышла книга «Я хочу сделать хороший дизайн продукта». Прочитал около 100 страниц, про дизайн пока очень мало, зато много — про контекст дизайна: стейкхолдеров, управление проектами и аджайл.

Книга прикольно структурирована: к каждой главе есть TL;DR, указание на пользу главы для определенных проектных ролей, ссылки на советы и кейсы в удобном коротком формате.

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

Пьесы и книги Дмитрия Данилова

На Данилова меня вывела прикольная ассоциативная цепочка: я посмотрел «Бугонию», и финальная сцена показалась мне нечаянной реминисценцией на финальный же куплет трека Славы КПСС «Конец зла» (ютуб).

В Genius я прочитал, что трек сильно напоминает посылом, настроением и даже конкретными фразами стихотворение Дмитрия Данилова «Три сантиметра». А Дмитрий Данилов известен пьесой «Человек из Подольска», по которой сняли фильм, я писал о нем.

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

Буду читать «Сережа очень тупой».

Мое выступление про ментальные модели

Выступил на конференции «Что и требовалось доказать» с темой про ментальные модели:

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

Голосовуха про Маккиавелли и этику

Короче

• https://sketchplanations.com/ — короткие комиксы с объяснением разных фактов о мире
• вновь открыл для себя подкаст Вафина — см. например выпуск про неолитический переход; крючочек: после перехода на оседлый образ жизни с возделыванием земель люди стали жить хуже с т.з. разнообразия питания и болезней, и только в конце 19 века (!) смогли догнать по этим показателям охотников-собирателей
• в канале Темы Субботина увидел телепромптер, который работает из «брови» макбука и с помощью нейронки «ведет» тебя по тексту — https://github.com/f/textream
• У меня в квартире теперь три увлажнителя Fanline и один Breeeth Natural на батарею. Не берите ультразвуковые — только барабанные, только хардкор.

Ильяхов писал про такую штуку:

1. У любой задачи есть срок жизни по умолчанию, например, 1 неделя
2. Через неделю она становится полупрозрачной, а еще через 5 дней полностью исчезает из инбокса с глаз долой, без твоего участия. Она попадает в какой-то скрытый раздел, куда ты по умолчанию не ходишь. 
   То есть однажды ты просыпаешься, а этой задачи просто нет, и хрен с ней.
3. Если ты что-то сделал с задачей — что-то в нее дописал, как-то ее дрочнул — срок обнуляется и она живет еще неделю.
4. Если тебе позарез нужно будет найти старую задачу, ты найдешь ее в том самом скрытом разделе. Но ты должен помнить какие-то ключевые слова, чтобы ее найти

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

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

Как бы я сделал, в сильно расширенном варианте:

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

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

С 2023 я пользуюсь системой Johnny.Decimal (далее j.d) и полностью доволен. Расскажу, что это такое и зачем нужно.

Что мы вообще храним?

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

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

Что важно при хранении файлов

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

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

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

Фиксируем для порядка два юзкейса и требование:
ЮК1. Найти файл, когда он нужен
ЮК2. Сохранить файл так, чтобы его потом можно было найти
Т1. Система хранения должна поддерживать множество проектов

Система Johnny Decimal нужна ровно для этих юзкейсов.

Как устроена система Johnny Decimal: правила

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

Начнем с правил. Они описывают подход к организации папок, в системе он строго иерархичный.

Папки организуются по уровням:
Уровень 1: Область; обозначается диапазоном двузначных чисел и именем; все диапазоны должны поместиться в общий диапазон от 0 до 99 — система ограничена таким количеством идентификаторов.
Уровень 2: Категория; обозначается двузначным числом и именем
Уровень 3: Айдишник (ID); обозначается именем и двухчастным идентификатором вида «СС.ID», где СС — номер категории, ID — число от 00 до 99.

Общие правила:

1. Области, категории и айдишники — это всегда папки;
2. В областях — только папки категорий, в папках категорий — только папки айдишников, в папках айдишников — файлы
3. Еще раз: файлы можно хранить только в папках айдишников! В папках областей и категорий файлы хранить нельзя
4. Нумерация должна совпадать с иерархией: CC айдишника совпадает с номером категории, номер категории входит в диапазон области
5. Структура хранения полностью отражена в индексе.

Таким образом, структура получается примерно такая:

Личное и семейное — это область, куда входят категории с 11 по 19; в этой папке могут быть только подпапки. Мои документы — это категория в рамках области, в этой категории может быть сто айдишников, от 11.00 до 11.99, это тоже папки. Ну и наконец 11.01 Паспорт РФ — это айдишник, папка для файлов. Там, как несложно догадаться, лежат сканы паспорта.

Что нам дает такая организация? Зная, что сканы и другая инфа про паспорту лежат в папке 11.01, я могу легко найти ее в хранилище: найти по имени папки или просто снавигировать по структуре — из айди понятно, что она лежит в категории 11, которая лежит в области 10-19.

Как я узнаю, что паспорт — именно в папке 11.01? Из самой важной части j.d — индекса.

Индекс

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

Правила работы с индексом:

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

Я свой индекс храню в виде текстового файла на гитхабе. Он состоит из трех разделов: сам индекс, перечень хранилищ и журнал изменений.

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

Индекс — центральный элемент системы, без него ничего не будет работать.

Важность этого понимания хорошо демонстрирует вот этот комментарий к нашему звонку-вебинару по j.d:

Хранилища

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

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

Я указываю хранилище в скобках после названия папки — в данном случае это яндекс.диск (yd = yandex drive):

Хранилище указано для категории 11 Мои документы — это означает, что все входящие в категорию папки лежат на нем, если для конкретной папки не указано другое хранилище.

Пример:

13.14 Машина Kia Seltos + мануал + страховка полис (yd, gk, ob)

Инфа по машине лежит на яндекс.диске (файлы, сканы и т. п.), в гугл кипе (ссылки, короткие заметки), в обсидиане (журнал техосмотров, журнал ремонтов). В моем случае примерно понятно из контекста, что в каком хранилище, но в целом в поисках нужной информации не так и долго посмотреть во всех трех. Релевантные заметки в обсидиане и гугл кип помечены тегом #jd и в заголовок у них вынесен айдишник 13.14, полнотекстовый поиск находит их за полсекунды.

Все хранилища записаны в файле с индексом, список выглядит примерно так:

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

Как вести проекты

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

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

В 2023 автор методики Джонни предлагал делать так:

1. Заводить «проектные области», которые обозначаются буквами: у меня «A» — это проекты Алемиры, моего работодателя в 2023
2. Двузначным числом после буквы обозначать конкретный проект: A01 — проект по разработке Classrooms, одного из продуктов Алемиры
3. Далее — та же структура `Область/Категория/ID` — в итоге получается примерно такое:

И так далее еще на 130 строк

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

Короче, подход неудобный и я его не рекомендую.

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

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

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

Как я работаю с системой

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

В файле индекса у меня живут:

1. Структура системы с указанием хранилищ — для этого индекс и нужен
2. Список хранилищ с короткими идентификаторами (Яндекс.диск — yd), чтобы указывать их напротив айдишников/категорий/областей
3. Журнал изменений системы и индекса — чтобы не забыть какие-то важные штуки про сам индекс, айдишники, хранилища или еще что-то в отношении системы.

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

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

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

Джонни рекомендует использовать айдишники начиная с ХХ.01, а ХХ.00 зарезервировать для меты по этой категории. Этой рекомендации я следую, и мне это пригодилось в паре случаев.

Не все хранится в файлах. Заметки я веду в Obsidian (лонгриды и хранение текстов по дефолту) и Apple Notes (то, что может понадобиться на ходу или с телефона).
Если под айдишником всего одна заметка — айдишник я прописываю прямо в название в квадратных скобках: [16.19] 2026-01 Москва, Хайп (17-24 января). С квадратными скобками их легче искать. Также я прописываю тег #jd в каждой такой заметке, чтобы можно было найти их одним списком.
Если под айдишником несколько заметок — я создаю в заметочнике папку по всем правилам и кладу заметки в нее.

Изредка я меняю структуру хранилища, чаще — сами хранилища. Я забирал все личное из Дропбокса в Некстклауд, потом перенес в Яндекс.диск, и отразить эти изменения в индексе занимало минут десять.

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

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

Хорошим способом прокачать j.d кажется использование тегов. Я писал про другого увлеченного чувака, Карла Войта, который написал кандидатскую на тему tag trees, у него много любопытных мыслей, но главный мой вывод все-таки следует из j.d: тегам тоже нужен центральный индекс! Кажется, мне именно этого не хватало, чтобы работа с тегами приносила пользу, а не гемор. К этому я пока не перешел, но планирую.

Ссылки и заключение

Джонни недавно решил сделать воркбук по системе бесплатным, почитать об этом и забрать можно тут: https://jdcm.al/20-29-communication/22-blog/22.00.0148-the-workbook-is-free/

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

Звонок-вебинар с неструктурированным обсуждением системы я выкладывал тут: https://artemushanov.ru/?go=all/vebinar-po-j-d-kak-hranit-i-organizovyvat-fayly/

Доска, которую я показывал на вебинаре, тут: https://app.holst.so/share/b/a762870f-458e-452f-a067-0ab496d2f0ab

На ней же выложен мой индекс-файл для ознакомления.

Апдейт: выложил в канале архив c настроенной самим Джоном системой организации личных файлов — Life Admin System. В архиве сами папки, мануалы и обяснения.

История продвижения баточника Сникерс в России — каноничная с точки зрения создания новой ниши на новом рынке под существующий продукт.

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

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

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

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

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

И русского человека стали учить.

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

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

В конце 90х Марс перешел в BBDO, где им и придумали гениальную концепцию «не тормози, сникерсни», которая сработала тогда и работает до сих пор.

Можно выделить три этапа восприятия Сникерса потребителями, три разных «джоба»:

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

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

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

Сколько это стоило — создать новую нишу и «перепрошить» потребительское восприятие? И что это дало?

В 1995 году Марс тратил на рекламу около 20 млн долларов при выручке около 300 млн долларов в год. В том же году был построен завод в Ступино (150 млн долларов). Рынок России стал самым быстрорастущим и прибыльным за всю современную историю компании.

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

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

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

Проект продукту не враг

Ведущий сходу говорит «а давайте-ка проясним — что такое продуктовое мышление и зачем оно фронтендерам?». Один из участников начинает стандартную историю:

...И продуктовое управление, оно в большей степени про развитие в зоне неопределенности, когда мы не знаем, как сделать правильно. И когда у нас нет какого-то даже внятного первоначального образа результата, и нам нужен этот образ результата откуда-то придумать и его получить.
...Единственный способ туда идти, это эмпирически. Сделал шажочек, который видишь, порефлексировал, понял, что дальше, второй, третий, пятый, и в какой-то момент…
...И потом уже появляется там понятный родмэп, и где-то там уже местами может быть переход в то же самое проектное управление...

Ответа на вопрос «что такое ПМ» нет, логика «продуктовое управление является эволюцией проектного подхода для работы в условиях неопределенности» неверна, так как у двух озвученных подходов — разный предмет интереса:

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

Продуктовый подход нужен для управления ценностью продукта через эволюцию, в коммерческих компаниях он нужен для обеспечения коммерческого успеха по Рейнертсену, решения принимаются с точки зрения влияния на прибыль жизненного цикла (life‑cycle profit impact/LCPI).
Проекты в продуктовом контексте — упаковка части работ в поставку фиксированного изменения продукта, цель — сделать поставку, решения принимаются с точки зрения обеспечения ценности заказчику с учетом ограничений.
Что делать — это продуктовое решение, как именно это сделать быстро и эффективно — набор проектных решений.

Если продукт — это кофемашина, то проект — это разработка и запуск модели v2 к определённой дате

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

Мышление и подход

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

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

Голодный человек видит в батончике «Степ» способ быстро перекусить, а голодный человек с продуктовым мышлением — еще и коммерческий продукт, который кто-то придумал, разработал, протестировал, вывел на рынок. Батончик конкурирует с другими батончиками на полке, продаётся, приносит маржу и требует решений о развитии.

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

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

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

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

Инварианты в продуктовом подходе

Каждый тип «подхода» вводит ряд постоянных понятий и свойств, вокруг которых организуются методы работы с ними.

В продуктовом подходе я бы выделил следующие:

1. Объект управления — продукт на горизонте жизненного цикла (от замысла до вывода с рынка).
2. Развитие продукта происходит через замкнутый цикл изменения и обучения, работающий по логике PDCA и встроенный в регулярную работу. Выстроены петли обратной связи.
3. Успех определяется через фактические выгоды и их проверку (outcome), а не через рабочие продукты или выполнение запланированного объема (outputs). Главная метрика — lifecycle profit.
4. Эмпирический подход: мы не путаем карту с территорией, объект с его описанием, поэтому решения принимаем на основе эмпирической информации из реального мира, а не только из рассуждений/презентаций. Пользу теорий, аналитических данных и гипотез мы признаем, но понимаем их ограничения.

Про метрики

Позже в видео обсуждают метрики:

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

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

Дальше Саша Ложечкин рассказывает про компании, работающие по моделям «топ-даун» (визионер всем говорит, что делать) и «боттом-ап» (компания как венчурный фонд, финансирующий инициативы сотрудников). Это хороший заход на различение «продуктового результата» (денег!) и «проектного результата» — пакета поставки. В боттом-ап компании, рассматривающей инициативы сотрудников как потенциальные продукты или продуктовые изменения, никто не даст денег-времени на реализацию MVP без минимального коммерческого обоснования. Которое придется давать на продуктовом языке и приводить к LCPI. То есть, в таких компаниях продуктовое мышление придется развить.

В предыдущих сериях

С неверностью дихотомии «проектный подход vs продуктовый» я уже спорил в старом посте, про типовые ошибки рассказывал в видео с обзором текстов и постов, про свое отношение — рассказывал в зум-вебинаре с Динарой и подборке постов про создание продуктов.

Фреймворк OMG Essence

Эссенс придумал Ивар Якобсон, автор UML и юзкейсов. На верхнем уровне фреймворк определяет три области интересов, в которых расположены семь «альф» — абстрактных отражений разных аспектов проекта.

Области: клиентская, инженерная, менеджерская.
Альфы: стейкхолдеры и возможности; описание и воплощение системы; команда, метод работы и сами работы.

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

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

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

Факторы успеха из отчета CHAOS

До 2020 года исследовательская группа Standish Group выпускала отчеты-исследования CHAOS о проектах разработки софта. Отчет строился на основе собственных исследований: группа собирала данные с большого количества проектов в разных отраслях (я встречал цифру в 50 000 проектов), проводила интервью с проектными командами, руководителями и клиентами, и делала выводы.

Я делал посты про отчет 2018 и отчет 2020 года.

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

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

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

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

Decision Latency

Decision Latency — это разница во времени между моментом идентификации необходимости принять решение и моментом принятия этого решения. Главный тезис из отчета: The value of the interval is greater than the quality of the decision.

Можно разложить DL на три составляющие:

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

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

Способы повлиять на эту метрику лежат в альфе «метод», но затрагивают все остальные: необходимость принять решение может возникнуть в рамках любой из альф. Поэтому рабочей схемой кажется разработка общего подхода к принятию решений с адаптацией под конкретные ситуации. Так же будет полезно завести табличку и трекать все три стадии, чтобы понять — хорошая на проекте DL или нет. В доке https://archives.obm.ohio.gov/Files/Major_Project_Governance/Resources/Resources_and_Templates/03_Initiate/26_Tracking_Decision_Latency_Guidance.pdf есть такой перечень полей для таблички:

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

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

Про децентрализацию много пишет Рейнертсен (мои посты про его книгу), а «решениям» как двигателю проекта посвящен фреймворк Decision Patterns Джона Фитча (два поста о нем).

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

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

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

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

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

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

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

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

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

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

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

Проект должен управляться по аджайлу

Тут довольно очевидно: это альфа «метод» (way of working), у команды должны быть наработаны практики работы по аджайлу. В приоритете — альфа «система» и ее соответствие ожиданиям стейкхолдеров, именно этому должен быть подчинен весь цикл от сбора и анализа требований до релиза.

Практический вывод: если вы не строительная организация — закопайте и не разрешайте выкапывать «водопад».

Команда должна хорошо уметь в аджайл и в технологии

Ядро Essence Kernel состоит из трех типов элементов: области активности, альфы и оргспособности (capabilities). «Хорошо уметь...» — это про оргспособности.

В Essence описываются шесть типов оргспособностей:

1. Stakeholder Representation
2. Analysis
3. Development
4. Testing
5. Leadership
6. Management

Упомянутые в принципе умения касаются анализа, разработки, тестирования и управления, а альфы «Метод» и «Команда» — это скорее контекст их использования.

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

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

Быстрая заметка из моего канала.

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

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

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

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

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

Ссылки на другие платформы:

• https://vkvideo.ru/video-232921620_456239017
• https://youtu.be/tOXybnkIqd0
• https://rutube.ru/video/10d5c71ee562c3d0ec05cf86b99960de/

Упоминал ранее j.d тут и тут.

Текстовая версия тут: https://artemushanov.ru/?go=all/sistema-katalogizirovaniya-johnny-decimal/

Пион пишет:

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

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

Я стал думать — а умею ли я работать из состояния «затрахан вусмерть», и сделал вывод, что проверять не хочется.

А потом вспомнил.

Готовимся к командировке

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

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

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

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

Ну и вот накануне вылета в Москву началось.

Почти готовы

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

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

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

Макс пожал плечами и согласился. Второй Макс, программист, посопротивлялся, но потом согласился.

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

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

Макс достал заготовленный вискарь, и началось томительное ожидание.

Один по цене двух

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

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

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

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

Инженеры переезжают в другой офис, побольше

Цирк

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

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

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

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

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

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

Гости сочли хорошей идеей оставить свои бокалы на устройстве

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

Тут должно стать понятно, при чем тут пост Пион из начала поста: на этот момент мы (ну ладно, я) не спали около суток.

Путь в Красногорск

Собрав и упаковав четыре девайса, мы тащим их на улицу, там грузим в машину Ромы (один из наших). Рома живет в Красногорске, мы в машину уже не помещаемся — «езжайте на автобусе, пацаны, Миша знает адрес».

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

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

Грузимся, едем, приезжаем, падаем спать. Время — полтретьего ночи.

Второй раунд

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

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

Я стал думать — а умею ли я работать из состояния «затрахан вусмерть», и вспомнил, что когда-то умел.

Разбирал фотки в гугл облаке, наткнулся на вот эту и разблокировал воспоминание:

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

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

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

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

Во-вторых, ходить приходилось пешком, много.

Ну и в-третьих, когда разносили пенсии — был риск подвергнуться нападению.

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

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

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

Сначала мы съездили на ночную сортировку. Сотрудники разбирали пришедшую почту и раскладывали по зонам развоза.

Потом мы поехали на развоз — следующим вечером. Мы ездили за почтовой буханкой и наблюдали за процессом.

Ящики с почтой на полу «буханки»

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

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

Как-то так выглядело

Автор инициативы Светлана спустя пару недель на звонке сказала, что руководство не поддержало проект.

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

Гигант этот, к сожалению, просрал все свои шансы и допустил появление конкурентов вроде Сдэка, Боксбери и служб доставки маркетплейсов. А мог бы оседлать этот тренд и верхом на нем ворваться в новую прекрасную эру.

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

Из этой точки зрения следует другая точка зрения — что в работе, в рабочем контексте, нужно давать новичкам совершать ошибки, даже стремиться к этому, и тогда они быстро научатся правильной работе. Марк Цукерберг, не последний человек в мире, даже ввел рабочее мотто «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 — моей системы организации файлов и заметок (upd. пост про систему — по ссылке). Индекс мне нужен для того, чтобы вспомнить, где лежит некоторый файл, или записать новую папку для хранения. Сейчас это обычный текстовый файл на гитхабе, хотя сначала я чрезмерно усложнил работу с ним — вел в заметочниках, с кучей категорий и папок. В итоге перешел на ведение 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) 💀.