Продукт

ClaudeMD автоматического выбора ИИ-модели для продуктовой работы Рейтинги – это стартовая калибровка, а не фиксированные данные и чем выше число, тем лучше. Модель / Стоимость / Интеллект / Вкус sonnet-5 / 8 / 6 / 6 / opus-4. / 8 / 5 / 8 / 7 / fable-5 / 3 / 9 / 8 / – Стоимость. То, что ощущается в лимитах токенов и скорости. – Интеллект. Насколько сложную, многошаговую или неоднозначную задачу можно доверить модели без присмотра. – Вкус. Качество структуры документа, формулировок, тона в коммуникации и чуткость к контексту. Откалибруй эти цифры под собственный опыт после пары недель использования. Важна не точность чисел, а сам принцип: не гонять сложные решения через дешёвую модель и не тратить дорогую модель на рутину. Как применять: – Это дефолты, а не ограничения. Если результат дешёвой модели не дотягивает, то не спрашивай разрешения, перезапускай с более сильной. Суди по результату, а не по тому, что модель просто должна была справиться.

Пересогласование стоит дешевле, чем решение, принятое на слабом анализе

– Когда параметры конфликтуют для чего-то, что реально влияет на решения или уходит наружу, опирайся на: 1. Интеллект > 2. Вкус > 3. Стоимость – Массовая механическая работа (расшифровка транскриптов интервью, разметка тикетов, сведение таблиц с метриками, черновой синтез фидбека из десятков источников): sonnet-5. – Всё, что уходит наружу стейкхолдерам, клиентам, руководству (питчи, обоснование приоритизации, деликатные апдейты о задержках, переговоры о scope): нужен вкус ≥ 7. – Ревью и вторая пара глаз (проверка PRD перед отправкой инженерам, стресс-тест roadmap, поиск дыр в бизнес-кейсе): fable-5 или opus-4.8, по возможности оба как независимые мнения, если решение необратимое. – Стратегические и неоднозначные решения (trade-off между конкурирующими метриками, приоритизация, спорные ставки без явного правильного ответа): fable-5. – Никогда не используй самую слабую модель для документов, которые пойдут выше вашего уровня или станут прецедентом для команды. Режимы работы – Написание PRD и спек с нуля → opus-4.8 как основа → fable-5 для финального ревью перед отправкой в разработку. – Discovery-синтез sonnet-5 для чистой расшифровки на входе (несколько интервью → инсайты → гипотезы) → fable-5 для самого синтеза (нужен интеллект, чтобы не сгладить противоречия) – Приоритизация бэклога / RICE-скоринг → sonnet-5 для механического прогона по формуле → opus-4.8 для проверки, не искажает ли формула реальный контекст → fable-5 для синтеза – Коммуникация о задержках и плохих новостях стейкхолдерам → fable-5 или opus-4.8. Тон и причины здесь важнее скорости. – Рутинные апдейты статуса, саммари встречи, заметки в трекер → sonnet-5. – Pre-mortem, поиск слабых мест в плане запуска → opus-4.8 → fable-5 как отдельная независимая проверка. – Черновик поста / статьи / контента на основе рабочих заметок → opus-4.8 для черновика → fable-5 для финальной правки тона и структуры. – Анализ больших выгрузок данных / метрик → sonnet-5 для первого прохода и агрегации → эскалация на opus-4.8, если нужна интерпретация неоднозначных паттернов → fable-5 для финальной проверки паттернов.

✨ Как эффективно использовать SKU-коды SKU-коды активно применяются в розничной торговле, на маркетплейсах и в сфере дистрибуции. Они позволяют точно отслеживать товарные запасы, контролировать сроки годности продукции и проводить анализ продаж. Благодаря мобильным сканерам штрихкодов сотрудники могут быстро обновлять информацию о наличии товаров, что повышает точность складского учета. SKU-коды помогают вовремя выявлять просроченные позиции и упрощают процесс их списания. Они также незаменимы для анализа спроса: с их помощью легко определить, какие товары продаются лучше всего, а какие залеживаются на складе. На маркетплейсах использование SKU ускоряет поиск нужного товара на складах, что помогает быстрее комплектовать заказы и повышает качество обслуживания клиентов. Фаундер | Бизнес и Стартапы

У Эрика Риса (того самого автора Lean Startup) вышла новая книга — Incorruptible. Читаю, оч нравится и сильно резонирует, впечатлениями поделюсь отдельно, а пока разберу, что про неё написал Марти Каган. Всю карьеру Каган повторял: сильный продукт — вот что делает компанию сильной. Теперь поправка: продукт необходимое условие, но не достаточное, а иногда именно он компанию и губит. Звучит вывернуто, но логика простая: как только ты доказал, что умеешь делать хорошие продукты, компания становится лакомой добычей для опуртунистов. Приходят люди с другим интересом: быстро снять кэш и выйти. Заходят в борд, меняют основателя, вычищают миссионеров, за пару лет выжигают культуру, и то, что собиралось годами, схлопывается. Каган бывало умолял советы директоров не выкидывать лидеров из-за одного слитого квартала: просадки бывают у всех, смотрите на длинный горизонт, вы и себе роете яму. По факту, редко работало, и Каган отмечает это, как свой слабый скил. Убедить инвестора, который в продукте не шарит, почти никогда не получалось. Как правило, это не болячка хрупких стартапов, так же перемалывает и зрелые компании. Годами он считал это просто платой за живую экосистему. Неизбежное зло, забей, занимайся тем, что в твоей власти. Книга Риса заставила его в этом усомниться. Если Lean Startup была про то, как построить сильный продукт, то Incorruptible — про то, как построить компанию, которую у тебя не отнимут. И защита тут не продуктовая и не культурная, а скучная — корпоративное управление. Структуры, которые Рис зовёт mission-locked: миссию юридически зашивают в устав так, что перехватить контроль и перекрутить бизнес на короткие деньги технически невозможно. Каган же governance всю жизнь держал за тему для юристов, сам туда не лез, спихивал на аутсорс, но книга его натолкнула на осознание ошибки. И книгу читает почти как приговор юристам, бизнес-школам и консультантам, которые должны были компании защищать, а в итоге просрали все полимеры. И почему это вообще про продакта, а не только про основателя. От того, как устроено владение компанией, тихо зависит, дадут тебе делать нормальный продукт или ты каждый спринт/квартал/ревью будешь отбиваться от секвестра. Неочевидно, если ты привык мерить компанию продуктом, а не тем, кто ей рулит и на каких условиях. https://www.svpg.com/great-products-bad-companies/

Кастомный фичеринг Катите какую-то новую штуку в продукте, подумайте как о ней узнает пользователь. Но не все фичи нужно сопровождать попапами, всплывахами и рассылками. Одна из таких в Яндекс Навигаторе попалась мне на днях. Ребята подсвечивают куда смотрят камеры. Синее поле - если ты в допустимом скоростном режиме и красное, если превышаешь. Узнал об этой функции нативно, стоял на светофоре, смотрю какое-то поле показывают. Думаю о как круто, вау эффект и лояльность продукту. То есть, мне, как водителю, не нужно дополнительно объяснять, что это и зачем. Очевидная функциональность без доп.промо, кайф. Выбор делать фичеринг или нет решается через простые ux тесты на небольших выборках. Дал целевым респондентам задачку с новой функцией, посмотрел справляются или нет, принял решение. Хорошо же❤️ #юиксюайное

Запись подкаста "Директор бренда", где говорили про VK Знакомства и обсудили много интересного: - Как мы строим доверие в одном из крупнейших цифровых сервисов России - Как нам удаётся сохранять идентичность бренда внутри большой экосистемы - Рассказал про кейс масштабного ребрендинга Badoo, который я проводил - Почему я считаю, что крупные продукты постепенно отказываются от манипуляций и темных паттернов - Как алгоритмы знакомств решают, кого вам показывать - Поделился главным инсайтом о людях, который я вынес за 15 лет работы в дейтинге - Чем, на мой взгляд, российский рынок знакомств отличается от мирового - Каким я вижу будущее рынка знакомств и главные тренды ближайших лет Смотрите подробнее https://youtu.be/Cv019gk8VEI

Почему AI-персоны так убедительно врут Как-то я писала про подход, суть которого юзер-ресерч с помощью AI-персон. Ты описываешь портрет клиента, а LLM отыгрывает его и отвечает на вопросы как живой человек. Звучит как мечта соло-билдера: ноль рекрутинга, ноль созвонов, а “инсайты” можно собрать за один вечер. Но не так однозначно. Что с ними не так: • Модели склонны подстраиваться под рамку вопроса. Дашь чуть наводящую формулировку, и нейронка очень убедительно подтвердит то, что ты и так хотел услышать. • Если не дать модели свежие реальные данные, она опирается на усреднённое прошлое: тексты, паттерны и представления, на которых её обучали. А не на поведение конкретных пользователей сегодня. • Они плохо преподносят сюрпризы. Хороший ресерч часто ценен именно тем, что человек говорит или делает что-то, чего ты вообще не ожидал. AI-персона чаще выдаёт правдоподобное. Но правдоподобное мы и сами можем придумать. В итоге ответы часто получаются плоскими, слишком аккуратными и слишком благожелательными. Synthetic users могут хвалить то, что реальные люди потом игнорируют, не понимают или отвергают. Но это не значит, что инструмент бесполезный. Просто он работает ДО ресерча, а не вместо него: • Прогнать гайд интервью и поймать кривые, скучные или наводящие вопросы. • Быстро накидать гипотезы, чтобы прийти на живые созвоны более подготовленным. • Сделать pre-mortem концепта перед тем, как тратить бюджет на рекрутинг. • Проверить, какие возражения или edge кейсы стоит отдельно послушать у реальных людей. Источник: https://userevaluation.com/post/synthetic-users-vs-real-participants/ #PG_education @productgames

Клиент не сказал ни одного «да». И это была лучшая встреча за месяц На прошлой неделе собрал звонок: я и двое фаундеров, участники клуба MFS, Саша и Стас. Саша делает базу данных для AI-стартапов — она удешевляет хранение данных и ускоряет поиск. Стас — основатель HR-tech с enterprise-клиентами. Идея простая — прокастдевить Стаса как потенциального клиента Саши. Посмотреть, где болит, и понять, ложится ли туда продукт. Пошло не по плану. Уже к третьей минуте Саша начал рассказывать, какой у него классный продукт, сколько он сэкономит на инфраструктуре и как легко на него переехать. Стас — отвечать возражениями. Сижу и понимаю: это уже не кастдев, это переговоры, на которые Стас вообще-то не приходил. Пришлось вмешаться: ребят, стоп, мы тут ничего не продаём. Саша — «а я и не продаю». Стас — «нет, ты продаёшь». Но в итоге именно из этой перепалки вышло самое ценное. Стас поделился, что у него за последний год прилетели контракты по 350к евро с процедурой закупки по девять месяцев. В сделках такого масштаба IT-блок клиента согласовывает весь стек вендоров — если видит незнакомый продукт, просто говорит «нет», и сделка, за которую боролись почти год, просто слетает. Например, один крупный клиент без ISO 27001 поставил сделку на холд. Поэтому Стасу на текущем этапе развития плевать на экономию токенов и любую оптимизацию, которую предлагал Саша, — единственное, что для него важно, чтобы ничего не угрожало сделкам. Дальше Стас прямо сформулировал, как у него внутри устроено принятие решения: CTO смотрит на технологию, Head of Sales — на возможные угрозы для плана продаж, и ему вообще всё равно, сколько продукт экономит компании. Если хоть один скажет «нет» — сделки не будет. Два покупателя, и говорить с ними нужно на разных языках. В концу разговора Саша сказал, что цель встречи выполнена — узнал ровно то, за чем приходил. Хотя за весь звонок Стас не сказал ни одного «да». Зато накидал десяток возражений, которые для раннего стартапа могут быть ценнее чем продажа. Андрей Резинкин | Money For Startup

Да кто такие эти ваши producer-side A/B-тесты? В своей яндексовской эре работы над рекомендациями я точечно работал над качеством ранжирующей модели и не выглядывал за пределы этой области. Та же история была и в рекомендательном периоде работы в X. Но тут один добрый человек рассказал мне, что я оказывается жизни-то вообще и не знаю. Качество системы с точки зрения пользователя это ещё половина проблемы. Дело в том, что для долгосрочного качества платформы и процветания бизнеса необходимо смотреть на то, как изменение системы влияет на производителей контента (что в соцсети, что в маркетплейсе). В самом экстремальном случае система может показывать пользователям очень маленькую прослойку разнообразных авторов и игнорировать остальных. Те могут расстроиться и перестать постить, тем самым ухудшить долгосрочную ситуацию. Влияние на авторов и замеряется с помощью этого самого producer-side A/B теста. Посмотрим на то, как выглядит наивная её реализация в контексте рекомендаций. Среди всех авторов выделяем 2 группы - контрольную и тестовую - к примеру, по 1%. Скор для (98+1)% документов считается дефолтной моделью, тогда как для тестового набора из 1% будем предсказывать новой моделькой. Допустим, что она отдаёт большее предпочтения мелким авторам. Такой тест покажет прекрасный результат - все мелкие авторы счастливы и стали генерировать больше контента. Классический user-side тест, допустим, показал нейтральные метрики. Вроде бы всё в шоколаде, и вы шипаете изменение в прод, но вот беда - эффект испарился. Задроты вам укажут - на лицо нарушение Stable Unit Treatment Value Assumption. Перевожу на русский - изменение ведёт себя по-разному в зависимости от доли, на которую его раскатили. Тот кусочек мелких авторов среди 1%-ной выборки получил преимущество перед 99% таких же вне её. Раскатив изменение, весь рост показов, которые они получили в AB-тесте, размажется на остальные 99%. Чтобы побороть этот эффект, нужен фреймворк посложнее. Одно из решений предлагается в статье от Меты - "A Counterfactual Framework for Seller-Side A/B Testing on Marketplaces". Не знаю, насколько в ней это впервые предложили - может и нет, мне не важно. Иллюстрация на картинке. Итак, теперь мы будем оценивать 100% постов обеими системами - старой и новой (синей и зелёной). Для документов из контрольной выборки мы получаем их финальные позиции, как если бы мы ранжировали все 100% документов так, как обычно - они обозначены как C_1 и C_2. В то же время, документы из тестовой выборки получают свои финальные позиции так, как если бы все 100% документов ранжировала новая система - это T_1 и T_2. Финальную выдачу для пользователя мы создаём, расставляя эти документы на их соответствующие позиции, закрывая глаза на коллизии и помещая случайно друг под другом, если позиции точно совпали. Самый прикол этой схемы в том, что на ранжирование остальных 98% документов в принципе всё равно - до выкатки это будет старая система, после выкатки это будет новая система, но размер эффекта на документы в обоих случаях ожидается одинаковый. Именно это в том числе и проверяют авторы данной работы. В нижней части слева расположена выдача до выкатки - pre-test, а справа после выкатки - back-test. Авторы приводят результаты своих тестов, в которых демонстрируют одинаковость эффекта на измеряемые документы. Такая схема тестирования гораздо ближе к SUTVA. Надо понимать, что эта грёбаная SUTVA никогда не выполняется полностью. Любая выкатка изменяет распределение данных для обучения и последующее ранжирование. В обычных пользовательских A/B-тестах на это закрывают глаза и надеются, что эффект сохранится, что часто подтверждается holdback-экспом. А вот с авторскими A/B-тестами приходится проделывать такую гимнастику, чтобы хоть как-то подобраться к честному замеру. @knowledge_accumulator

Грустный #producthumor на тему событий прошлой недели, когда Apple удалил все приложения VK из стора. Хочется понять как работает такой подход и почему им активно не пользуются мошенники. Помню был период, когда Альфабанк почти каждую неделю публиковал новое приложение в сторе. Всякие Учёты доходов, Холдеры, A-интерьеры и BizKey-и. Их регулярно удаляли, а компания запускала новые. Интересно, как это выглядит с точки зрения команды безопасности? У каждого приложения есть возможность авторизовать клиента в мобильном банкинге с доступом ко всем деньгам? А поддержка как с этим работает? Для мошенников, кажется, вообще идеальный способ. Делаешь приложение, заманиваешь клиентов банка, получаешь реквизиты доступа, делаешь запрос на OTP, используешь его и реквизиты для входа в настоящее приложение, выводишь деньги. Или я что-то не понимаю? Поделитесь в комментариях, если знаете. #producteye

Как запустить новый продукт — и не разругаться, когда стратегия начинает ломаться Кейс «Авито Премиум» Продолжаем разбирать, как продукту и бизнесу работать на равных, — уже на примере запуска нового продукта. В «Авито» была стратегическая задача: стать лидером премиум-ресейл-сегмента и привлечь новую аудиторию в фешен-категорию. Но бизнес и продукт изначально смотрели на реализацию по-разному: ➡️ Бизнес видел точку роста в профессиональных продавцах — бутиках и ресейл-магазинах люксовых брендов. Логика была понятной: у таких продавцов уже проверенный ассортимент, и не придется масштабно вкладываться в проверку подлинности товаров. ➡️ Продуктовая команда пошла исследовать поведение пользователей — и увидела, что основной запрос — возможность безопасно покупать оригинальные вещи массового премиум-сегмента: Adidas, Michael Kors и других брендов, где особенно много реплик. Из этого сформировалась гипотеза, что пользователям нужны: — проверка на подлинность; — отдельное пространство с проверенными товарами. А еще на старте казалось, что основу ассортимента составят профессиональные продавцы. Но в ходе запуска выяснилось, что пользователи намного активнее реагируют на предложения частных продавцов. И тогда исходная стратегия начала меняться. Потому что вместе с ростом частного ассортимента вырос и объем проверок. А модель, в которой проверка оплачивалась платформой, перестала сходиться по экономике. Командам пришлось быстро перестраивать подход: ➡️ пересматривать позиционирование; ➡️ менять финансовую модель; ➡️ аккуратно тестировать платную проверку; ➡️ искать баланс между экономикой, ассортиментом и пользовательским опытом. При этом продукт и бизнес не начали тянуть систему в разные стороны: — бизнес — в сторону прибыли, — продукт — в сторону пользовательского опыта. Команды заранее договорились об общей целевой метрике — GMV (общий объем продаж), но разделили зоны влияния: 🔵 Бизнес отвечал за ассортимент и средний чек. 🔵 Продукт — за конверсии внутри воронки проверки и организацию премиального пространства. Помогло и то, что работа была синхронизирована не только на уровне метрик — она включала: — регулярные встречи; — совместные продуктовые разборы; — общие ассортиментные стратегии; — единые годовые цели; — прозрачные каналы коммуникации. А еще — совместное погружение в контекст: команды вместе запускали премиальный пункт выдачи на Патриарших прудах, общались с продавцами, собирали обратную связь и сами проходили операционные сценарии пользователей. В итоге запуск показал, что налаженная совместная работа продукта и бизнеса позволяет вовремя отследить важные сигналы рынка и пересобрать стратегию под его запросы. Чек-лист Что помогает продукту и бизнесу не развалиться, когда стратегия меняется уже после запуска: 1️⃣ Договориться о единых терминах. Чтобы продуктовые процессы не звучали для бизнеса как «птичий язык». 2️⃣ Связать продуктовые метрики с бизнес-целями Чтобы команда могла объяснять влияние продукта на языке бизнеса. 3️⃣ Провести взаимный онбординг: — продукта в бизнес; — бизнеса в продукт. 4️⃣ Обсудить стратегию развития продукта заранее: — видение бизнеса; — драйверы и барьеры продукта; — допустимые компромиссы; — систему метрик. 5️⃣ Зафиксировать зоны ответственности: — кто принимает решения; — где границы бизнеса; — где границы продукта; — кто подключается в спорных ситуациях. 6️⃣ Планировать не только дорожную карту, но и критерии гибкости. Что команда будет делать, если рынок или экономика покажут другую картину? 7️⃣ Регулярно погружаться в контекст друг друга: — совместные интервью; — просмотр пользовательских сценариев; — участие в операционных процессах; — тестирование продукта своими руками. Потому что в реальности почти ни один запуск не идет ровно по первоначальному плану. По мотивам доклада «Продукт и бизнес на равных: как договариваться и влиять на деньги, приоритеты и общие цели» Алены Медведевой на конференции ProductSense’25. 💙 VK 🖤 YouTube @productsense

Народная карта бензина собрала почти 2 млн посетителей за три дня. Её навайбкодил один человек Бэкенд кое-как держит нагрузку, но от нормальной монетизации автор отказывается из принципа — пока есть только донаты. На фоне топливного кризиса появился ГдеБЕНЗ: народная карта, на которой водители сами в реальном времени отмечают, где топливо есть, где очередь, где машин мало и куда ехать уже бессмысленно. Логика простая до примитива: любой публичной заправке можно выдать эти четыре статуса, никакой регистрации нет, как и отдельного приложения, карта работает прямо в браузере. Один водитель отметил, что бензин появился, второй подтвердил, третий уточнил марку и очередь — и десятки людей рядом уже понимают, где стоит пытаться заправиться, а где нет. За первые дни ГдеБЕНЗ собрал больше 100 тысяч отметок, 2 тысячи добавленных вручную заправок и 80 тысяч установок карты на главный экран. Я поговорил с его автором Евгением Чудовым: судя по присланным скринам из Яндекс.Метрики, у проекта за трое суток — 1,8 млн уникальных посетителей, 3,5 млн визитов и 13,2 млн просмотров. Для сравнения: за первые двое суток было 812 тысяч уникальных пользователей. То есть сегодня у сервиса плюс миллион аудитории. Чудов — маркетолог и предприниматель, основатель биржи рекламы Marketly в каналах MAX. Он ведёт сетку каналов на 2 млн+ подписчиков, сделал популярного бота автопостинга «Отложка» (им пользуются 30 тысяч+ каналов). Думаю, можно сказать, что он запускался не с нуля — у него уже были готовая дистрибуция, как и привычка строить инструменты самому под себя. ГдеБЕНЗ, по его словам, он придумал в самолёте, по приземлении накидал план — и к вечеру всё работало. Сервис собран с помощью Claude. На вопрос про разработку Чудов ответил лаконично: «Токенов не счесть» — за эти дни он спалил почти два недельных лимита тарифа Claude Max (который даёт x20 к обычным лимитам). Конечно, ГдеБЕНЗ работает не идеально. Первые сутки автор прыгал с сервера на сервер, наращивая мощность по чуть-чуть, чтобы сайт работал — потом увеличил ресурсы кратно, но лаги и недогруз карты у части пользователей остаются. Инфраструктура к такому наплыву готова не была, и это нормально для сервиса, которому всего несколько дней от роду. Монетизировать ГдеБЕНЗ Чудов хочет, но «исключительно полезной рекламой»: говорит, скамеры и чёрная реклама уже набежали, и «лучше уйду в минус, чем буду толкать людям грязь». Пока — только добровольные чаевые на сервера. Самым диким событием за эти дни он назвал то, что криптаны на хайпе уже успели выпустить монету «ГдеБЕНЗ», а он к этому не имел отношения — пришлось публично открещиваться. Отдельная примета — каналы ГдеБЕНЗ в MAX и Telegram уже насчитывают десятки тысяч подписчиков. В MAX их больше, чем в Telegram, что косвенно говорит о реальной популярности в регионах, а не только в столично-питерском пузыре. На вопрос, сколько процентов заправок сейчас сталкиваются с нехваткой, Чудов отвечать отказался — по его словам, его и так подозревают, что проект «чей-то» и сделан не из благих побуждений. В одном из постов от ГдеБЕНЗ подробно развенчивалась конспирология, что проект — это OSINT для поиска объектов для нанесения ударов. Ну и из топливных компаний и регуляторов с ним пока никто не связывался; говорит, был бы рад, если бы написали те же Яндекс Заправки. Нечасто случается, что вот прям резко и массово оказываются нужны такие узкоспециализированные коммуникационные сервисы — а когда такая потребность возникает, с инструментами типа Claude Code одинокий вайбкодер закрывает её быстрее, чем любая корпорация. И дело не только в скорости разработки (хотя в большой компании ты такое за три дня не выкатишь), но и в рисках того, чтобы показывать дефицит в реальном времени — сегодня это может быть социально радиоактивно. Бензин из воздуха ГдеБЕНЗ, конечно, не создаёт. Но честно отвечает на единственный вопрос, который сейчас волнует полстраны: ехать или не стоит.

Услышьте гениального интроверта ❤ Защита инициативы в компании часто происходит ярко, с презентацией и красноречивым спикером. Но что, если за всеми красками скрывается посредственная идея? Точно ли вы сможете это увидеть? Мы в Авито опасаемся таких ситуаций и поэтому на защите вместо спича и презентаций принимаем только 6-пейджер. Это шестистраничный текстовый документ, в котором по строгим правилам описана инициатива. Да, это скучно, зато работает гениально: структурирует логику, нивелирует харизму и позволяет сравнивать идеи объективно. 📌 Георгий Степанов из продуктового офиса Авито недушно рассказал о процессе в статье: читайте и берите в работу.

Знаете, от чего прям противно? Вот эти вот прогрессбары, которые движутся не от настоящего прогресса, а с предзаданной скоростью. Типа, чтобы пользователь не пугался. В чем вообще идея прогрессбара? Вот у тебя есть N файлов, ты скопировал M из них, и показал на прогрессбаре M / N × 100%. Ну и ты видишь, сколько работы сделано, а сколько осталось. Некоторые прогрессбары даже время примерное до конца показывали! Потом люди заметили, что иногда прогресс неравномерен. Например, с теми же файлами, большой файл копируется дольше, а прогресс мы считаем по количеству. Тогда на большом файле 1% прогресса будет продвигаться дольше, чем на маленьких. Или скачивание из интренета, там вообще непредсказуемо. Если ты начнешь тут считать время, оставшееся до конца, оно у тебя будет плясать — 30 секунд, полдня, неделя, о, снова 30! Пошли сразу шутки, про 99%, про квантовую природу прогрессбаров и так далее. Но — что важно — отображаемый прогресс был связан хоть с чем-то реальным! Можно было поставить курсор мыши на текущее положение, и если оно через 15 минут сдвинулось, значит программа еще что-то делает, а не зависла. Понятно, что прогресс можно предсказать не всегда. Какая-нибудь установка софта, или, не знаю, обработка фотки плагином, короче, какая-то операция, которая не бьется так легко на N шагов, и в которой не всегда понятно, что такое прогресс. Для таких случаев придумали крутилки и недетерменированные прогресс-бары — это такие, в которых полосы нет, а просто все закрашено паттерном и крутится бесконечно по циклу. Типа, идея та же, операция делается, но сколько там прошло и сколько осталось мы фиг его знает. Это все нормальные идеи. Пока что все хорошо. Элементы используются по назначению, коммуникация честная, претензий нет. А потом какой-то маркетолог, или, может, таролог или астролог, в общем, человек с выдуманной профессией, подумал: смотрите. Допустим, мы логиним пользователя. Это сколько-то времени займет. Сколько? Никто не знает. Может, секунду. Может, десять. Вряд ли больше десяти. Но и не мнгновенно. То есть подождать придется. Так? Так. Это значит что? Что пользователь будет переживать. Надо ему что-то показать. Давайте покажем ему детерменированный прогресс-бар! Программисты сразу такие: ну нет, мы прогресс не посчитаем, там сложно, или еще какое-то му-хрю, расписались в беспомощности. И тут мораль/сила воли/система ценностей, которой ни у кого из присуствующих и не было, дала слабину. «Давайте рисовать прогресс от балды!» — сказали они. За первую секунду закрасим 25%. Равномерно, будем добавлять 1% каждые 40 мс. За вторую закрасим, условно, 20%, за третью 15% и так далее. Как только загрузимся, то сразу дорисовываем до 100%, все же радуются, когда кажется, что куча времени еще осталась, а тут хоба и все сразу сделано! Ну а если не загрузимся за 10 секунд, то последние 5% будем тянуть сколько сможем, по какой-нибудь бесконечно приближающейся асимптоте (я уверен, что на том митинге, где это решили, прозвучало слово асимптота, мне нужно хоть что-то приятное про него представлять, иначе хана). Так родилось самое противное изобретение современного интерфейсостроения — лживый прогрессбар. По сути своей он недетерменированный. Но выглядит как детерменированный. Он намеренно лжет и о совершенном прогрессе, и об оставшемся времени. Лжет прямо вам в лицо и не стесняется этого. Еще и выдает это под соусом заботы о пользователе. А ничо тот факт, что мне, как пользователю, нравилось знать, что происходит? Что мне настоящий прогресс, сколь угодно неравновномерный, дороже любых лживых ваших мультфильмов? К настоящему можно было приспособиться, можно было выводы какие-то делать. Им можно было ПОЛЬЗОВАТЬСЯ. А со лживым можно только пить водку, грустно смотреть и плакать. Хватит прятать от меня компьютер! Хватит кормить меня пустыми обещаниями! Я взрослый человек, я хочу знать, что происходит! Я готов принять любой прогресс, пока он правдивый. А обещаниями своими в веб-интерфейсах друг друга кормите.

По мере того как роли в сферах разработки продуктов, дизайна, Data Science и других сливаются воедино благодаря ИИ, я размышлял о том, как они могут выглядеть в будущем (Boris Cherny, Claude Code) Например, глядя на команду Claude Code, я выделяю пять архетипов: 1. Прототипировщик (Prototyper): генерирует совершенно новые идеи; выдает множество идей, большинство из которых не доходят до стадии реализации. 2. Создатель (Builder) быстро превращает прототип или идею в готовый к эксплуатации продукт или инфраструктуру. 3. Упорядочиватель (Sweeper): приводит в порядок интерфейс, упрощает код и систему, удаляет лишнее, оптимизирует производительность. 4. Развиватель (Grower): берёт уже созданный продукт и дорабатывает его для улучшения соответствия продукта рынку (Product-Market Fit). 5. Поддержка (Maintainer): отвечает за зрелую систему, обеспечивая её безопасность, надёжность, быстродействие и эффективность по мере масштабирования. Многие специалисты совмещают две, а иногда и три роли. Я также заметил, что эти роли не жестко привязаны к должностным обязанностям. Например, в Anthropic есть дизайнеры, соответствующие категориям 1, 2 или 3; то же самое касается инженеров, продакт-менеджеров и специалистов по данным.

Здоровой команде требуется сочетание этих ролей в зависимости от продукта:

- Для нового продукта, ещё не нашедшего соответствие рынку (pre-PMF), нужны люди с сильными навыками типов 1, 2 и 3. - Для растущего продукта, нашедшего соответствие рынку, нужны типы 2, 3, 4 и отчасти 5. - Для продукта с сильным соответствием рынку нужны типы 3, 4, 5 и отчасти 2. Возможно, именно так будут выглядеть продуктовые роли будущего, а не как нынешние узкоспециализированные должности. – 3 основных типа лидеров продукта – Новая структура любого отдела в компании – Командные роли по Белбину