Transcription
Знаете, обычно работает такое, ну, железное правило. Как только какая-то очень сложная технология становится дешёвой и массовой, мы автоматически предполагаем, что чья-то жизнь сейчас сказочно упростится.
Ага, это классическая иллюзия. Да, вот именно. Вспомнить хотя бы калькуляторы. Они же буквально спасли бухгалтеров от необходимости бесконечно считать всё в столбик, верно? Освободили им кучу времени.
И вот сейчас мы оказались в реальности, где создание программного обеспечения с помощью искусственного интеллекта стоят какие-то просто смешные копейки. Копейки и, что немаловажно, секунды. Да, рабочие прототипы генерируются буквально за считанные секунды по одному короткому текстовому запросу.
И казалось бы, ну, для продакт-менеджеров, то есть людей, чья прямая обязанность управлять созданием этих самых продуктов, наступил просто золотой век. Сиди себе, генерируй код и радуйся жизни. Если бы всё было так просто.
Вот. Но пропуск в том, в том, на самом деле, их работа внезапно превратилась в какой-то сущий кошмар. Ну, это очень распространённая ловушка любого крупного технологического скачка. Нам всем кажется, что если производству чего-либо становится проще, то исчезает и сама сложность управления этим процессом.
Угу. Но система работает совершенно иначе. Облегчение процесса просто берёт и сдвигает вот это пресловутое узкое место. Ну, ботлнек на следующий этап. Логично. Когда барьер для входа падает практически до нуля, и программировать может вообще кто угодно, старая проблема дефицита ресурсов просто исчезает. Но на её место мгновенно, вот буквально в тот же день, приходит новая проблема, как управлять абсолютным неконтролируемым хаосом.
И именно поэтому сегодня мы решили максимально детально разобрать эту тему. Наш глубокий разбор строится вокруг невероятно подробного материала от аналитика Нейта Бжонса, который препарирует этот феномен. Он объясняет, почему дешёвый софт не просто усложнил, а буквально сломал традиционную модель работы менеджера продукта.
И это потрясающий анализ, надо сказать. Абсолютно. Наша цель сегодня не просто в очередной раз восхититься тем, как ИИ ловко пишет код. Ну, это уже пройденный этап, никого этим не удивишь. Мы хотим понять саму механику новой парадигмы. Как корпорациям выживать в условиях вот этого беспрецедентного изобилия программного обеспечения? И почему способность сказать жёсткое, аргументированное "нет" вдруг стало самым ценным навыком на рынке?
Чтобы осознать вообще масштаб происходящего землетрясения в индустрии, нужно сначала посмотреть на фундамент, который сейчас рушится. Ну, как вообще эта профессия функционировала исторически.
Давай копнём в историю. Если мы отбросим все красивые термины, все эти современные фреймворки, то десятилетиями вся дисциплина управления продуктами строилась вокруг одной единственной концепции, вокруг тотального дефицита.
То есть, грубо говоря, продакт-менеджера нанимали, потому что разработчики стоили слишком, слишком дорого. Именно разработка программного обеспечения всегда была астрономически дорогим удовольствием.
Ага. Время инженеров - это исторически самый ограниченный и дорогой ресурс в любой IT-компании. Поэтому все эти классические ритуалы, которые мы привыкли ассоциировать с работой продакт-менеджера, ну там написание многостраничных документов с требованиями, изнурительные многомесячные планирования дорожных карт.
О, да, эти бесконечные встречи. Бесконечные встречи, где все до хрепоты спорят о приоритетах. Все это существовало совершенно не для того, чтобы быстрее выпустить продукт на рынок.
Стоп, стоп, стоп, подожди. Разве спринты и вот это всё не задумывались именно для скорости? Звучит так, будто менеджеры продуктов были просто какими-то высокооплачиваемыми вредничающими полицейскими.
В каком-то смысле так и было. Вся эта бюрократия была изначально спроектирована как система искусственного торможения.
Вау. Да. И её скрытая цель - максимально замедлить процесс старта разработки, чтобы драгоценное время инженеров расходовалось только на самые проверенные, самые надёжные идеи. Цена ошибки была просто фатальной.
Ну да, переписывать код месяцами - это сжигать миллионы. Точно. Ни одна компания не могла себе позволить, чтобы, скажем, отдел маркетинга вдруг решил клонировать корпоративный мессенджер просто потому, что им не понравился цвет кнопок. Или чтобы любая случайная идея, придуманная руководством за утренним кофе, тут же уходила в код.
Слушай, мне тут на ум приходит образ такого сурового вышибалы на входе в очень элитный ночной клуб.
Так, так. Внутри клуба сидят инженеры, они пишут код, и места критически мало, а снаружи стоит этот вот PM – вышибала. К нему выстраивается огромная бесконечная очередь из идей, амбиций, каких-то запросов от отдела продаж, жалоб от пользователей.
Угу. И он пускает внутрь только самые обоснованные и финансово просчитанные идеи, потому что если пустить вообще всех, клуб просто треснет по швам и закроется.
Очень, очень точная метафора. А теперь, ээ, посмотрите, что произошло. Искусственный интеллект не просто уволил этого вышибалу, он взял и снёс сами стены этого клуба бульдозером.
Ого, ничего себе картинка. Сегодня фильтра на входе больше просто не существует. Создание работающих прототипов перестало быть какой-то магией, доступной лишь узкой касте программистов. И вот реакция индустрии на это разрушение стен довольно забавна.
Сейчас из каждого утюга звучат советы, что продакт-менеджер теперь обязан превратиться в эдакого суперпрототипировщика, но который сам с утра до вечера сидит и генерирует приложение с помощью ИИ. Ну, звучит логично. Если программировать стало легко, значит менеджер должен делать это сам и экономить бюджет компании. Разве нет?
Это крайне поверхностный взгляд. Использование ИИ для создания прототипа - это больше не уникальное конкурентное преимущество. Это базовая необходимость, ну, как умение пользоваться электронной почтой или Excel.
Угу. Настоящая сложная работа менеджера теперь начинается ровно в тот момент, когда генерация кода заканчивается. Вот я тут как раз читаю статистику из нашего материала, и у меня, честно говоря, волосы на голове шевелятся от того, как это выглядит на практике. В статье приводятся данные по внутренней экосистеме платформы от Microsoft.
О, да, эти цифры поражают. Для понимания, это их корпоративный набор low-code решений, ну, таких конструкторов, где сотрудники могут собирать программы мышкой и с помощью ИИ-подсказок почти без написания классического кода.
Угу. Так вот, ээ, внутри самой Microsoft их сотрудники создали более 1 млн активов. Миллион.
И это только внутри одной компании? Да. Это включает 18.000 сред для ботов, 170.000 различных мини-приложений, 50.000 автоматизированных рабочих процессов и больше тысячи чатботов. Это просто какой-то шокирующий масштаб.
Эти цифры не просто удивляют, они фиксируют исторический момент. Это та самая смерть эпохи дефицита. Подумайте, как изменилась воронка идей. Раньше менеджер смотрел на презентации, какие-то абстрактные макеты или текст, текстовые описания того, что люди только хотят сделать.
А теперь он приходит в понедельник в офис, открывает корпоративную сеть, а там лежат сотни тысяч уже готовых, живых инструментов, да, работающих программ. Какой-нибудь менеджер по продажам за выходные от нечего делать собрал дашборд, который сам тянет данные CRM, анализирует их нейросетью и рассылает письма клиентам. И это работает. Это такие, ну, продукты-зомби. Они живые, они выполняют реальные бизнес-функции, но у них нет ни официального владельца, ни документации, ни вообще понимания, что с ними делать дальше.
Совершенно верно. И это фундаментально меняет главный вопрос профессии. Раньше менеджер спрашивал: "Ну, стоит ли нам тратить деньги компании, чтобы это построить?"
Угу. Сейчас этот вопрос полностью потерял смысл, потому что работа уже построена, ресурсы – вре́мя сотрудника и мощностей – уже потрачены. Новый ключевой вопрос звучит так: кто-то уже собрал этот инструмент? Имеет ли он хоть какое-то значение для глобальной стратегии компании? И что нам с ним теперь делать? То есть фокус сместился.
Полностью. Фокус сместился с распределения дефицита на категоризацию и управление вот этим информационным изобилием.
Слушай, ну звучит, честно говоря, как тайная фантазия любого генерального директора. Все сотрудники внезапно стали такими сверхпродуктивными, сами решают свои мелкие проблемы, не дёргают IT-отдел по пустякам.
Разве это не прекрасно? Почему мы вообще говорим об этом как о проблеме? Если какой-нибудь Вася из бухгалтерии собрал скрипт, который экономит ему 3 часа в день, да пусть пользуется на здоровье. В чём подвох?
Подвох в том, что бесплатный сыр бывает только в мышеловке. И у этой сверхпродуктивности есть просто катастрофическая тёмная сторона. Быстрая и совершенно бесконтрольное создание программного обеспечения неопытными людьми неизбежно означает быстрые и фатальные ошибки. Так, в материалах упоминается отчёт компании Git Guardian, которая занимается информационной безопасностью. Они проанализировали состояние утечек секретных данных за 2026 год.
И что там? Так вот, количество ключей доступа к ей-сервисам, которые сотрудники случайно опубликовали в открытом доступе на публичном GitHub, достигло 1.200.000 ещё в двадцатом году. Это колоссальный рост на 81% за год. И ожидается, что в этом году цифра вырастет ещё чуть ли не вдвое.
Подожди, давай проясним саму механику, как это вообще происходит на практике.
Ну вот представьте, что тот самый Вася из бухгалтерии, о котором мы говорили, просит нейросеть написать ему скрипт для сортировки счетов. И пишет отличный код. Всё работает. Но чтобы этот скрипт мог читать документы, ему нужен пароль, ну или API-ключ от корпоративной базы данных.
Угу. Вася берёт и вставляет этот ключ прямо открытым текстом в код, а потом, чтобы перекинуть этот скрипт коллеге или сохранить себе резервную копию, загружает этот код в публичный репозиторий. Всё, катастрофа.
Да? Ключ от финансовой базы компании теперь доступен любому хакеру в интернете.
Ого. То есть компания раздала тысячам своих сотрудников мощные такие промышленные электроинструменты, но никто не провёл инструктаж по технике пожарной безопасности. И теперь, когда кто-то случайно пропиливает несущую стену здания, разгребать все эти завалы должен продакт-менеджер.
Именно так. И это, кстати, блестяще объясняет, почему идея о том, что менеджер продукта может быть сугубо гуманитарием, таким фасилитатором встреч или человеком, который просто красиво рисует презентации, окончательно умерла.
Все, конец эпохи. Абсолютный. И продукты – это сложнейшие технические системы. Менеджер сегодня просто обязан досконально понимать техническую природу того, что происходит в компании. Изобилие вот этих прототипов означает, что везде плодятся неучтённые пароли, какие-то локальные базы данных, хаотичные интеграции, когда одна программа неконтролируемо передаёт данные другой.
То есть, ээ, если продукт-менеджер не понимает, как устроены, например, API-вызовы. А давай, кстати, расшифруем для тех, кто не каждый день с этим сталкивается.
Давай. API-вызов – это ведь, грубо говоря, когда одна программа стучится к другой по интернету и просит какую-то информацию. Так? И за каждый такой стук сервис, ну, вроде OpenAI, списывает с корпоративного счёта доли цента.
Абсолютно верно. И если менеджер не понимает, что какой-то безобидный с виду скрипт делает тысячи таких запросов в минуту, компания может в конце месяца получить счёт на сотни тысяч долларов за облачные услуги. Ничего себе сюрприз для бухгалтерии.
Более того, менеджер должен понимать, как работают циклы ИИ-агентов, кто и как выдаёт разрешение на доступ к чувствительной информации, какая там задержка, стоимость. И критически важно понимать, что такое evaluations, то есть оценки качества моделей.
Да, вот про evaluations подробнее. Звучит как какой-то, ну, заумный термин из секретных лабораторий. Что это такое на практике? Evaluations – это, по сути, система строгих экзаменов для нейросети. Поскольку языковые модели, как мы знаем, склонны к галлюцинациям, то есть могут уверенно выдавать абсолютно выдуманные факты за реальные, мы не можем просто взять и выпустить ИИ-бота общаться с живыми клиентами.
Ага. Он там такого наговорит. Точно. Нам нужно прогнать его через тысячи, десятки тысяч тестовых сценариев и математически измерить, как часто он ошибается, грубит или, что самое страшное, выдаёт конфиденциальную информацию. Если менеджер не знает, как спроектировать такие тесты, он выпустит продукт, который разрушит репутацию компании буквально за один день.
Хорошо. Картина вырисовывается, честно говоря, немного пугающая. Если неконтролируемое создание вот таких ИИ-инструментов несёт такие огромные риски безопасности и непредвиденных расходов, то самый логичный шаг для руководства – это просто взять и нажать на рубильник. Запретить всё.
Да, запретить использование любых несанкционированных нейросетей, заблокировать все доступы и вернуть всё под жёсткий, железбетонный контроль IT-отдела. Всё, проблема решена, разве нет?
И это самая частая реакция классического менеджмента. И она же самая разрушительная.
Почему? Потому что здесь мы сталкиваемся с потрясающей концепцией, которую автор исследования называет "община прототипов" или "prototype commons".
Звучит как какое-то поселение программистов-хиппи в лесу. Что это за община такая? Это неформальное, почти стихийное пространство внутри корпорации, где живут все эти самодельные скрипты и агенты автоматизации. И хитрость в том, что сотрудники создают их не от скуки. Они создают их, чтобы закрыть реальные, кровоточащие дыры в бизнес-процессах, до которых у официального IT-отдела просто годами не доходили руки.
Ага. То есть, если отдел логистики устал каждый день вручную переносить адреса доставок из писем в Excel, и руководство 3 года игнорировало их созданные просьбы купить нормальный софт, они просто просят нейросеть написать им парсер почты, и он работает.
Именно так. Это "община прототипов" – это не просто какой-то склад кустарных поделок. Это самая точная тепловая карта проблем компании в реальном времени.
Ух ты, да. Она ярко подсвечивает скрытый спрос, реальные болевые точки, которые мешают людям работать прямо сейчас. И если вы придёте туда с дубинкой запретов, эти инструменты никуда не исчезнут.
Они просто уйдут в подполье. Появится то, что в индустрии называют "теневым IT". Люди продолжат гонять через эти левые скрипты и конфиденциальные данные клиентов. Просто теперь они будут делать это тайно со своих личных ноутбуков или телефонов.
Абсолютно. И компания узнает об этом только тогда, когда эти данные сольют хакерам, и они появятся в даркнете.
Да, это худший сценарий. Поэтому правильный подход – это не запрет, а то, что Джонс называет "открытым исследованием". Продукт-менеджер должен сменить роль строгого надзирателя на роль любопытного исследователя. Он должен прийти к сотрудникам и выстроить такой уровень доверия, чтобы они сами добровольно показывали ему свои разработки. И как должен выглядеть этот разговор?
Вопросы должны звучать примерно так: "Вау, покажите, что вы тут сделали, как это работает, какую проблему вы пытались решить. И главное, мягко уточнить, к каким таблицам и базам данных этот инструмент обращается. Инновации должны происходить на свету, а не в тени".
О'кей, допустим, мы покопались в этой общине и нашли там абсолютный бриллиант. Ну, какой-то гениальный скрипт, который экономит компании кучу денег и времени. Мы же не можем просто взять этот код, написанный, ну, реально на коленке, и сказать: "Всё, ребята, с завтрашнего дня вся многотысячная компания работает через него".
Конечно, нет. Это самоубийство.
И как этот хаос структурировать? И вот тут в материале появляется отличная система, которую называют "лестница производственных классов". Да, чтобы управлять этим бездонным морем продуктов, нужна строгая категоризация с очень понятными правилами. Эта лестница состоит из четырёх ступеней. И давайте разберём её на каком-нибудь простом практическом примере.
Давай. Допустим, тот самый сотрудник службы поддержки создал скрипт, который читает гневные письма от клиентов и автоматически формирует черновик очень вежливого ответа, опираясь на базу знаний компании. Отличный пример. Итак, первая ступень нашей лестницы – это "персональный инструмент". Сотрудник запускает его только на своём рабочем компьютере, ну, чтобы облегчить жизнь лично себе. Какие тут действуют правила?
Правило здесь ровно одно. Этот скрипт не должен иметь доступа к чувствительным данным клиентов или коммерческой тайне, и он не имеет права отправлять ответы клиентам напрямую. То есть только формировать черновик, который человек потом проверяет. Звучит безопасно, да?
Если это правило соблюдается, продакт-менеджеру вообще не нужно в это вмешиваться. Пусть человек пользуется и экономит свои нервы.
Но скрипт оказался настолько хорош, что сотрудник поделился им с коллегами по смене, и теперь им пользуются, скажем, 10 человек. И мы переходим на вторую ступень – "командная бета-версия". Здесь уже одной свободы маловато, верно? Конечно, как только инструментом начинает пользоваться целая группа, сразу возникают риски зависимости. На этом этапе у скрипта должен появиться чёткий владелец.
Тот, кто его создал. Тот, кто его создал, да, и обязательно его заместитель. На случай, если создатель уволится или уйдёт в отпуск, должна появиться хотя бы какая-то базовая текстовая инструкция. И самое главное, нужен план реагирования на сбой – план Б. И именно, если завтра модель обновит свою API, и скрипт намертво свернётся, как эти 10 человек будут работать? Они должны чётко понимать, что придётся временно вернуться к ручному вводу, и бизнес-процесс от этого не должен рухнуть.
Понятно. Идём дальше по лестнице. Скрипт работает просто идеально. Слухи о нём дошли до высшего руководства. И теперь директор по клиентскому сервису говорит: "Я хочу, чтобы весь наш колл-центр, все 500 человек использовали эту гениальную штуку". И мы на третьей ступени – "поддерживаемый внутренний продукт". Тут, я так понимаю, детские игры заканчиваются.
Да, это переломный момент. Инструмент официально становится критической инфраструктурой компании. Теперь им управляет профессиональный продакт-менеджер. Код должен быть переписан или хотя бы тщательно проверен профессиональными инженерами.
Уже не на коленке. Настраивается круглосуточный мониторинг. Не падает ли сервер, не тормозит ли сеть? Внедряется строгая система прав доступа. Кто может менять настройки этого скрипта, а кто имеет право только им пользоваться? И обязателен регулярный аудит безопасности.
Ну и ээ, логичная вершина. Эволюция, четвёртая ступень – "продукт для клиентов". Это внешний уровень. Допустим, мы решаем сделать из этого внутреннего скрипта полноценного чатбота, который уже вообще без участия живого оператора отвечает клиентам прямо на сайте.
Здесь вступают в силу максимальные, самые жёсткие корпоративные стандарты. Тот самый процесс evaluations, о котором мы говорили чуть раньше. Тысячи тестов на галлюцинации, строжайшие проверки на безопасность промптов, чтобы, знаете, какой-нибудь хитрый клиент не мог взломать бота и заставить его раздавать бесплатные скидки всем подряд.
Да, такие случаи уже бывали. Это катастрофа. Это полноценный коммерческий софт со всеми вытекающими.
Эта лестница, ээ, она очень логична. Мы берём хорошую идею снизу и по правилам аккуратно тащим её наверх. Но в статье есть один момент, который меня просто поразил. Автор утверждает, что главная фундаментальная ошибка современных компаний – это когда эта лестница работает только в одном направлении, только наверх.
И это феноменально важное наблюдение. Мы все привыкли думать только о масштабировании. Больше, выше, сильнее. Но управление продуктом в эпоху ИИ – это, в первую очередь, гигиена. Это способность сознательно понижать статус продуктов на этой лестнице или вовсе их безжалостно убивать.
Знаете, это до боли напоминает ситуацию с ящиком для хлама. Ну, который есть у каждого дома, на кухне или где-нибудь в коридоре.
О, да. Мы все знаем этот ящик. Туда отправляются старые батарейки, какие-то зарядки от телефонов, которых у нас давно уже нет, загадочные болтики из IKEA, высохшие маркеры. Мы бросаем это всё туда с мыслью: "А вдруг пригодится". Но оно никогда не пригодится.
Никогда. И вот в масштабах корпорации этот ящик превращается в настоящую чёрную дыру, засасывающую огромные деньги.
Идеальная аналогия. В IT это красиво называется "техническим долгом", но в эпоху ИИ он растёт просто в геометрической прогрессии. Если менеджер не берёт на себя жёсткую ответственность находить старые скрипты и говорить: "Так, стоп. Этот бот для HR был популярен год назад. Сейчас им пользуются два человека, а мы ежемесячно платим за сервера и поддержку баз данных. Мы официально понижаем его статус обратно до персонального инструмента и снимаем с корпоративной поддержки".
Угу. Если он этого не сделает, компания просто захлебнётся. Она будет тратить миллионы на поддержание жизни абсолютно мёртвых проектов. Умение хирургически точно отсекать лишнее. Вот истинное проявление профессионального суждения сегодня.
Слушай, если попытаться как-то собрать все эти элементы в единую картину, мы действительно находимся в эпицентре невероятного исторического разворота. Мы окончательно прощаемся с эпохой, девиз которой звучал так: "Мы физически не можем построить всё, потому что у нас нет на это денег и инженеров".
Да, эта эпоха ушла. И мы на полной скорости влетаем в новую, захватывающую, но очень-очень опасную реальность. Её девиз: "Мы можем построить вообще всё, что угодно". Вопрос лишь в том, что именно из этого нам действительно следует строить.
И я хочу особо подчеркнуть, что этот сдвиг парадигмы затрагивает далеко не только людей с должностью "продакт-менеджер" на визитке. Это фундаментальное изменение правил игры для вообще любого человека, работающего с информацией.
Согласен. Если сделать процесс генерации, будь то написание кода для скрипта, создание текста презентации или какой-то первичный анализ данных, абсолютно бесплатным и мгновенным, а значит, ценность специалиста как создателя вот этого первичного сырья стремительно падает. Настоящим золотом становится человеческое суждение.
Умение выбирать, да. Ваша способность отфильтровать информационный шум, классифицировать сгенерированные идеи, применить критическое мышление к результатам работы машин, понять, какие стандарты качества нужны в каждой конкретной ситуации. Вот что будет определять профессиональную ценность ближайшее десятилетие.
Мм, и это, знаете, заставляет задуматься о совершенно фантастических сценариях ближайшего будущего. Если процесс создания софта уже сейчас свёлся к простому написанию промпта, а человек всё больше выступает в роли куратора этой огромной, разрастающейся экосистемы, не превратится ли менеджер из эдакого прораба на стройке в эколога цифровых систем? Ну, человека, который просто следит за тем, чтобы в корпоративном лесу не расплодились какие-нибудь инвазивные виды скриптов.
Очень интересная мысль. И самое интригующее. А что произойдёт с этой аккуратной лестницей классов, когда ИИ-агенты эволюционируют настолько, что начнут сами анализировать скрытый спрос?
Ого, это уже звучит как Skynet. Ну вот представьте, ИИ замечает неэффективность в работе бухгалтерии. Он сам генерирует для них новый инструмент, сам тестирует его, сам прогоняет через evaluations и разворачивает для использования другими ИИ-агентами вообще без единого касания человека. Сможем ли мы в принципе отследить такую эволюцию?
Это огромный вопрос. Или наши человеческие методы контроля и классификации окажутся для их скоростей безнадёжно медленными? В общем, тут определённо есть над чем подумать.