История с ИИ и «заменой разработчиков» ранее уже была в другом виде.
Когда появлялись коробочные решения, тоже говорили: теперь программисты не нужны → любой менеджер сможет всё собрать сам. На практике оказалось иначе.
Бизнес почти всегда выходит за рамки стандартной логики. И в какой-то момент любой инструмент упирается в границу, где «должно работать, но не работает».
И вот здесь уже нужен разработчик: залезть вглубь, разобраться, где именно ломается логика, и собрать кастомное решение.
Поэтому по факту это не замена, а усиление. Инструменты ускоряют работу и позволяют делать больше за единицу времени, но не убирают потребность в экспертизе.
Более того с ростом возможностей растут и ожидания. И спрос на таких специалистов не падает, а наоборот увеличивается.
ИИ сейчас делает ровно то же самое: он не убирает проблему, а масштабирует её.
И если изначально процесс кривой, то с ИИ это просто становится видно быстрее и больнее.
Есть ощущение, что как и «overqualified», так и «найм по вайбу» часто маскируют одну и ту же проблему → несовпадение скорости человека и системы.
Когда приходишь в компанию, где 5–10 лет всё работало в стабильном режиме, любые попытки ускорить процессы автоматически создают напряжение. Не потому что изменения плохие, а потому что система выстроена под другую скорость и уровень требований.
В итоге человек, который даёт результат, начинает восприниматься не как усиление, а как источник риска: он затрагивает устоявшиеся связи, зоны ответственности и неформальный баланс.
И дальше у системы всего два сценария: либо она его «переваривает» и замедляет, либо выталкивает.
Поэтому вопрос не только в найме, а в готовности компании к изменениям. Без пересмотра базовых принципов и культуры один «сильный игрок» почти никогда не меняет систему → она меняет его быстрее.
Вспоминается известный эксперимент с обезьянами: в клетке висит банан, но как только одна из обезьян пытается к нему полезть → всех обливают холодной водой. В итоге обезьяны начинают сами останавливать любого, кто тянется к банану.
Дальше по одной заменяют всех обезьян на новых, которые не знают про воду. Но каждый раз, когда новичок тянется к банану, его уже бьют остальные → хотя никто из них сам не сталкивался с наказанием.
В итоге формируется поведение без понимания причины.
С людьми можно выстраивать похожие механики через стимулы и закрепление. Но у человека есть возможность осмыслить свои действия и решить, продолжать их или нет.
Поэтому ключевая задача не просто сформировать привычку, а чтобы в процессе у пользователя появился собственный смысл продолжать.
Геймификация может запустить поведение, но устойчивость появляется только тогда, когда оно держится не на стимуле, а на внутренней ценности.
Feedback loops — безусловно мощный инструмент, но это → усилитель.
Если воронка не выстроена, они просто ускоряют сжигание денег 🔥
Поэтому сначала → нормальная логика процесса и конверсии, и только потом геймификация как способ масштабировать уже работающую модель прибыли, а не убытков.
Здесь пользователь просто убирает промежуточное звено. Это уже ближе к хобби, а хобби мы не называем работой, потому что это про удовольствие, а не про обязательство.
Суть геймификации → формирование устойчивого поведения, а не «черрипикинг» краткосрочных всплесков активности.
Если без стимуляции поведение не сохраняется, значит, работает не ценность продукта, а сама механика. А это уже риск для долгосрочного удержания.
Более рабочий вариант → не обходить, а вовлекать изначально.
Если вопрос критичный, логичнее сразу включать генерального в повестку с участием всех принимающих решения. Тогда это выглядит как нормальный управленческий процесс, а не как эскалация через голову, которая часто воспринимается как подрыв роли руководителя.
И термин «продажа» здесь, на мой взгляд, как раз уместен.
Суть не в формальном согласовании, а в том, чтобы лица, принимающие решения, действительно приняли и поняли трансформацию. Только тогда она доходит до результата.
Если изменения идут «из-под палки», на уровне исполнения часто возникает формальное выполнение или ошибки, которые могут подорвать весь процесс.
Из практики — на длинных трансформациях это особенно заметно.
Тезис про «создание проблем» скорее выглядит как удачный маркетинговый крючок. Он легко считывается, потому что у многих пользователей есть эмоционально окрашенные воспоминания о платных ограничениях, paywall-механиках или игровых бустах.
Но устойчивые цифровые продукты, как правило, строятся на более тонкой работе с поведением пользователя - через снижение трения, формирование привычек, сетевые эффекты и глубокое понимание пользовательских сценариев.
Большие деньги почти никогда не делаются на раздражении пользователя. Обычно они появляются там, где продукт становится частью регулярного поведения или инфраструктуры пользователя.
Критерий фальсифицируемости → действительно сильная идея.
Но иммунизация, кажется, возникает не только в дискуссиях. Это скорее общий механизм человеческого мышления. Когда новая информация противоречит привычной картине мира, возникает когнитивный диссонанс, и первая реакция часто защитная → «этого не может быть».
В этом смысле иммунизация может быть не столько ошибкой мышления, сколько естественным механизмом сохранения внутренней согласованности.
В статье хорошо описана теоретическая сторона процессного подхода, но, как мне кажется, немного недооценена организационная реальность внедрения процессов - то, что автор как раз предложил обсудить в комментариях :)
На практике процессы редко проектируются с чистого листа. Чаще они возникают как результат быстрого запуска продукта или MVP и постепенно обрастают сложностью. Со временем формируется своего рода «процессный технический долг», и исправление таких процессов требует уже не только методологии, но и серьёзных организационных изменений.
Кроме того, специалисты по процессам на практике выступают не только как аналитики, но и как внутренние консультанты и переговорщики. У них редко есть прямые управленческие полномочия, поэтому большинство изменений приходится фактически → «продавать» владельцам процессов и руководителям подразделений.
И именно в этой точке - где сталкиваются интересы разных подразделений - процессные инициативы чаще всего либо трансформируются, либо останавливаются.
Информация
В рейтинге
4 288-й
Откуда
Кольцово, Новосибирская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Системы принятия решений и управление рисками, Архитектор бизнес-процессов и систем решений
История с ИИ и «заменой разработчиков» ранее уже была в другом виде.
Когда появлялись коробочные решения, тоже говорили: теперь программисты не нужны → любой менеджер сможет всё собрать сам.
На практике оказалось иначе.
Бизнес почти всегда выходит за рамки стандартной логики.
И в какой-то момент любой инструмент упирается в границу, где «должно работать, но не работает».
И вот здесь уже нужен разработчик:
залезть вглубь, разобраться, где именно ломается логика, и собрать кастомное решение.
Поэтому по факту это не замена, а усиление.
Инструменты ускоряют работу и позволяют делать больше за единицу времени, но не убирают потребность в экспертизе.
Более того с ростом возможностей растут и ожидания.
И спрос на таких специалистов не падает, а наоборот увеличивается.
ИИ сейчас делает ровно то же самое:
он не убирает проблему, а масштабирует её.
И если изначально процесс кривой,
то с ИИ это просто становится видно быстрее и больнее.
Есть ощущение, что как и «overqualified», так и «найм по вайбу» часто маскируют одну и ту же проблему → несовпадение скорости человека и системы.
Когда приходишь в компанию, где 5–10 лет всё работало в стабильном режиме, любые попытки ускорить процессы автоматически создают напряжение.
Не потому что изменения плохие, а потому что система выстроена под другую скорость и уровень требований.
В итоге человек, который даёт результат, начинает восприниматься не как усиление, а как источник риска: он затрагивает устоявшиеся связи, зоны ответственности и неформальный баланс.
И дальше у системы всего два сценария:
либо она его «переваривает» и замедляет,
либо выталкивает.
Поэтому вопрос не только в найме, а в готовности компании к изменениям.
Без пересмотра базовых принципов и культуры один «сильный игрок» почти никогда не меняет систему → она меняет его быстрее.
Вспоминается известный эксперимент с обезьянами:
в клетке висит банан, но как только одна из обезьян пытается к нему полезть → всех обливают холодной водой. В итоге обезьяны начинают сами останавливать любого, кто тянется к банану.
Дальше по одной заменяют всех обезьян на новых, которые не знают про воду.
Но каждый раз, когда новичок тянется к банану, его уже бьют остальные → хотя никто из них сам не сталкивался с наказанием.
В итоге формируется поведение без понимания причины.
С людьми можно выстраивать похожие механики через стимулы и закрепление.
Но у человека есть возможность осмыслить свои действия и решить, продолжать их или нет.
Поэтому ключевая задача не просто сформировать привычку, а чтобы в процессе у пользователя появился собственный смысл продолжать.
Геймификация может запустить поведение,
но устойчивость появляется только тогда, когда оно держится не на стимуле, а на внутренней ценности.
Иначе поведение живёт, пока работает механика...
Feedback loops — безусловно мощный инструмент, но это → усилитель.
Если воронка не выстроена, они просто ускоряют сжигание денег 🔥
Поэтому сначала → нормальная логика процесса и конверсии,
и только потом геймификация как способ масштабировать уже работающую модель прибыли, а не убытков.
Классическая цепочка:
работа → деньги → эмоции.
Здесь пользователь просто убирает промежуточное звено.
Это уже ближе к хобби, а хобби мы не называем работой, потому что это про удовольствие, а не про обязательство.
Суть геймификации → формирование устойчивого поведения, а не «черрипикинг» краткосрочных всплесков активности.
Если без стимуляции поведение не сохраняется, значит, работает не ценность продукта, а сама механика.
А это уже риск для долгосрочного удержания.
Более рабочий вариант → не обходить, а вовлекать изначально.
Если вопрос критичный, логичнее сразу включать генерального в повестку с участием всех принимающих решения.
Тогда это выглядит как нормальный управленческий процесс, а не как эскалация через голову, которая часто воспринимается как подрыв роли руководителя.
И термин «продажа» здесь, на мой взгляд, как раз уместен.
Суть не в формальном согласовании, а в том, чтобы лица, принимающие решения, действительно приняли и поняли трансформацию. Только тогда она доходит до результата.
Если изменения идут «из-под палки», на уровне исполнения часто возникает формальное выполнение или ошибки, которые могут подорвать весь процесс.
Из практики — на длинных трансформациях это особенно заметно.
Пустые ниши на рынке обычно заполняются довольно быстро. Главная сложность не в том, чтобы их занять, а в том, чтобы вовремя их увидеть.
Читая истории «успешного успеха», мы почти не видим тысячи похожих проектов, которые тоже верили, что их продукт нужен рынку → но рынок так не решил
Тезис про «создание проблем» скорее выглядит как удачный маркетинговый крючок. Он легко считывается, потому что у многих пользователей есть эмоционально окрашенные воспоминания о платных ограничениях, paywall-механиках или игровых бустах.
Но устойчивые цифровые продукты, как правило, строятся на более тонкой работе с поведением пользователя - через снижение трения, формирование привычек, сетевые эффекты и глубокое понимание пользовательских сценариев.
Большие деньги почти никогда не делаются на раздражении пользователя. Обычно они появляются там, где продукт становится частью регулярного поведения или инфраструктуры пользователя.
Критерий фальсифицируемости → действительно сильная идея.
Но иммунизация, кажется, возникает не только в дискуссиях. Это скорее общий механизм человеческого мышления. Когда новая информация противоречит привычной картине мира, возникает когнитивный диссонанс, и первая реакция часто защитная → «этого не может быть».
В этом смысле иммунизация может быть не столько ошибкой мышления, сколько естественным механизмом сохранения внутренней согласованности.
В статье хорошо описана теоретическая сторона процессного подхода, но, как мне кажется, немного недооценена организационная реальность внедрения процессов - то, что автор как раз предложил обсудить в комментариях :)
На практике процессы редко проектируются с чистого листа. Чаще они возникают как результат быстрого запуска продукта или MVP и постепенно обрастают сложностью. Со временем формируется своего рода «процессный технический долг», и исправление таких процессов требует уже не только методологии, но и серьёзных организационных изменений.
Кроме того, специалисты по процессам на практике выступают не только как аналитики, но и как внутренние консультанты и переговорщики. У них редко есть прямые управленческие полномочия, поэтому большинство изменений приходится фактически → «продавать» владельцам процессов и руководителям подразделений.
И именно в этой точке - где сталкиваются интересы разных подразделений - процессные инициативы чаще всего либо трансформируются, либо останавливаются.