Именно такие люди и меняют парадигму мышления, закладывая фундамент светлого будущего. Современники чаще всего не понимают их замысел или воспринимают его как утопию. Но те, кто созрел, изучают такие кейсы, читают их труды, смотрят на результат и затем масштабируют уже однажды проработанный подход.
По сути, это классический путь развития цивилизации: сначала идея кажется безумием одного человека → потом становится локальной практикой → а затем новой нормой для всех.
Города ведь тоже не появились в современном виде мгновенно. Когда-то кто-то впервые додумался провести воду, сделать канализацию, встроить в среду не только функцию, но и человеческое достоинство. А потом это перестало быть исключением и стало обязательным стандартом.
В этом смысле история Ивреа особенно показательна: сначала нестандартное мышление одного человека, потом работающая модель, а затем культурное и историческое наследие для всех.
Подбирайте сотрудников с синдромом отложенной жизни. Это позволит Вам заменить высокую зарплату сейчас обещаниями о светлом будущем. При этом старайтесь, чтобы Ваши обещания были максимально расплывчатыми. Это даст сотрудникам возможность самим додумать, что им обещали. С учетом их синдрома Вам, скорее всего, не придется объясняться почему обещание не выполнилось
Это как раз одна из причин, почему выжигается смысл работы для специалистов.
Практически у каждого в окружении есть такой кейс: работодатель продаёт «светлое будущее», человек вкладывается, тащит, верит. А когда наступает момент, где это будущее должно материализоваться → ничего не происходит.
Результат предсказуемый: выгорание → разочарование → увольнение. И самое неприятное → дальше человек уже не готов вкладываться ни в одной компании.
То есть тактически Вы выигрываете → получаете дешёвую мотивацию здесь и сейчас. Но стратегически убиваете доверие к рынку и сами же теряете сильных людей в будущем.
Если совсем упростить: это не про управление → это про утилизацию людей как ресурса.
Основная проблема не в том, что вы пишете что-то неверно → проблема в том, чтобы это дошло до ЛПР.
Они часто банально не умеют работать с клиентом, как бы странно это ни звучало. Фокус смещён в прибыль → а не в удовлетворённость.
В итоге движение идёт по минному полю: пока клиенты терпят → всё работает но как только приходит конкурент с другим подходом → приходится либо резко перестраиваться, либо умирать.
Хотя почти всегда есть окно, чтобы перейти плавно.
Проблема гигантов → в отсутствии гибкости. А работа с фидбеком → это как раз инструмент гибкости.
«Иногда руководители спрашивают: как убедить команду обновлять доску в реальном времени?
Боюсь, что иногда → большинство, а меньшинство озвучило это вслух.
Отличная статья!!! Особенно понравилось, что акцент сделали именно на потоке, а не на «доске ради доски».
Из практики внедрения: самая частая проблема → не WIP-лимиты и не метрики, а банально !!!человеческий фактор!!!
Если команда воспринимает канбан как инструмент контроля, а не облегчения работы, он не взлетает. Для сотрудника это выглядит как «теперь за мной ещё и следят, и работать надо больше за те же деньги» → отсюда сопротивление.
Поэтому внедрение не про доску, а про:
— объяснение ценности для команды (меньше хаоса, меньше переключений, меньше «висяков», иногда — и рост дохода за счёт прозрачности и эффективности) — меньше микро менеджмента и лишних вопросов — и только потом уже метрики и WIP (которые чаще нужны бизнесу, а не работникам)
Ну и классическая ошибка → копировать «как в статье». Канбан → инструмент с идеологией, но часто берут только форму, не понимая сути.
В итоге получается не управление потоком, а просто красиво разложенные задачи 🙂
Если у кого-то это взлетело без сопротивления → значит, у вас сотрудники сами просили WIP-лимиты 🙂
У меня первая мысль на такие новости простая: LLM часто не решает системные проблемы, а усиливает их.
Если в компании данные неструктурированы, неконсистентны и местами просто семантически неверны, модель не превратит это в знание. Она начнёт генерировать поверх этого хаоса убедительные, но нестабильные ответы.
Причём проблема обычно глубже, чем кажется. Data-специалист может привести поля к правильным типам и формату, но если он изолирован от бизнес-логики, то он часто не увидит, что с фронтов в принципе приходит не тот смысл, который должен приходить.
То есть дефект может быть не технический, а процессный. И именно такие дефекты компании хуже всего замечают и почти никогда не умеют нормально оценивать. Система вроде бы работает, но работает слабо прогнозируемо.
Поэтому на неподготовленной среде вместо буста бизнеса очень легко получить буст проблем. А реальный эффект появляется только там, где сначала навели порядок в данных, процессах и управленческой логике.
Тут хорошо видно, что процесс держится на личности, а не на системе.
Пока руководитель вручную собирает всё по чатам, разговорам и памяти людей, это работает только за счёт его личного ресурса.
На мой взгляд, правильнее было бы не улучшать этот героизм, а постепенно выстраивать полуавтоматический контур: короткий регулярный шаблон сбора кейсов, материалов, изменений и болей, а уже потом редактура и упаковка в рассылку.
Живой тон письма можно оставить человеческим, но сбор сырья для него не должен каждый месяц быть ручной экспедицией
Я вообще с большой осторожностью отношусь к любым статьям, построенным на опросах.
Опросы → это отдельная и довольно ювелирная область, тесно связанная с социологией, когнитивными искажениями и формулировками вопросов. Очень многое зависит не только от того, кого опрашивали, но и от того, кто проектировал сам опрос, как именно были заданы вопросы, как собирались, интерпретировались ответы и какая цель была изначально как гипотеза.
Без изучения методологии, формулировок и компетенции авторов такие результаты легко становятся инструментом манипуляции, иногда даже без прямого злого умысла. Люди нередко отвечают не то, что реально делают или думают, а то, что им кажется правильным, ожидаемым или просто удобным в моменте.
В этом смысле очень показателен подход из книги Роб Фитцпатрика «Спроси маму»: люди часто врут не специально, а просто из-за природы человеческого общения и самоописания. Поэтому любые выводы из опросов надо делать крайне аккуратно.
При этом сами опросы, конечно, важны. Это один из способов нащупать массовые паттерны и гипотезы. Но именно как отправная точка для дальнейшего анализа, а не как готовая истина.
Тут, на мой взгляд, проблема вообще не столько в AI, сколько в примитивном верхнеуровневом управлении без понимания реального процесса.
Классическая ошибка — считать только “чистое время операции” и игнорировать всё сопутствующее: подготовку, переключение контекста, проверку результата, фиксацию, завершение работы и переход к следующей задаче.
Условно, если приём пациента длится 20 минут, на бумаге кажется, что можно принять 3 человека в час. А в реальности нужно ещё завершить фиксацию по предыдущему, подготовиться к следующему, переключиться, уточнить детали — и реальная пропускная способность по факту 2.
С AI та же история. Руководство часто видит только “скорость генерации ответа”, но не учитывает время на постановку задачи, проверку, сравнение вариантов, правки, перепроверку фактов и встраивание результата в рабочий процесс.
Поэтому перегруз создаёт не сам AI, а плохой расчёт процесса. Если не учитывать полный цикл работы, система почти неизбежно будет перегружена.
Добавил бы главный критерий: рефакторинг нужен только там, где текущая реализация уже создаёт реальную проблему. Рефакторить ради рефакторинга → плохая инженерная практика.
Обычно больше пользы даёт точечная работа по самым нагруженным и болезненным местам системы, чем попытка “оздоровить всё сразу”.
Плюс рефакторинг → вещь ювелирная: более красивый вариант кода не всегда быстрее и надёжнее в реальном исполнении. Это проверяется не вкусом разработчика, а практикой, нагрузкой и фактическим поведением системы.
И да смешивать рефакторинг с изменениями поведения просто нельзя. А сами шаги должны быть максимально маленькими, изолированными и откатными.
История с ИИ и «заменой разработчиков» ранее уже была в другом виде.
Когда появлялись коробочные решения, тоже говорили: теперь программисты не нужны → любой менеджер сможет всё собрать сам. На практике оказалось иначе.
Бизнес почти всегда выходит за рамки стандартной логики. И в какой-то момент любой инструмент упирается в границу, где «должно работать, но не работает».
И вот здесь уже нужен разработчик: залезть вглубь, разобраться, где именно ломается логика, и собрать кастомное решение.
Поэтому по факту это не замена, а усиление. Инструменты ускоряют работу и позволяют делать больше за единицу времени, но не убирают потребность в экспертизе.
Более того с ростом возможностей растут и ожидания. И спрос на таких специалистов не падает, а наоборот увеличивается.
ИИ сейчас делает ровно то же самое: он не убирает проблему, а масштабирует её.
И если изначально процесс кривой, то с ИИ это просто становится видно быстрее и больнее.
Есть ощущение, что как и «overqualified», так и «найм по вайбу» часто маскируют одну и ту же проблему → несовпадение скорости человека и системы.
Когда приходишь в компанию, где 5–10 лет всё работало в стабильном режиме, любые попытки ускорить процессы автоматически создают напряжение. Не потому что изменения плохие, а потому что система выстроена под другую скорость и уровень требований.
В итоге человек, который даёт результат, начинает восприниматься не как усиление, а как источник риска: он затрагивает устоявшиеся связи, зоны ответственности и неформальный баланс.
И дальше у системы всего два сценария: либо она его «переваривает» и замедляет, либо выталкивает.
Поэтому вопрос не только в найме, а в готовности компании к изменениям. Без пересмотра базовых принципов и культуры один «сильный игрок» почти никогда не меняет систему → она меняет его быстрее.
Вспоминается известный эксперимент с обезьянами: в клетке висит банан, но как только одна из обезьян пытается к нему полезть → всех обливают холодной водой. В итоге обезьяны начинают сами останавливать любого, кто тянется к банану.
Дальше по одной заменяют всех обезьян на новых, которые не знают про воду. Но каждый раз, когда новичок тянется к банану, его уже бьют остальные → хотя никто из них сам не сталкивался с наказанием.
В итоге формируется поведение без понимания причины.
С людьми можно выстраивать похожие механики через стимулы и закрепление. Но у человека есть возможность осмыслить свои действия и решить, продолжать их или нет.
Поэтому ключевая задача не просто сформировать привычку, а чтобы в процессе у пользователя появился собственный смысл продолжать.
Геймификация может запустить поведение, но устойчивость появляется только тогда, когда оно держится не на стимуле, а на внутренней ценности.
Feedback loops — безусловно мощный инструмент, но это → усилитель.
Если воронка не выстроена, они просто ускоряют сжигание денег 🔥
Поэтому сначала → нормальная логика процесса и конверсии, и только потом геймификация как способ масштабировать уже работающую модель прибыли, а не убытков.
Здесь пользователь просто убирает промежуточное звено. Это уже ближе к хобби, а хобби мы не называем работой, потому что это про удовольствие, а не про обязательство.
Суть геймификации → формирование устойчивого поведения, а не «черрипикинг» краткосрочных всплесков активности.
Если без стимуляции поведение не сохраняется, значит, работает не ценность продукта, а сама механика. А это уже риск для долгосрочного удержания.
Более рабочий вариант → не обходить, а вовлекать изначально.
Если вопрос критичный, логичнее сразу включать генерального в повестку с участием всех принимающих решения. Тогда это выглядит как нормальный управленческий процесс, а не как эскалация через голову, которая часто воспринимается как подрыв роли руководителя.
И термин «продажа» здесь, на мой взгляд, как раз уместен.
Суть не в формальном согласовании, а в том, чтобы лица, принимающие решения, действительно приняли и поняли трансформацию. Только тогда она доходит до результата.
Если изменения идут «из-под палки», на уровне исполнения часто возникает формальное выполнение или ошибки, которые могут подорвать весь процесс.
Из практики — на длинных трансформациях это особенно заметно.
Тезис про «создание проблем» скорее выглядит как удачный маркетинговый крючок. Он легко считывается, потому что у многих пользователей есть эмоционально окрашенные воспоминания о платных ограничениях, paywall-механиках или игровых бустах.
Но устойчивые цифровые продукты, как правило, строятся на более тонкой работе с поведением пользователя - через снижение трения, формирование привычек, сетевые эффекты и глубокое понимание пользовательских сценариев.
Большие деньги почти никогда не делаются на раздражении пользователя. Обычно они появляются там, где продукт становится частью регулярного поведения или инфраструктуры пользователя.
Критерий фальсифицируемости → действительно сильная идея.
Но иммунизация, кажется, возникает не только в дискуссиях. Это скорее общий механизм человеческого мышления. Когда новая информация противоречит привычной картине мира, возникает когнитивный диссонанс, и первая реакция часто защитная → «этого не может быть».
В этом смысле иммунизация может быть не столько ошибкой мышления, сколько естественным механизмом сохранения внутренней согласованности.
В статье хорошо описана теоретическая сторона процессного подхода, но, как мне кажется, немного недооценена организационная реальность внедрения процессов - то, что автор как раз предложил обсудить в комментариях :)
На практике процессы редко проектируются с чистого листа. Чаще они возникают как результат быстрого запуска продукта или MVP и постепенно обрастают сложностью. Со временем формируется своего рода «процессный технический долг», и исправление таких процессов требует уже не только методологии, но и серьёзных организационных изменений.
Кроме того, специалисты по процессам на практике выступают не только как аналитики, но и как внутренние консультанты и переговорщики. У них редко есть прямые управленческие полномочия, поэтому большинство изменений приходится фактически → «продавать» владельцам процессов и руководителям подразделений.
И именно в этой точке - где сталкиваются интересы разных подразделений - процессные инициативы чаще всего либо трансформируются, либо останавливаются.
Информация
В рейтинге
2 983-й
Откуда
Кольцово, Новосибирская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Системы принятия решений и управление рисками, Архитектор бизнес-процессов и систем решений
Человек → которому будут возводить памятники.
Именно такие люди и меняют парадигму мышления, закладывая фундамент светлого будущего.
Современники чаще всего не понимают их замысел или воспринимают его как утопию.
Но те, кто созрел, изучают такие кейсы, читают их труды, смотрят на результат и затем масштабируют уже однажды проработанный подход.
По сути, это классический путь развития цивилизации:
сначала идея кажется безумием одного человека →
потом становится локальной практикой →
а затем новой нормой для всех.
Города ведь тоже не появились в современном виде мгновенно.
Когда-то кто-то впервые додумался провести воду, сделать канализацию, встроить в среду не только функцию, но и человеческое достоинство.
А потом это перестало быть исключением и стало обязательным стандартом.
В этом смысле история Ивреа особенно показательна:
сначала нестандартное мышление одного человека,
потом работающая модель,
а затем культурное и историческое наследие для всех.
Это как раз одна из причин, почему выжигается смысл работы для специалистов.
Практически у каждого в окружении есть такой кейс:
работодатель продаёт «светлое будущее», человек вкладывается, тащит, верит.
А когда наступает момент, где это будущее должно материализоваться → ничего не происходит.
Результат предсказуемый:
выгорание → разочарование → увольнение.
И самое неприятное → дальше человек уже не готов вкладываться ни в одной компании.
То есть тактически Вы выигрываете → получаете дешёвую мотивацию здесь и сейчас.
Но стратегически убиваете доверие к рынку и сами же теряете сильных людей в будущем.
Если совсем упростить:
это не про управление → это про утилизацию людей как ресурса.
Работает? Да.
Устойчиво? Нет.
Статья хорошая, и есть над чем ещё поработать.
Основная проблема не в том, что вы пишете что-то неверно → проблема в том, чтобы это дошло до ЛПР.
Они часто банально не умеют работать с клиентом, как бы странно это ни звучало.
Фокус смещён в прибыль → а не в удовлетворённость.
В итоге движение идёт по минному полю:
пока клиенты терпят → всё работает
но как только приходит конкурент с другим подходом → приходится либо резко перестраиваться, либо умирать.
Хотя почти всегда есть окно, чтобы перейти плавно.
Проблема гигантов → в отсутствии гибкости.
А работа с фидбеком → это как раз инструмент гибкости.
Must have для всех → но не для каждого 🙂
Типовая ошибка → воспринимать ИИ как замену.
На деле это ускоритель.
Проблема не в том, что модель не чувствует «голос».
Голос → это результат мышления редактора, его выбора и задачи.
Поэтому ИИ не замена специалисту, а усилитель:
у сильного → кратный рост
у слабого → быстрее и масштабней ошибки
Боюсь, что иногда → большинство, а меньшинство озвучило это вслух.
Отличная статья!!! Особенно понравилось, что акцент сделали именно на потоке, а не на «доске ради доски».
Из практики внедрения: самая частая проблема → не WIP-лимиты и не метрики, а банально !!!человеческий фактор!!!
Если команда воспринимает канбан как инструмент контроля, а не облегчения работы, он не взлетает. Для сотрудника это выглядит как «теперь за мной ещё и следят, и работать надо больше за те же деньги» → отсюда сопротивление.
Поэтому внедрение не про доску, а про:
— объяснение ценности для команды (меньше хаоса, меньше переключений, меньше «висяков», иногда — и рост дохода за счёт прозрачности и эффективности)
— меньше микро менеджмента и лишних вопросов
— и только потом уже метрики и WIP (которые чаще нужны бизнесу, а не работникам)
Ну и классическая ошибка → копировать «как в статье».
Канбан → инструмент с идеологией, но часто берут только форму, не понимая сути.
В итоге получается не управление потоком, а просто красиво разложенные задачи 🙂
Если у кого-то это взлетело без сопротивления → значит, у вас сотрудники сами просили WIP-лимиты 🙂
У меня первая мысль на такие новости простая: LLM часто не решает системные проблемы, а усиливает их.
Если в компании данные неструктурированы, неконсистентны и местами просто семантически неверны, модель не превратит это в знание. Она начнёт генерировать поверх этого хаоса убедительные, но нестабильные ответы.
Причём проблема обычно глубже, чем кажется. Data-специалист может привести поля к правильным типам и формату, но если он изолирован от бизнес-логики, то он часто не увидит, что с фронтов в принципе приходит не тот смысл, который должен приходить.
То есть дефект может быть не технический, а процессный. И именно такие дефекты компании хуже всего замечают и почти никогда не умеют нормально оценивать. Система вроде бы работает, но работает слабо прогнозируемо.
Поэтому на неподготовленной среде вместо буста бизнеса очень легко получить буст проблем. А реальный эффект появляется только там, где сначала навели порядок в данных, процессах и управленческой логике.
Тут хорошо видно, что процесс держится на личности, а не на системе.
Пока руководитель вручную собирает всё по чатам, разговорам и памяти людей, это работает только за счёт его личного ресурса.
На мой взгляд, правильнее было бы не улучшать этот героизм, а постепенно выстраивать полуавтоматический контур: короткий регулярный шаблон сбора кейсов, материалов, изменений и болей, а уже потом редактура и упаковка в рассылку.
Живой тон письма можно оставить человеческим, но сбор сырья для него не должен каждый месяц быть ручной экспедицией
Я вообще с большой осторожностью отношусь к любым статьям, построенным на опросах.
Опросы → это отдельная и довольно ювелирная область, тесно связанная с социологией, когнитивными искажениями и формулировками вопросов. Очень многое зависит не только от того, кого опрашивали, но и от того, кто проектировал сам опрос, как именно были заданы вопросы, как собирались, интерпретировались ответы и какая цель была изначально как гипотеза.
Без изучения методологии, формулировок и компетенции авторов такие результаты легко становятся инструментом манипуляции, иногда даже без прямого злого умысла. Люди нередко отвечают не то, что реально делают или думают, а то, что им кажется правильным, ожидаемым или просто удобным в моменте.
В этом смысле очень показателен подход из книги Роб Фитцпатрика «Спроси маму»: люди часто врут не специально, а просто из-за природы человеческого общения и самоописания. Поэтому любые выводы из опросов надо делать крайне аккуратно.
При этом сами опросы, конечно, важны. Это один из способов нащупать массовые паттерны и гипотезы. Но именно как отправная точка для дальнейшего анализа, а не как готовая истина.
Тут, на мой взгляд, проблема вообще не столько в AI, сколько в примитивном верхнеуровневом управлении без понимания реального процесса.
Классическая ошибка — считать только “чистое время операции” и игнорировать всё сопутствующее: подготовку, переключение контекста, проверку результата, фиксацию, завершение работы и переход к следующей задаче.
Условно, если приём пациента длится 20 минут, на бумаге кажется, что можно принять 3 человека в час. А в реальности нужно ещё завершить фиксацию по предыдущему, подготовиться к следующему, переключиться, уточнить детали — и реальная пропускная способность по факту 2.
С AI та же история. Руководство часто видит только “скорость генерации ответа”, но не учитывает время на постановку задачи, проверку, сравнение вариантов, правки, перепроверку фактов и встраивание результата в рабочий процесс.
Поэтому перегруз создаёт не сам AI, а плохой расчёт процесса. Если не учитывать полный цикл работы, система почти неизбежно будет перегружена.
Добавил бы главный критерий: рефакторинг нужен только там, где текущая реализация уже создаёт реальную проблему. Рефакторить ради рефакторинга → плохая инженерная практика.
Обычно больше пользы даёт точечная работа по самым нагруженным и болезненным местам системы, чем попытка “оздоровить всё сразу”.
Плюс рефакторинг → вещь ювелирная: более красивый вариант кода не всегда быстрее и надёжнее в реальном исполнении. Это проверяется не вкусом разработчика, а практикой, нагрузкой и фактическим поведением системы.
И да смешивать рефакторинг с изменениями поведения просто нельзя. А сами шаги должны быть максимально маленькими, изолированными и откатными.
История с ИИ и «заменой разработчиков» ранее уже была в другом виде.
Когда появлялись коробочные решения, тоже говорили: теперь программисты не нужны → любой менеджер сможет всё собрать сам.
На практике оказалось иначе.
Бизнес почти всегда выходит за рамки стандартной логики.
И в какой-то момент любой инструмент упирается в границу, где «должно работать, но не работает».
И вот здесь уже нужен разработчик:
залезть вглубь, разобраться, где именно ломается логика, и собрать кастомное решение.
Поэтому по факту это не замена, а усиление.
Инструменты ускоряют работу и позволяют делать больше за единицу времени, но не убирают потребность в экспертизе.
Более того с ростом возможностей растут и ожидания.
И спрос на таких специалистов не падает, а наоборот увеличивается.
ИИ сейчас делает ровно то же самое:
он не убирает проблему, а масштабирует её.
И если изначально процесс кривой,
то с ИИ это просто становится видно быстрее и больнее.
Есть ощущение, что как и «overqualified», так и «найм по вайбу» часто маскируют одну и ту же проблему → несовпадение скорости человека и системы.
Когда приходишь в компанию, где 5–10 лет всё работало в стабильном режиме, любые попытки ускорить процессы автоматически создают напряжение.
Не потому что изменения плохие, а потому что система выстроена под другую скорость и уровень требований.
В итоге человек, который даёт результат, начинает восприниматься не как усиление, а как источник риска: он затрагивает устоявшиеся связи, зоны ответственности и неформальный баланс.
И дальше у системы всего два сценария:
либо она его «переваривает» и замедляет,
либо выталкивает.
Поэтому вопрос не только в найме, а в готовности компании к изменениям.
Без пересмотра базовых принципов и культуры один «сильный игрок» почти никогда не меняет систему → она меняет его быстрее.
Вспоминается известный эксперимент с обезьянами:
в клетке висит банан, но как только одна из обезьян пытается к нему полезть → всех обливают холодной водой. В итоге обезьяны начинают сами останавливать любого, кто тянется к банану.
Дальше по одной заменяют всех обезьян на новых, которые не знают про воду.
Но каждый раз, когда новичок тянется к банану, его уже бьют остальные → хотя никто из них сам не сталкивался с наказанием.
В итоге формируется поведение без понимания причины.
С людьми можно выстраивать похожие механики через стимулы и закрепление.
Но у человека есть возможность осмыслить свои действия и решить, продолжать их или нет.
Поэтому ключевая задача не просто сформировать привычку, а чтобы в процессе у пользователя появился собственный смысл продолжать.
Геймификация может запустить поведение,
но устойчивость появляется только тогда, когда оно держится не на стимуле, а на внутренней ценности.
Иначе поведение живёт, пока работает механика...
Feedback loops — безусловно мощный инструмент, но это → усилитель.
Если воронка не выстроена, они просто ускоряют сжигание денег 🔥
Поэтому сначала → нормальная логика процесса и конверсии,
и только потом геймификация как способ масштабировать уже работающую модель прибыли, а не убытков.
Классическая цепочка:
работа → деньги → эмоции.
Здесь пользователь просто убирает промежуточное звено.
Это уже ближе к хобби, а хобби мы не называем работой, потому что это про удовольствие, а не про обязательство.
Суть геймификации → формирование устойчивого поведения, а не «черрипикинг» краткосрочных всплесков активности.
Если без стимуляции поведение не сохраняется, значит, работает не ценность продукта, а сама механика.
А это уже риск для долгосрочного удержания.
Более рабочий вариант → не обходить, а вовлекать изначально.
Если вопрос критичный, логичнее сразу включать генерального в повестку с участием всех принимающих решения.
Тогда это выглядит как нормальный управленческий процесс, а не как эскалация через голову, которая часто воспринимается как подрыв роли руководителя.
И термин «продажа» здесь, на мой взгляд, как раз уместен.
Суть не в формальном согласовании, а в том, чтобы лица, принимающие решения, действительно приняли и поняли трансформацию. Только тогда она доходит до результата.
Если изменения идут «из-под палки», на уровне исполнения часто возникает формальное выполнение или ошибки, которые могут подорвать весь процесс.
Из практики — на длинных трансформациях это особенно заметно.
Пустые ниши на рынке обычно заполняются довольно быстро. Главная сложность не в том, чтобы их занять, а в том, чтобы вовремя их увидеть.
Читая истории «успешного успеха», мы почти не видим тысячи похожих проектов, которые тоже верили, что их продукт нужен рынку → но рынок так не решил
Тезис про «создание проблем» скорее выглядит как удачный маркетинговый крючок. Он легко считывается, потому что у многих пользователей есть эмоционально окрашенные воспоминания о платных ограничениях, paywall-механиках или игровых бустах.
Но устойчивые цифровые продукты, как правило, строятся на более тонкой работе с поведением пользователя - через снижение трения, формирование привычек, сетевые эффекты и глубокое понимание пользовательских сценариев.
Большие деньги почти никогда не делаются на раздражении пользователя. Обычно они появляются там, где продукт становится частью регулярного поведения или инфраструктуры пользователя.
Критерий фальсифицируемости → действительно сильная идея.
Но иммунизация, кажется, возникает не только в дискуссиях. Это скорее общий механизм человеческого мышления. Когда новая информация противоречит привычной картине мира, возникает когнитивный диссонанс, и первая реакция часто защитная → «этого не может быть».
В этом смысле иммунизация может быть не столько ошибкой мышления, сколько естественным механизмом сохранения внутренней согласованности.
В статье хорошо описана теоретическая сторона процессного подхода, но, как мне кажется, немного недооценена организационная реальность внедрения процессов - то, что автор как раз предложил обсудить в комментариях :)
На практике процессы редко проектируются с чистого листа. Чаще они возникают как результат быстрого запуска продукта или MVP и постепенно обрастают сложностью. Со временем формируется своего рода «процессный технический долг», и исправление таких процессов требует уже не только методологии, но и серьёзных организационных изменений.
Кроме того, специалисты по процессам на практике выступают не только как аналитики, но и как внутренние консультанты и переговорщики. У них редко есть прямые управленческие полномочия, поэтому большинство изменений приходится фактически → «продавать» владельцам процессов и руководителям подразделений.
И именно в этой точке - где сталкиваются интересы разных подразделений - процессные инициативы чаще всего либо трансформируются, либо останавливаются.