Очередной разбор: ювелирка, банкротство, ЦОД, договорка купли-продажи. Ещё супервизия в одной из корпоративных групп, там разговаривали про сервисы и customer journey. В следующий четверг проведу последний разбор в объявленной серии. Везде одно и то же, в разных предметных областях, с системами разной природы. Вот некоторое количество болей, которые открылись на наших разборах по системному мышлению и надо принимать какие-то решения, как это чинить (ибо проблемы даже у тех, у кого я этих проблем уже не ожидал увидеть, надо ещё раз поглядеть – что в наших руководствах и заданиях делается, чтобы этих проблем не было. Может, добавить “фундаментальные мантры/промпты”, чтобы на это мочь тренировать? Ибо материалы по большей части понимаются, но не применяются – “слишком всего много, непонятно за что хвататься, надо бы маршрут”. Вопрос больше методический, чем методологический: понятно, чему учить, не очень понятно, как):
– неудержание внимания на говоримом, несобранность на удержании связности рассуждения. Там две проблемы: замечание логических ошибок на уровне формального использования идентификаторов/лексем (скажем: “моя целевая система – это часть табуретки” означает, что нам дана безымянная по факту система, это не сразу понимается, что “имя части отсутствует”). Там проблема про “слова важны и неважны”: отсутствие работы на лексическом уровне (ситуации типа “косил косой косой косой”: использование одного термина для разных типов, ситуации отнесения термина к предметной области, в том числе к уровню абстракции, неотслеживание собственной речи – “результатом коммуникации является результат, а не намерение”, то есть внутренняя речь и внешняя идут, например, на разном уровне абстракции, это не замечается, то есть “выбор слов” идёт неверный). Высказывания типа “бухгалтер действует как юрист” не парсятся в плане что там роль, а что должность, метонимии не замечаются (роль главного бухгалтера – идёт “на ура”, рассуждение дальше про роль, но термин должности. Когда идёт перескок с роли на должность не замечается ни у себя, ни у других). Отглагольные существительные как глаголы – это боль (тестируют не знаки на что там денотат, а на “часть речи”).
– плохая работа с предметными областями в их раскладке по уровням абстракции/метамоделирования. Ситуация “нет слов из предметной области, тест – хлебопечки подходят” или “вы не покрыли все ситуации, приводите частный пример, хлебопечки не попали”. Тут, мне кажется, ключевое: недообъяснение.
– неудержание 4D объекта, “вещи”. Это без эмерджентности, без отнесения к предметным областям. Просто чтобы не было поведением, информацией, свойством, отношением. Проблема в собранности: в рассуждениях даже при выявлении этого объекта – вместо объекта в речи легко появляются другие объекты, или описание объекта, или поведение объекта, причём иногда как метонимии, а иногда и просто от невнимательности, “поток сознания”. Это на стыке с лексикой (называют плохо, собранности нет на однозначности использования лексики), но нет понимания уровня абстракции для разговора о предметной области, понимания предметной области как таковой, поэтому лексика тыкается наугад. То есть “предметная область” и “вещь” тесно связаны: вещь мало определить как вещь, её надо как-то отнести к предметной области и дать на правильном уровне рассказа о предметной области. Тренинг разговора с удержанием нескольких уровней абстракции (“система самолёт функция летит”).
– собственно системное рассуждение: собрать все части вещи (а не некоторые) и договориться о границе с окружением, понять функцию вещи в окружении и эмерджентность, разные состояния вещи в их отличии от других вещей (например, бабочка и куколка в отличие от усиков бабочки). Для этого надо убедиться, что вещь, а также уметь всё это правильно назвать. Вот тут “скачок во время эксплуатации/использования, то есть в будущее, а также скачок референтного индекса: customer eXperience”. Удержание рассуждение чёрного ящика, но при этом надо собрать все части системы, чтобы убедиться, что граница чёрного ящика проходит не внутри системы, а по границе всех её частей.
– выход в операционный менеджмент: проверка на то, что можно посчитать выпуск. О чём беседовать с CEO.
– собранность на мантре/промпте: разбирательство с целевой системой, а не соскальзывание к своей, собственно системность: “взгляд сначала вовне, потом на то, что в руках”. Но это уже так далеко, что можно не обсуждать: без решения предыдущих проблем не получается.
– выход в методологию: что делаешь с каким предметом метода, как предмет метода связан с какой системой. Далее выход к описанию графа создателей – и ходы на причинно-следственные описания связи твоей работы с ускорением выпуска. Отдельный вопрос про ролевые фантазии вместо рассуждений про метод, но тут важней вообще ход на то, что твой проект (скажем, описание какой-то системы, ибо вначале это “моя целевая система – это описание”, или “наша целевая система” вообще без упоминания целевой) как-то связан с выпуском целевой.
У нас есть чаты поддержки личного, рабочего и исследовательского развития инженеров-менеджеров, и в терминах того же телеграма эти чаты могли бы быть чатами каналов. Что обычно пишут каналы? Новости, и надо разобраться, новости чего могут быть (для меня это развитие темы “эскиз клубного AI-проекта”, Эскиз клубного AI-проекта: ailev — LiveJournal, но там “в общем виде”, а тут надо задать какой-то образец). Мне кажется, что это могут быть новости трёх тем, трёх подканалов:
– культуртрегерский подканал: новости методов мышления. Что нового появилось в мире (тренды), что может претендовать на интеграцию в текущий текст руководств, что это поменяет в жизни? Что не работает или устарело и заменено новым, поэтому должно быть выкинуто из руководств (deprecation alert)? Diff между фронтиром “в жизни” и текстом руководств. Подняли голову – и смотрим на горизонт. Главное, чтобы не увидеть всю вселенную на горизонте, иначе этот поток новостей всё смоет. Нужен жёсткий фильтр значимости (собственно, культуртрегерская работа).
– подканал разработки, новости разработчиков (команда создателей руководства, инженерный процесс разработки, новые фичи/версии, методология и методика): Если считать, что мы разрабатываем какие-то новые версии стандартов мышления, то это “новости комитета по стандартизации”: новости про новые версии (release notes), rationale/ADR изменений, планы по issue tracker и roadmap, изменения в инструментарии разработки, методы работы команды разработчиков руководств и знакомство с членами команды (meet-the-team), ответы на частые вопросы про разработку, дополнительные материалы, которые в руководство не вошли и ведение репозитория таких материалов. Поход documentation as a code, похоже на ведение новостной ленты по какой-то софтовой разработке. То, что это руководства/регламенты и работа по ним, снимает все вопросы по “почему вы так часто их меняете, мы не успеваем учиться”: на работе таких вопросов не задают, и это работа/стажировка. Но зато на работе надо отслеживать изменения регламентов/стандартов/руководств, этому и помогаем. Заглядываем на кухню, смотрим за качеством приготовления того, что потом надо будет есть.
– подканал освоения (learning and adoption) работы по руководствам: новости освоения работы по руководствам (там формулировки по типу “освоение методологической работы на основании нашего руководства”, то есть не “освоение руководства”, а освоение работы по руководству, а имя руководства уходит в название метода работы, и это в серой зоне между “инвестированием времени” и “получение пользы от уже сделанных инвестиций”, это же “работа по регламенту”!). Новые мероприятия, новости LXP (learning eXperience platform), запуск стажировок и корпоративных программ, последовательность освоения, рекомендации по миграции знаний на новые версии, инструментарий для работы по руководствам, как лучше выполнять задания, квалификации (как их получить, “как подготовиться к собеседованию”, метрики в сообществе – состав по квалификациям, прохождения заданий, разбор частых ошибок), истории успеха инженеров-менеджеров из сообщества, где и как пообщаться по поводу обмена опытом, запросы на помощь разработчикам, куда устроиться на работу. Новости культурной жизни: как приобщиться к культуре и что происходит в сообществе.
Всё это близко пересекается с темой “вертикальных AI-агентов”. “Вертикальный” – это отсылка к domain specific agents, а сегодня это почти синоним для domain specific LLMs. У меня на эту тему был даже большой пост “Предметно-ориентированность непредметно-ориентированных моделей”, Предметно-ориентированность непредметно-ориентированных моделей: ailev — LiveJournal. Но смена терминологии с языка разработчиков (domain specific) на язык экономистов (Vertical markets, or “verticals,” are business niches where vendors serve a specific audience and their set of needs. Vertical markets are increasingly being served via ecommerce businesses because of the minimal overhead and ability to reach a worldwide audience) ведёт к смене аспекта: vertical agents это “новый SaaS”, то есть вычислительная парадигма в распределённых вычислениях цивилизации. В разговоре о них в https://www.youtube.com/watch?v=ASABxNenD_U говорится о том, что структурирование рынка там может идти примерно так же, как прошло в SaaS, и черты этого уже видны: 1. Массовые потребительские продукты типа гугля, а в AI – Siri, ChatGPT, Gemini. Тут крупные корпорации, у остальных нет шансов. 2. Неочевидные потребительские продукты, это были “маркетплейсы”: уберизация всея мира, AirBnb, Doordash (доставка еды в тот же день, 56% американского рынка), в агентах “неочевидные массовые AI-агенты” шанс для стартапов. Ну, и 3. Вертикальные AI-агенты для B2B (предыдущие были для потребительских рынков) под специфические задачи. Думать нужно примерно по той же линии, что описана в руководстве по системному мышлению: софт сам по себе обычно бесполезен без команды, которая жмёт на нём кнопочки, поэтому граница системы проекта разработки корпоративного софта должна проводиться чаще всего не по границе собственно софта, а по границе команды его пользователей. Вот эти “вертикальные AI-агенты” как раз отражают этот сдвиг – замена команд, которые пользовались корпоративным софтом. Тут шанс для огромных стартапов, ибо это чаще всего замена скучной рутинной производственной и административной работы (что-то там вокруг производственных/административных платформ, тренд на автоматизацию DevOps труда, “безлюдное производство”) или “грязная и опасная работа” (робототехника), а на зарплату команд корпорации тратили деньги больше, чем на SaaS софт. Тут же “команда+SaaS по цене SaaS или совсем немного больше”. Интересные советы: никогда не продадите AI-агента команде, которую агент должен заменить, поэтому продажи идут только топ-менеджерам, а топ-менеджеров на эту тему надо доучивать: чтобы не купили себе проблемы вместо их решения (есть уже много примеров отката с AI-агентов на людей ввиду проседания качества работы, но это, понятно, временное явление, будет быстро уходить – и будет наоборот, как в беспилотном вождении, “лучше людей”, и это будет основной причиной, даже не экономика. Просто “лучше качество работы, твоя бабушка так не свяжет” – точность, безошибочность, скорость, а не “не болеет, нет профсоюза, не матерится, не уходит в запой”). Новый инструментарий для вертикалей вроде https://vectorshift.ai/ – там смесь no-code платформы, code SDK (через IDE и API), marketplace, agents, search и всё-всё всё для офисной автоматизации, что должно заместить все эти Oracle Suits – фишка в том, что предприятия не понимают, какие им нужны агенты, поэтому они берут “агентский SDK для вертикальных агентов” и дальше делают сами себе кастомных вертикальных агентов – это отражение подхода agile, ибо у них там по ходу дела меняется вообще всё, а агент должен обладать evolvability, вот такие платформы и дают агента с как-то гарантированной evolvability.
Теперь принимаем к сведению предыдущий абзац, и начинаем сочинять стартап – это ещё один рассказ о мастерской инженеров-менеджеров, только с акцентом на корпоративные программы и заменой наставников на Aisystant, который становится совсем уж AI-агентом с узкой/вертикальной специализацией. Решаемая проблема – evolvability/развиваемость инженеров-менеджеров. Спич-питч мог бы быть вроде: “Инженеры и менеджеры постоянно сталкиваются с необходимостью осваивать новые методы работы, реагируя на изменения в технологиях и рыночной ситуации. Мы считаем, что в компании нужно развивать и инженеров, и менеджеров, поэтому выбрали термин инженер-менеджер, это заодно учитывает, что у многих сотрудников сочетаются и инженерные, и менеджерские функции. Необходимость быстрого развития и отдельных инженеров-менеджеров, и быстрого развития всей организации попадает в серую зону ответственности HR (ответственность за evolvability/развиваемость как отдельных инженеров-менеджеров, так и корпоративной культуры, поддерживающей развитие, в сообществе сотрудников организации – формирование и поддержание культуры непрерывного обучения/развития), CTO (направление развития: чему именно надо непрерывно доучивать инженеров в каждый отдельный момент времени, поддержание быстрой адаптации команд к новым технологиях и удержание качества инженерных решений) и CEO (в части содержательного направления развития менеджеров: какие новые методы и инструменты менеджмента будут развиваться в компании, а также удержания и развития стратегии компании менеджерами, равно как развитие лидерских качеств у инженеров по мере прихвата ими менеджерских работы в ходе роста масштаба их проектов, планирование преемственности/succession planning). HR понимает, что нужно развивать, но ничего не может сказать про направления развития: HR не понимает ни в инженерии, ни в менеджменте, он понимает в людях и сообществах с их корпоративной культурой, безотносительно содержания того, чем эти люди и сообщества занимаются. А CTO и CEO понимают в инженерии и менеджменте соответственно, понимают, чем заняты сотрудники сейчас и чем должны будут заняты в ходе развития – и методы работы текущие, и методы и предметы работы будущие (то есть техническая и корпоративная стратегия) как раз у них. В любом случае, в компании надо удерживать развиваемость/evolvability как архитектурную характеристику и для отдельных сотрудников, и для компании в целом, а также надо непрерывно стажировать людей по новым методам работы (в том числе новых сотрудников: для них текущий метод работы в организации – новый, а ещё сотрудников надо доучивать, чтобы они могли расти по карьерной лестнице, например, увеличивали долю профессионально, а не по наитию, выполняемых менеджерских работ). Это личное и рабочее развитие сотрудников, а также удержание развития организации в целом надо как-то делать без отрыва сотрудников от работы: пока они учатся, текущую работу за них выполнять никто не будет. Традиционное обучение (курсы, тренинги, корпоративные университеты) часто оторвано от реальных проблем, занимает много времени и не всегда успевает за рынком, а также не ориентировано на удержание корпоративной культуры развиваемости. Мы предоставляем AI-агентов как наставников, которые интегрируются в ежедневный рабочий процесс инженеров-менеджеров вашей компании, проактивно выявляют их пробелы в их уровне рабочего развития в контексте текущих и будущих задач, а также помогают справиться и с прикладными задачами: текущей, и будущей работой. В отличие от конкурентов, мы не просто обучаем конкретным, быстро меняющимся прикладным технологиям для тех или других инженерных и менеджерских новых методов работы. Наши AI-наставники (индивидуальный Aisystant для каждого сотрудника) формируют у ваших сотрудников современную “картину мира” – глубокое понимание принципов системного рационального мышления, творческого решения проблем и эффективного самообучения/саморазвития. Эта современная картина мира позволяет им быстрее осваивать требуемые техническими и корпоративными стратегиями новые методы и инструменты, повышая развиваемость (evolvability) как отдельных инженеров-менеджеров, так и всей организации. Таким образом, Aisystant помогает HR формировать культуру личного и корпоративного развития, поддерживать готовность к изменениям, CTO – внедрять технологические новации, а CEO – достигать стратегических целей через высокоадаптивные и компетентные команды, где инженеры берут на себя и часть менеджерских функций”. Это, конечно, ещё надо почистить (любая LLM даст 100500 замечаний, как это улучшить), но вы наверняка поняли идею. Для меня же это очередной рассказ о том, чем мы занимаемся по линии b2b рынка (и даже тут ещё надо отстроиться от многочисленных предложений по линии talent development и почистить так, чтобы это не читалась как идея заменить людей у HR и CTO, наоборот, убрать лишний заход в их функции, сохранить узкую вертикальную специализацию на личном, рабочем, исследовательском развитии инженеров-менеджеров), а не b2c – это ведь описание корпоративного предложения, для инженеров-менеджеров “с улицы” надо говорить иначе.
Намеренно эпатажная картинка (несамо)развития инженеров-менеджеров, алармистам и художественным натурам – аларм, неприкрытый троллинг, “игнорирование интересов людей детектед” (или наоборот, неигнорирование, там же явно ситуация выращивания, а не эксплуатации-насилия?! Ах, какая этическая серая зона!). В компании это же “инженерно-менеджерский состав”, а не инженеры-менеджеры, чётко выражает в b2b предложении другой области интересов, других по факту объектов. Помним, что каждая роль конструирует свой мир: “встать в позицию другой роли – это по факту получить не новый набор фич для своего объекта, это получить новую реальность с новыми объектами, и вопрос совпадения со старой реальностью сразу проблематичен. Это не “чайник тёплый” и “чайник розовый” для одного чайника, который находим в жизни, и в проекте надо ещё договориться, что речь идёт о чайнике и зачем вообще нам понадобилось рассматривать чайник, как он связан с целевой системой. Там вообще обычно будет не чайник и про чай разговора не будет, и все связи с объектами другие и объекты другие – и заземления не будет, его надо будет искать специально. Очень трудно скакнуть в чужую реальность, там увидишь не другие фичи знакомых объектов, а вообще другой мир, другие объекты в других отношениях. Мы учим сразу заземлять на объекты материального мира, чтобы договориться и про другие интересы других ролей (и то, что у тебя самого интересы, а не “общий взгляд системного мыслителя”). Но вот эта тренировка выхода в eXperience другого – она нужна, встать в позицию другой роли, увидеть вообще другой мир, а не новое свойство знакомого тебе объекта” – это из пятого абзаца в lytdybr: ailev — LiveJournal).
