Обсуждали сегодня на лабе будущий семинар по использованию ИИ в работе: как настроить себе панель экспертов, которые будут составлять-комментировать-править ваши описания, как контролировать их работу и тп.
Пыталась уговорить Анатолия провести семинар в режиме лайв/прямой трансляции: в смысле, чтобы он расшарил какой-то из своих чатов, в котором общается с ИИ, и показал вживую, как он с ними работает. Анатолий не уговорился, но пообещал написать мини-руководство по использованию ИИ в работе и провести семинар (но без лайва). И это будет полезно!
Пыталась уговорить Анатолия провести семинар в режиме лайв/прямой трансляции: в смысле, чтобы он расшарил какой-то из своих чатов, в котором общается с ИИ, и показал вживую, как он с ними работает. Анатолий не уговорился, но пообещал написать мини-руководство по использованию ИИ в работе и провести семинар (но без лайва). И это будет полезно!
Почему я не пишу посты и тексты руководств при помощи ИИ
Несмотря на то, что я нахожу ИИ весьма полезным и всё чаще обращаюсь к нему за составлением описаний, я не использую его для написания текстов руководства по "Рациональной работе" (и будущей "Инженерии сообществ"). ИИ-агент просто... не может мне помочь.
Для меня самый полезный/удобный/применимый сценарий использования ИИ – это ситуация, когда я уже точно знаю, что мне нужно, и мне нужны "руки", которые смогут составить описание (а я его потом прокритикую и поменяю). Так, например, я попросила o3 (самая полезная модель для моих целей) составить мне рецепт солодовой ржаной чиабатты. Потом заглянула в книжку, порекомендованную GPT же (да, я требую не только соблюдения правил составления описания и критику описания, но и список источников информации), поправила рецепт. Приготовила по нему – получилось, считаю вполне успешным эксперимент. GPT также выступил неплохим дизайнером.
Но с текстами руководств он мне не помощник. В первую очередь потому, что я сама перед началом работы лишь примерно понимаю, какое будет содержание... и оно процентов на 40-50 по итогу отличается от первоначальных планов.
И ещё один важный момент: мне в руководстве приходится не сколько понятным языком переписывать имеющуюся информацию о важных объектах внимания, сколько достраивать картинку: каких именно кусочков информации не хватает пользователям (инженерам-менеджерам), чтобы начать применять прочтенное-освоенное. Эта информация в общем доступе отсутствует, ИИ кучи проблем, которые возникают в реальности, не видит, выдает очень общие/generic ответы.
То есть, мне приходится работать с неопределённостью: нельзя спрогнозировать, что именно потребуется добавить в руководство (а что – убрать). Надо сначала открыть/discover информацию о том, что мешает пониманию и решить, какие способы принципиально не подходят для решения проблемы. И вот тогда ИИ-агенты, вероятно, помогут доделать работу.
Чётко как написано в учебниках австрийской школы: неопределённость не даёт прогнозировать и не поддаётся измерению.
Несмотря на то, что я нахожу ИИ весьма полезным и всё чаще обращаюсь к нему за составлением описаний, я не использую его для написания текстов руководства по "Рациональной работе" (и будущей "Инженерии сообществ"). ИИ-агент просто... не может мне помочь.
Для меня самый полезный/удобный/применимый сценарий использования ИИ – это ситуация, когда я уже точно знаю, что мне нужно, и мне нужны "руки", которые смогут составить описание (а я его потом прокритикую и поменяю). Так, например, я попросила o3 (самая полезная модель для моих целей) составить мне рецепт солодовой ржаной чиабатты. Потом заглянула в книжку, порекомендованную GPT же (да, я требую не только соблюдения правил составления описания и критику описания, но и список источников информации), поправила рецепт. Приготовила по нему – получилось, считаю вполне успешным эксперимент. GPT также выступил неплохим дизайнером.
Но с текстами руководств он мне не помощник. В первую очередь потому, что я сама перед началом работы лишь примерно понимаю, какое будет содержание... и оно процентов на 40-50 по итогу отличается от первоначальных планов.
И ещё один важный момент: мне в руководстве приходится не сколько понятным языком переписывать имеющуюся информацию о важных объектах внимания, сколько достраивать картинку: каких именно кусочков информации не хватает пользователям (инженерам-менеджерам), чтобы начать применять прочтенное-освоенное. Эта информация в общем доступе отсутствует, ИИ кучи проблем, которые возникают в реальности, не видит, выдает очень общие/generic ответы.
То есть, мне приходится работать с неопределённостью: нельзя спрогнозировать, что именно потребуется добавить в руководство (а что – убрать). Надо сначала открыть/discover информацию о том, что мешает пониманию и решить, какие способы принципиально не подходят для решения проблемы. И вот тогда ИИ-агенты, вероятно, помогут доделать работу.
Чётко как написано в учебниках австрийской школы: неопределённость не даёт прогнозировать и не поддаётся измерению.
Иллюстрация к тому, как неопределённость мешает (мне) писать тексты руководств при помощи ИИ.
1. Текст раздела "Вещь, которая создаётся в ходе стажировки" разделился на 2 текста: часть осталась в этом разделе, часть переехала в новый раздел "Мастерство рациональной работы как инвестиционный актив".
2. Планируемый раздел "Как применять и развивать полученное мастерство" переименован в "Каким должно быть моё мастерство рациональной работы" с заменой содержания процентов так на 80.
3. Пришла в голову идея использовать кое-какие методы/практики запуска консалтинговых проектов (идея, которую LLM в принципе не предлагали). Причём методы будут применяться не прямо в том порядке, в каком они предлагаются в первоисточнике, а в видоизменённом. В основе лежит идея о "дистанционном (через AIsystant) разговоре о том, что вам вообще нужно от стажировки.
Последняя идея будет воплощена в тексте не сразу целиком, а частично: сначала часть практик/методов вставлю, посмотрю на группах, доделаю "Введение" до версии 3.0.
1. Текст раздела "Вещь, которая создаётся в ходе стажировки" разделился на 2 текста: часть осталась в этом разделе, часть переехала в новый раздел "Мастерство рациональной работы как инвестиционный актив".
2. Планируемый раздел "Как применять и развивать полученное мастерство" переименован в "Каким должно быть моё мастерство рациональной работы" с заменой содержания процентов так на 80.
3. Пришла в голову идея использовать кое-какие методы/практики запуска консалтинговых проектов (идея, которую LLM в принципе не предлагали). Причём методы будут применяться не прямо в том порядке, в каком они предлагаются в первоисточнике, а в видоизменённом. В основе лежит идея о "дистанционном (через AIsystant) разговоре о том, что вам вообще нужно от стажировки.
Последняя идея будет воплощена в тексте не сразу целиком, а частично: сначала часть практик/методов вставлю, посмотрю на группах, доделаю "Введение" до версии 3.0.
Почему у Анатолия получается сейчас писать новую версию текста руководства по системному мышлению при помощи LLM
Во-первых, в качестве "входящего" текста (input text) у него имеется руководство версии 10+ с высоким качеством (в тч онтологического) материала. (помним о требовательности ИИ к качеству данных и принципе shit in – shit out? так вот, здесь эта проблема устранена).
Во-вторых, уже некоторое время назад основное содержание текста (онтология системного подхода, принципы и ключевые идеи и тп) меняется слабо – основные методологические находки уже давно в тексте. Неопределённость в отношении содержания сведена к минимуму.
В-третьих, к настоящему моменту методически (с точки зрения подачи) текст тоже изменен. Основные методические находки тоже уже применены для передачи содержания. Там есть ещё куда работать (чтобы дополировать подачу), но основные "мутации", дающие наибольший прирост в понимании – уже пройдены. Неопределённость в отношении методики подачи материала значительно уменьшилась (хоть и не совсем до минимума).
В-четвёртых, Анатолий хорошо понимает, что делает сейчас: сажает системный подход, разработанный ранее на основе эвристик инженерии и менеджмента, на (теоретическую) основу физики, биологии и прочих естественнонаучных теорий, прибегающих к понятиям системы (это практически цитата из последнего текста https://ailev.livejournal.com/1768211.html). Он достаточно хорошо представляет, что должно (в самом общем виде!) появиться на выходе. Неопределённость если и есть, то в основном в отношении каких-то мелких нюансов содержания или подачи – но не в отношении концептуальной идеи. То есть, нет принципиальной неопределённости в вопросах "Что делать", "Зачем делать", "Почему именно так делать".
Вот тут ИИ работает на ура, конечно.
Или в ситуации незнания конкретной предметной области: вы не знаете, как печь солодовую ржаную чиабатту (см мой предыдущий пост), но можете попросить ИИ предоставить вам рецепт, составленный профессиональными пекарем (кондитером-пекарем) и пищевым химиком. Но незнание =/ неопределённости! Я знала, что именно мне нужно, не знала, каким методом достичь результата!
С неопределённостью разбирайтесь сами, дорогие развивающиеся. Вам на то творческие способности и даны)
Во-первых, в качестве "входящего" текста (input text) у него имеется руководство версии 10+ с высоким качеством (в тч онтологического) материала. (помним о требовательности ИИ к качеству данных и принципе shit in – shit out? так вот, здесь эта проблема устранена).
Во-вторых, уже некоторое время назад основное содержание текста (онтология системного подхода, принципы и ключевые идеи и тп) меняется слабо – основные методологические находки уже давно в тексте. Неопределённость в отношении содержания сведена к минимуму.
В-третьих, к настоящему моменту методически (с точки зрения подачи) текст тоже изменен. Основные методические находки тоже уже применены для передачи содержания. Там есть ещё куда работать (чтобы дополировать подачу), но основные "мутации", дающие наибольший прирост в понимании – уже пройдены. Неопределённость в отношении методики подачи материала значительно уменьшилась (хоть и не совсем до минимума).
В-четвёртых, Анатолий хорошо понимает, что делает сейчас: сажает системный подход, разработанный ранее на основе эвристик инженерии и менеджмента, на (теоретическую) основу физики, биологии и прочих естественнонаучных теорий, прибегающих к понятиям системы (это практически цитата из последнего текста https://ailev.livejournal.com/1768211.html). Он достаточно хорошо представляет, что должно (в самом общем виде!) появиться на выходе. Неопределённость если и есть, то в основном в отношении каких-то мелких нюансов содержания или подачи – но не в отношении концептуальной идеи. То есть, нет принципиальной неопределённости в вопросах "Что делать", "Зачем делать", "Почему именно так делать".
Вот тут ИИ работает на ура, конечно.
Или в ситуации незнания конкретной предметной области: вы не знаете, как печь солодовую ржаную чиабатту (см мой предыдущий пост), но можете попросить ИИ предоставить вам рецепт, составленный профессиональными пекарем (кондитером-пекарем) и пищевым химиком. Но незнание =/ неопределённости! Я знала, что именно мне нужно, не знала, каким методом достичь результата!
С неопределённостью разбирайтесь сами, дорогие развивающиеся. Вам на то творческие способности и даны)
Livejournal
Укрощение нежити и его результат: унифицированный системный подход (unified systems framework, USF)
Куда я исчез? Главным образом укрощал AI и занимался системным мышлением. Оригинальная идея у меня была много лет назад: заниматься артигогикой, то есть учить AI (вот пост аж 2012 года про это, и там 111 к нему древних комментов https://ailev.livejournal…
Какие вещи продают разработчики ИТ-продуктов? (1/3)
На самом деле весьма интересный вопрос, на котором "сыпятся" многие. Потому что... на него есть разные ответы!
1. Вы можете посчитать "вещью" физический экземпляр программы в момент, когда с ним взаимодействует пользователь. Например, вы разрабатываете ERP-систему для фармацевтов, которая отражает поток лекарств, проходящих через аптеку. Тогда вы говорите, что ERP-система в тот момент, когда фармацевт Пётр отмечает, какие лекарства поступили в аптеку, является физическим объектом (помогает отмечать состояния лекарств, с ней может взаимодействовать конкретный пользователь и принимать решения, например, Пётр понимает, что успокоительных не хватает, и отправляет заявку на склад; склад получает заказ и начинает комплектовать следующую поставку. То есть, не просто поменялось что-то в описаниях в программе, а разные люди в разных ролях и разных местах начали что-то делать иначе по итогу).
С таким пониманием вещи есть одна проблема: оно по бОльшей части устарело.
Физические экземпляры программ считали вещами в 90-х – 00-х. И модели монетизации, то есть, превращения вещей в деньги, отражали это: по бОльшей части компании покупали диски с записанным на них кодом, устанавливали на свои компьютеры и пользовались сами. Платили один раз большую сумму авансом (large upfront payment), после чего получали экземпляр программы, которым могли пользоваться бесконечно.
Некоторые компании продолжают работать по этой модели. Например, компания, которая делает Alfred (быстрые клавиши для Mac), работает по этой модели: вы можете купить лицензию на конкретную версию Альфреда (за 34 фунта), а можете купить вечные обновления (за 59 фунтов). Однократный платеж, больше ничего не требуется. Вместе с платежом передается право собственности на физический экземпляр программы (с обновлениями или без).
Но это редкость. Компании по большей части отказались от такой модели – когда обнаружилось, что физические экземпляры программы надо дорабатывать. Операционная система обновляется – нужно обеспечивать совместимость с новыми версиями; появляются конкуренты, копирующие вас – надо что-то обновлять РЕГУЛЯРНО (а не раз в год или даже полгода! это медленно!). Что делать?
Проблему описывал ещё Голдратт в своей книге "Критическая цепь":
Как ответ на это, были придуманы концепции Lean и Agile (гибкой разработки, бережливого продукта). Но изменения в производстве вещей не могли не отразиться на самом определении вещей и моделях монетизации!
На самом деле весьма интересный вопрос, на котором "сыпятся" многие. Потому что... на него есть разные ответы!
1. Вы можете посчитать "вещью" физический экземпляр программы в момент, когда с ним взаимодействует пользователь. Например, вы разрабатываете ERP-систему для фармацевтов, которая отражает поток лекарств, проходящих через аптеку. Тогда вы говорите, что ERP-система в тот момент, когда фармацевт Пётр отмечает, какие лекарства поступили в аптеку, является физическим объектом (помогает отмечать состояния лекарств, с ней может взаимодействовать конкретный пользователь и принимать решения, например, Пётр понимает, что успокоительных не хватает, и отправляет заявку на склад; склад получает заказ и начинает комплектовать следующую поставку. То есть, не просто поменялось что-то в описаниях в программе, а разные люди в разных ролях и разных местах начали что-то делать иначе по итогу).
С таким пониманием вещи есть одна проблема: оно по бОльшей части устарело.
Физические экземпляры программ считали вещами в 90-х – 00-х. И модели монетизации, то есть, превращения вещей в деньги, отражали это: по бОльшей части компании покупали диски с записанным на них кодом, устанавливали на свои компьютеры и пользовались сами. Платили один раз большую сумму авансом (large upfront payment), после чего получали экземпляр программы, которым могли пользоваться бесконечно.
Некоторые компании продолжают работать по этой модели. Например, компания, которая делает Alfred (быстрые клавиши для Mac), работает по этой модели: вы можете купить лицензию на конкретную версию Альфреда (за 34 фунта), а можете купить вечные обновления (за 59 фунтов). Однократный платеж, больше ничего не требуется. Вместе с платежом передается право собственности на физический экземпляр программы (с обновлениями или без).
Но это редкость. Компании по большей части отказались от такой модели – когда обнаружилось, что физические экземпляры программы надо дорабатывать. Операционная система обновляется – нужно обеспечивать совместимость с новыми версиями; появляются конкуренты, копирующие вас – надо что-то обновлять РЕГУЛЯРНО (а не раз в год или даже полгода! это медленно!). Что делать?
Проблему описывал ещё Голдратт в своей книге "Критическая цепь":
Наши продукты имеют очень короткий жизненный цикл. Сейчас это шесть месяцев, но все говорит о том, что он будет продолжать сокращаться. В то же время, несмотря на все наши
усилия, время разработки новых продуктов у нас около двух лет. Вы видите проблему?
Он опять делает паузу. Помолчав, он вслух говорит то, о чем они сейчас думают:
– Время разработки в два года при том, что мы должны выводить на рынок новый продукт каждые шесть месяцев, означает только одно. Вопрос не стоит: «Мы допустим промах или нет?». Вопрос стоит: «Когда мы допустим промах?». И не забывайте: мы не можем позволить себе допустить промах хотя бы раз.
Они молчат, переваривая услышанное. Наконец Леви прерывает тишину:
– Ваша миссия – найти способ, который позволит нам кардинально сократить время разработки. Мы несколько лет пытались найти ответ везде, где только возможно. Мы его не нашли.
Что у нас осталось – это вы. Вы должны найти ответ.
Как ответ на это, были придуманы концепции Lean и Agile (гибкой разработки, бережливого продукта). Но изменения в производстве вещей не могли не отразиться на самом определении вещей и моделях монетизации!
Alfredapp
Alfred - Productivity App for macOS
Alfred is a productivity application for macOS, which boosts your efficiency with hotkeys, keywords and text expansion. Search your Mac and the web, and control your Mac using custom actions with the Powerpack.
Какие вещи продают разработчики ИТ-продуктов? (2/3)
Итак, начиная с 2000-х и 2010-х, мир начал более-менее массово переходить на методы гибкой разработки и быстрой поставки продуктов (и их обновлений) на рынок. Вместе с технологическими новациями, позволившими расширить память, массовым доступом к Интернету, расширением пропускной способности Интернета появилась возможность досылать обновления продуктов онлайн.
Компании начали больше внимания уделять не сколько "физическому экземпляру программы", сколько сеансу работы пользователя с этим физическим экземпляром программы. Появилась профессия UX-дизайнера, стало принято думать об удобстве программы для пользователя.
Итак, общий тренд – "вещью"/целевой системой начинают считать (явно или не очень) "сеанс работы пользователя с физическим экземпляром программы". Физический экземпляр программы стал лишь частью этого сеанса (а кроме него, есть пользователь, который достигает цели или не достигает во время сеанса и испытывает по этому поводу какие-то чувства, и не только).
К примеру, можно посчитать "вещью" сеанс работы фармацевта Петра, в ходе которого он дозаказывает успокоительные со склада. Тогда помимо чисто "технических" подробностей работы непосредственно ERP-системы мы должны думать об удобстве использования программы для Петра и кладовщика Семёна, о том, чтобы данные подтянулись вовремя (и можно было собрать заказ), и так далее.
Смена вещи потребовала смены модели превращения вещи в деньги. Вместо большого авансового платежа компании стали вводить подписочную модель. Пользователь платил за возможность получить доступ к программе и воспользоваться ею во время сеанса. При этом он был лишён права собственности на физический экземпляр программы, но сохранял право пользования им (на время оплаченного доступа).
Кроме того, компания, забирая право собственности, в обмен предлагала постоянные обновления программы (пока оплачивается подписка) – и более низкую цену продукта. При этом, если компания удерживает клиента достаточно долго (2+ года), она зарабатывает больше, чем с прошлой моделью монетизации! То есть, в выигрыше оказываются все.
Сеанс использования физического экземпляра программы по-прежнему является вещью (но не конечной, те не целевой системой, а "нашей системой", "нашей вещью") для некоторых команд – а именно команд, которые разрабатывают продукты в специфических отраслях (например, развлечения), и, возможно, для "платформенных" команд. Но для большинства клиентских или операционных команд, разрабатывающих продукты, продаваемые клиентам, этого недостаточно.
Тип вещи, в создании которых участвуют именно эти команды (и компания в целом), опять изменился. Вещи, в создании которых участвуют компании, вновь укрупнились (и сдвинулись ещё дальше в область работы клиента).
Конкуренция усилилась, разработчики массово научились делать достаточно качественные продукты. Кроме того, появление в 2022 году умных LLM-моделей, способных написать несложный код, дополнительно уменьшило стоимость непосредственно разработки кода/building. Навык чистой разработки сам по себе не ценится сейчас высоко (если только вы не специалист экстра-класса, и к тому же с достаточно редкой специализацией. Например, программируете на языке Cobol, на котором написан софт многих финансовых компаний США).
Чтобы выделиться из толпы, придётся пойти по протоптанному пути: то есть, компания должна вновь взять на себя больше обязанностей и делать больше для клиентов. А значит, вещь вновь должна стать более масштабной.
Итак, начиная с 2000-х и 2010-х, мир начал более-менее массово переходить на методы гибкой разработки и быстрой поставки продуктов (и их обновлений) на рынок. Вместе с технологическими новациями, позволившими расширить память, массовым доступом к Интернету, расширением пропускной способности Интернета появилась возможность досылать обновления продуктов онлайн.
Компании начали больше внимания уделять не сколько "физическому экземпляру программы", сколько сеансу работы пользователя с этим физическим экземпляром программы. Появилась профессия UX-дизайнера, стало принято думать об удобстве программы для пользователя.
Итак, общий тренд – "вещью"/целевой системой начинают считать (явно или не очень) "сеанс работы пользователя с физическим экземпляром программы". Физический экземпляр программы стал лишь частью этого сеанса (а кроме него, есть пользователь, который достигает цели или не достигает во время сеанса и испытывает по этому поводу какие-то чувства, и не только).
К примеру, можно посчитать "вещью" сеанс работы фармацевта Петра, в ходе которого он дозаказывает успокоительные со склада. Тогда помимо чисто "технических" подробностей работы непосредственно ERP-системы мы должны думать об удобстве использования программы для Петра и кладовщика Семёна, о том, чтобы данные подтянулись вовремя (и можно было собрать заказ), и так далее.
Смена вещи потребовала смены модели превращения вещи в деньги. Вместо большого авансового платежа компании стали вводить подписочную модель. Пользователь платил за возможность получить доступ к программе и воспользоваться ею во время сеанса. При этом он был лишён права собственности на физический экземпляр программы, но сохранял право пользования им (на время оплаченного доступа).
Кроме того, компания, забирая право собственности, в обмен предлагала постоянные обновления программы (пока оплачивается подписка) – и более низкую цену продукта. При этом, если компания удерживает клиента достаточно долго (2+ года), она зарабатывает больше, чем с прошлой моделью монетизации! То есть, в выигрыше оказываются все.
Сеанс использования физического экземпляра программы по-прежнему является вещью (но не конечной, те не целевой системой, а "нашей системой", "нашей вещью") для некоторых команд – а именно команд, которые разрабатывают продукты в специфических отраслях (например, развлечения), и, возможно, для "платформенных" команд. Но для большинства клиентских или операционных команд, разрабатывающих продукты, продаваемые клиентам, этого недостаточно.
Тип вещи, в создании которых участвуют именно эти команды (и компания в целом), опять изменился. Вещи, в создании которых участвуют компании, вновь укрупнились (и сдвинулись ещё дальше в область работы клиента).
Конкуренция усилилась, разработчики массово научились делать достаточно качественные продукты. Кроме того, появление в 2022 году умных LLM-моделей, способных написать несложный код, дополнительно уменьшило стоимость непосредственно разработки кода/building. Навык чистой разработки сам по себе не ценится сейчас высоко (если только вы не специалист экстра-класса, и к тому же с достаточно редкой специализацией. Например, программируете на языке Cobol, на котором написан софт многих финансовых компаний США).
Чтобы выделиться из толпы, придётся пойти по протоптанному пути: то есть, компания должна вновь взять на себя больше обязанностей и делать больше для клиентов. А значит, вещь вновь должна стать более масштабной.
Какие вещи продают разработчики ИТ-продуктов? (3/3)
Новый тренд, который ещё не отыгран до конца (не исчерпал свой потенциал, в отличие от предыдущих) – это искать "вещь" в предметной области вашего клиента. То есть, по умолчанию считать, что "вещь" изготавливаете не вы одни, и вы вообще можете быть далеко в цепочке создания.
– это ваше рассуждение.
Как же найти эту вещь? С физическим экземпляром программы уже разобрались; сеансы/сессии работы сделали для клиентов удобными. Пришла пора делать следующий шаг – разбираться в предметной области клиента. Для этого придётся задать себе вопрос: "что описывают данные, содержащиеся в нашем продукте? Какие объекты физического мира они описывают (или какие объекты физического мира должны по итогу появиться)?"
Вернёмся к ERP-системе для фармацевтов. Какие данные содержатся в ней? Какие ключевые объекты внимания описываются? На какие объекты обращают внимание исполнители разных ролей с разных сторон/viewpoints?
Ключевой объект внимания в ней – это, конечно, лекарства, наполняющие аптеку. Точнее, целый поток лекарств, который проходит через аптеку и идёт до покупателя (желательно) или на утилизацию (нежелательно).
С этим потоком лекарств и разбирается фармацевт в аптеке. А ещё кладовщик Семён на складе или логист Катя, планирующая поставку. И теперь надо поддержать ERP-системой как экзкортексом методы работы фармацевта, а затем кладовщика и логиста (в необходимом объёме). А значит – придётся разобраться, какими способами/методами работает фармацевт реально (а потом может потребоваться разобраться в методах работы кладовщика, логиста и так далее).
Потому что все они участвуют в перемещении этого потока лекарств, а ваша ERP-система описывает этот поток и помогает провести его быстрее, ни о чём не забыть. А ещё, может быть, подсказывает удачные варианты сочетания товаров на продажу. Например, если женщина-покупатель берёт детские товары для младенцев, может иметь смысл предложить ей не "просто какой-то товар по акции", а салфетки для детей или ланолиновый крем от трещин (и ваша ERP-система может подсказать это).
Модель превращения вещей в деньги тут совершенно особая. Jacco van der Kooji, автор Revenue Architecture, называет эту модель монетизации Consumption – "оплата за потреблённую ценность/пользу/value".
В самом простом варианте это модель Pay Per Use (плати за объём потреблённого блага). Pay Per Use используют компании в отраслях, в которых единицы потребляемого блага достаточно просто измерить: потреблённые минуты разговора для телеком-операторов, километры, которые вы проехали в более оживлённые ("пиковые") часы с высоким спросом, и так далее.
Чуть более сложный случай – это pay per action (плати за совершённое действие). Часто эта модель используется в MarketTech: например, маркетологи активно используют модель оплаты "плати за клик"/pay per click (отсюда все эти cost per click и прочие). Сайты-отзовики могут платить своим авторам бонусы за написанный отзыв. Всё это разновидности pay per action.
Наконец, самый сложный вариант – pay per outcome (оплата только за результат). Это самый сложный, но и самый прибыльный вариант – если компания может его реализовать. Чтобы воспользоваться этой моделью монетизации, надо ооочень хорошо разбираться в предметной области, оооочень хорошо разобраться со своей вещью и позиционированием на рынке (продуктовый/стратегический маркетинг) и применять ценообразование по ценности/value-based pricing. В целом, из публичных личностей самый яркий амбассадор такой модели монетизации – Алекс Хормози / Alex Hormozi. Он это всё уловил.
Вообще, возможно, pay per outcome придётся вынести в отдельный класс/категорию – потому что для полноценного применения этой модели монетизации может потребоваться... вновь сменить вещь, добраться до конечной вещи, которая потребляется конечным покупателем ("благо первого порядка").
Новый тренд, который ещё не отыгран до конца (не исчерпал свой потенциал, в отличие от предыдущих) – это искать "вещь" в предметной области вашего клиента. То есть, по умолчанию считать, что "вещь" изготавливаете не вы одни, и вы вообще можете быть далеко в цепочке создания.
"Вещь далеко от нас, и мы можем с ней ВООБЩЕ не взаимодействовать непосредственно" (и даже, скорее всего, В ПРИНЦИПЕ не взаимодействуете непосредственно).
– это ваше рассуждение.
Как же найти эту вещь? С физическим экземпляром программы уже разобрались; сеансы/сессии работы сделали для клиентов удобными. Пришла пора делать следующий шаг – разбираться в предметной области клиента. Для этого придётся задать себе вопрос: "что описывают данные, содержащиеся в нашем продукте? Какие объекты физического мира они описывают (или какие объекты физического мира должны по итогу появиться)?"
Вернёмся к ERP-системе для фармацевтов. Какие данные содержатся в ней? Какие ключевые объекты внимания описываются? На какие объекты обращают внимание исполнители разных ролей с разных сторон/viewpoints?
Ключевой объект внимания в ней – это, конечно, лекарства, наполняющие аптеку. Точнее, целый поток лекарств, который проходит через аптеку и идёт до покупателя (желательно) или на утилизацию (нежелательно).
С этим потоком лекарств и разбирается фармацевт в аптеке. А ещё кладовщик Семён на складе или логист Катя, планирующая поставку. И теперь надо поддержать ERP-системой как экзкортексом методы работы фармацевта, а затем кладовщика и логиста (в необходимом объёме). А значит – придётся разобраться, какими способами/методами работает фармацевт реально (а потом может потребоваться разобраться в методах работы кладовщика, логиста и так далее).
Потому что все они участвуют в перемещении этого потока лекарств, а ваша ERP-система описывает этот поток и помогает провести его быстрее, ни о чём не забыть. А ещё, может быть, подсказывает удачные варианты сочетания товаров на продажу. Например, если женщина-покупатель берёт детские товары для младенцев, может иметь смысл предложить ей не "просто какой-то товар по акции", а салфетки для детей или ланолиновый крем от трещин (и ваша ERP-система может подсказать это).
Модель превращения вещей в деньги тут совершенно особая. Jacco van der Kooji, автор Revenue Architecture, называет эту модель монетизации Consumption – "оплата за потреблённую ценность/пользу/value".
В самом простом варианте это модель Pay Per Use (плати за объём потреблённого блага). Pay Per Use используют компании в отраслях, в которых единицы потребляемого блага достаточно просто измерить: потреблённые минуты разговора для телеком-операторов, километры, которые вы проехали в более оживлённые ("пиковые") часы с высоким спросом, и так далее.
Чуть более сложный случай – это pay per action (плати за совершённое действие). Часто эта модель используется в MarketTech: например, маркетологи активно используют модель оплаты "плати за клик"/pay per click (отсюда все эти cost per click и прочие). Сайты-отзовики могут платить своим авторам бонусы за написанный отзыв. Всё это разновидности pay per action.
Наконец, самый сложный вариант – pay per outcome (оплата только за результат). Это самый сложный, но и самый прибыльный вариант – если компания может его реализовать. Чтобы воспользоваться этой моделью монетизации, надо ооочень хорошо разбираться в предметной области, оооочень хорошо разобраться со своей вещью и позиционированием на рынке (продуктовый/стратегический маркетинг) и применять ценообразование по ценности/value-based pricing. В целом, из публичных личностей самый яркий амбассадор такой модели монетизации – Алекс Хормози / Alex Hormozi. Он это всё уловил.
Вообще, возможно, pay per outcome придётся вынести в отдельный класс/категорию – потому что для полноценного применения этой модели монетизации может потребоваться... вновь сменить вещь, добраться до конечной вещи, которая потребляется конечным покупателем ("благо первого порядка").
Теперь вы думаете не о потоке лекарств, который проходит через аптеку. Теперь вы думаете как минимум о наборе лекарств, которым лечится пациент (а дальше вы вообще можете замахнуться на здоровое состояние его тушки). Пациенты вылечиваются благодаря грамотно подобранным лекарствам и рабочим схемам лечения, по которым они лечатся. Все по цепочке получают оплату за вылеченного пациента (а впоследствии – и за незаболевшего благодаря профилактике, которой займется аптека тоже). Аптека получает оплату за лекарства, поставщики софта за рекомендации и тп.
Это очень, очень, ОЧЕНЬ сложно реализовать. Но в этом сценарии можно зарабатывать даже больше: устранена принципиальная неопределённость "это полезно или нет" (да, полезно), а значит, за то же самое можно взять больше денег, чем за подписку, например, а удерживать клиента не годами, а десятилетиями.
Кто это затащит – тот молодец.
Пойду думать, как бы мне оказаться молодцом 🤓
Это очень, очень, ОЧЕНЬ сложно реализовать. Но в этом сценарии можно зарабатывать даже больше: устранена принципиальная неопределённость "это полезно или нет" (да, полезно), а значит, за то же самое можно взять больше денег, чем за подписку, например, а удерживать клиента не годами, а десятилетиями.
Кто это затащит – тот молодец.
Пойду думать, как бы мне оказаться молодцом 🤓
Forwarded from CX: Стратегическая логика (Михаил Руденко)
Недавно мне на глаза попался довольно истеричный пост, который я не буду вам целиком цитировать, чтобы не делать рекламу сомнительным ребятам. Ограничусь пересказом общего смысла. Он незамысловат: малый бизнес — это для отважных.
Далее несколько абзацев про то, что это грызня не на жизнь а на смерть, вечный стресс, продажи до одурения и no mercy for losers.
Я в жизни достаточно общался с малым бизнесом, как успешным, так и не очень, чтобы утверждать уверенно: существует корреляция между относительной легкостью ведения бизнеса и одним фактором. Когда этот фактор есть — всё складывается. Когда нет — всё тяжко и вечный стресс. Этот фактор называется «понимание собственной ценности».
Я дерзко берусь утверждать, что если не основная, то по крайней мере одна из основных проблем малого бизнеса заключается в том, что почти все там ничерта не понимают, что и кому они продают.
У них в голове на эту тему либо пусто вообще, либо там бурлит такой ядрёный компот из всей той лажи, которую вещают всякие «маркетологи без бюджета» и «монстры продаж», что боже сохрани так жить.
Они постоянно мечутся: то «продают удобство», то «сервис», то «эмоции». При этом никто толком не может объяснить почему именно так, а не иначе. А про то, чем это отличается от представления соседа, который тоже сходил на конференцию и тоже теперь продает «удобство» или «избавление от головной боли», я вообще молчу.
Почему у них так? Рискну предположить, что они попадают в стратегию с фатальной петлей обратной связи. Чем меньше понимаешь в продукте, тем больше приходится прикладывать усилий к тому, чтобы его продать. Чем больше усилий по продаже того, что не можешь объяснить – тем меньше удельная эффективность этих усилий. А значит, тем больше выгорания и стресса. Чем больше стресса, тем больше страха, что всё пропало, а значит надо усиленно продавать. И далее по кругу.
По тому как предприниматель ведет себя в стрессе можно спрогнозировать его будущее. Если он, обнаружив, что его продукт не очень-то хотят покупать, начинает «продавать до умопомрачения» — это потенциальное банкротство.
Если же он останавливается и задумывается над тем почему так происходит и начинает разбираться — шанс есть.
Малый бизнес это не только желание разбогатеть — это прежде всего идея. Хорошо проработанная, хорошо структурированная идея. Идея, в которую предприниматель не только верит, но и может объяснить. Каждый предприниматель обязан быть немножечко визионером.
Потому рано или поздно наступит тот волшебный момент, когда придется делегировать. И вот тут ой — если не разобраться как устроено твое ценностное предложение, не получится нормально:
- Наладить продажи. Продажники просто не поймут что им нужно продавать.
- Наладить маркетинг. Маркетологи буду выдумывать преимущества и лить воду в коммуникациях. Бюджеты будут улетать в трубу, а маркетологи будут еще намекать на скидки и прочую работу в убыток. Просто потому что не понимают, а какие еще ручки крутить, чтобы привлечь клиента?
- Наладить процессы тоже не выйдет. Потому что если не знаешь что ты делаешь, то непонятно и как это делать.
- В конце концов, пострадает и финансовый менеджмент. Если ты не понимаешь, как у тебя формируется добавленная стоимость, то не сможешь назначить адекватную цену. И будешь все время жить методом проб и ошибок.
Ставить каждый день шкуру на кон и при этом идти этим самым методом проб и ошибок — вот что на самом деле вызывает стресс, о котором писал автор канала. А вовсе не малый бизнес как таковой. Это натуральная русская рулетка. Причём, самое странное, что в нее никто не заставляет играть. Есть и другие варианты. Но они всё выбирают и выбирают крутить барабан, в надежде что выпадет сектор приз.
Далее несколько абзацев про то, что это грызня не на жизнь а на смерть, вечный стресс, продажи до одурения и no mercy for losers.
Я в жизни достаточно общался с малым бизнесом, как успешным, так и не очень, чтобы утверждать уверенно: существует корреляция между относительной легкостью ведения бизнеса и одним фактором. Когда этот фактор есть — всё складывается. Когда нет — всё тяжко и вечный стресс. Этот фактор называется «понимание собственной ценности».
Я дерзко берусь утверждать, что если не основная, то по крайней мере одна из основных проблем малого бизнеса заключается в том, что почти все там ничерта не понимают, что и кому они продают.
У них в голове на эту тему либо пусто вообще, либо там бурлит такой ядрёный компот из всей той лажи, которую вещают всякие «маркетологи без бюджета» и «монстры продаж», что боже сохрани так жить.
Они постоянно мечутся: то «продают удобство», то «сервис», то «эмоции». При этом никто толком не может объяснить почему именно так, а не иначе. А про то, чем это отличается от представления соседа, который тоже сходил на конференцию и тоже теперь продает «удобство» или «избавление от головной боли», я вообще молчу.
Почему у них так? Рискну предположить, что они попадают в стратегию с фатальной петлей обратной связи. Чем меньше понимаешь в продукте, тем больше приходится прикладывать усилий к тому, чтобы его продать. Чем больше усилий по продаже того, что не можешь объяснить – тем меньше удельная эффективность этих усилий. А значит, тем больше выгорания и стресса. Чем больше стресса, тем больше страха, что всё пропало, а значит надо усиленно продавать. И далее по кругу.
По тому как предприниматель ведет себя в стрессе можно спрогнозировать его будущее. Если он, обнаружив, что его продукт не очень-то хотят покупать, начинает «продавать до умопомрачения» — это потенциальное банкротство.
Если же он останавливается и задумывается над тем почему так происходит и начинает разбираться — шанс есть.
Малый бизнес это не только желание разбогатеть — это прежде всего идея. Хорошо проработанная, хорошо структурированная идея. Идея, в которую предприниматель не только верит, но и может объяснить. Каждый предприниматель обязан быть немножечко визионером.
Потому рано или поздно наступит тот волшебный момент, когда придется делегировать. И вот тут ой — если не разобраться как устроено твое ценностное предложение, не получится нормально:
- Наладить продажи. Продажники просто не поймут что им нужно продавать.
- Наладить маркетинг. Маркетологи буду выдумывать преимущества и лить воду в коммуникациях. Бюджеты будут улетать в трубу, а маркетологи будут еще намекать на скидки и прочую работу в убыток. Просто потому что не понимают, а какие еще ручки крутить, чтобы привлечь клиента?
- Наладить процессы тоже не выйдет. Потому что если не знаешь что ты делаешь, то непонятно и как это делать.
- В конце концов, пострадает и финансовый менеджмент. Если ты не понимаешь, как у тебя формируется добавленная стоимость, то не сможешь назначить адекватную цену. И будешь все время жить методом проб и ошибок.
Ставить каждый день шкуру на кон и при этом идти этим самым методом проб и ошибок — вот что на самом деле вызывает стресс, о котором писал автор канала. А вовсе не малый бизнес как таковой. Это натуральная русская рулетка. Причём, самое странное, что в нее никто не заставляет играть. Есть и другие варианты. Но они всё выбирают и выбирают крутить барабан, в надежде что выпадет сектор приз.
Поставки мелкими партиями при работе над разными типами вещей и их описаний, или MVP бывает сложным.
Часть 1: вводная
Я много пишу и говорю о пользе "поставок мелкими партиями": вы делаете как можно быстрее ту работу, которую можете выполнить и которую имеет смысл показывать другим, показываете, получаете обратную связь и дорабатываете. Постоянное выполнение работ в таком режиме позволяет вам одновременно обеспечить высокую скорость работы и достаточно быстро повышающуюся точность.
Но "наладить работу по принципу мелких партий" только звучит просто. На самом деле полноценная реализация достаточно трудоёмкая и полна неочевидных "подводных камней".
Например, что такое минимальный продукт/minimun viable product? Чётких однозначных критериев, которые были бы верны для каждого случая – нет! Есть только набор принципов, которыми стоит руководствоваться, и сигналов, на которых нужно ориентироваться.
Сначала о принципах, которыми надо руководствоваться.
Часть 1: вводная
Я много пишу и говорю о пользе "поставок мелкими партиями": вы делаете как можно быстрее ту работу, которую можете выполнить и которую имеет смысл показывать другим, показываете, получаете обратную связь и дорабатываете. Постоянное выполнение работ в таком режиме позволяет вам одновременно обеспечить высокую скорость работы и достаточно быстро повышающуюся точность.
Но "наладить работу по принципу мелких партий" только звучит просто. На самом деле полноценная реализация достаточно трудоёмкая и полна неочевидных "подводных камней".
Например, что такое минимальный продукт/minimun viable product? Чётких однозначных критериев, которые были бы верны для каждого случая – нет! Есть только набор принципов, которыми стоит руководствоваться, и сигналов, на которых нужно ориентироваться.
Сначала о принципах, которыми надо руководствоваться.
Поставки мелкими партиями при работе над разными типами вещей и их описаний, или MVP бывает сложным.
Часть 2: думаем об эксплуатации объекта
Принцип 1. Обращаем внимание на то, как будет использоваться вещь (какие сценарии эксплуатации есть). Аналогично при создании MVP рабочих продуктов в вашей повседневной деятельности. "Как пользователь (или адресат, если речь об описании) сможет сделать что-то сам?".
Сначала – не как Я могу это сделать, а как ОНИ смогут это использовать. А затем вопрос "как я могу что-то сделать сейчас (и могу ли, и какие промежуточные действия надо выполнить и промежуточные рабочие продукты получить, чтобы смочь)?".
Например, как я сама рассуждаю, когда выбираю, что попадёт в следующий релиз руководства, а что нет? Я думаю о том, как этот материал поможет инженерам-менеджерам что-то допонять/доразъяснить для себя – и пойти сделать нужное. Скажем, разделы "Игра "Назови вещь", "Зачем нужна игра" и "О вещах и ситуациях их эксплуатации" можно было публиковать (в составе руководства) почти сразу после их составления и вычитки. Это материал, который помогает сосредоточить внимание инженеров-менеджеров на вещи/целевой системы.
(Кстати, после публикации этих разделов вскрылись еще и проблемы подачи материала: когда мы только начинаем разговор о "вещах", мы понимаем, что пользователи руководства, впервые столкнувшиеся с материалом, будут думать в рамках аристотелевской онтологии с его "сущностями/entities", "свойствами/attributes" и так далее. И часть ошибок с выявлением вещи будет связана с этим. Но потом мы должны обеспечить смену онтологии в головах пользователей руководства, а не в тексте. И эту смену мы сейчас не вполне обеспечиваем. И нет, пары фраз или даже абзацев в "онтологических" кусочках текста недостаточно, чтобы смена произошла.
Нужно только в тексте написать больше: например, в онтологических кусочках текста подробнее объяснить, почему нужен 4Д экстенсионализм на базе набора типов/системы типов BORO и какие невидимые, но существенные проблемы переход к такому экстенсионализму решаем. А в кусочках по собранности и работе добавить объяснение того, что такое время (наметки в отдельном посте), после этого еще раз вернуться ко введённым в онтологических кусочках "темпоральные части физических объектов" и, наконец, расписать подробнее, почему мы запрещаем называть вещами "процессы" (к моменту начала объяснения в тексте в голове пользователя руководства уже должны быть основы, из которых он может додумать объяснение сам, вот поэтому все эти подготовительные танцы). И вот это вот всё надо сделать, чтобы в головах пользователей (а значит, и в их действиях) начали проявляться изменения (в ходе выделения вещей), которые можно заметить и по которым можно судить о начале появления мастерства.
Но в следующий релиз всё это не попадёт. В следующий релиз пойдет в очередной раз обновлённое "Введение" с 5 или 6 новыми подразделами сразу. Выдавать во "Введение" меньше не имеет смысла: даже в текущей версии "Введение" уже позволяет как-то настроиться на стажировку, так что насущной необходимости резать поставку до 1 подраздела нет. Кроме того, эти 5 или 6 подразделов тесно связаны по смыслу + позволяют наконец убрать подразделы про "Собранность как прикладное мастерство" и пр из раздела 1 (где запланированы другие изменения). Так что тут сокращать поставку до 1 подраздела (описания) в релизе не вижу смысла.
А вот когда вернусь к основному материалу, там поставки будут именно партиями по 1 подразделу. И там логика обновлений порой будет не очень очевидной 😃
Часть 2: думаем об эксплуатации объекта
Принцип 1. Обращаем внимание на то, как будет использоваться вещь (какие сценарии эксплуатации есть). Аналогично при создании MVP рабочих продуктов в вашей повседневной деятельности. "Как пользователь (или адресат, если речь об описании) сможет сделать что-то сам?".
Сначала – не как Я могу это сделать, а как ОНИ смогут это использовать. А затем вопрос "как я могу что-то сделать сейчас (и могу ли, и какие промежуточные действия надо выполнить и промежуточные рабочие продукты получить, чтобы смочь)?".
Например, как я сама рассуждаю, когда выбираю, что попадёт в следующий релиз руководства, а что нет? Я думаю о том, как этот материал поможет инженерам-менеджерам что-то допонять/доразъяснить для себя – и пойти сделать нужное. Скажем, разделы "Игра "Назови вещь", "Зачем нужна игра" и "О вещах и ситуациях их эксплуатации" можно было публиковать (в составе руководства) почти сразу после их составления и вычитки. Это материал, который помогает сосредоточить внимание инженеров-менеджеров на вещи/целевой системы.
(Кстати, после публикации этих разделов вскрылись еще и проблемы подачи материала: когда мы только начинаем разговор о "вещах", мы понимаем, что пользователи руководства, впервые столкнувшиеся с материалом, будут думать в рамках аристотелевской онтологии с его "сущностями/entities", "свойствами/attributes" и так далее. И часть ошибок с выявлением вещи будет связана с этим. Но потом мы должны обеспечить смену онтологии в головах пользователей руководства, а не в тексте. И эту смену мы сейчас не вполне обеспечиваем. И нет, пары фраз или даже абзацев в "онтологических" кусочках текста недостаточно, чтобы смена произошла.
Нужно только в тексте написать больше: например, в онтологических кусочках текста подробнее объяснить, почему нужен 4Д экстенсионализм на базе набора типов/системы типов BORO и какие невидимые, но существенные проблемы переход к такому экстенсионализму решаем. А в кусочках по собранности и работе добавить объяснение того, что такое время (наметки в отдельном посте), после этого еще раз вернуться ко введённым в онтологических кусочках "темпоральные части физических объектов" и, наконец, расписать подробнее, почему мы запрещаем называть вещами "процессы" (к моменту начала объяснения в тексте в голове пользователя руководства уже должны быть основы, из которых он может додумать объяснение сам, вот поэтому все эти подготовительные танцы). И вот это вот всё надо сделать, чтобы в головах пользователей (а значит, и в их действиях) начали проявляться изменения (в ходе выделения вещей), которые можно заметить и по которым можно судить о начале появления мастерства.
Но в следующий релиз всё это не попадёт. В следующий релиз пойдет в очередной раз обновлённое "Введение" с 5 или 6 новыми подразделами сразу. Выдавать во "Введение" меньше не имеет смысла: даже в текущей версии "Введение" уже позволяет как-то настроиться на стажировку, так что насущной необходимости резать поставку до 1 подраздела нет. Кроме того, эти 5 или 6 подразделов тесно связаны по смыслу + позволяют наконец убрать подразделы про "Собранность как прикладное мастерство" и пр из раздела 1 (где запланированы другие изменения). Так что тут сокращать поставку до 1 подраздела (описания) в релизе не вижу смысла.
А вот когда вернусь к основному материалу, там поставки будут именно партиями по 1 подразделу. И там логика обновлений порой будет не очень очевидной 😃
Поставки мелкими партиями при работе над разными типами вещей и их описаний, или MVP бывает сложным.
Часть 3: серьёзные риски – сложный MVP
Принцип 3. Если создаваемый вами (рабочий) продукт имеет дело с жизнью, здоровью и смертью людей непосредственно, ваш MVP будет сложным.
Например, MVP фемтосекундного лазера, при помощи которого проводят операции лазерной коррекции зрения, будет выглядеть как "зрелый продукт" с точки зрения ИТ-разработчиков, создающих софт для управления проектами.
Но также сложными будут и MVP сложных инфраструктурных объектов. Там дело не только и даже не столько в том, что мы имеем дело с жизнью и смертью, сколько в сроке эксплуатации объекта. Разберём это на примере Крымского моста.
Часть 3: серьёзные риски – сложный MVP
Принцип 3. Если создаваемый вами (рабочий) продукт имеет дело с жизнью, здоровью и смертью людей непосредственно, ваш MVP будет сложным.
Например, MVP фемтосекундного лазера, при помощи которого проводят операции лазерной коррекции зрения, будет выглядеть как "зрелый продукт" с точки зрения ИТ-разработчиков, создающих софт для управления проектами.
Но также сложными будут и MVP сложных инфраструктурных объектов. Там дело не только и даже не столько в том, что мы имеем дело с жизнью и смертью, сколько в сроке эксплуатации объекта. Разберём это на примере Крымского моста.
Поставки мелкими партиями при работе над разными типами вещей и их описаний, или MVP бывает сложным.
Часть 4: срок эксплуатации имеет значение (1/2)
Принцип 3. Если создаваемый вами (рабочий) продукт будет эксплуатироваться долго (срок эксплуатации измеряется десятилетиями, может, больше), а стоимость переделок крайне высока, MVP может выглядеть крайне неожиданно – и будет достаточно дорогим и сложным сам по себе. Часто имеют дело с такой ситуацией те, кто участвует в строительстве базовых объектов инфраструктуры.
Скажем, вы строите мост – большой, сложный, который будет эксплуатироваться десятилетиями. Например, Крымский мост. Основной мост – основную вещь – нельзя строить кое-как. Во-первых, такой мост – мост типа "базовый объект инфраструктуры". Он является важной частью межрегиональной транспортной системы, должен обеспечивать перевозку массы грузов и пассажиров (едущих по делам или отдыхать). Мост длинный, строится в непростой геологически, географически и биологически зоне:
– Самый главный мост: как строят мост через Керченский пролив.
Кроме того, вы должны учесть, что мост не единственная часть межрегиональной транспортной системы – и он не должен мешать судоходству в Керченском проливе. А заодно – выдержать непростые погодные условия: первая версия моста, достроенная осенью 1944 года (!), продержалась около 6 месяцев – после чего треть опор была повреждена льдом с Азовского моря. Мост пришлось демонтировать.
А еще, говорят ли вам как строителям или нет, но мост строится с учетом не только гражданских, но и военных сценариев использования: рядом расположена враждебно настроенная страна, которая стремительно катится от состояния "государство" к состоянию "территории / дикое поле", и в такой ситуации с точки зрения безопасности лучше предполагать, что военный конфликт скорее будет, чем нет.
Поэтому строителям и участвующим в строительстве надо учесть, что:
• может потребоваться возить много тяжелых грузов (партия танков, например);
• военные другой страны могут попытаться подорвать или атаковать мост – и вам нужно предполагать, что им чего-то удастся достичь (нет таких средств, которые обеспечивают 100% безопасность, отказоустойчивость и прочие -ости). Значит, должна быть возможность быстро восстановить мост. Это накладывает ограничения на конструкцию (требуется обеспечить хорошую модульность: чтобы при выпадении секции моста её можно было достаточно быстро восстановить, и восстановление не затянулось бы на годы).
То есть, при строительстве нужно закладывать повышенную прочность, обеспечивать быструю ремонтируемость и тп. Это – дорого. Поэтому и MVP в данном случае будет непростой. Точнее, MVP будет много и для разных аудиторий. Для гражданских пассажиров и перевозчиков MVP будет "Керченский паром" (да-да, несмотря на то, что паром открыт еще в 1953 году – намного раньше, чем запущен в эксплуатацию мост).
А еще о мосте в ходе его эксплуатации следует думать примерно так, как описывает Талеб в своих книжках. Когда мост строится, предполагается обычно, что он будет эксплуатироваться десятилетиями. За десятилетия ОБЯЗАТЕЛЬНО прилетит какой-нибудь "лебедь": эпидемия, война, развал и тп. И это тоже следует учитывать, когда закладывается фундамент, в смысле, строится базовый объект инфраструктуры. "Как бы сделать так, чтобы Крымский мост:: вещь было крайне сложно прибить или вывести из эксплуатации, даже если все вокруг будет разваливаться" – примерно так следует рассуждать при строительстве объектов подобного типа.
Часть 4: срок эксплуатации имеет значение (1/2)
Принцип 3. Если создаваемый вами (рабочий) продукт будет эксплуатироваться долго (срок эксплуатации измеряется десятилетиями, может, больше), а стоимость переделок крайне высока, MVP может выглядеть крайне неожиданно – и будет достаточно дорогим и сложным сам по себе. Часто имеют дело с такой ситуацией те, кто участвует в строительстве базовых объектов инфраструктуры.
Скажем, вы строите мост – большой, сложный, который будет эксплуатироваться десятилетиями. Например, Крымский мост. Основной мост – основную вещь – нельзя строить кое-как. Во-первых, такой мост – мост типа "базовый объект инфраструктуры". Он является важной частью межрегиональной транспортной системы, должен обеспечивать перевозку массы грузов и пассажиров (едущих по делам или отдыхать). Мост длинный, строится в непростой геологически, географически и биологически зоне:
Строительству предшествовали масштабные геодезические исследования и кадастровые работы. Из зоны будущей стройки были отселены редкие животные, на другие участки были пересажены растения, занесенные в Красную книгу. Проводились работы по разминированию и археологические раскопки.
– Самый главный мост: как строят мост через Керченский пролив.
Кроме того, вы должны учесть, что мост не единственная часть межрегиональной транспортной системы – и он не должен мешать судоходству в Керченском проливе. А заодно – выдержать непростые погодные условия: первая версия моста, достроенная осенью 1944 года (!), продержалась около 6 месяцев – после чего треть опор была повреждена льдом с Азовского моря. Мост пришлось демонтировать.
А еще, говорят ли вам как строителям или нет, но мост строится с учетом не только гражданских, но и военных сценариев использования: рядом расположена враждебно настроенная страна, которая стремительно катится от состояния "государство" к состоянию "территории / дикое поле", и в такой ситуации с точки зрения безопасности лучше предполагать, что военный конфликт скорее будет, чем нет.
Поэтому строителям и участвующим в строительстве надо учесть, что:
• может потребоваться возить много тяжелых грузов (партия танков, например);
• военные другой страны могут попытаться подорвать или атаковать мост – и вам нужно предполагать, что им чего-то удастся достичь (нет таких средств, которые обеспечивают 100% безопасность, отказоустойчивость и прочие -ости). Значит, должна быть возможность быстро восстановить мост. Это накладывает ограничения на конструкцию (требуется обеспечить хорошую модульность: чтобы при выпадении секции моста её можно было достаточно быстро восстановить, и восстановление не затянулось бы на годы).
То есть, при строительстве нужно закладывать повышенную прочность, обеспечивать быструю ремонтируемость и тп. Это – дорого. Поэтому и MVP в данном случае будет непростой. Точнее, MVP будет много и для разных аудиторий. Для гражданских пассажиров и перевозчиков MVP будет "Керченский паром" (да-да, несмотря на то, что паром открыт еще в 1953 году – намного раньше, чем запущен в эксплуатацию мост).
А еще о мосте в ходе его эксплуатации следует думать примерно так, как описывает Талеб в своих книжках. Когда мост строится, предполагается обычно, что он будет эксплуатироваться десятилетиями. За десятилетия ОБЯЗАТЕЛЬНО прилетит какой-нибудь "лебедь": эпидемия, война, развал и тп. И это тоже следует учитывать, когда закладывается фундамент, в смысле, строится базовый объект инфраструктуры. "Как бы сделать так, чтобы Крымский мост:: вещь было крайне сложно прибить или вывести из эксплуатации, даже если все вокруг будет разваливаться" – примерно так следует рассуждать при строительстве объектов подобного типа.
Naked Science
Самый главный мост: как строят мост через Керченский пролив
Пожалуй, ни одна масштабная стройка, после подготовки к зимней Олимпиаде в Сочи, не приковывала к себе так много внимания, как строительство моста через Керченский пролив. Как строят главный мост России и каким он будет, рассмотрел Naked Science.
Поставки мелкими партиями при работе над разными типами вещей и их описаний, или MVP бывает сложным.
Часть 5: сигнал(ы) о том, что объект, над которым вы работаете, уже не MVP
Самый общий сигнал: выпуск сильно замедлился, и сроки выпуска становятся слабопрогнозируемыми (потоковое время/Flow Time растягивается, и перспектив завершения не видно). Почему тут надо прерывать рабочий цикл (слова выбраны не случайно; разработчики знают, что иногда надо прерывать цикл, чтобы подпрограмма не выполнялась бесконечно). Если вы заметили, что вошли в "бесконечный цикл", когда вы делаете одно и то же действие (которое не приводит к результату) – например, бесконечно думаете, но ничего не происходит – вам надо закончить работу и показать "что есть".
Обычно в работе это ощущается так: вы (или ваша команда, или ещё какой агент) "застряли" и почти не продвигаетесь, хотя прилагаете усилия. Например, вам нужно принести описание возможной стратегии продвижения продукта – а вы ничего составить не можете, и опция "добавить времени" больше не помогает: вы просто продолжаете тупить в дополнительно выделенное время, признаков продвижения не видно.
В таком случае рекомендуется... идти общаться! Брать имеющиеся наработки – и идти общаться с людьми, которые понимают в теме, в которой вы застряли (subject matter expert).
Почему с людьми? Потому что предполагается, что к этому моменту вы уже пообщались с LLM-ками и выжали из них что можно (в том числе стребовали с LLM список источников информации, отобрали из них более заслуживающие доверия и пошли навскидку проверили, нет ли явных грубых ошибок в вашем совместном с LLM творческом описании).
Вам нужны теперь люди, которые имеют опыт применения мастерства в реальном мире – которые смогут вам указать на всякое неочевидное, что не знает и/или не учтёт LLM (имейте в виду, что проблема "неявного знания"/tacit knowledge сейчас LLM-ками не вполне решается. И общими LLM-ками вряд ли будет когда-либо решена – нужны узкоспециализированные, которые будут заточены под знание конкретной отрасли/предметной области на базе общего "ИИ-интеллекта").
Обратная связь от других людей-специалистов в предметной области – повышает шанс или найти решение проблемы, или передоговориться (о том, что будете решать другую проблему, а эту пока оставите в покое и/или будете раздумывать о ней не спеша, обсуждать её не спеша в режиме "десятого приоритета" в выделенное время). С точки зрения операционного менеджмента это позволяет уменьшить потоковое время – а заодно не превращать распределение потокового времени в жирнохвостое (где с прогнозированием бооольшие трудности, и средние не работают).
В общем, можно сказать, что базовая идея такая: следите за прогрессом, когда он замедлился сильно, переходите к постоянным циклам критики / обратной связи. Несём сделанное для обсуждения (например, чертежи или 3Д модель Крымского моста) и несём критиковать; кладём балку новым способом и показываем окружающим (и получаем по шапке, это обязательно рано или поздно произойдет в цикле критики).
Критика / обратная связь не всегда будет приятной; но она должна быть полезной. Если неприятная форма критики не мешает её воспринимать и принимать, то всё ок, с формой не стоит заморачиваться слишком сильно. Но если вы переборщите, не удивляйтесь, что вашу критику пропустят мимо ушей, будь хоть 100 раз вы умничка и прав. Так что хорошо подумайте, что вам важнее: быть правым/ самым умным/ красивым, или достичь цели. Это ЧАСТО разные штуки)
Часть 5: сигнал(ы) о том, что объект, над которым вы работаете, уже не MVP
Самый общий сигнал: выпуск сильно замедлился, и сроки выпуска становятся слабопрогнозируемыми (потоковое время/Flow Time растягивается, и перспектив завершения не видно). Почему тут надо прерывать рабочий цикл (слова выбраны не случайно; разработчики знают, что иногда надо прерывать цикл, чтобы подпрограмма не выполнялась бесконечно). Если вы заметили, что вошли в "бесконечный цикл", когда вы делаете одно и то же действие (которое не приводит к результату) – например, бесконечно думаете, но ничего не происходит – вам надо закончить работу и показать "что есть".
Обычно в работе это ощущается так: вы (или ваша команда, или ещё какой агент) "застряли" и почти не продвигаетесь, хотя прилагаете усилия. Например, вам нужно принести описание возможной стратегии продвижения продукта – а вы ничего составить не можете, и опция "добавить времени" больше не помогает: вы просто продолжаете тупить в дополнительно выделенное время, признаков продвижения не видно.
В таком случае рекомендуется... идти общаться! Брать имеющиеся наработки – и идти общаться с людьми, которые понимают в теме, в которой вы застряли (subject matter expert).
Почему с людьми? Потому что предполагается, что к этому моменту вы уже пообщались с LLM-ками и выжали из них что можно (в том числе стребовали с LLM список источников информации, отобрали из них более заслуживающие доверия и пошли навскидку проверили, нет ли явных грубых ошибок в вашем совместном с LLM творческом описании).
Вам нужны теперь люди, которые имеют опыт применения мастерства в реальном мире – которые смогут вам указать на всякое неочевидное, что не знает и/или не учтёт LLM (имейте в виду, что проблема "неявного знания"/tacit knowledge сейчас LLM-ками не вполне решается. И общими LLM-ками вряд ли будет когда-либо решена – нужны узкоспециализированные, которые будут заточены под знание конкретной отрасли/предметной области на базе общего "ИИ-интеллекта").
Обратная связь от других людей-специалистов в предметной области – повышает шанс или найти решение проблемы, или передоговориться (о том, что будете решать другую проблему, а эту пока оставите в покое и/или будете раздумывать о ней не спеша, обсуждать её не спеша в режиме "десятого приоритета" в выделенное время). С точки зрения операционного менеджмента это позволяет уменьшить потоковое время – а заодно не превращать распределение потокового времени в жирнохвостое (где с прогнозированием бооольшие трудности, и средние не работают).
В общем, можно сказать, что базовая идея такая: следите за прогрессом, когда он замедлился сильно, переходите к постоянным циклам критики / обратной связи. Несём сделанное для обсуждения (например, чертежи или 3Д модель Крымского моста) и несём критиковать; кладём балку новым способом и показываем окружающим (и получаем по шапке, это обязательно рано или поздно произойдет в цикле критики).
Критика / обратная связь не всегда будет приятной; но она должна быть полезной. Если неприятная форма критики не мешает её воспринимать и принимать, то всё ок, с формой не стоит заморачиваться слишком сильно. Но если вы переборщите, не удивляйтесь, что вашу критику пропустят мимо ушей, будь хоть 100 раз вы умничка и прав. Так что хорошо подумайте, что вам важнее: быть правым/ самым умным/ красивым, или достичь цели. Это ЧАСТО разные штуки)
ИИ-шки, как и среднестатистический человек:
1. Точно так же несут бред
2. Точно так же экономят ресурсы (токены, точнее, вычислительные мощности датацентров)
3. Точно так же не запоминают, если им не скажешь 5+ раз
4. Точно так же фокусируются на неважном, если их не прерывать (особенно если собираете внутри ИИ-шки экспертную панель)
5. Точно так же [эксперты в рамках экспертной панели/команды внутри ИИ] ссорятся между собой и никак не могут определиться, что говорить
6. Точно так же забывают инструкции (и надо напоминать/контролировать их соблюдение), точно так же надо проверять
7. Точно так же дают не самый плохой результат (не самую плохую версию ответа) не с первого раза
8. Точно так же надо просить прокритиковать свое же рассуждение и предложить способы его улучшения
9. Точно так же сдаются, когда просишь их в десятый раз перегенерировать ответ (и точно так же надо подбодрить, когда они сдаются, чтобы попытались ещё)
10. Точно так же нужна модель собеседника, чтобы общаться.
Главное отличие при общении в другом. Когда ты имеешь дело с человеком, тебе надо открыть/discover этого человека, чтобы составить правильную модель собеседника в своей голове (мы общаемся через модели в головах). Ты изначально не знаешь, какой этот человек на самом деле, поэтому требуется постоянно открывать/discover его, чтобы осуществить delivery – собственно коммуникацию.
А когда имеешь дело с ИИ, тебе надо смоделировать себе собеседника (иначе тебе будет отвечать собеседник-пересказчик первых 10 страниц гугла, который говорит на языке, понятном среднему пользователю).
Последние сетки вполне себе могут сносно сделать аватар какого-нибудь специалиста в предметной области (можно прямо сразу моделировать конкретного человека, а можно просто задавать портрет, например, врач-терапевт с 20+ годами стажа, входящий в топ 1% в предметной области), смоделировать его коммуникационный стиль, установить ограничения на выдумывание (в частности, выдумывание списков источников информации). Тогда можно получить не совсем плохое описание, которое уже пригодно для человеческой критики (нормальными специалистами, разумеется), и затем проверять "в бою" отредактированное описание.
Человеческая критика необходима, потому что роботу недоступно озарение, он просто генерирует "что-то подходящее к ситуации", его шкура не на кону, он не умрет, если что-то неправильно скажет (и не будет это проверять в реальности). Но робот может сэкономить время на генерировании гипотез и первых версий описаний – при условии, что ты сам:
– умеешь моделировать (есть фундаментальное онтологическое мастерство),
– знаешь предметную область и продолжаешь её непрерывно исследовать,
– знаешь, как именно общаются ИИ-шки и как эволюционируют способы их общения (где как косячат и где соломки подложить).
1. Точно так же несут бред
2. Точно так же экономят ресурсы (токены, точнее, вычислительные мощности датацентров)
3. Точно так же не запоминают, если им не скажешь 5+ раз
4. Точно так же фокусируются на неважном, если их не прерывать (особенно если собираете внутри ИИ-шки экспертную панель)
5. Точно так же [эксперты в рамках экспертной панели/команды внутри ИИ] ссорятся между собой и никак не могут определиться, что говорить
6. Точно так же забывают инструкции (и надо напоминать/контролировать их соблюдение), точно так же надо проверять
7. Точно так же дают не самый плохой результат (не самую плохую версию ответа) не с первого раза
8. Точно так же надо просить прокритиковать свое же рассуждение и предложить способы его улучшения
9. Точно так же сдаются, когда просишь их в десятый раз перегенерировать ответ (и точно так же надо подбодрить, когда они сдаются, чтобы попытались ещё)
10. Точно так же нужна модель собеседника, чтобы общаться.
Главное отличие при общении в другом. Когда ты имеешь дело с человеком, тебе надо открыть/discover этого человека, чтобы составить правильную модель собеседника в своей голове (мы общаемся через модели в головах). Ты изначально не знаешь, какой этот человек на самом деле, поэтому требуется постоянно открывать/discover его, чтобы осуществить delivery – собственно коммуникацию.
А когда имеешь дело с ИИ, тебе надо смоделировать себе собеседника (иначе тебе будет отвечать собеседник-пересказчик первых 10 страниц гугла, который говорит на языке, понятном среднему пользователю).
Последние сетки вполне себе могут сносно сделать аватар какого-нибудь специалиста в предметной области (можно прямо сразу моделировать конкретного человека, а можно просто задавать портрет, например, врач-терапевт с 20+ годами стажа, входящий в топ 1% в предметной области), смоделировать его коммуникационный стиль, установить ограничения на выдумывание (в частности, выдумывание списков источников информации). Тогда можно получить не совсем плохое описание, которое уже пригодно для человеческой критики (нормальными специалистами, разумеется), и затем проверять "в бою" отредактированное описание.
Человеческая критика необходима, потому что роботу недоступно озарение, он просто генерирует "что-то подходящее к ситуации", его шкура не на кону, он не умрет, если что-то неправильно скажет (и не будет это проверять в реальности). Но робот может сэкономить время на генерировании гипотез и первых версий описаний – при условии, что ты сам:
– умеешь моделировать (есть фундаментальное онтологическое мастерство),
– знаешь предметную область и продолжаешь её непрерывно исследовать,
– знаешь, как именно общаются ИИ-шки и как эволюционируют способы их общения (где как косячат и где соломки подложить).
Почему я приветствую развитие ИИ
Во-первых, если вы хорошо разбираетесь в своей предметной области, вы получаете ускорение в своей предметной области примерно в 10 раз: https://t.me/theworldasaneuralnetworkchat/1364
Во-вторых, вся эта история про ИИ/LLM – это история про экономию ресурсов. Первую версию описания дешевле собрать вместе с командой нежити под кураторством человека, чем бегать за всеми белковыми экспертами и собирать их в одном месте, уговаривать сотрудничать и тп.
Сейчас едва ли не основные траты ресурсов во время работ приходятся именно на координационные акты. "Как сделать" ("как применить метод" и даже "как сформулировать метод") постепенно перестают представлять настоящую проблему. "Как собрать команду и как её уговорить сотрудничать" – куда более весёлый квест.
В-третьих, чем больше распространяется ИИ, чем больше людей его используют, тем больше BS окажется нагенерировано и тем ярче проявится это в работе. Тем больше будет стимулов заниматься развитием личного интеллекта (а не только искусственного) 😉
Умные люди будут ужасаться происходящему и будут стараться спастись от глупости – и спасти окружающих. В общем, нам будет чем заниматься)
Во-первых, если вы хорошо разбираетесь в своей предметной области, вы получаете ускорение в своей предметной области примерно в 10 раз: https://t.me/theworldasaneuralnetworkchat/1364
Во-вторых, вся эта история про ИИ/LLM – это история про экономию ресурсов. Первую версию описания дешевле собрать вместе с командой нежити под кураторством человека, чем бегать за всеми белковыми экспертами и собирать их в одном месте, уговаривать сотрудничать и тп.
Сейчас едва ли не основные траты ресурсов во время работ приходятся именно на координационные акты. "Как сделать" ("как применить метод" и даже "как сформулировать метод") постепенно перестают представлять настоящую проблему. "Как собрать команду и как её уговорить сотрудничать" – куда более весёлый квест.
В-третьих, чем больше распространяется ИИ, чем больше людей его используют, тем больше BS окажется нагенерировано и тем ярче проявится это в работе. Тем больше будет стимулов заниматься развитием личного интеллекта (а не только искусственного) 😉
Умные люди будут ужасаться происходящему и будут стараться спастись от глупости – и спасти окружающих. В общем, нам будет чем заниматься)
Telegram
The World as a Neural Network in The World as a Neural Network Chat
I spent a weekend testing different AI agents (ChatGPT and others) as physics assistants. First, I generated a truly original idea, one that I am confident is not yet known, and confirmed that neither Google nor the AI agents had any knowledge of it. Then…
Обсуждали недавно в чате нового потока "Рациональной работы" (https://system-school.ru/programs/orgdev – кто не знает, что это такое) "вещь/систему, которую создаёт предприятие". И речь зашла, конечно, о предприятиях, которые продают "воздух", не участвуют толком в создании никакой вещи.
Например, в академической среде изрядное количество людей, которые пишут статьи (те делают описания) ради статей, а точнее – ради "плюшек", которые получают за n напечатанных статей (прибавка к зарплате или даже tenure – пожизненный гарантированный найм для преподавателя).
Есть и коммерческие (на первый взгляд) организации, которые проводят исследования безопасности использования ИИ для политиков: https://systemsworld.club/t/veshh-v-sozdanii-kotoroj-uchastvuet-predpriyatie-zadanie-9-3-iz-kursa-1-1-raczionalnaya-rabota/24031.
Но если результаты работ такой компании используются, чтобы та или иная политическая группировка получила побольше политического (и экономического, и силового) ресурса под крик "ИИ небезопасно, давайте запретим!", то по сути, о существовании какой-то вменяемой/адекватной вещи говорить не приходится. Компания если и участвует в создании, то в создании политической группировки в состоянии "получила власть (прибавку к власти)". О воплощении в жизнь адекватных экономических решений в области ИИ тут говорить не приходится.
Точно так же можно продавать "косметику" (какую-то определённую), а можно – пустые обещания что-то изменить во внешности человека.
Все эти ситуации объединяет одно – создатели, не участвующие в создании какой-то вещи, меняющей мир (и желательно – к лучшему), фактически участвуют в создании очередного "МММ", которое нужно исключительно для обеспечения благосостояния его основателей.
Участвовать ли в очередном изводе МММ – личный выбор каждого. К нам в МИМ/ШСМ обычно приходят люди, которым не интересно создавать МММ, а интересно менять мир к лучшему. Очень приятно работать с такими людьми ❤️
Например, в академической среде изрядное количество людей, которые пишут статьи (те делают описания) ради статей, а точнее – ради "плюшек", которые получают за n напечатанных статей (прибавка к зарплате или даже tenure – пожизненный гарантированный найм для преподавателя).
Есть и коммерческие (на первый взгляд) организации, которые проводят исследования безопасности использования ИИ для политиков: https://systemsworld.club/t/veshh-v-sozdanii-kotoroj-uchastvuet-predpriyatie-zadanie-9-3-iz-kursa-1-1-raczionalnaya-rabota/24031.
Но если результаты работ такой компании используются, чтобы та или иная политическая группировка получила побольше политического (и экономического, и силового) ресурса под крик "ИИ небезопасно, давайте запретим!", то по сути, о существовании какой-то вменяемой/адекватной вещи говорить не приходится. Компания если и участвует в создании, то в создании политической группировки в состоянии "получила власть (прибавку к власти)". О воплощении в жизнь адекватных экономических решений в области ИИ тут говорить не приходится.
Точно так же можно продавать "косметику" (какую-то определённую), а можно – пустые обещания что-то изменить во внешности человека.
Все эти ситуации объединяет одно – создатели, не участвующие в создании какой-то вещи, меняющей мир (и желательно – к лучшему), фактически участвуют в создании очередного "МММ", которое нужно исключительно для обеспечения благосостояния его основателей.
Участвовать ли в очередном изводе МММ – личный выбор каждого. К нам в МИМ/ШСМ обычно приходят люди, которым не интересно создавать МММ, а интересно менять мир к лучшему. Очень приятно работать с такими людьми ❤️
Мастерская инженеров-менеджеров
Рабочее развитие
Поднять свою квалификацию в создании и развитии самых разных систем, от классических "железных" и программных до организационных и сообществ.
Как вы, возможно, уже знаете, большая стажировка по "Рациональной работе" будет распилена на 4 стажировки поменьше:
1. Распожаризация: как не "тушить пожары" на работе, а избегать их появления.
2. Моделирование как основа коммуникации и лидерства.
3. Рабочее моделирование в инженерии и менеджменте.
4. Причинность, интервенции и контрфактичность в инженерии и менеджменте.
Руководства в интерфейсе AIsystant тоже будут распилены на 4 отдельных руководства. И материал в них будет обновлён!
Я уже начала переписку раздела 1 – и перепилила половину подразделов. Подразделы стали покороче и, надеюсь, попонятней, там добавлены алгоритмы, например, алгоритм проверки, не спутали ли вы вещь и действие. Дальше в раздел будет добавлен материал по различению моделей и описаний (чего сейчас не хватает).
Иии разделы по моделированию, которые будут в "Распожаризации", тоже изменятся. Текущий раздел 2 "Что такое онтологическая работа" будет переназван (рабочее название – "Отслеживать трату ресурсов") и начинаться будет с описания точки зрения операционного менеджера. Как думает (или должен думать) операционный менеджер, как связаны трата ресурсов и проход, и так далее.
После чего собственно расскажем, что такое "роль", "viewpoint", "индивид", "категория/класс", "отношения" и тп.
Надеюсь, нашим инженерам-менеджерам понравится такой подход и станет легче применять материал руководств в жизни! ❤️
1. Распожаризация: как не "тушить пожары" на работе, а избегать их появления.
2. Моделирование как основа коммуникации и лидерства.
3. Рабочее моделирование в инженерии и менеджменте.
4. Причинность, интервенции и контрфактичность в инженерии и менеджменте.
Руководства в интерфейсе AIsystant тоже будут распилены на 4 отдельных руководства. И материал в них будет обновлён!
Я уже начала переписку раздела 1 – и перепилила половину подразделов. Подразделы стали покороче и, надеюсь, попонятней, там добавлены алгоритмы, например, алгоритм проверки, не спутали ли вы вещь и действие. Дальше в раздел будет добавлен материал по различению моделей и описаний (чего сейчас не хватает).
Иии разделы по моделированию, которые будут в "Распожаризации", тоже изменятся. Текущий раздел 2 "Что такое онтологическая работа" будет переназван (рабочее название – "Отслеживать трату ресурсов") и начинаться будет с описания точки зрения операционного менеджера. Как думает (или должен думать) операционный менеджер, как связаны трата ресурсов и проход, и так далее.
После чего собственно расскажем, что такое "роль", "viewpoint", "индивид", "категория/класс", "отношения" и тп.
Надеюсь, нашим инженерам-менеджерам понравится такой подход и станет легче применять материал руководств в жизни! ❤️
Livejournal
lytdybr
С удивлением обнаружил, что последний lytdybr писал ещё в середине сентября, пару месяцев назад. После этого записи все были по определённой тематике и заголовки поэтому соответствующие. Но нельзя сказать, что ничего не происходит. Происходит, но как и раньше…