У ГП в лекции «Организация, руководство, управление» есть такая байка про Вторую мировую:

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

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

«Бич Атлантики» Focke-Wulf Fw 200 Condor © By Bundesarchiv, Bild 146-1978-043-02 / CC-BY-SA 3.0, CC BY-SA 3.0 de

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

Для чего зенитки ставили на грузовые корабли — разве не сбивать самолеты? Нет, у кораблей другая задача: доставить груз (и сам корабль с экипажем) до места назначения в невредимости. Именно на эту цель и работали зенитки: они снижали риск быть потопленными бомбардировщиками.

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

Установка зенитки на транспортный корабль © Блог Royal Marines History

Правильными метриками должны быть следующие, в таком порядке:

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

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

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

Итак, пост приводит нас к очевидному выводу:

Плохая метрика хуже, чем отсутствие метрики

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

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

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

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

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

На пост его вдохновил вопрос подписчика:

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

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

• никакого «продуктового мышления» нет, есть просто «мышление»
• агент с сильным мышлением ставит цель, строит план и меняет кусочек мира; цепочка «цель → модель мира → симуляция → действие» — это и есть продуктовое мышление
• (неявно) научить продуктовому мышлению нельзя

Женя в теме, занимается продуктами довольно давно (главный по продукту в ecwid), много и обстоятельно пишет про важные в контексте созидательной деятельности штуки (ментальные модели, рациональность, математика), но в его объяснении отсутствует большой и важный для обсуждаемого вопроса кусок.

Поэтому буду спорить 🤷‍♂️

Тезис: продуктового мышления нет

Сначала цитата, с которой я согласен:

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

Она нам еще пригодится.

Цитата:

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

Аргументы Жени:
1) определения продуктового мышления у разных авторов в интернете — плохие
2) материалы в интернете не дают ответа, как обзавестись продуктовым мышлением

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

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

Тезис: есть просто мышление

Цитата:

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

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

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

Значит, есть какая-то переменная часть в их мышлении.

Эффективное мышление первым делом различает объекты, с которыми работает. У продакта, хирурга и логиста эти объекты — разные и определяются разными понятиями:

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

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

Фиксируем важный вопрос: чем определяются эти важные для деятельности объекты и как они вообще в головах у этих специалистов появились?

Логическая цепочка от цели к результату

Цитата:

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

Цепочку из цитаты можно применить и к продакту, и к диспетчеру, и к хирургу. Верна ли цепочка? — в целом да. Цепочка довольно точно выражает поведение целеориентированного/рационального агента. Она универсальна.

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

Мы уже определили, что в работе разные роли используют разные объекты, важные в их конкретном контексте. И «сидят» эти объекты в той самой «модели мира» из цитаты. Потому что никто не держит в голове детальную модель ВООБЩЕ ВСЕГО известного им мира, она там не поместится и вычислительной мощности на нее не хватит.

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

Когда этот человек действует («щиплет» мир, согласно цитате), он совершает над этими объектами какие-то действия, операции, определяемые выбранным методом.

Определим термины.

МИМ (бывш. ШСМ) определяет метод как воспроизводимый способ получать рабочий продукт/результат, и дает такую формулу:

Метод = Дисциплина + Технология

где:

• Дисциплина определяет рамку: система понятий + принятые способы деятельности. Это «тело» знания; именно дисциплина задает модель мира.
• Метод — воспроизводимый способ получить результат. Это операция.
• Технология — это конкретные инструменты (физические или софтверные), которые нужны в рамках метода.

Цепочка понятий выглядит так:
Дисциплина поставляет онтологию → онтология задаёт, из чего строится модель мира → метод оперирует моделью, чтобы получить рабочий продукт; всё это исполняется в акте мышления ролью.

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

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

Что такое «продуктовое мышление» (будет сложно)

Что такое «мышление» вообще?

Мышление — это вычисление над моделью мира

(адаптированное определение МИМ).

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

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

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

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

Женина цепочка рационального агента «цель → модель мира → симуляция → действие» должна быть дополнена, чтобы стать предметной для продакта. Если мы укажем, что цель, модель, симуляция и действие определяются набором продуктовых дисциплин, то все встает на свои места.
Цель — задается онтологией и формулируется в понятиях дисциплины. Модель мира — строится из объектов онтологии. Симуляция — делает прогоны методов по модели мира (и производится осознанно и явно). Действие — исполняет выбранный метод и обеспечивает рабочий продукт.

Если раскладывать уровни понятий от нижнего (по аналогии с софтом) к верхнему прикладному, получится такой домик:

• Этаж 0, наш фундамент — мышление. Независимое от доменов и предметных областей вычисление агента над описаниями/моделями мира. У мышления самого по себе нет содержания или специфики, оно может прикладываться к любой области и «работать» по ней.
• Этаж 1 — трансдисциплины («интеллект-стек» по МИМ). Это дисциплины/методы мышления о любых объектах и о самих методах: понятизация, онтология, эпистемология, рациональность, системное мышление, методология, этика, эстетика — и т. д. Эти дисциплины переносимы между предметными областями, так как своего предметного содержания не имеют. Именно системное мышление, в моей картине мира, и является базовой трансдисциплиной для продуктового мышления. И именно здесь сидят рациональность и теория принятия решений, под которые можно подвести Женину цепочку.
• Этаж 2 — прикладные дисциплины, собранные под роль/предмет. Именно здесь живет продуктовое мышление как общая онтологическая рамка (продукт, жизненный цикл, окупаемость разработки тиражом, сделка) и стек дисциплин (юнит-экономика, экономика потока разработки, работа со спросом (JTBD, законы Эренберга-Басса), ценообразование, валидация гипотез — и так далее).
• Этаж 3 — мастерство агента. Способность конкретного агента исполнять методы стека в продуктовой работе. Мастерство неотчуждаемо, его нельзя одно транзакцией перенести с агента на агента — стеком нужно овладеть через обучение и практику.
• Этаж 4 — подход. Устройство деятельности организации под методы стека, позволяющее распределить их на доступное количество агентов. Организация, пользуясь трансдисциплинами с первого этажа, может сделать освоение стека более простым для агентов, учредив для этого специальные роли (тьюторов, методологов) и применяя соответствующие методы. Этот этаж за рамками нашего обсуждения, но глянуть на него полезно.

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

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

В чем исходный пост Жени верен:

1. Без мышления (этаж 0) остальные этажи не освоить и не применить
2. Обеспечить владение мастерством через рассказ или чтение пары статей — нельзя

В чем исходный пост неверен:

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

Теперь соберем мою версию определения продуктового мышления:

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

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

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

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

© xkcd

Финал

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

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

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

Можно предложить свой ответ на вопрос Жениного читателя: «как к продукту» нужно относиться только к тому, что можно считать продуктом.

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

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

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

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

В канале «Стратегическая логика» был пост про разное восприятие продуктов и услуг, и в качестве базового тезиса приводится следующий:

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

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

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

Воспроизводство

Основное различие — в подходе к воспроизводству продукта и услуги.

© magnific.com

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

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

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

© magnific.com

Улучшение

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

Услугу улучшить в том же смысле нельзя.

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

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

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

Масштабирование

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

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

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

Продажа и владение

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

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

Вывод

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

Из услуги можно вытащить продукт

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

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

Это пост про то, как работает системная инженерия, на примере решения ситуации с рубашкой. Смешно? Это только пока лишь.

Ставим задачу

Проблема: рубашка в течение дня выбивается из брюк. Это некрасиво, неудобно, приходится постоянно оправляться и думать «не выбилась ли?». Раздражает.

Альтернативы вроде «носить навыпуск» или «сменить стиль на стритвир» не рассматриваем.

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

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

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

2) Заправлять рубашку в трусы;

• Плюсы: немного лучше держит рубашку в подбрючном пространстве.
• Минусы: жестко рубашку не фиксирует — все равно может вылезти; если брюки низкие — при определенных наклонах и приседах из-под них может вылезти резинка трусов, а это гораздо хуже, чем выбившаяся рубашка; не со всеми трусами и рубашками (толстая ткань) сработает; сторонники going commando трусов не носят.

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

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

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

Фиксируем требования

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

Ориентируемся на лучшие практики

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

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

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

Целимся в DIY-версию

Лесенка предпочтений к конструкции:

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

Любое требование, кроме ТУ1, будем считать необязательным, им потенциально можно пожертвовать либо в пользу другого требования, либо в пользу упрощения/удешвеления конструкции. Да и ТУ1 можно переформулировать, если трейд-офф выгодный.

Ищем целевую систему

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

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

На фото — пример движения тела

Поработаем с двумя системными уровнями:
1) Система, внутри которой выполняется целевая функция П. — «надсистема». В нашем случае — это «тело мужчины, одетое в брюки с рубашкой»;
2) «Наша система» — то, что мы, собственно, придумываем. Это наше П., которое мы пока что определим как «система удержания рубашки в брюках».

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

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

Режем систему на части

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

Конструктивное разбиение

Функциональное разбиение отвечает на вопрос «что делает?». Конструктивное — «из чего состоит?». Пространственное — «как части системы расположены в пространстве?».

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

Функциональное разбиение системы «тело в рубашке и брюках»:

• Ф1. Генератор движения; создает перемещение рубашки относительно брюк.
• Ф2. Передатчик движения; передает движение от генератора к рубашке через кинетическую цепочку.
• Ф3. Удержатель рубашки; удерживает рубашку в брюках.

Конструктивное разбиение системы — мы «привязываем» конкретную физическую реализацию к каждой функциональной части:

• К1. Тело (и далее — руки, ноги, шея, грудь, живот, таз); играет роли Ф1 (генератора) и Ф2 (передатчика движений).
• К2. Рубашка; состоит из рукавов, воротника, надбрючной и подбрючной частей; играет роль Ф2, при этом демонстрирует нежелаемое поведение: вылезает из брюк при воздействии движения.
• К2.1 Подбрючная часть рубашки (дописано позже — понадобится нам ниже)
• К3. Брюки; состоят из штанин, пояса, внутренней поверхности пояса (нам важно выделить этот элемент), шлевок под ремень, ремня (будем считать его частью брюк), пуговиц под подтяжки, застежек; играют роли Ф2, Ф3.

Пространственное разбиение:

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

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

Интерфейсы:

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

Еще раз думаем про проблему и систему

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

© wikihow

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

Делаем главный вывод: проблема возникает из-за смещения ткани на интерфейсе КИ2, между рубашкой и брюками.

Исходя из этого формулируем определение целевой системы:

Система ограничения миграции ткани рубашки в подбрючном пространстве.

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

Что сходу приходит в голову:

1. Поработать с интерфейсом КИ1 — ослабить возможность воздействия К1 на К2. Это сложная затея, т. к. интерфейс — динамичный, полного прилегания К1 к К2 обычно не бывает, а расположение и размеры пятен контакта изменяются в зависимости от поведения человека и других внешних условий. Вижу тут много сложностей и почти наверняка — нарушение ТЭ2 и 3 и ТК5 и 6, а это важные для меня требования.
2. Поработать с интерфейсом КИ2 — тут два направления:
   2.1 Лучше удерживать К2.1 внутри П3 при упомянутых изменениях параметров К1.
   2.2 Научиться возвращать К2.1 внутрь П3, если модуль сместился относительно П3 на определенную дельту.
3. Поискать решение за пределами КИ2: удерживать К2.1 внутри П3 не на интерфейсе КИ2, а ниже или выше.

Теперь нужно подобрать практики, которые помогут найти решение.

Ищем и применяем подходящую практику

Задача характеризуется набором противоречий

• Рубашку нужно удерживать, но нельзя жестко фиксировать
• Нужно удерживать рубашку, но нельзя нарушать комфорт ношения и движения
• Желательно не модифицировать рубашки и брюки, но без взаимодействия с ними задачу не решить

Самый известный мне способ найти решение при наличии противоречий — ТРИЗ. Попробуем его.

Формулируем идеальный конечный результат (ИКР):

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

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

У нас есть:

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

Формулируем противоречия:

• ТП1. Рубашку нужно удерживать, но нельзя жестко фиксировать
• ТП2. Рубашку нужно удерживать, но нельзя нарушать комфорт
• ТП3. Система должна быть универсальной, но учитывать особенности конкретной одежды

Выделение оперативной зоны и оперативного времени — локализуем контекст проблемы:

1. Где именно возникает вредный эффект? — на поясе, интерфейс КИ2
2. Когда именно? — при изменении размеров/пропорций К1 (тела) или движении К1
3. В какой момент начинается выход рубашки? — когда свободный запас (К2.1) по длине менее необходимой длины для компенсации изменения К1
4. Где возникает потеря удержания? — в районе пояса (КИ2)

Оперативная зона: КИ2 (поясная зона + верх подбрючного пространства)
Оперативное время: момент натяжения рубашки К2 при движении.

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

Генерация принципов разрешения противоречий:

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

Как решать будем?

Итак, у нас есть несколько технических противоречий — нужно прикинуть, как именно мы можем их устранить.

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

Разрешение:
1) Свободный ход до порога
2) Сопротивление после порога
3) Страховая складка при заправке

ТП2. Удержание против комфорта
Система должна лучше удерживать рубашку от вылезания.
Система не должна менять посадку одежды и нарушать комфорт/теплообмен.

Разрешение:
1) Разделить в пространстве — удерживать только в рабочих зонах
2) Изменить геометрию — не давать рубашке вылезти за счет геометрии системы
3) Распределить удержание — вместо сильного давления в точке обеспечить слабое удержание на площади

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

Разрешение:
1) Разделение системы на базовую и опциональную конструктивные части;
2) Ассортимент — несколько версий, от универсальной до специализированной;
3) Временная модификация одежды — закрепляющиеся модули.

Варианты системы

Учитывая все вышеописанное, накидаем направления поиска решений.

1. Автономные системы
2. Модификация рубашки
3. Модификация брюк
4. Модификация рубашки и брюк

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

В дизайне часов я не понимаю, но имею сказать.

Приехал мне с Авито «Луч»-однострелочник, вот такой:

Что в нем кайфового:

1. Большие цифры с нулями
2. Идеальный шрифт: тонкий, но читаемый
3. Белый циферблат
4. Гармоничность всех размеров, расстояний, пробелов и прочих элементов типографики

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

А вот более поздняя версия модели:

Типографика куда хуже. Лихой логотип выбивается из стиля, но это ладно. Цифры — толстые и большие, нулей нет. Зачем-то сделали шпаргалку на промежутке 12..1. Контраст в ширине часовых и минутных рисок слишком большой, на и без того заметных часовых рисках поставили точки. Стало грязнее, грубее, короче — хуже.

А вот прям свежая версия, с сайта «Луча»:

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

Вот они, слева направо, криво кропнутые — можно сравнить:

Контекст

Ко мне обратились с запросом помочь вывести из кризиса проект по заказной разработке софта.

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

Софт, который заказали исполнителю — система для проведения тендеров на закупку материалов и услуг.

Важные моменты:

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

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

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

Накидаю списком все, что выяснилось на звонках и ранее:

1. Команда собрана и укомплектована, зарплаты платятся вовремя. В команде 9 человек: дизайнер, фронтендер, бэкендер, аналитик бизнес-процессов, два аналитика 1С, разработчик 1С, основной РП (тот самый, которым недовольны, внешник), младший РП (сотрудник команды Исполнителя, который недавно подключился для помощи основному РП).
2. Основные контактные лица на стороне Заказчика — аналитик бизнес-процессов (внешник, был нанят под проект), руководитель одного из отделов.
3. Прошло 3 месяца из 6 заложенных на первый модуль.
4. Разработана основа ЛК Поставщика — можно зарегаться, завести компанию, завести сотрудников.
5. Основная система (1С: ERP) стала доступна для анализа функциональных разрывов неделю назад.
6. РП не наладил операционку и стандартные проектные ритуалы, демотивировался и демотивировал команду.
7. Требования собираются несистемно, плохо документируются, скоуп проекта (и без того невнятный) раздулся из-за бесконтрольного добавления хотелок и задачек заказчиком.
8. Работа документируется в Outline, таски в Yougile.
9. Нет описанного процесса — ни as-is, ни to-be; есть пара огромных bpmn-схем, непонятных без объяснения автором.
10. Нет понимания, каковы вообще границы первого модуля.
11. Самое важное: нет критериев успешности модуля, не определена процедура сдачи. Короче, непонятно, кто и в рамках какой процедуры со стороны клиента скажет «все ок, принимаем, завтра оплатим».

Освобождаем основного РП от обязанностей, идем разбираться с целевым процессом.

Шаг 1: изучаем ситуацию

Первым делом изучили bpmn-схемы и доступные постановки. Постановки состояли из блок-схем и коротких описаний в странном формате. Оказалось, аналитик команды был на самом деле аналитиком бизнес-процессов и изначально пришел нарисовать to-be-процесс и согласовать его с клиентом. А нужен был инженер по требованиям или хотя бы бизнес-аналитик.

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

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

Постановки были вот в таком формате, страниц на пять

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

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

Делаю для руководства Заказчика первый артефакт — проблемы, разложенные на системной схеме проекта:

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

Шаг 2: пускаем пыль в глаза и пересобираем план

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

Демо-сценарий выглядит бледно: полторы фичи, в демонстрации сценарий с ними проходит за пять минут. Заказчик будет недоволен, особенно учитывая растущий негатив к результатам и темпу разработки в целом. Принимаем решение в быстром режиме нарукожопить 2-3 фичи из бэклога, на моках, чтобы демо выглядело получше. Это манипуляция и пыль в глаза, но другого способа снизить потенциальное недовольство заказчика сходу придумать не получается.

Очень быстро пилим эти фичи, очень быстро тестим и доводим до ума, выносим на демо. Замечаний (помимо «давайте быстрее») нет, привычно просят немного поиграть шрифтами, потому что ui should be more friendly and appealing.

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

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

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

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

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

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

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

Из прочего:

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

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

Резюме — принятые решения

Проблемы: проект фиксовый; половина срока прошла, а работы сделано около 10-15% от общего объема; непонятно, что именно делаем — а значит, будут проблемы со сдачей; команда работает стихийно; 1С стала доступна только неделю назад.

Команда

1. Уволить РП и аналитика; взять другого аналитика на замену, т. к. с требованиями беда
2. Поменять роли: младший РП берет на себя операционку и ежедневную рутину, консультант-РП берет на себя архитектуру управления проектом

Метод работы

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

План работы

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

Ошибки

1. Мы не остановили разработку и анализ до выяснения важных обстоятельств: хватит ли оставшегося времени на разработку всего запланированного; кто и как будет принимать работу в конце первого модуля.
2. Мы не запустили обсуждение по увеличению срока разработки на 1-2 месяца из-за недоступности 1С. Это сильно навредит Исполнителю ближе к концу разработки первого модуля.

Конец первой части.

Еще раз поговорим про факторы успешности проектов, с большим упором на теорию задержки решений. Пост 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.

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

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

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

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

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

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

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

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

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

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

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

Второй раунд

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

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

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