В Китае в округе Цзиньюн появился геймерский отель Master-K. За $50/сутки можно получить апартаменты для двоих пользователей с топовыми ПК, а также к лобби с игровым клубом и общению с другими фанатами игр.
ChatGPT запускает Health сервис. 2 года, 260+ врачей. На базе того, что 230+М человек в неделю задают вопросы связанные со здоровьем.
В начале прошлого года уже публиковали исследование сравнения GPT-4+ prompt engineering (без fine-tuning) и лицензированных терапевтов на 18 терапевтических виньетках (коротких кейсах) - Hatch et al. PLOS Mental Health. Оценивали не клинический эффект, а поддерживающие ответы. Ответы терапевтов писали 13 специалистов и 9 из них с PhD/PsyD. Далее 830 участников (широкая выборка, не только клиницисты) оценивали тексты вслепую.
В тесте Тьюринга на Угадай Кто Ответил различимость почти на уровне случайного выбора: 56,1% терапевта vs 51,2% ChatGPT
В post-hoc анализах модель чаще выглядела более “connecting”, более эмпатичной. И в целом по шкале общих факторов терапии (эмпатия, поддержка и т.д..) средняя оценка модели была немного выше (27,72 vs 26,12). Понятно, что тест на виньетках и это оставляет большие риски при обобщении модели и переводе в практику
При этом концептуально, я думаю, что этот тренд не про замену врача, а про триаж. Модель может позволить снять страх первого вопроса и дать дополнительный буст обратиться к врачу при ред флагах. В общем интересно будет потестить.
Также любопытно будет влияние на статистику в ранней диагностике, запущенных случаях и ложных обращениях. AI-Health не новость, но ChatGPT имеет тот охват и соотвенно потенциальное влияние, которые могут влиять на крупные цифры
Представлен локальный и бесплатный сервис BentoPDF для работы с PDF. Вся обработка происходит в браузере. Умеет объединение, разделение, поворот, удаление страниц и кроппинг, а также в нём можно быстро добавить вотермарку, сделать нумерацию страниц и поменять текст в файлах. При этом бесплатно, без лимитов и даже регистрацию не просят.
Microsoft не смогла сдержать свои обещания - компания добавила ИИ-поиск в настройки Windows 11, но он не работает с фразой, которую разработчики предлагают для теста.
Владельцы iPhone 17 Pro и Pro Max сообщили о возникновении статического шума из динамиков смартфонов во время зарядки. Звук напоминает шипение старого радиоприемника. У части пользователей проблема с шумом возникает при воспроизведении видео на низкой громкости, а у кого-то шум появляется при скроллинге страниц в интернете. Этот шум слышно при использовании любой зарядки, как оригинальной, так и от сторонних производителей. Часть пользователей, которые заменили свои смартфоны на новые, также продолжают жаловаться на неприятный звук. В техподдержке Apple сообщили, что уже изучают вопрос с этим шумом.
Почему хорошие технические решения иногда ломают бизнес?
За годы работы заметил частую закономерность: решение может быть абсолютно правильным с точки зрения архитектуры и при этом плохо работать в реальности компании/бизнеса.
Причина почти всегда одна: его принимали без учёта операционных ограничений (людей, сроков, процессов).
С тех пор, стараюсь смотреть на технические решения не только глазами инженера или CTO, но и через призму того, как с ними будет жить бизнес каждый день (COO).
Это наблюдение и стало решающим для меня при определении направления развития карьеры в сторону управления процессами. Зачастую, правильно (как требуется) поставленные процессы добиваются большего бизнес-эффекта, чем самое технически совершенное решение.
А как вы находите баланс между операционкой и техническим совершенством продукта?
Неделю назад выступал с темой MCP сервера и как можно решить проблему с забиванием контекста как при старте диалога, так и при последующем общении через MCP сервера
Это больше походит на исследовательскую работу, а не на мой каждодневный сценарий использования. Мне было интересно, до скольки токенов можно сжать диалог без ухудшения качества
Вот, можете ознакомиться ⤵️⤵️⤵️
Давайте для начала о том, что такое MCP
MCP — протокол, который позволяет LLM подключаться к внешним сервисам: Notion, GitHub, Jira, Google Analytics, любой сервис с API. Один стандартный разъём вместо зоопарка интеграций — как USB для AI.
Протокол создали в Anthropic в ноябре 2024, в декабре 2025 передали в Linux Foundation с поддержкой OpenAI, Google, Microsoft и AWS. Де-факто стандарт индустрии. Вот тут есть каталог серверов, можете глянуть
Я уже писал про MCP ранее, тоже можете глянуть
Model Context Protocol. Революция в интеграции AI с данными?
Как управлять Notion, GitHub через Claude. Мои примеры MCP серверов
--------------
Но у MCP есть две неочевидные проблемы, на которые я наткнулся после нескольких месяцев активного использования.
🛸 Проблема №1: Tools съедают контекст до старта
Предзагруженные MCP Tools занимают Context Window ещё до первого сообщения. Как системный промпт — уже там, когда вы только открыли чат.
Конкретные цифры из моих замеров:
Apify MCP — 7 инструментов, ~11.8k токенов
GitHub Official MCP — 40 инструментов, ~25-30k токенов
Несколько серверов вместе — легко съедают 40-70k токенов
При контексте в 200k это уже 20-35% бюджета — и вы ещё ничего не спросили.
🛸 Проблема №2: JSON забивает контекст в процессе
MCP-сервер — это переброска JSON-запросов между LLM и сервисом. Каждый вызов инструмента генерирует запрос и ответ, которые остаются в истории чата. Эти JSON часто громоздкие — особенно ответы с данными. Контекст забивается не на старте, а по ходу общения.
Почему это важно
Популярные модели имеют Context Window 128-200k токенов. Это весь бюджет чата: системные промпты, знания о вас, файлы, коннекторы. Что не влезает — забывается.
Хуже того: чем больше загружено в контекст, тем чаще модель теряет детали. В тестах на поиск 8 фактов GPT-5.1 падает с 65% до 30% при заполнении до 100k токенов. Даже более мощная GPT-5.2 проседает с 95% до 70%.
То есть проблема не только в лимите, но и в качестве работы модели при забитом контексте.
Решение для проблемы №1: Dynamic MCP
Docker Dynamic MCP — подключаем серверы не заранее, а динамически, во время разговора.
Например, вместо 40+ инструментов GitHub в контексте постоянно — лёгкий шлюз с базовыми командами:
mcp-find— найти сервер в каталогеmcp-add— подключить к текущей сессииmcp-exec— выполнить инструментmcp-remove— отключить сервер
Базовая нагрузка: ~4k токенов вместо 40-70k. Серверы подключаются по требованию и удаляются, когда больше не нужны. Работает с каталогом Docker MCP, где уже 300+ верифицированных серверов.
Нужно установить Desktop Client и в настройках Beta Features включить Enable Docker MCP Toolkit
Решение проблемы №2: запускать MCP сервера в SubAgents
SubAgents из Claude Code выполняют запрос в изолированном контексте, возвращая только результат.
Вся грязная работа — поиск серверов, подключение, вызовы инструментов, парсинг JSON-ответов — происходит в отдельном контексте подагента. В основной контекст попадает только чистый финальный ответ.
Claude Code (основной контекст)
│
▼ Запрос
┌─────────────┐
│ SubAgent │ ← вся работа с MCP
└─────────────┘
│
▼ Только результат
Claude Code (чистый контекст)Итог: ~70k токенов экономии = 35% контекста свободно для реальной работы
Для полного описания всего этого нужна большая статья, так как без картинок и примеров суть идеи может быть непонятна
В фильме «Дьявол носит Prada» есть несколько конфликтов, которые можно разобрать с помощью «Тучи» (Теории ограничений).
Пример «Тучи» для главной героини — Энди Сакс
1. Цель (Общая миссия) - «Стать успешной в карьере и сохранить личную жизнь»
2. Требование А - «Работать на Миранду Пристли (строить карьеру в модной индустрии)»
3. Требование Б- «Поддерживать отношения с близкими (парнем, друзьями, семьёй)»
4. Конфликт - Если Энди полностью посвятит себя работе → потеряет личные отношения.
Если Энди будет уделять время личной жизни → не справится с требованиями Миранды и упустит карьерные возможности.
5. Скрытые убеждения (предположения)
«Успех в карьере требует полного отказа от личной жизни».
«Работа в глянцевом журнале — это только тяжелая эксплуатация, а не путь к успеху».
«Если я не буду соответствовать ожиданиям Миранды, я провалюсь».
В фильме Энди сначала жертвует личной жизнью, но потом осознаёт, что карьера в таком формате её не устраивает. Это классический пример неразрешённого конфликта, который привёл к эмоциональному кризису.
Если бы она использовала «Тучу», то могла бы найти решение, которое сохраняет и карьеру, и отношения.
В Теории ограничений (ТОС, Theory of Constraints — TOC), разработанной Элияху Голдраттом, есть инструмент для решения конфликтов - Туча - диаграмма конфликта, которая помогает выявить скрытые предположения (почему мы считаем, что конфликт неизбежен?) и найти объединяющее решение. Структура "Тучи
Она состоит из 5 элементов, связанных логическими стрелками:
1. Цель (Общая миссия) – чего хочет достичь система (компания, человек).
2. Желание 1 (Требование А) – один из способов достичь цели.
3. Желание 2 (Требование Б) – другой способ достичь цели, который противоречит первому.
4. Конфликт (Проблема) – почему эти два желания не могут быть выполнены одновременно.
Таким образом конфликт визуализируется и начинается поиск решения, которое удовлетворяет оба желания.Туча помогает не просто увидеть конфликт, но и найти корень проблемы и прийти к прорывному решению (когда оба желания удовлетворены), а не к компромиссу (когда по сути не удовлетворяется ни одно).
Такие решения возможны, если:
Отказаться от «или-или» мышления.
Искать интересы всех сторон
Использовать дополнительные ресурсы (которые есть всегда).
5. Предположения (Скрытые убеждения) – глубинные причины конфликта, которые мешают найти решение.
Суть Теории ограничений — ломать ложные дилеммы!
Год перемен: как мы переходим на “Клиентократию”
Уходящий год - время больших перемен. Команды моих проектов переходят на модель управления “Клиентократия”. В прошлом году часть сотрудников обучалась этому подходу и весь текущий год мы посвятили тому, чтобы осуществить переход.
К чему мы пришли к декабрю?
На самом деле, у нас большие перемены. Во-первых, мы полностью разделили проекты - теперь команда “Можем” существует отдельно (платформа по оказанию бытовых услуг, куда входят проекты “НянЯрядом”, “Гульдог”, “Мурчалкин”), отдельно - экосистема для работы и обучения “StudentTerra” (куда, в частности, входит и стартап-студия, как команда для быстрого тестирования новых бизнес-идей).
Проекты разделены на команды в соответствии с принципами “Клиентократии”. Для части команд - команды продукта, команды маркетинга, мобильного приложения, развития - уже создана новая система мотивации, которая позволяет каждому ощущать свой вклад в развитие общего дела. Остальные команды будут замотивированы уже в декабре-январе.
Параллельно идет работа по созданию полностью прозрачной экономики и четких метрик качества в каждой команде. Все метрики выводятся на понятные и информативные дашборды.
Если говорить в целом, то за этот год мы внедрили “Клиентократию” примерно на 70%, а значит - осталось немного! Какие-то подразделения уже “живут” по новым принципам, какие-то - начнут уже в январе нового года. Главное, чего мы ждем - полной прозрачности процессов, лучшей мотивации ребят, и максимальную полезность для пользователей наших сервисов!
Слабые сигналы — это ранние, едва заметные признаки будущих изменений, кризисов или новых возможностей. В бизнесе их часто игнорируют из-за неочевидности, но именно они позволяют предупредить угрозы и опередить тренды .
Почему это важно
В бизнес-среде слабые сигналы играют критическую роль. Они помогают предотвращать кризисы: например, рост мелких жалоб клиентов может сигнализировать о будущем массовом оттоке, а уход ключевых сотрудников — о кадровом коллапсе. Одновременно эти сигналы открывают новые возможности— когда нецелевое использование продукта указывает на перспективный рынок, а эксперименты конкурентов становятся индикатором тренда.
Как работать с сигналами?
Мониторить периферию : соцсети, отзывы, данные сотрудников
Анализировать аномалии даже минимальные отклонения
Создавать чувствительные каналы : быстрый сбор информации
Парадокс : самые слабые сигналы часто несут либо самые серьезные риски , либо самые выгодные возможности.
Геймификация программ лояльности: самые популярные и эффективные механики
Задача любой цифровой программы лояльности — сформировать у человека привычку регулярно пользоваться сервисом. Сделать это можно в том числе с помощью геймификации. Чтобы разобраться, какие игровые механики работают наилучшим образом, наша команда изучила десятки приложений международных брендов. Оказалось, что в рецепте хорошей геймификации почти всегда есть два компонента — один или оба:
Петля вознаграждения. Действие ведет к поощрению и одновременно является следующим шагом к более масштабной цели. Чтобы эта концепция работала, важны ежедневные микрозадачи с быстрой обратной связью. Это дает игроку ощущения прогресса, а дополнительные стимулы — от игровых очков до адаптированных целей, помогают держать пользователя в непрерывном потоке.
Механика коллекционирования. Людям нравится собирать сущности, предметы или точки на карте. Особенно, если это органично вписано в общую сценарную канву. Сеттинг, миссии и обаятельные персонажи в этом контексте особенно важны. Они наполняют смыслом наши действия: мы не просто собираем камни в лесу — мы строим высокую башню, в котором укроем принцессу от дракона.
Также на вовлеченность пользователей влияют и другие инструменты:
активное сообщество и другие социальные механики: обсуждения, обмен знаниями, обмен игровыми артефактами и в целом возможность делиться успехами;
многоуровневые системы баннеров и пушей: они напоминают пользователю о поставленных целях и игровых задачах, а также об успехах и поражениях других участников.
Отдельно можно выделить интеграции с нативными приложениями трекинга. Если игровая динамика программы предполагает реальную физическую активность, то взаимодействие с Google Fit, Apple Health и аналогами позволяет встроить игру в реальность и завязать ее на различных устройствах вроде фитнес-браслетов.
В продуктовой команде скорость разработки напрямую зависит от того, насколько ясно сформулированы задачи, понятны цели и заранее учтены возможные риски. Здесь важна роль продуктового аналитика — человека, который помогает команде двигаться быстрее за счет точной постановки, глубокого анализа потребностей клиентов и выбора оптимальных решений.
Ира, продуктовый аналитик в группе AI-решений, рассказывает, как она организует эту работу на практике: от подготовки задач и взаимодействия с разработкой до поиска решений.
В команде я удерживаю фокус на цели и беру ответственность за задачи: разбираюсь в сложных ситуациях, помогаю выстраивать прозрачную коммуникацию и принимаю оперативные решения. Это снижает расфокус и делает процесс предсказуемым — команда понимает, куда движется и зачем.
Что я собираю перед тем, как задача уходит в разработку
Перед постановкой я собираю всю необходимую информацию: формулирую бизнес‑цель задачи, уточняю детали изменений, описываю контекст, среду разработки и тестирования, а главное — фиксирую ожидаемый результат и сроки.
Когда разработчик видит не просто, что надо сделать, а какую пользу это принесет, он быстрее принимает решения и точнее реализует задачу без повторных уточнений.
Как определяются приоритеты
В нашей команде мы обычно смотрим на потребность клиентов. Если видим, что функционал действительно отвечает на их запрос, — такие решения идут в реализацию первыми.
Этот подход помогает не отвлекаться на второстепенные задачи и концентрировать усилия на том, что действительно важно для клиента.
Какие артефакты ускоряют реализацию
Я подробно описываю, какие части продукта изменятся, как это повлияет на текущие сценарии, и указываю стенд, где уже настроена необходимая среда.
Если задача объемная, мы созваниваемся командой — при такой коммуникации часто выстраивается решение, которое проще и технологичнее первоначального.
Недавно была задача, которую мы уже обсуждали и даже накидали примерный вариант решения.
Однако при более детальном изучении оказалось, что проблема связана всего лишь с багом — его исправление полностью решило вопрос без дополнительных доработок.
Такие моменты — важная часть моей работы: иногда потребность можно закрыть без разработки, и задача превращается в быстрый фикс вместо большой доработки.
Что помогает выстраивать эффективную работу с разработкой
В команде у нас есть единый шаблон заведения задачи — он помогает не забыть важные детали.
А еще мы регулярно проводим мозговые штурмы и обсуждаем логику функционала до реализации. Часто для объяснения рисуем схемы: они помогают быстрее находить общую логику.
Как я сокращаю количество уточнений и переделок
Перед отправкой в разработку обязательно перечитываю постановку: это почти всегда помогает выявить мелкие недочеты.
В более технических задачах аналитик может не знать всех нюансов, и тогда лучше заранее встретиться с разработчиком. Вопросы по мере реализации — это нормально, особенно если появляются новые вводные. Сложнее противостоять меняющимся требованиям.
Инструменты, которые помогают работать быстрее
Мне помогает держать работу под контролем простой список дел — он позволяет ничего не упустить, когда задач много. Еще важны регулярные синки с командой, где можно услышать последние новости, обсудить проблемы и при необходимости помочь команде.
Сложные и объемные разработки фиксируем в Confluence — это наш ориентир, который помогает видеть всю работу по этапам и не терять контекст по крупным задачам.
У команды разработки, конечно, есть и Канбан‑доска, а недавно мы добавили дополнительную доску в разрезе целей, чтобы удобнее отслеживать прогресс и понимать, насколько приближаемся к ключевым результатам.
В будущем планируем сделать ориентир на роадмап.
Ближайшие события
Как мы собрали 500 человек на демо продукта
Привет! Это Владимир Князев, Agile-коуч трайба HR Tech в ОТП, и сегодня я расскажу о том, как мы организовали самое большое демо внутри компании и собрали на него 500 человек — максимум, возможный в Zoom.
Это было демо по продукту OTP Space — единому пространству HR-сервиса, в котором каждый сотрудник может оформить отпуск, поставить цели и посмотреть структуру компании. Поэтому нам важно было рассказать о нём на всю компанию. В этом посте я поделюсь, с помощью каких инструментов мы привлекли 500 человек и как удержали внимание. В прошлой статье я рассказал о приоритизации ICE и как её применять.
Не рассылкой единой
Нашей целью было привлечь как можно больше участников. Поэтому мы обратились к коллегам из внутренней коммуникации и предложили сделать большую рассылку. Договориться удалось не сразу: нужно было доказать, что это будет полезная рассылка, а не очередное приглашение на внутреннюю встречу. Нам помогло то, что до нас в ОТП уже запускали похожие кампании — например, с приглашением на митап по искусственному интеллекту. Мы использовали это как прецедент: «Раз они смогли — почему не сможем мы?».
Мы сделали рассылку на несколько подразделений, и она помогла собрать 300 участников. Тогда кто-то из команды предложил задействовать другой инструмент — наш чат-бот. Мы отправили через него приглашение с датой и временем проведения демо. Чат-бот помог привлечь ещё 200 слушателей — и мы достигли максимума, возможного в Zoom.
Нам удалось собрать столько участников с помощью разных методов коммуникации. Поэтому наш основной совет при организации больших демо — не ограничиваться стандартной рассылкой, а использовать нетипичные методы, идеи, которые могут появиться внутри команды.
Как удержали интерес сотрудников
Демо на сотни человек ≠ просто рассказ. Здесь нужна полноценная фасилитация, с которой самому спикеру не справиться.
Нашу встречу мы организовали так: я выполнял роль модератора, а продакт рассказывал о новых релизах. Пока он вёл презентацию, я удерживал внимание участников и управлял динамикой встречи: следил за таймингом и тишиной, отключал микрофоны, если нужно, читал вопросы в чате.
Самое сложное на таких встречах — не выйти за тайминг. У нас был всего час на демо продукта и ответы на вопросы. Поэтому мы сразу предупредили слушателей: ответим на вопросы в конце встречи в последние 15 минут. Перед тем, как передать вопросы спикеру, я структурировал их, объединял похожие, исключал неконструктивные. На короткие вопросы отвечали в чате, остальные озвучивали по порядку.
Что с обратной связью
ОТП Space — продукт масштабный, вопросов было много. После демо мы выгрузили весь чат, отсортировали вопросы, на которые не успели ответить, и постарались дать индивидуальный ответ каждому участнику. Это заняло время, но оно того стоило — обратная связь от сотрудников стала основой для следующих итераций в развитии продукта.
Кстати, многие комментарии были не в формате «вопрос», а в формате «здесь неудобно», «вот это переделайте» или «как классно сделали, давайте масштабируем этот функционал на другие подразделения». Мы посмотрели на живые боли наших пользователей, это очень ценно.
Советы для демо без лимитов
Вот что нужно учесть при подготовке демо на большую аудиторию:
- заранее продумываем инструменты для привлечения участников;
- приглашаем фасилитатора для модерации встречи;
- очерчиваем структуру демо в начале встречи: поясняем, о чём расскажем, на какие вопросы аудитории ответим сразу, а на какие — после демо;
- планируем демо как диалог с пользователями, чтобы собрать развёрнутую обратную связь у широкого круга сотрудников;
закладываем ресурс на обработку обратной связи.
Для следующего подобного демо мы ищем платформу с более высоким лимитом участников или вообще без него. Более гибкие настройки микрофонов минусом тоже не будут. В комментариях делитесь советами по организации демо продуктов.
Читайте, чем живёт IT в ОТП — в ТГ канале. А ещё я веду личный канал про Agile и изменения.
94 ГБ ОЗУ может утилизировать приложение Discord — реддитор поделился скриншотом этой ситуации. Он надеется, что фича с принудительной перезагрузкой приложения исправит ситуацию.
Ранее разработчики Discord для Windows «научили» мессенджер автоматически перезапускаться в фоновом режиме, если он использует более 4 ГБ ОЗУ. На Reddit создатели объяснили, что это часть текущего исследования и временная мера, призванная снизить нагрузку на память, с которой сталкиваются пользователи.
Раз уж вчера начали говорить про вайбкодинг (да как говорить, 40 комментов уже), то давайте своими пожеланиями для создания своего первого продукта поделюсь
Это часть 2, вот тут часть 1
Пункты ниже в основном подходят для первого продукта, который хочется создать и монетизировать
Создание продукта — это только начало
После релиза MVP начинается стадия шейпинга: сбор фидбека, итерации, баги, улучшение онбординга, поддержка, оплаты. Часто продукт после запуска и продукт через 3 месяца — это разные продукты.
Если думаешь "запущу и пойду делать следующий" — скорее всего, первый не взлетит без постоянных финансовых и временных затрат на его продвижение.
Статистически, первые значимые деньги начнут приходить через 4-5 месяцев
Много микро-проектов = масштабирование ошибок
Есть такой популярный совет — "Делай 1 проект в месяц, что-то выстрелит".
Но проблема в том, что если ты не понимаешь, почему первый не взлетел — второй провалится по той же причине. И третий. И десятый.
Этот совет еще может будет хорош для serial founders, которые уже прошли не один цикл и понимают паттерны. Для первого-второго проекта лучше сфокусироваться и вытащить максимум learnings из одного
Хорошая цель для первого продукта — не юникорн, а 300 платящих клиентов
Найди 300 человек на планете, которые платят $10/мес = $3k MRR. Это уже актив, который позволяет жить практически где угодно.
Для подобного продукта сейчас не обязательно искать инвесторов, собирать огромную команду или считать TAM SAM SOM, все можно сделать одному при достаточном усердии
Пивоты — это норма, а не провал
YouTube начинался как дейтинг-сервис. Instagram — как приложение с чек инами и фильтрами. WhatsApp — как статусы для контактов.
Первая идея почти никогда не та, что взлетит. Главное — быть в рынке и слушать, что говорят пользователи.
Продвижение также важно, как и продукт
Отличный продукт без дистрибуции умрёт. Средний продукт с хорошим продвижением будет вполне комфортно себя чувствовать.
И на продвижение точно придётся тратить не меньше времени, чем на создание и улучшение, поэтому ⤵️
Органика требует времени — поэтому о продвижении надо начинать думать тогда же, когда и о создании продукта
SEO, контент, комьюнити — это всё работает, но с задержкой в 3-6 месяцев.
Если начнёшь думать о продвижении после запуска — потеряешь полгода. Пиши, публикуй, собирай аудиторию параллельно с разработкой.
Очень хорошо заходит формат Building in Public, где вы делитесь успехами и сложностями на пути к первым клиентам.
И да, похвалите Gemini за инфографику. Он немного накосячил с визуальной последовательностью, но все равно красиво сделал
Раз уж вчера начали говорить про вайбкодинг (да как говорить, 40 комментов уже), то давайте своими пожеланиями для создания своего первого продукта поделюсь
Это часть 1, вот тут часть 2
Пункты ниже в основном подходят для первого продукта, который хочется создать и монетизировать
Первый продукт лучше строить на пересечении: "Интересно / Могу / Кто-то за это заплатит"
И именно в таком порядке.
Если вам не интересно, то все остальные пункты уже не так важны.
По поводу Могу / Не могу
Сейчас "не смочь" — уже не рабочая отмазка. Разработка была единственной ощутимой проблемой, из-за которой людям приходилось говорить "О нет, это не моё, я гуманитарий".
По поводу "Заплатит / Не заплатит"
А если никто за это не заплатит — ну и ладно, хотя бы разберётесь как создать хоть что-то рабочее в первый раз. С текущими технологиями цена ошибки — несколько потраченных вечеров, а не месяцы и тысячи долларов как раньше.
Легче всего для первого продукта решать проблему, которая есть и у тебя
Поиск абстрактных "проблем рынка" через Reddit или Keywords мало чего даст тому, кто не понимает основы Customer Development'a.
Если это не твоя проблема — тебе сложно будет понять боль клиентов.
Когда делаешь для себя — ты уже понимаешь задачу, лучше понимаешь, где искать таких же людей, и можешь отличить важное от лишнего ☕️
То, что получилось у конкурентов, не обязательно получится у тебя
"У них работает, значит и у меня сработает" — возможно, но нет.
Успех часто связан с набором случайностей. Попали в хайп, у CEO огромный социальный нетворк или связи, залетел виральный пост, влили много на рекламу.
Конечно, лучше смотреть на продукт конкурента, чем не смотреть вообще.
Но к наличию каждой функции в продукте конкурента лучше относиться скептически, потому что ⤵️
80% фичей конкурентов, скорее всего, не работают
Многие смотрят на конкурентов и думают: "Надо сделать всё это, чтобы быть конкурентным".
А по факту — большая часть их фичей не используется или не влияет на метрики. Они сами не знают, что работает. Или знают, но не скажут.
Не копируй весь набор. Найди 1-2 вещи, которые реально решают проблему, и сделай их лучше.
Допустим, мне часто нужно вытаскивать аудиодорожки из длинных видео. Видеоряд грузить в интернет, чтобы вытащить аудиодорожку — слишком долго. Мне предлагают скачать всякие сложные сервисы, где эта функция еще и будет под платной подпиской. Следовательно, за пару вечеров я бы мог создать себе сервис с одной функцией — извлечь аудио. И для меня это уже будет ценно. А если будет ценно для меня, то и другие такие найдутся
Отсутствие конкурентов — red flag
Кажется логичным: у моей идеи нет конкурентов = голубой океан = ваукакклас.
На практике — если нет конкурентов = либо рынка нет, либо ищешь не там, либо рынок только зарождается и придётся потратить миллионы на создание спроса.
Конкуренты — это всегда хорошо. Они доказали, что рынок существует. Твоя задача — сделать лучше для конкретной ниши.
И да, похвалите Gemini за инфографику. Он немного накосячил с визуальной последовательностью, но все равно красиво сделал
В обновлении Telegram появилась возможность создать на устройстве ключ доступа (passkey), который позволит мгновенно входить в мессенджер с помощью PIN или биометрических данных, в том числе Face ID и отпечатка пальцев. Криптографические ключи для входа будут храниться на устройстве и могут синхронизироваться с приложениями для управления паролями от iCloud, Google и других сервисов.
«Ключи доступа работают всегда и везде — и при перебоях с СМС, и в заграничных поездках, и даже в лифтах на парковках», — пояснили в Telegram, используя мем про другой мессенджер.
Проект Remove Windows Ai позволяет с помощью одного открытого скрипа удалить ИИ-мусор из Windows 11 за два клика: Copilot, Recall, ИИ в Пейнте, браузере, поиске Windows. В Powershell под администратором (если вы уверены на свой страх и риск, что это правильно и нужно вам): () & ([scriptblock]::Create((irm "https://raw.githubusercontent.com/zoicware/RemoveWindowsAI/main/RemoveWindowsAi.ps1"))).
Рынок IT в напряжении. ОПЯТЬ?
За последние 2 недели сразу несколько знакомых написали мне, что работа проектным менеджером или продуктовым менеджером, стало найти тяжелее чем обычно.
Обычно поиск для грейда выше джуна поиск занимал 1-3 месяца. Сейчас некоторые ищут уже по пол года, но до сих пор продолжают перебирать, а не сразу соглашаться.
На уровне повыше стало тоже хуже, но предложения всё равно периодически прилетают по разным контактам, даже если не в активном поиске.
А за последние 2 года я прошел десяток интервью в топовые компании: Яндекс, Т-банк, Авито, Сбертехнологии и несколько менее именитых. Почти во всех этих компаниях один из этапов это хардскилл грейдирование на продакт-менеджера. Когда тебе нужно порешать определенные продуктовые кейсы.
Я собрал интересные кейсы и обернул их в тест.
Пройти тут https://t.me/topproductmanager_bot?start=testversion=producttest
PS условий лучше чем в Skyeng пока никто так и не предложил