У меня первая мысль на такие новости простая: LLM часто не решает системные проблемы, а усиливает их.
Если в компании данные неструктурированы, неконсистентны и местами просто семантически неверны, модель не превратит это в знание. Она начнёт генерировать поверх этого хаоса убедительные, но нестабильные ответы.
Причём проблема обычно глубже, чем кажется. Data-специалист может привести поля к правильным типам и формату, но если он изолирован от бизнес-логики, то он часто не увидит, что с фронтов в принципе приходит не тот смысл, который должен приходить.
То есть дефект может быть не технический, а процессный. И именно такие дефекты компании хуже всего замечают и почти никогда не умеют нормально оценивать. Система вроде бы работает, но работает слабо прогнозируемо.
Поэтому на неподготовленной среде вместо буста бизнеса очень легко получить буст проблем. А реальный эффект появляется только там, где сначала навели порядок в данных, процессах и управленческой логике.
Тут хорошо видно, что процесс держится на личности, а не на системе.
Пока руководитель вручную собирает всё по чатам, разговорам и памяти людей, это работает только за счёт его личного ресурса.
На мой взгляд, правильнее было бы не улучшать этот героизм, а постепенно выстраивать полуавтоматический контур: короткий регулярный шаблон сбора кейсов, материалов, изменений и болей, а уже потом редактура и упаковка в рассылку.
Живой тон письма можно оставить человеческим, но сбор сырья для него не должен каждый месяц быть ручной экспедицией
Я вообще с большой осторожностью отношусь к любым статьям, построенным на опросах.
Опросы → это отдельная и довольно ювелирная область, тесно связанная с социологией, когнитивными искажениями и формулировками вопросов. Очень многое зависит не только от того, кого опрашивали, но и от того, кто проектировал сам опрос, как именно были заданы вопросы, как собирались, интерпретировались ответы и какая цель была изначально как гипотеза.
Без изучения методологии, формулировок и компетенции авторов такие результаты легко становятся инструментом манипуляции, иногда даже без прямого злого умысла. Люди нередко отвечают не то, что реально делают или думают, а то, что им кажется правильным, ожидаемым или просто удобным в моменте.
В этом смысле очень показателен подход из книги Роб Фитцпатрика «Спроси маму»: люди часто врут не специально, а просто из-за природы человеческого общения и самоописания. Поэтому любые выводы из опросов надо делать крайне аккуратно.
При этом сами опросы, конечно, важны. Это один из способов нащупать массовые паттерны и гипотезы. Но именно как отправная точка для дальнейшего анализа, а не как готовая истина.
Тут, на мой взгляд, проблема вообще не столько в AI, сколько в примитивном верхнеуровневом управлении без понимания реального процесса.
Классическая ошибка — считать только “чистое время операции” и игнорировать всё сопутствующее: подготовку, переключение контекста, проверку результата, фиксацию, завершение работы и переход к следующей задаче.
Условно, если приём пациента длится 20 минут, на бумаге кажется, что можно принять 3 человека в час. А в реальности нужно ещё завершить фиксацию по предыдущему, подготовиться к следующему, переключиться, уточнить детали — и реальная пропускная способность по факту 2.
С AI та же история. Руководство часто видит только “скорость генерации ответа”, но не учитывает время на постановку задачи, проверку, сравнение вариантов, правки, перепроверку фактов и встраивание результата в рабочий процесс.
Поэтому перегруз создаёт не сам AI, а плохой расчёт процесса. Если не учитывать полный цикл работы, система почти неизбежно будет перегружена.
Добавил бы главный критерий: рефакторинг нужен только там, где текущая реализация уже создаёт реальную проблему. Рефакторить ради рефакторинга → плохая инженерная практика.
Обычно больше пользы даёт точечная работа по самым нагруженным и болезненным местам системы, чем попытка “оздоровить всё сразу”.
Плюс рефакторинг → вещь ювелирная: более красивый вариант кода не всегда быстрее и надёжнее в реальном исполнении. Это проверяется не вкусом разработчика, а практикой, нагрузкой и фактическим поведением системы.
И да смешивать рефакторинг с изменениями поведения просто нельзя. А сами шаги должны быть максимально маленькими, изолированными и откатными.
История с ИИ и «заменой разработчиков» ранее уже была в другом виде.
Когда появлялись коробочные решения, тоже говорили: теперь программисты не нужны → любой менеджер сможет всё собрать сам. На практике оказалось иначе.
Бизнес почти всегда выходит за рамки стандартной логики. И в какой-то момент любой инструмент упирается в границу, где «должно работать, но не работает».
И вот здесь уже нужен разработчик: залезть вглубь, разобраться, где именно ломается логика, и собрать кастомное решение.
Поэтому по факту это не замена, а усиление. Инструменты ускоряют работу и позволяют делать больше за единицу времени, но не убирают потребность в экспертизе.
Более того с ростом возможностей растут и ожидания. И спрос на таких специалистов не падает, а наоборот увеличивается.
ИИ сейчас делает ровно то же самое: он не убирает проблему, а масштабирует её.
И если изначально процесс кривой, то с ИИ это просто становится видно быстрее и больнее.
Есть ощущение, что как и «overqualified», так и «найм по вайбу» часто маскируют одну и ту же проблему → несовпадение скорости человека и системы.
Когда приходишь в компанию, где 5–10 лет всё работало в стабильном режиме, любые попытки ускорить процессы автоматически создают напряжение. Не потому что изменения плохие, а потому что система выстроена под другую скорость и уровень требований.
В итоге человек, который даёт результат, начинает восприниматься не как усиление, а как источник риска: он затрагивает устоявшиеся связи, зоны ответственности и неформальный баланс.
И дальше у системы всего два сценария: либо она его «переваривает» и замедляет, либо выталкивает.
Поэтому вопрос не только в найме, а в готовности компании к изменениям. Без пересмотра базовых принципов и культуры один «сильный игрок» почти никогда не меняет систему → она меняет его быстрее.
Вспоминается известный эксперимент с обезьянами: в клетке висит банан, но как только одна из обезьян пытается к нему полезть → всех обливают холодной водой. В итоге обезьяны начинают сами останавливать любого, кто тянется к банану.
Дальше по одной заменяют всех обезьян на новых, которые не знают про воду. Но каждый раз, когда новичок тянется к банану, его уже бьют остальные → хотя никто из них сам не сталкивался с наказанием.
В итоге формируется поведение без понимания причины.
С людьми можно выстраивать похожие механики через стимулы и закрепление. Но у человека есть возможность осмыслить свои действия и решить, продолжать их или нет.
Поэтому ключевая задача не просто сформировать привычку, а чтобы в процессе у пользователя появился собственный смысл продолжать.
Геймификация может запустить поведение, но устойчивость появляется только тогда, когда оно держится не на стимуле, а на внутренней ценности.
Feedback loops — безусловно мощный инструмент, но это → усилитель.
Если воронка не выстроена, они просто ускоряют сжигание денег 🔥
Поэтому сначала → нормальная логика процесса и конверсии, и только потом геймификация как способ масштабировать уже работающую модель прибыли, а не убытков.
Здесь пользователь просто убирает промежуточное звено. Это уже ближе к хобби, а хобби мы не называем работой, потому что это про удовольствие, а не про обязательство.
Суть геймификации → формирование устойчивого поведения, а не «черрипикинг» краткосрочных всплесков активности.
Если без стимуляции поведение не сохраняется, значит, работает не ценность продукта, а сама механика. А это уже риск для долгосрочного удержания.
Более рабочий вариант → не обходить, а вовлекать изначально.
Если вопрос критичный, логичнее сразу включать генерального в повестку с участием всех принимающих решения. Тогда это выглядит как нормальный управленческий процесс, а не как эскалация через голову, которая часто воспринимается как подрыв роли руководителя.
И термин «продажа» здесь, на мой взгляд, как раз уместен.
Суть не в формальном согласовании, а в том, чтобы лица, принимающие решения, действительно приняли и поняли трансформацию. Только тогда она доходит до результата.
Если изменения идут «из-под палки», на уровне исполнения часто возникает формальное выполнение или ошибки, которые могут подорвать весь процесс.
Из практики — на длинных трансформациях это особенно заметно.
Тезис про «создание проблем» скорее выглядит как удачный маркетинговый крючок. Он легко считывается, потому что у многих пользователей есть эмоционально окрашенные воспоминания о платных ограничениях, paywall-механиках или игровых бустах.
Но устойчивые цифровые продукты, как правило, строятся на более тонкой работе с поведением пользователя - через снижение трения, формирование привычек, сетевые эффекты и глубокое понимание пользовательских сценариев.
Большие деньги почти никогда не делаются на раздражении пользователя. Обычно они появляются там, где продукт становится частью регулярного поведения или инфраструктуры пользователя.
Критерий фальсифицируемости → действительно сильная идея.
Но иммунизация, кажется, возникает не только в дискуссиях. Это скорее общий механизм человеческого мышления. Когда новая информация противоречит привычной картине мира, возникает когнитивный диссонанс, и первая реакция часто защитная → «этого не может быть».
В этом смысле иммунизация может быть не столько ошибкой мышления, сколько естественным механизмом сохранения внутренней согласованности.
В статье хорошо описана теоретическая сторона процессного подхода, но, как мне кажется, немного недооценена организационная реальность внедрения процессов - то, что автор как раз предложил обсудить в комментариях :)
На практике процессы редко проектируются с чистого листа. Чаще они возникают как результат быстрого запуска продукта или MVP и постепенно обрастают сложностью. Со временем формируется своего рода «процессный технический долг», и исправление таких процессов требует уже не только методологии, но и серьёзных организационных изменений.
Кроме того, специалисты по процессам на практике выступают не только как аналитики, но и как внутренние консультанты и переговорщики. У них редко есть прямые управленческие полномочия, поэтому большинство изменений приходится фактически → «продавать» владельцам процессов и руководителям подразделений.
И именно в этой точке - где сталкиваются интересы разных подразделений - процессные инициативы чаще всего либо трансформируются, либо останавливаются.
Information
Rating
2,684-th
Location
Кольцово, Новосибирская обл., Россия
Date of birth
Registered
Activity
Specialization
Системы принятия решений и управление рисками, Архитектор бизнес-процессов и систем решений
У меня первая мысль на такие новости простая: LLM часто не решает системные проблемы, а усиливает их.
Если в компании данные неструктурированы, неконсистентны и местами просто семантически неверны, модель не превратит это в знание. Она начнёт генерировать поверх этого хаоса убедительные, но нестабильные ответы.
Причём проблема обычно глубже, чем кажется. Data-специалист может привести поля к правильным типам и формату, но если он изолирован от бизнес-логики, то он часто не увидит, что с фронтов в принципе приходит не тот смысл, который должен приходить.
То есть дефект может быть не технический, а процессный. И именно такие дефекты компании хуже всего замечают и почти никогда не умеют нормально оценивать. Система вроде бы работает, но работает слабо прогнозируемо.
Поэтому на неподготовленной среде вместо буста бизнеса очень легко получить буст проблем. А реальный эффект появляется только там, где сначала навели порядок в данных, процессах и управленческой логике.
Тут хорошо видно, что процесс держится на личности, а не на системе.
Пока руководитель вручную собирает всё по чатам, разговорам и памяти людей, это работает только за счёт его личного ресурса.
На мой взгляд, правильнее было бы не улучшать этот героизм, а постепенно выстраивать полуавтоматический контур: короткий регулярный шаблон сбора кейсов, материалов, изменений и болей, а уже потом редактура и упаковка в рассылку.
Живой тон письма можно оставить человеческим, но сбор сырья для него не должен каждый месяц быть ручной экспедицией
Я вообще с большой осторожностью отношусь к любым статьям, построенным на опросах.
Опросы → это отдельная и довольно ювелирная область, тесно связанная с социологией, когнитивными искажениями и формулировками вопросов. Очень многое зависит не только от того, кого опрашивали, но и от того, кто проектировал сам опрос, как именно были заданы вопросы, как собирались, интерпретировались ответы и какая цель была изначально как гипотеза.
Без изучения методологии, формулировок и компетенции авторов такие результаты легко становятся инструментом манипуляции, иногда даже без прямого злого умысла. Люди нередко отвечают не то, что реально делают или думают, а то, что им кажется правильным, ожидаемым или просто удобным в моменте.
В этом смысле очень показателен подход из книги Роб Фитцпатрика «Спроси маму»: люди часто врут не специально, а просто из-за природы человеческого общения и самоописания. Поэтому любые выводы из опросов надо делать крайне аккуратно.
При этом сами опросы, конечно, важны. Это один из способов нащупать массовые паттерны и гипотезы. Но именно как отправная точка для дальнейшего анализа, а не как готовая истина.
Тут, на мой взгляд, проблема вообще не столько в AI, сколько в примитивном верхнеуровневом управлении без понимания реального процесса.
Классическая ошибка — считать только “чистое время операции” и игнорировать всё сопутствующее: подготовку, переключение контекста, проверку результата, фиксацию, завершение работы и переход к следующей задаче.
Условно, если приём пациента длится 20 минут, на бумаге кажется, что можно принять 3 человека в час. А в реальности нужно ещё завершить фиксацию по предыдущему, подготовиться к следующему, переключиться, уточнить детали — и реальная пропускная способность по факту 2.
С AI та же история. Руководство часто видит только “скорость генерации ответа”, но не учитывает время на постановку задачи, проверку, сравнение вариантов, правки, перепроверку фактов и встраивание результата в рабочий процесс.
Поэтому перегруз создаёт не сам AI, а плохой расчёт процесса. Если не учитывать полный цикл работы, система почти неизбежно будет перегружена.
Добавил бы главный критерий: рефакторинг нужен только там, где текущая реализация уже создаёт реальную проблему. Рефакторить ради рефакторинга → плохая инженерная практика.
Обычно больше пользы даёт точечная работа по самым нагруженным и болезненным местам системы, чем попытка “оздоровить всё сразу”.
Плюс рефакторинг → вещь ювелирная: более красивый вариант кода не всегда быстрее и надёжнее в реальном исполнении. Это проверяется не вкусом разработчика, а практикой, нагрузкой и фактическим поведением системы.
И да смешивать рефакторинг с изменениями поведения просто нельзя. А сами шаги должны быть максимально маленькими, изолированными и откатными.
История с ИИ и «заменой разработчиков» ранее уже была в другом виде.
Когда появлялись коробочные решения, тоже говорили: теперь программисты не нужны → любой менеджер сможет всё собрать сам.
На практике оказалось иначе.
Бизнес почти всегда выходит за рамки стандартной логики.
И в какой-то момент любой инструмент упирается в границу, где «должно работать, но не работает».
И вот здесь уже нужен разработчик:
залезть вглубь, разобраться, где именно ломается логика, и собрать кастомное решение.
Поэтому по факту это не замена, а усиление.
Инструменты ускоряют работу и позволяют делать больше за единицу времени, но не убирают потребность в экспертизе.
Более того с ростом возможностей растут и ожидания.
И спрос на таких специалистов не падает, а наоборот увеличивается.
ИИ сейчас делает ровно то же самое:
он не убирает проблему, а масштабирует её.
И если изначально процесс кривой,
то с ИИ это просто становится видно быстрее и больнее.
Есть ощущение, что как и «overqualified», так и «найм по вайбу» часто маскируют одну и ту же проблему → несовпадение скорости человека и системы.
Когда приходишь в компанию, где 5–10 лет всё работало в стабильном режиме, любые попытки ускорить процессы автоматически создают напряжение.
Не потому что изменения плохие, а потому что система выстроена под другую скорость и уровень требований.
В итоге человек, который даёт результат, начинает восприниматься не как усиление, а как источник риска: он затрагивает устоявшиеся связи, зоны ответственности и неформальный баланс.
И дальше у системы всего два сценария:
либо она его «переваривает» и замедляет,
либо выталкивает.
Поэтому вопрос не только в найме, а в готовности компании к изменениям.
Без пересмотра базовых принципов и культуры один «сильный игрок» почти никогда не меняет систему → она меняет его быстрее.
Вспоминается известный эксперимент с обезьянами:
в клетке висит банан, но как только одна из обезьян пытается к нему полезть → всех обливают холодной водой. В итоге обезьяны начинают сами останавливать любого, кто тянется к банану.
Дальше по одной заменяют всех обезьян на новых, которые не знают про воду.
Но каждый раз, когда новичок тянется к банану, его уже бьют остальные → хотя никто из них сам не сталкивался с наказанием.
В итоге формируется поведение без понимания причины.
С людьми можно выстраивать похожие механики через стимулы и закрепление.
Но у человека есть возможность осмыслить свои действия и решить, продолжать их или нет.
Поэтому ключевая задача не просто сформировать привычку, а чтобы в процессе у пользователя появился собственный смысл продолжать.
Геймификация может запустить поведение,
но устойчивость появляется только тогда, когда оно держится не на стимуле, а на внутренней ценности.
Иначе поведение живёт, пока работает механика...
Feedback loops — безусловно мощный инструмент, но это → усилитель.
Если воронка не выстроена, они просто ускоряют сжигание денег 🔥
Поэтому сначала → нормальная логика процесса и конверсии,
и только потом геймификация как способ масштабировать уже работающую модель прибыли, а не убытков.
Классическая цепочка:
работа → деньги → эмоции.
Здесь пользователь просто убирает промежуточное звено.
Это уже ближе к хобби, а хобби мы не называем работой, потому что это про удовольствие, а не про обязательство.
Суть геймификации → формирование устойчивого поведения, а не «черрипикинг» краткосрочных всплесков активности.
Если без стимуляции поведение не сохраняется, значит, работает не ценность продукта, а сама механика.
А это уже риск для долгосрочного удержания.
Более рабочий вариант → не обходить, а вовлекать изначально.
Если вопрос критичный, логичнее сразу включать генерального в повестку с участием всех принимающих решения.
Тогда это выглядит как нормальный управленческий процесс, а не как эскалация через голову, которая часто воспринимается как подрыв роли руководителя.
И термин «продажа» здесь, на мой взгляд, как раз уместен.
Суть не в формальном согласовании, а в том, чтобы лица, принимающие решения, действительно приняли и поняли трансформацию. Только тогда она доходит до результата.
Если изменения идут «из-под палки», на уровне исполнения часто возникает формальное выполнение или ошибки, которые могут подорвать весь процесс.
Из практики — на длинных трансформациях это особенно заметно.
Пустые ниши на рынке обычно заполняются довольно быстро. Главная сложность не в том, чтобы их занять, а в том, чтобы вовремя их увидеть.
Читая истории «успешного успеха», мы почти не видим тысячи похожих проектов, которые тоже верили, что их продукт нужен рынку → но рынок так не решил
Тезис про «создание проблем» скорее выглядит как удачный маркетинговый крючок. Он легко считывается, потому что у многих пользователей есть эмоционально окрашенные воспоминания о платных ограничениях, paywall-механиках или игровых бустах.
Но устойчивые цифровые продукты, как правило, строятся на более тонкой работе с поведением пользователя - через снижение трения, формирование привычек, сетевые эффекты и глубокое понимание пользовательских сценариев.
Большие деньги почти никогда не делаются на раздражении пользователя. Обычно они появляются там, где продукт становится частью регулярного поведения или инфраструктуры пользователя.
Критерий фальсифицируемости → действительно сильная идея.
Но иммунизация, кажется, возникает не только в дискуссиях. Это скорее общий механизм человеческого мышления. Когда новая информация противоречит привычной картине мира, возникает когнитивный диссонанс, и первая реакция часто защитная → «этого не может быть».
В этом смысле иммунизация может быть не столько ошибкой мышления, сколько естественным механизмом сохранения внутренней согласованности.
В статье хорошо описана теоретическая сторона процессного подхода, но, как мне кажется, немного недооценена организационная реальность внедрения процессов - то, что автор как раз предложил обсудить в комментариях :)
На практике процессы редко проектируются с чистого листа. Чаще они возникают как результат быстрого запуска продукта или MVP и постепенно обрастают сложностью. Со временем формируется своего рода «процессный технический долг», и исправление таких процессов требует уже не только методологии, но и серьёзных организационных изменений.
Кроме того, специалисты по процессам на практике выступают не только как аналитики, но и как внутренние консультанты и переговорщики. У них редко есть прямые управленческие полномочия, поэтому большинство изменений приходится фактически → «продавать» владельцам процессов и руководителям подразделений.
И именно в этой точке - где сталкиваются интересы разных подразделений - процессные инициативы чаще всего либо трансформируются, либо останавливаются.