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

Получаем софт – "нашу вещь", турникет с софтом – "более крупная вещь, в которую входит наша" и сделку как физический объект, включающий в себя турникет с софтом – "вещь". Можем далее рассматривать "множество/set/collection сделок, которые совершаются на множестве/set/collection турникетов" (и сделать модель парка как набора турникетов с софтом, причем турникеты рассматривать как точки касания/touchpoints, где происходят касания/touches клиента/посетителя и те самые сделки). Успокоимся на этом? Нет 🙂

Сделки можно, конечно, рассматривать как вещь – но за ними ли приходят клиенты парка развлечений? Нет, клиентов интересует приятное времяпрепровождение (обычно с семьей), они хотят получать субъективные переживания от приятно проведенного времени. А теперь вспоминаем о том, как описывается понятие "пользы" в австрийской школе. Цель посетителей парка – развлечься, отдохнуть; польза – это переживания, полученные в ходе отдыха. Интенсивные переживания позволяют посетителям переключиться с мыслей о работе и повседневных бытовых делах. Если переключение вышло на "отлично", удалось перезарядиться и отдохнуть, посетители ушли с ощущением праздника – они извлекли много пользы из своего визита.
Польза, как видно, извлекается не из факта совершения сделок (вообще-то расставаться с деньгами по умолчанию людям обычно больно), а из ВИЗИТА в парк. Будем рассматривать визит в парк как вещь?

Нет, мы поступим интереснее – сменим название рассматриваемой вещи. Визит в парк – это, конечно, неплохо; проблема в том, что в головах людей прочно укоренилась ассоциация с визитом в парк как с мероприятием, которое отсчитывается от события "входа в парк" и заканчивается событием "выхода из парка". Но что если мы хотим рассмотреть части визита, например, посещение конкретного аттракциона (с конкретной сделкой и конкретно пройденными турникетами)? А что если мы вообще хотим посмотреть на времяпрепровождение посетителей в парке – не только когда они посещают аттракционы, но и, например, когда покупают сладкую вату ребенку? А что если нас интересует не только оффлайн визит в парк, но и взаимодействие клиентов с приложением парка (которое тоже может быть предоставлено компанией, делающей билетную систему)?

В таком случае может быть уместнее название вещи "развлекательная сессия" или "развлекательный сеанс". Это интересная вещь: название предполагает безмасштабность вещи. То есть, мы можем выделить "развлекательную сессию" длиной с визит в парк, и тогда развлекательная сессия начинается, например, когда посетители /искатели развлечений (семья) входит в парк, и заканчивается, когда они выходят из парка. А может быть мини развлекательная сессия, в ходе которой посетитель посещает аттракцион, тогда она начинается с момента "постановки посетителя в очередь к аттракциону" и заканчивается, когда посетитель "выходит из аттракциона". (При этом следует обратить внимание, что билетная система в её текущем состоянии может не поддерживать такое описание сессии: в ней отсчёт времени начинается с момента прохождения турникета. Конец сессии можно рассчитать, если вычислить среднее время проката на аттракционе и время на то, чтобы выйти из него – такие данные у парков, вероятно, есть. А вот полное время ожидания клиента в очереди придётся как-то считать отдельно и найти способы его замерять). Более того, развлекательной сессией может быть даже покупка ребенку сахарной ваты, где вообще нет турникетов! Почему? Потому что посетитель оценивает пользу по итогам всего визита в парк, и ему неважно, были ли там где-то турникеты. Если впечатления испортит хамоватая продавщица, которая обсчитала родителей и дала вату не такого цвета ребенку, то посетители будут менее охотно открывать кошелек в следующих сессиях. Менеджеры и владельцы Disney – профессионалы в облегчении кошельков посетителей, которые знают, как сделать так, чтобы посетитель РАДОВАЛСЯ пустому кошельку – очень много внимания посвящают приятным впечатлениям клиентов в каждой точке контакта/touchpoint в рамках каждой развлекательной сессии.

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

Вещь эта – целевая система для парка развлечений, а не для нас; почему мы, создатели софта, должны об этом думать? Потому что софт должен помогать как-то менять сессии (увеличивать их количество, качество и тп таким образом, чтобы это приводило к увеличению выручки парка). Если вы хотите зарабатывать больше денег, у вас должен появиться во внимании объект типа "развлекательная сессия" и рассуждение, как вы участвуете в создании такой сессии. Как на этом можно заработать больше, поговорим как-нибудь в следующий раз, когда будем разбирать разные способы монетизации, то есть, превращения вещей в деньги. Пока же выведем цепочку рассуждений / chain of thought/ CoT, которая должна помогать нам дойти до жизни такой до такой интересной вещи, как "развлекательная сессия".

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

Здесь активно задействуются творческие способности и насмотренность. Если их нет – формируем насмотренность сами, спрашиваем LLM-ки, ищем людей, которые могут поделиться опытом, изучаем литературу "как мы сделали то-то и то-то" (например, Be Our Guest – книжка о компании Дисней и её парках), ищем фундаментальные модели под капотом прикладных.

Имеет ли смысл копать дальше? Да нет, мы уже нашли (конечную) вещь – развлекательную сессию. Дальше уже придется рассуждать о других типах сессий, с которыми сталкиваются агенты, играющие роль посетителей (игровая, если играют в World of Tanks, учебная, если учатся, рабочая и так далее). Это рассуждение в предметной области, в которой работают парки развлечений, уже не имеет смысла. (Ну ок, у наших клиентов и другие типы сессий есть, и дальше что? как нам это выручку позволит поднять?). Максимум – можем порассуждать о том, как жизнь клиентов сера и уныла без развлекательных сессий наших клиентов. Так что тут можем и остановиться. Мы нашли всех кандидатов (которых смогли найти) на гордое звание "вещи".

Ноооо мы все равно еще можем поискать вещи – только теперь не "конечные", а "промежуточные". Не то чтобы поиск был так нужен, но раз уж начал(а) искать вещи, то сложно остановиться. А ещё – эти промежуточные вещи тоже можно превратить в деньги (те монетизировать), увеличив прибыль вашей компании, так что в следующий раз порассуждаем о таких промежуточных вещах и промежуточной пользе от них. Затем можно будет обсудить методы превращения всех этих вещей в деньги (стратегии/методы монетизации / monetization strategies, основанные на моделях выручки/revenue models).

А затем вновь вернёмся к австрийцам. Вы же не думали, что я так просто эту тему отпущу? 😏

Немного о скорости мышления в распределенных представлениях и в символьных.
Идею про разные вещи, описанную выше, я продумала за примерно 1 час. За это время я не только продумала идею, которая легла в опубликованный вчера мега-пост, но еще и идею следующего поста (о возможных "наших вещах" для компании, продающей билетную систему) + 10% поста по моделям монетизации для этой компании. И это всё за час!

Распаковывала идею в посте я 4 часа 😅 Да, с перерывом на обед и небольшую прогулку – но без них бы не получилось закончить и за это время.
Потоковое время – 4 ч vs потоковое время – 1 ч. Всего-то в 4 раза больше...

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

Хорошая штука– мышление в распределенных представлениях...

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

Если мы определяем "вещь"/целевую систему как "турникет с софтом" (еще "платежный терминал с билетно-пропускным софтом" и так далее), то можно далее думать о "железе", на которое устанавливается софт. Что это за турникеты? Можно ли заключить с производителями популярных турникетов договор о предустановке нашего софта. Таким образом компания может увеличить число потенциальных клиентов: люди склонны пользоваться предустановленным софтом (и нередко уходят с него, только если что-то не устраивает). Клиентам, в свою очередь, не надо будет отдельно платить за установку: она будет частично включена в цену турникета (платежного терминала, etc), а частично затраты на установку покроет сама компания-создатель билетной системы (будет оплачивать производителю). Расходы на договор с производителем можно покрыть за счет расширения клиентской базы и увеличения числа подписок (в том числе долгосрочных).
Можно также задуматься о местах, где устанавливаются турникеты (или платежные терминалы) – точках контакта с посетителем парка. Что это за места? Насколько стабильно работает Интернет? Что если связь будет плохая? Как может компания помочь парку решить эти вопросы? Что можно придумать? Здесь потребуется хорошее знание бизнеса клиента (customer knowledge) и моделирование его предметной области (да, разработчикам софта необходимо иметь модели предметной области, описания которой они поддерживают).

Если мы определяем "вещь"/целевую систему как сделку между парком развлечений (и его частью), то можем попытаться подумать о том, как увеличить количество таких сделок для парка развлечений. Но возникает небольшая проблема: надо определить класс сделок, которые заключаются между парком и посетителем. Здесь можно уйти в юридические тонкости договоров оферты, заключаемых между посетителем и парком. Но это не выглядит как перспективное направление развития: в конце концов, парк развлечений работает в B2C индустрии, он оказывает услуги физлицам, а не юрлицам. Юридические тонкости менее важны, чем впечатления/переживания посетителей. Поэтому стоит отказаться выделять в качестве вещи сделку и перейти к наиболее перспективному кандидату – "развлекательной сессии".

Если мы определяем "вещь"/целевую систему как развлекательную сессию, в ходе которой посетитель получает приятные переживания/хорошие впечатление, мы можем максимально развернуться. Во-первых, вещь – развлекательную сессию – создаёт парк развлечений (т.е. является её создателем). Но владельцы и управленцы парков могут вообще не выделять этот объект вниманием и выполнять работы по нужным методам интуитивно (т.е. плохо). Их надо научить выполнять работы по новым методам. Для начала надо научить пользоваться нашим софтом, то есть, создать у создателей мастерство применения методов работы с клиентами, поддержанное нашим экзокортексом. После того, как сотрудники парка научились работать нужными методами с вашим софтом, парк развлечений должен увидеть изменение в выручке и/или прибыли (например, создатель софта обещает повышение прибыли на 35%). Но это только первый шаг, можно пойти дальше. Можно не просто создавать мастерство (и надеяться, что оно затем как-то правильно используется), но и буквально поменять кусок парка развлечений – ИЛИ компании, управляющей парком развлечений.

То есть, имеется такой граф создателей: управляющая компания (которая создает парк развлечений и управляет им) –> (создает) –> парк развлечений –> (создает) –> развлекательная сессия. И наша компания может предложить не только (и даже не столько!) софт, сколько "новую версию (части) управляющей компании" (и, соответственно, новую/изменённую версию части парка развлечений, чтобы развлекательные сессии происходили как можно чаще и стоили как можно дороже, при этом посетители парков были бы счастливы платить больше. Можно сказать, что компания, которая начала с софта, пришла к созданию у парка организационной способности (оргспособности/capability) зарабатывать больше денег (в том числе за счет наличия правильных моделей предметной области с правильными причинно-следственными связями, позволяющих выбрать подходящие методы работы и организовать работу по этим методам).

И на этом можно заработать больше денег быстрее. Ведь ваш клиент – бизнес, который готов хорошо заплатить за увеличение прибыли в 2-3-5 раз. За это парк заплатит куда больше, чем за софт (пусть даже полезный).

В следующий раз попробуем разобрать revenue models для разных видов "наших вещей".

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

–– по количеству агентов/людей (признак классификации): сотрудник vs команда как набор сотрудников;
–– по общности методов (или классов методов): маркетологи vs продажники как исполнители разных ролей (выполняющие работы разными методами), или исходящие продажи/outbound sales vs входящие продажи/inbound sales (и те, и другие – продажники, то есть, у них есть общий класс методов; но специализация у них разная);
–– по общности (единиц) работ или по общности производственной линии/line/routing/flow, например, участвуют в общем проекте или в производственной линии по созданию одной и той же вещи (целевой системы), выпускают одни релизы.

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

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

Во-первых, когда клиент предпринимает клиентское путешествие с вашей компанией, он воспринимает компанию как единое целое. Это вы, создатели/агенты, знаете, что компания неоднородна, внутри есть разные отделы, в рамках одного отдела есть соперничество между разными командами, есть разграниченные зоны ответственности между командами, и так далее. Клиент не хочет в этом разбираться, "проблемы индейцев шерифа не волнуют". Он видит только то, что компания не хочет или не может ему помочь, хотя на самом деле компания способна это сделать – но проблема в том, что точка контакта/touchpoint, в котором оказался клиент, является "ничейной землёй", никто не несёт ответственность за то, чтобы переместить клиента в другую точку. А происходит это именно по той причине, что нет кроссфункциональной команды (мини-бизнеса в рамках большого бизнеса), которая бы отвечала за выпуск вещи для этого типа клиентов и за полное клиентское путешествие для этого типа клиентов! В итоге маркетологи занимаются своим, продажники – своим, разработчики или прочие инженеры – своим делом, а за "стыки" и интеграцию не отвечает никто.
Создавая кроссфункциональные команды, вы решаете эту проблему.

Вторая проблема – формирование "силосных ям" и "информационных пузырей". Во-первых, важные кусочки "неявного знания" о клиенте, его проблемах, особенностях разработки продукта для него – вообще не выходят за пределы "отделов"; в итоге другие отделы, участвующие в выпуске вещи, не знают, что именно нравится/не нравится клиенту в продукте, как быстро можно будет выпустить, например, новую фичу, и так далее. Специальные координационные встречи помогают куда хуже, чем формирование кроссфункциональной команды.
Кроме того, поскольку команды всё-таки по большей части состоят из людей (а не ИИ), следует учитывать групповую динамику (психологическую). Люди в группах склонны оптимизировать свое поведение так, чтобы максимизировать выгоду для себя и/или группы, начинать преследовать цели вроде "установить власть и поменять тут всё как надо" (вместо преследования общей цели предприятия). В итоге вы можете увидеть, как администраторы, которые должны обеспечивать компании платформу, оптимизируют свою работу – ценой постоянных проблем и прерываний в основной операционной деятельности. Например, предлагают не вносить изменения в курс, чтобы облегчить им работу, или не выполняют текущую административную работу по 3-4 месяца. Чтобы это не происходило в ужасающих масштабах, переформируйте команды вокруг общего "клиентского пути".

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

Что такое время? Вроде бы простой вопрос, но на самом деле нет. Потому что существует целых 3 концепции времени!

1️⃣ "Логическое" время или смена состояний выбранных объектов в результате каких-то действий/движения. Например, смены состояний омлета и его составляющих (яйца, зелень, сыр) в ходе готовки. Или изменение количества кортизола в теле. Важно, что привычного нам измеримого (в часах, минутах, секундах) здесь нет! Важны только состояния: возможные и невозможные с учетом текущего состояния. Например, если молоко свернулось, вернуть его обратно в "свежее" состояние уже нельзя; какие-то состояния обратимы, какие-то нет. Те интересует только "логика смены состояний".
Это время не "приходит", оно "наблюдается" или "создается": повар "создает" готовый омлет; вы составляете "описания". Мы не измеряем его; мы только подмечаем, что есть "процесс" как какие-то непрерывные смены состояний, которые начинаются (событие начала процесса) и заканчиваются (событие завершения процесса).
Изучавшие руководство по методологии в Школе системного менеджмента могут также попробовать назвать это время "методологическим": мы обсуждаем метод (как аспект поведения, который предполагает, что в результате действий меняются состояния) и результаты выполнения работ по методу.


2️⃣ Измеримое или хронологическое время, которое мы измеряем в часах, минутах, секундах и так далее. Его мы иногда можем называть "физическим", но на самом деле это неправильно, потому что измеряемое время – это... абстракция!

Вернемся в древние времена и представим, что людям надо договориться, когда они встретятся – так, чтобы они реально встретились и не получилось так, что один еще спит, а второй уже ждет на условленном месте. Что делать?
Конечно же, выбрать общий ориентир. "Встретимся после ужина" – плохой ориентир: что если вы поедите в разное время? Нужно было выбрать что-то, что будет меняться, и меняться независимо от действий человека. И таким объектом стали... светила (солнце днем и звезды ночью). "Встретимся, когда появится первая звезда", "встретимся на восходе солнца" – это уже куда более понятная, выполнимая договоренность!
После люди обратили внимание, что когда светило движется по небу, что-то меняется, например, укорачивается или удлиняется тень на земле. Так возникли солнечные часы: человек воткнул в землю палку, начертил вокруг неё круг и наблюдал, как тень от палки движется по кругу. Теперь можно было договориться: каждый втыкает палку у себя дома и договаривается, что встречаются в тот момент, когда тень от часов находится в определённом положении.
Изобрели люди и другие типы часов: водяные (клепсидра), огненные (свечи), песочные. Однако они не особо прижились: свечи сгорают по-разному в зависимости от материала, размера свечи и так далее; вода тоже будет вытекать быстрее или медленнее в зависимости от размера горлышка, наклона бутыли и так далее. Песочные часы использовались чаще, но в очень специальных ситуациях: на современном языке они служили скорее таймером Помодоро, который отмерял время очередной "помидорки", и не были пригодны для массовой общественной договоренности по поводу (больших) масштабов времени.

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

Кроме движения светил, люди подмечали и смены состояний природы вокруг (времена года, сезоны), а также смены психофизиологических состояний человека (на еще более длинных масштабах). То есть, в основе концепции измеряемого времени тоже вневременная концепция смен состояний физических объектов, выбранных в качестве "базовых": светил в ходе движения, природы (животных, растений и тп) в ходе множества циклов день-ночь, человеческого тела (позднее еще – психики).
Поэтому, когда мы измеряем, сколько длился какой-то процесс (например, выступления на конференции ШСМ-2025), мы измеряем длительность одних процессов относительно других (процесса движения светил). Это измеряемое/хронологическое время еще могут называть "объективным" или "физическим" (в определенных сообществах! например, сейчас в курсе РР оно называется "физическим", но я буду менять название на "измеряемое/хронологическое время").
Это время, в отличие от логического, "наступает" и "приходит". Его мы не создаем (мы же не создаем движение светил, которое лежит в основе концепции хронологического времени), его мы измеряем!

3️⃣ Третья концепция времени – переживаемое/ощущаемое время в ходе выполнения агентом действий. Очень интересная концепция, которая описывает, как агент (обычно человек, конечно же) воспринимает время изнутри, "в своей голове". Наши субъективные часы идут с разной скоростью. Есть люди, которые успевают переделать кучу дел, хотя прошло всего ничего времени (по их субъективным часам). Есть люди, которые, напротив, тратят 100500 часов на простые дела.
Казалось бы, первые счастливцы, а вторым не повезло. Но в реальности особенности восприятия времени обычно уравновешиваются: "скоростным" людям куда тяжелее удерживать внимание вдолгую (год+), а медленные как раз "вцепляются" как питбули в дело и доводят его до конца. В общем, как обычно: есть плюсы и минусы у каждого типа восприятия.

Субъективное время неодинаково. Наполеон прожил 51 год – но в его жизни произошло столько событий, причем влияющих на судьбы мира, что его субъективное время жизни дольше, чем у пастуха, который прожил 100 хронологических лет. В общем, субъективное время измеряет частоту и/или интенсивность жизненных событий (интенсивность смены состояний).


Теперь самое интересное. Физики, рассуждая о "физической концепции времени", будут отсылать вас к кортежу <логическое время, хронологическое время>. То есть, им будут интересны смены состояний каких-то физических объектов, и они будут измерять время смены состояний хронологически в какой-то системе измерений. В зависимости от ситуации физики могут говорить о кортеже в целом или отсылать точечно к логическому либо хронологическому времени.
Поэтому говорить о хронологическом времени как о "физическом" (или о логическом как физическом) неверно: физическое время = <логическое время, хронологическое время>.

Австрийцы (последователи современной версии австрийской школы) будут говорить о "субъективном времени", отсылая на самом деле к кортежу <ощущаемое время, хронологическое время>.

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

#австрийская_экономическая_школа

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

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

#хочу_лето

В который раз убеждаюсь, что главой административной службы НЕЛЬЗЯ назначать чистого администратора, желательно, чтобы человек на этой должности совмещал свою административную роль с какой-нибудь ролью, предполагающей непосредственную работу с клиентами.
Хотя... судя по тому, что я наблюдаю, не поможет. Вроде и человек непосредственно с клиентами работает, но главное для него (нее) - НЕ ПЕРЕНАПРЯЧЬСЯ НИ НА ГРАММ.

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

Первый способ уже попробовала, теперь попробуем второй

Три способа истолковать, что такое "технология"

Когда кто-то произносит слово "технология", что вы представляете?

Оказывается, есть три способа истолковать это слово (то есть, одно слово-омоним отсылает сразу к трём вариантам значения):
– технология как описание,
– технология как вещь,
– технология как метод работы.

Итак, что же это значит?
Говоря слово "технология", мы можем отсылать к описанию, которое можно использовать для создания вещи. Например, в серии постов о магазине музыки iTunes как об инновации (iTunes and the Basis of Competition in the MP3 Player Market, iTunes Case: Technological Innovation: https://reactionwheel.net/2018/12/itunes-case-technological-innovation.html) Джерри Ньюман описывает как технологию стандарт mp3:: документ, который описывает алгоритм кодирования аудиосигналов в формат mp3.

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

Но также часто, произнося слово "технология", мы отсылаем к методам работы. Например, "технология приготовления пиццы" явно отсылает нас к способу/методу, которым можно приготовить пиццу (с учётом имеющихся ресурсов!).

Вероятно, какую-то технологию можно считать распакованной, если:
– есть описания, при помощи которых можно создавать вещи,
– есть вещи, созданные после или ДО появления таких описаний (сначала инженеры долго возятся/tinker и что-то создают, а потом ученые долго чешут затылки и пытаются объяснить, почему у них получилось),
– есть полезные и широко распространённые вещи, которые дают возможность применять новые методы работы (например, слушать музыку новым способом),
– новые способы/методы работы массово применяются,
– благодаря применению новых способов/методов работы агенты приобретают новые возможности или способности что-то сделать (сделать новые вещи, новые открытия, после чего появятся описания, по которым создаются вещи, и так далее).

Этот кусочек про технологии буду вставлять в руководство по рациональной работе.

Вообще у меня сейчас идёт медленное, ленивое обновление моих разделов РР. Добавляю понятия из праксеологии (для разбирательства с вещью), вычитываю текст, исправляю онтологические ошибки, и так далее.
Текущая версия моих разделов – примерно 3.1, нужно обновить её до 3.5, прежде чем будет скачок к версии 4.0.

В версии 4.0 материалы разделов по моделированию, рациональности и работе переплетутся ещё сильнее, начнём тащить общую логику рассуждений и причинность (по кусочкам) с первых разделов. Но чтобы до неё добраться, нужна промежуточная версия 3.5/3.7, чтобы устранить кое-какие косяки.

Переход на версию 3.5/3.7 будет медленным, это не фокусная деятельность. Сейчас больше фокус на экспериментах, чтобы материал, который буду давать, был обкатан.

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

Может быть, кусочки буду выкладывать периодически – но мб не тут, а в ТенЧате (чтобы индексировалось поисковиками).

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

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

Почему я не пишу посты и тексты руководств при помощи ИИ

Несмотря на то, что я нахожу ИИ весьма полезным и всё чаще обращаюсь к нему за составлением описаний, я не использую его для написания текстов руководства по "Рациональной работе" (и будущей "Инженерии сообществ"). ИИ-агент просто... не может мне помочь.

Для меня самый полезный/удобный/применимый сценарий использования ИИ – это ситуация, когда я уже точно знаю, что мне нужно, и мне нужны "руки", которые смогут составить описание (а я его потом прокритикую и поменяю). Так, например, я попросила o3 (самая полезная модель для моих целей) составить мне рецепт солодовой ржаной чиабатты. Потом заглянула в книжку, порекомендованную GPT же (да, я требую не только соблюдения правил составления описания и критику описания, но и список источников информации), поправила рецепт. Приготовила по нему – получилось, считаю вполне успешным эксперимент. GPT также выступил неплохим дизайнером.

Но с текстами руководств он мне не помощник. В первую очередь потому, что я сама перед началом работы лишь примерно понимаю, какое будет содержание... и оно процентов на 40-50 по итогу отличается от первоначальных планов.
И ещё один важный момент: мне в руководстве приходится не сколько понятным языком переписывать имеющуюся информацию о важных объектах внимания, сколько достраивать картинку: каких именно кусочков информации не хватает пользователям (инженерам-менеджерам), чтобы начать применять прочтенное-освоенное. Эта информация в общем доступе отсутствует, ИИ кучи проблем, которые возникают в реальности, не видит, выдает очень общие/generic ответы.

То есть, мне приходится работать с неопределённостью: нельзя спрогнозировать, что именно потребуется добавить в руководство (а что – убрать). Надо сначала открыть/discover информацию о том, что мешает пониманию и решить, какие способы принципиально не подходят для решения проблемы. И вот тогда ИИ-агенты, вероятно, помогут доделать работу.
Чётко как написано в учебниках австрийской школы: неопределённость не даёт прогнозировать и не поддаётся измерению.

Иллюстрация к тому, как неопределённость мешает (мне) писать тексты руководств при помощи ИИ.

1. Текст раздела "Вещь, которая создаётся в ходе стажировки" разделился на 2 текста: часть осталась в этом разделе, часть переехала в новый раздел "Мастерство рациональной работы как инвестиционный актив".
2. Планируемый раздел "Как применять и развивать полученное мастерство" переименован в "Каким должно быть моё мастерство рациональной работы" с заменой содержания процентов так на 80.
3. Пришла в голову идея использовать кое-какие методы/практики запуска консалтинговых проектов (идея, которую LLM в принципе не предлагали). Причём методы будут применяться не прямо в том порядке, в каком они предлагаются в первоисточнике, а в видоизменённом. В основе лежит идея о "дистанционном (через AIsystant) разговоре о том, что вам вообще нужно от стажировки.

Последняя идея будет воплощена в тексте не сразу целиком, а частично: сначала часть практик/методов вставлю, посмотрю на группах, доделаю "Введение" до версии 3.0.

Почему у Анатолия получается сейчас писать новую версию текста руководства по системному мышлению при помощи LLM

Во-первых, в качестве "входящего" текста (input text) у него имеется руководство версии 10+ с высоким качеством (в тч онтологического) материала. (помним о требовательности ИИ к качеству данных и принципе shit in – shit out? так вот, здесь эта проблема устранена).

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

В-третьих, к настоящему моменту методически (с точки зрения подачи) текст тоже изменен. Основные методические находки тоже уже применены для передачи содержания. Там есть ещё куда работать (чтобы дополировать подачу), но основные "мутации", дающие наибольший прирост в понимании – уже пройдены. Неопределённость в отношении методики подачи материала значительно уменьшилась (хоть и не совсем до минимума).

В-четвёртых, Анатолий хорошо понимает, что делает сейчас: сажает системный подход, разработанный ранее на основе эвристик инженерии и менеджмента, на (теоретическую) основу физики, биологии и прочих естественнонаучных теорий, прибегающих к понятиям системы (это практически цитата из последнего текста https://ailev.livejournal.com/1768211.html). Он достаточно хорошо представляет, что должно (в самом общем виде!) появиться на выходе. Неопределённость если и есть, то в основном в отношении каких-то мелких нюансов содержания или подачи – но не в отношении концептуальной идеи. То есть, нет принципиальной неопределённости в вопросах "Что делать", "Зачем делать", "Почему именно так делать".

Вот тут ИИ работает на ура, конечно.
Или в ситуации незнания конкретной предметной области: вы не знаете, как печь солодовую ржаную чиабатту (см мой предыдущий пост), но можете попросить ИИ предоставить вам рецепт, составленный профессиональными пекарем (кондитером-пекарем) и пищевым химиком. Но незнание =/ неопределённости! Я знала, что именно мне нужно, не знала, каким методом достичь результата!

С неопределённостью разбирайтесь сами, дорогие развивающиеся. Вам на то творческие способности и даны)

Какие вещи продают разработчики ИТ-продуктов? (1/3)

На самом деле весьма интересный вопрос, на котором "сыпятся" многие. Потому что... на него есть разные ответы!

1. Вы можете посчитать "вещью" физический экземпляр программы в момент, когда с ним взаимодействует пользователь. Например, вы разрабатываете ERP-систему для фармацевтов, которая отражает поток лекарств, проходящих через аптеку. Тогда вы говорите, что ERP-система в тот момент, когда фармацевт Пётр отмечает, какие лекарства поступили в аптеку, является физическим объектом (помогает отмечать состояния лекарств, с ней может взаимодействовать конкретный пользователь и принимать решения, например, Пётр понимает, что успокоительных не хватает, и отправляет заявку на склад; склад получает заказ и начинает комплектовать следующую поставку. То есть, не просто поменялось что-то в описаниях в программе, а разные люди в разных ролях и разных местах начали что-то делать иначе по итогу).

С таким пониманием вещи есть одна проблема: оно по бОльшей части устарело.
Физические экземпляры программ считали вещами в 90-х – 00-х. И модели монетизации, то есть, превращения вещей в деньги, отражали это: по бОльшей части компании покупали диски с записанным на них кодом, устанавливали на свои компьютеры и пользовались сами. Платили один раз большую сумму авансом (large upfront payment), после чего получали экземпляр программы, которым могли пользоваться бесконечно.

Некоторые компании продолжают работать по этой модели. Например, компания, которая делает Alfred (быстрые клавиши для Mac), работает по этой модели: вы можете купить лицензию на конкретную версию Альфреда (за 34 фунта), а можете купить вечные обновления (за 59 фунтов). Однократный платеж, больше ничего не требуется. Вместе с платежом передается право собственности на физический экземпляр программы (с обновлениями или без).

Но это редкость. Компании по большей части отказались от такой модели – когда обнаружилось, что физические экземпляры программы надо дорабатывать. Операционная система обновляется – нужно обеспечивать совместимость с новыми версиями; появляются конкуренты, копирующие вас – надо что-то обновлять РЕГУЛЯРНО (а не раз в год или даже полгода! это медленно!). Что делать?

Проблему описывал ещё Голдратт в своей книге "Критическая цепь":

Наши продукты имеют очень короткий жизненный цикл. Сейчас это шесть месяцев, но все говорит о том, что он будет продолжать сокращаться. В то же время, несмотря на все наши
усилия, время разработки новых продуктов у нас около двух лет. Вы видите проблему?
Он опять делает паузу. Помолчав, он вслух говорит то, о чем они сейчас думают:
– Время разработки в два года при том, что мы должны выводить на рынок новый продукт каждые шесть месяцев, означает только одно. Вопрос не стоит: «Мы допустим промах или нет?». Вопрос стоит: «Когда мы допустим промах?». И не забывайте: мы не можем позволить себе допустить промах хотя бы раз.
Они молчат, переваривая услышанное. Наконец Леви прерывает тишину:
– Ваша миссия – найти способ, который позволит нам кардинально сократить время разработки. Мы несколько лет пытались найти ответ везде, где только возможно. Мы его не нашли.
Что у нас осталось – это вы. Вы должны найти ответ.

Как ответ на это, были придуманы концепции Lean и Agile (гибкой разработки, бережливого продукта). Но изменения в производстве вещей не могли не отразиться на самом определении вещей и моделях монетизации!

Какие вещи продают разработчики ИТ-продуктов? (2/3)

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

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

Итак, общий тренд – "вещью"/целевой системой начинают считать (явно или не очень) "сеанс работы пользователя с физическим экземпляром программы". Физический экземпляр программы стал лишь частью этого сеанса (а кроме него, есть пользователь, который достигает цели или не достигает во время сеанса и испытывает по этому поводу какие-то чувства, и не только).

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

Смена вещи потребовала смены модели превращения вещи в деньги. Вместо большого авансового платежа компании стали вводить подписочную модель. Пользователь платил за возможность получить доступ к программе и воспользоваться ею во время сеанса. При этом он был лишён права собственности на физический экземпляр программы, но сохранял право пользования им (на время оплаченного доступа).
Кроме того, компания, забирая право собственности, в обмен предлагала постоянные обновления программы (пока оплачивается подписка) – и более низкую цену продукта. При этом, если компания удерживает клиента достаточно долго (2+ года), она зарабатывает больше, чем с прошлой моделью монетизации! То есть, в выигрыше оказываются все.

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

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

Конкуренция усилилась, разработчики массово научились делать достаточно качественные продукты. Кроме того, появление в 2022 году умных LLM-моделей, способных написать несложный код, дополнительно уменьшило стоимость непосредственно разработки кода/building. Навык чистой разработки сам по себе не ценится сейчас высоко (если только вы не специалист экстра-класса, и к тому же с достаточно редкой специализацией. Например, программируете на языке Cobol, на котором написан софт многих финансовых компаний США).
Чтобы выделиться из толпы, придётся пойти по протоптанному пути: то есть, компания должна вновь взять на себя больше обязанностей и делать больше для клиентов. А значит, вещь вновь должна стать более масштабной.