В новом выпуске AviTalk Виталий Черемисинов, сооснователь EXPF Sigma рассказывает про то, как запустить стартап, выйти на внешний рынок и объединиться с Авито, одной из крупнейших IT-компаний в стране, превратив свою экспертизу в одну из сильнейших команд и продуктов на рынке.

А также про важность экспериментов и тестов для бизнеса, скорость проверки гипотез, стартапы, бизнес и прочее интересное и важное.

Всем, кто держит руку на пульсе рынка аналитики и IT-продуктов рекомендуется к просмотру.

Читать полностью…

Издание SF Standard опубликовало интервью с анонимным сотрудником Меты перед завтрашними сокращениями 8,000 человек.

Внутри компании прямо сейчас:

– Тревога от неизвестности, кто следующий на очереди, просто невыносимы.

– Внутренние рейтинги ранжируют сотрудников по количеству потраченных токенов ИИ и по количеству минут, проведенных в чат-боте. Сотрудники открыто признаются, что задают боту бессмысленные вопросы, чтобы улучшить свои показатели, потому что попадание в конец рейтинга является фактором риска и сигналом к увольнению. В тоже время, HR сообщают, что использование ИИ не будет учитываться при увольнениях.

– Заметки ИИ автоматически включены на каждом видеосовещании. Сотрудники отключают их вручную, чтобы откровенно говорить о том, кто может быть следующим в очереди.

– Как узнать об увольнении: электронное письмо в 7 утра на ваш личный почтовый ящик. К тому времени, как вы его прочитаете, ваши рабочие учетные записи уже будут удалены.

Один инженер Meta даже написал скрипт, который анализирует внутренние профили, чтобы определить, чей статус изменился на «деактивирован». Этот сотрудник использует его личную электронную таблицу для отслеживания уволенных коллег.

– ИИ предложил командам, успешно создавшим собственную замену ИИ, получить компенсацию за 5 лет работы, а затем быть уволенными в качестве награды за самозамену. Это предложение получило много одобрительных голосов.

Совсем другая история — что делают с теми, кто еще работает. За ними следят. Их ранжируют по использованию ИИ. Их просят обучить своих преемников. Им говорят смириться.

Слова сотрудника: «Даже если мы еще не потеряли работу из-за ИИ, нас уже превращают в товар».

Обращение Цукерберга ко всем сотрудникам, перефразированное:

ИИ развивается быстро, никто не знает, что нас ждет, руководство делает все возможное

Общее число рабочих мест, которые будут либо отменены, либо сокращены в 2026 году, составит 22,000 человек.

Читать полностью…

Получи грант до 75% на ИТ-магистратуру в области продуктового менеджмента от Центрального университета

В программе обучения: продуктовый дизайн, управление разработкой продукта, метрики, стратегический менеджмент, лидерство и другие дисциплины, необходимые для успешной работы в роли продакт-менеджера.

Программа включает в себя решение реальных задач от Сбера, Ozon, Avito, Х5 Tech, Lamoda, Т-Банка и других крупных ИТ-компаний. Преподаватели — эксперты отрасли, которые соединяют системный подход к знаниям и реальные бизнес-практики.

Занятия по вечерам и в выходные. Грант в магистратуре фиксируется при зачислении и остается неизменным на весь срок обучения.

Как получить грант?

1) Зарегистрируйся на сайте (вшить ссылку) и заполни заявку в личном кабинете.
2) Реши онлайн-контест.
3) Пройди собеседование с командой программы.

👉 Подай заявку до 7 июня и получи шанс на обучение в одной из лучших ИТ-магистратур страны.

Читать полностью…

Gamestop покупает eBay – главная новость этого года столетия тысячелетия на рынке

В пятницу вышло увлекательное интервью CEO GameStop Райна Коэна, в котором он рассказывает о том, как компания с капитализацией $10 млрд может поглотить компанию в пять раз больше её, о синергии онлайна с офлайном и пользовательским опытом, ценности обратной связи, эффективной работе бизнеса и команды, и, конечно же, об особенностях корпоративного управления в США.

Trump: “You better go out and buy stock now. This will be like a rocket ship that goes straight up.”

endofdaysprophet: By stocks before the Sun burns out!!! HAHAHA

🦧🚀🌝

Читать полностью…

Апрельский дайджест продактов уже готов к прочтению на майских. Подарок улиц (?).

– Subscription Value Loop
– Лонгитюдное исследование
– RACI, DACI, PIG
– DIBB

– Правило левой руки продакта
– Сегменты — Истина
– Вайб-кодинг продакт-менеджером
– Пишет ИИ, расхлёбывает продакт

– Анализ организации команды
– Анализ окупаемости команды
– Как изменится работа команд
– Как менеджеры показывают власть

– Внедрить нельзя отсеять
– Залипание на слове «уникальный»
– Почему мы делаем разные выводы
– Когда стал директором продуктОВ
– Start Leveling Up Your Team

– Неравнодушие как навык
– Экономия на крупном
– Как слышать других
– Высокоамплитудная несговорчивость
– Как понять, кто бесит на работе
– Компромисс и сотрудничество
– Новая структура компании

– Дизайн есть продолжение мира
– 20 промтов для UX/UI дизайнера
– Дизайн Госуслуг за/на 100 млн
– Durable Patterns in AI Product Design
– 3 слоя интерфейса будущего ИИ

– Гайд по GEO, AIO, AEO
– Seeing like a spreadsheet
– Стресс ≠(=) выгорание
– ИИ-слоп → шок → блок

– Даркнет мозга
– Работать с мозгом, а не против
– «Установки по умолчанию»
– AI вредит способности учиться
– Как быстро спрашиваешь ИИ

– Два пути, Семь Врат
– Reading is magic
– Just Art It
– Выходной — когда нет планов

🗣️ OCCULT by Macroblank

Читать полностью…

Вы либо становитесь острее с помощью ИИ, либо тупеете. И большинство людей тупеют.

Люди на планете всё быстрее разделяются на две категории:

1) Первая использует ИИ, чтобы делать ту же самую работу легче, и тратит сэкономленное время на "комфорт".

Но их результат работы остаётся тем же, а их личные способности разрушаются. И их положение ухудшается с каждым месяцем. И с каждым месяцем они всё сильнее убеждают себя чувствовать свою продуктивность, значимость и незаменямость, но, по факту, становясь всё более и более... заменяемыми ИИ.

Вопросы, от которых неудобно:

– Как быстро ты спрашиваешь ИИ перед тем, как сначала всё обдумать самому?

– Сколько времени ты тратишь на то, чтобы подумать над тем, КАКОЙ вопрос всё же задать ИИ?

– Сколько времени ты потратил на то, чтобы правильно и вдумчиво сформулировать КАК задать вопрос для ИИ?

И после этого всего ты так и не нашел ответ на свой вопрос без ИИ?

Тогда ответь на главный вопрос:

– А какая часть "твоей" работы, которую ты по привычке называешь своей, действительно твоя, а сколько из неё рухнет в момент, когда тебя заменит ИИ?

Большинство людей не задаются этими вопросами, потому что ответы неприятны. Но именно эта неприятность всегда является лучшим сигналом, который нужно уметь чувствовать и слышать.

А оглупение с ИИ не уникально, это лишь новый очередной паттерн поведения и когнитивных ошибок мозга человека: полагаешься на родителей/человека/одну работу/ИИ дольше, чем следует, и вот ты уже зависим, ломок и слаб и вырваться из этого круга всё сложнее. Не завись от зависимости, йо.

Слышал недавно, что обанкротившиеся компании продают переписки своих бывших сотрудников для обучения корпоративных моделей ИИ.

Круг замкнулся. ИИ – это(т) круг.

2) Вторая категория людей использует ИИ, чтобы пытаться делать то, что казалось для них невозможным раньше, и реинвестируют сэкономленное познание (как вам новый термин эпохи ИИ) в более широкое мышление, глубокое видение и масштабные результаты.

Их личные способности усиливаются, а результаты растут. И их становится всё труднее заменить с каждым годом, потому что они делают то, что предыдущее поколение вообще не могло сделать (правильнее сказать – "ещё не может" (совсем правильно, чтобы не расслабляться – "будущее поколение ещё не сделало")).

Как (не) общаться с ИИ:

– Закрой глаза. Дыши. Почувствуй То-Что-Скрыто за любым твоим вопросом. Спроси себя о том, а для чего ты Это ищешь.

– Ответ всегда рождается внутри, а не снаружи.

– Переверни поток общения с ИИ и объясняй ей Это как себе. Так ты найдёшь ответ на Это сам.

TLDR: Включай мозги и Видение сначала, и только после запускайте чат. Думай Чувствуй сначала, промпть потом.

Читать полностью…

Если вы выбираете таск-менеджер для команды и хотите считать разработку по метрикам поставки, то посмотрите в сторону Яндекс Трекера.

Из удобного в функционале есть мониторинг пропускной способности производительности команды (через измерение числа закрытых story points за спринт) и отслеживание эффективности потока (Throughput) команды, благодаря которому можно наглядно видеть, сколько закрывалось задач каждую неделю и сколько времени тратится на полезную работу.

Для измерения пропускной способности можно использовать виджет "График событий".

Как это работает:

1 – В качестве ключевого параметра задаётся дата завершения, в источнике задач задаются нужные типы задач: Задачи, Исследования и Ошибки (эпики не нужны) и выбирать статус "Закрыт" (для исключения задач в статусе "Отмена").

2 - При необходимости в "Источнике задач" можно отфильтровать задачи по каждому продукту/направлению. Группировку лучше делать по размеру спринта, например неделя или две.

3 - Чтобы строить такой график нужно заполнять "Дату завершения" во всех закрытых задачах, для чего в рабочем процессе во всех переходах в статус "Закрыт" нужно настроить заполнение даты завершения (и можно сразу настроить проставление резолюции).

Все эти и другие метрики можно легко найти, настроить и мониторить с помощью дашбордов в Яндекс Трекер.

Специальных знаний для настройки не требуется, а ответы можно найти в документации и в их группе поддержки в Telegram.

Читать полностью…

3 слоя интерфейса будущего ИИ

Layer 1. Отслеживание намерения пользователя

Сообщения, голос, местоположение, оповещения, календарь, привычки, биометрия и прочий контекст помимо базового ввода данных, благодаря которому Система понимает (и сразу на дальнейшее будущее предугадывает), что вы пытаетесь сделать, прежде чем вы явно начнёте что-либо делать или существенно измените паттерны своего привычного намерения поведения и Система "почувствует" это.

Layer 2. Область намерений активности ИИ

Вся фактическая работа Системы происходит через ИИ-агентов, управляющих ПО, API, файлами, почтой, календарями, процессами, транзакциями, биометрией и прочим контекстом и другими микро-сервисами, а большая часть использования пользователем компьютера превращается в наблюдение за монотонной работой машин.

Layer 3. Временные состояния UI/UX

Нам по-прежнему нужно проверять, сравнивать, редактировать, выбирать, утверждать, отклонять и получать результат сделанного нами ранее выбора ИИ.

Именно здесь сохраняется привычный графический интерфейс для пользователя, но работающий уже в виде неких одноразовых, специфичных для конкретной задачи поверхностей и суб-слоёв, создаваемых в каждый конкретный момент времени пользовательской задачи-ситуации.

Читать полностью…

Мы лишь придумываем проблемы,
Чтобы потом успешно их решать.
Весь рынок мир определён иным.
Пользователь – твой продукт.
Команда – продакт, а не ты.
Твой ум мешает росту.

Чувствуй, наблюдая.
Наблюдая, чувствуй.

Строй так мосты.
Влияй

Читать полностью…

Интересная новость: Авито Тех начали предлагать свою платформу для экспериментов Trisigma в формате VPC.

В рамках VPC-модели платформа разворачивается в изолированной инфраструктуре, что позволяет проводить эксперименты без передачи данных на сторону, а управление архитектурой и доступами полностью остается внутри компании. К тому же, новый формат поможет соблюдать жёсткие регламенты безопасности и легче проходить проверки.

В дальнейшем Авито Тех планирует выпустить полноценную версию для установки на собственные сервера клиента, что позволит закрыть потребности банков и госсектора, где требования к локализации данных максимально строгие.

Trisigma — платформа для автоматизации A/B-тестирования и комплексной аналитики продуктовых гипотез, разработанная командой Авито Тех.

Внутри компании на ней запускают более 7000 тестов, чтобы развивать ключевые сервисы и функции. Система справляется с огромными нагрузками, обрабатывая свыше 18 млрд событий каждые сутки.

Читать полностью…

Все проблемы в продукте растут из пространства неопределённости в принятии решений.

Попав в один из четырёх классических управленческих типов ошибок, проблема разрастается и постепенно оказывается во всем пространстве.

– Неясная цель. «Какую проблему-ситуацию мы решаем?»

– Неясные ограничения. «Есть ли у неё нас ограничения на ____?»

– Неясные компромиссы. «Что важнее, ____ или ____?»

– Неясный владелец. «Кто принимает финальное решение?»

Иными словами: 1) Зачем? (цель) 2) В каких условиях? (ограничения) 3) Что важнее при конфликте? (компромиссы) 4) Кто? (владелец).

После того, как вы определили, с чем была заминка, выполните рекурсию и если идея/фича/продукт/система отвечает на все четыре вопроса, то решение можно принимать. Если нет, то любое решение будет временным, а проблема 100% вернётся, но уже в другом обличье.

Читать полностью…

Среднее значенье — ложь. Сегменты — Истина

Причина 98% проблем в продукте – ты ничего не сегментировал

На какую бы идею/фичу/идею и под каким углом ты не смотрел, как бы обнадёживающе и радужно это всё не выглядело, причина того, что всё проваливается, почти всегда в том, что ты нашёл и смотришь на усредненную размытую идею/показатель/фичу, за которой скрываются два, три или даже четыре совершенно разных сценария/истории/JTBD/сегмента пользователей.

И плоская кривая их последующих метрик (приток, удержание, выручка, что угодно) часто скрывает ситуации, когда один сегмент стремительно уходит (отток), а другой агрессивно наращивает потребление, но именно за счёт этого, эти сегменты (которых ты не видишь) просто... взаимно нейтрализуют и выравнивают друг друга (и усредняют все метрики), вводя тебя в заблуждение и заставляя искать неведомые причины отсутствия роста.

Тоже самое с родмэпом. Если в нём за приоритет бьются сразу 3 сегмента пользователей, то у тебя 3 разных фичи (продукта?), 3 разных онбординга и 3 разных сценария, которые ты, из-за усреднения, спешно объединяешь и с гордостью называешь "единым решением". Нет, этотакнеработает.

Аналогичное вытекает в ценообразование и его продуктовое позиционирование. Пытаясь охватить сегменты с кардинально разными потребностями (и готовностью платить), твоя единая маркетинговая кампания + усредненная цена либо заставляет тебя недополучать и упускать прибыль в верхнем сегменте, либо закрывает продукт перед клиентами из нижнего.

– Даже если твой продукт пытается быть "всем для всех", его необходимо адаптировать под конкретные сегменты (проблем-пользователей-решений).

– Выбери Тот-Единственный-Сегмент, ради которого вы действительно создаёте продукт и отталкивайтесь от него соответствующим образом.

– Если высокоуровневые метрики выглядят криво или разнонаправленно, а интуиция, говорит, что что-то здесь не так, то разбей их по сегментам, которые определились выше.

Всякий раз, когда продуктовая задача кажется неразрешимой, раздели её на сегменты и взгляни на ситуацию заново.

Сегментируй ситуации и проблемы пользователей. Пользователи сегментируются сами. Далее, сами сегментируются идеи и решения. За ними подтянутся сегментированные посылы и цены.

Сегментируй. Всегда сегментируй.
Сегментирование работает всегда.

Читать полностью…

Новая структура любого отдела в компании

Всего 3 типа живых участников:

0. ИИ-агент

1. Архитектор

Те, кто разрабатывают операционные ИИ-процедуры, которые обучают и задают принципы ИИ-работы процессов в продукте и для команды.

Создают с нуля ИИ-процессы и обеспечивают работу инфраструктуры для ИИ, тестовые песочницы, системы интеграций, триажа (нет, не тиража) и доставки, определяя архитектуру и границы таких систем и задавая критерии качества того, как должен выглядеть нужный результат работы ИИ-агентов. Ключевой навык – критическому мышление и умение видеть слабые места в ИИ процессах.

2. Оператор

Все остальные участники, между которыми архитектор и ИИ распределяет задачи: расследование и верификация ошибок, доработка пользовательского интерфейса (UI), коммуникации с пользователями. Они требуют мастерства и внимательности.

3. General Manager

Тот-Кто-Отвечает-За-Продукт. Вкус, Видение, Свет.

Читать полностью…

Вайбкодинг продукта глазами продакта

Продолжаю кодить создавать некий-довольно-объемный по продуктовым и техническим меркам продукт с Claude, поделюсь наблюдениями:

– Не парь себе и ИИ мозги, не пиши на вайбе продукт с нуля, юзай опенсорс CMS с уже: а) продуманной; б) раздельной архитектурой.

Мой случай – Wordpress, в котором есть ядро и есть отдельно /plugins и /themes. Ядро постоянно, стабильно и ИИ его не трогает, вся работа по разработке продукта ведётся через плагины (бэк) и темы (фронт). Всё ограничено, порционно, версионно и контролируемо. Сэкономишь ИИ мозги и себе токены и не будешь тратить 80% времени/нервов/токенов на ненужную проверку и переписывание одного и того же места (ядра) ради мелких фиксов по сто раз.

– Смотри в сторону Single Page Application с раздельными .js под каждую фичу/"страницу". Это снова про ограниченность, версионность и контроль работы для тебя и ИИ. Плюс, так снова правильно для архитектуры, когда приложения общаются между собой раздельно, а не один .js управляет всем и сразу (создавая конфликты и глюки сразу во всём).

– 1 фича-апдейт = 1 чат в рамках 1 проекта и не будет никаких галлюцинаций. Апгрейдишь фичу – в первом промпте прикладывай архив с исходником последней stable версии фичи с прода (или коннекть GitHub). Апгрейднул – CHANGELOG - чат закончен.

Иначе уже спустя 2 часа чата машина начинает путаться в данных/коде и любая попытка разрулить лишь закапывает её и тебя в галлюцинации и баги ещё больше.

– Фиксы/баги можно объединять в одном чате, ИИ лучше видит контекст и находит связи между ними, но лучше тоже не копить и делить по stable версиям.

– Объясняй всё для ИИ наглядным языком, уточняй контекст, расшифровывай механики, стейты и позиционирование объектов на странице c их идентификацией.

Помогает: а) единый словарь терминов и понятий для фич/механик в твоём продукте (определимся с терминами и понятиями, классика, 2018 год); б) через Console смотреть на название их css-стилей. Потому что даже одна оговорка или размытое понятие может быть непонятно для ИИ и она начнёт додумывать его за тебя, что приведет её к галлюцинации.

Твой промпт = тех. задание, "нет ТЗ = результат ХЗ", ещё одна классика середины нулевых передаёт привет из прошлого.

– Прикладывай к промптам скрины с выделенными ошибками, поясняя текстом что на скринах. Несколько раз Claude сама нашла на скрине места с дублирующейся багой, которые я проглядел, поняла их и это помогло ей пофиксить 2+ баги разом.

– Не торопи ИИ с кодом и не давай ей с ним торопиться, всегда проси подтверждений понимания твоих задач и уточнения со стороны ИИ и ты снова сэкономишь токены, нервы и время.

– Для сложных фич/механик вначале проси у ИИ описание двух вариантов возможных решений, потом проси третий вариант, потом проси придумать оптимальное и подходящее решение на основе этих трёх. У меня во всех случаях ИИ выбирала третий вариант и с первой итерации писала его без серьёзных ошибок, имея на руках полный контекст что ей делать и что не делать.

– CHANGELOG MD – ключ и мост между релизами. После каждого успешного апдейта (чата) проси ИИ писать: а) интро проекта с точки зрения обновлённого кода/архитектуры; б) выжимку по изменениям и включай их в него, прикладывая в новом чате и прося читать все изменения для понимания контекста.

Потому что ИЗМЕНЕНИЯ = КОНТЕКСТ. Веди его ручками, чтобы не жечь лишний раз каждым апдейтом токены на разрастающийся док (старую инфу можно нужно подчищать).

– Скиллы и прочие "ты в роли" зашей в CHANGELOG один раз, а не в системный промпт/скилс, чтобы не вызывать их скрыто в каждом промпте, прожигая твои токены (ты же не Ланнистер).

– Слышал, что рефакторить код лучше через разные модели, устраивать оркестрации, подключать тулзы и прочее. Я до этого ещё не дошел, Claude отлично справляется со всем своим добром сама прямо через окно чата и обмен файлами контекстом.

В общем, как-то так. Впервые столкнулся с тем, что код и прод убегают вперёд дизайна. Думаю скоро подрубить github, а там и до VS Code + copilot не за горами. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Читать полностью…

Конференции про лидерство смотрю уже не первый год, субботняя Dream → Teamlead на прошлой неделе не стала исключением. Больше всего зашли два доклада: про стресс и лидерство.

Из интересного:

Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure, объяснил, что тимлидер(ство) – это сначала про стек навыков по управлению собой, и только потом про управление командой. При этом нужно комбинировать в себе все виды лидерства в зависимости от КОН-ТЕ-КСТА. Контекст – король. Таким образом, научившись управлять собой, научишься тимлидству как профессии.

Еще была интересная мысль о том, что в стрессе типы (грани) тимлида обостряются и либо эволюционируют, либо регрессируют, поэтому стрессом нужно уметь управлять. И иначе, стресс начнёт управлять тобой, а потом и всей командой.

Всё втекает и вытекает из другого. И в этом вся сложность и простота одновременно ☯️

Поэтому, лидер, застрявший в одном стиле управления, скорее всего провалится (и утащит за собой команду). Стресс лишь приблизит неизбежное.

Полезный совет – рост тимлида часто происходит по фидбеку команды. Спросите коллег: а) что они в тебе как лидере видят; б) чего им в тебе не хватает.

Про ИИ тоже говорили: продуктивность с ИИ растёт быстрее качества, поэтому непродуманный ИИ в процессах не только не помогает, но и создаёт дополнительное узкое горлышко в виде растущего объёма верификации и ответственности выросшего благодаря ИИ количеству результата работы.

Читать полностью…

Мы вступаем уже вступили в системную фазу ИИ

На этой фазе результаты определяются тем, насколько эффективно ИИ интегрирован в:

а) контекст;
б) инструменты;
в) временные состояния;
г) циклы(!) обратной связи.

И этот небольшой набор примитивов усиливает сдвиг продуктов в сторону Систем.

– Использование инструментов позволяет ИИ предпринимать любые действия с любыми данными, что переводит ИИ из вспомогательного в замкнутый цикл, в котором единицей ценности является завершённый рабочий процесс (JTBD).

Динамический(!!!) контекст — это новый слой данных

Протоколы типа MCP, позволяют ИИ-(и)-Системам получать необходимый контекст во время выполнения действий пользователем, вместо того чтобы полагаться на кем-либо и какие-либо предварительно загруженные данные.

Сам контекст становится более: а) персонализированным; б) ситуативно-ориентированным; в) динамическим.

Это значит, что один и тот же контекст может использоваться в разное время, в разных моделях, в разных инструментах и для разных действий, в том числе, одновременно. И владение набором данных имеет меньшее значение, чем понимание текущих и возможных связей между данными

– ИИ маршрутизаторы определяют, какая ИИ (или последовательность ИИ) обрабатывает каждую задачу, исходя из сложности, задержки или стоимости и динамически распределяют вычислительные ресурсы в зависимости от: 1) момента; 2) контекста, изучая и находя в них закономерности.

– Телеметрия в Системе фиксирует и анализирует поведение всей Системы в целом: какие маршруты были выбраны, в каком контексте времени, какие действия были предприняты, какие результаты они дали и, что самое главное – как на это отреагировали пользователи.

Всё-Это снова замыкает цикл ☯️

На основе этих базовых принципов строятся определённые стратегии согласования. И вместо того, чтобы полагаться на статичные метки, проставленные людьми, современный ИИ теперь генерирует обучающие сигналы с помощью ИИ-судей, валидаторов и симуляторов, что снижает затраты на динамическую персонализацию и позволяет Системам напрямую ориентироваться на реальные показатели эффективности в зависимости от момента времени пользователя-продукта-задачи.

В своей совокупности, эти базовые элементы и стратегии приближают нас к созданию Систем, состоящих из более мелких и специализированных моделей, координация которых осуществляется через специальные уровни оркестрации ИИ (микро-ИИ-системы в макро-ИИ-Системе – у Вселенной прекрасное чувство юмора (как и Она-Сама)).

В долгосрочной перспективе, вся эта дифференциация будет смещаться в сторону ценообразования, ориентированного на создаваемую ценность, в которой покупатели будут платить за измеримые результаты работы ИИ: за решенный тикет в службе поддержки, урегулированную страховую претензию или подготовленный юридический документ.

В областях с высокой степенью неопределённости или финансовым влиянием, ИИ-оринетированные Системы могут напрямую принимать на себя риски, взимая процент от полученной экономии или выручки (привет, ИИ-кошелёк от Stipe).

По мере того как эти системы будут становиться всё более зрелыми, дифференциация будет перемещаться к созданию контекста, маршрутизации решений и выявлению ошибок.

Для создания надёжных конкурентных преимуществ необходима взаимосвязь между продуктовыми процессами в конкретной области и достигаемыми в ней ИИ-результатами.

И чем ближе Система к «Истине» (ground truth) конкретной предметной области, тем проще согласовать её поведение с создаваемой ею ценностью

Для продактов в эпоху ИИ это означает смещение своего видения и мышления в сторону ИИ как живой сущности в Системе продукта, которую можно подвергнуть аудиту, усовершенствовать и, в конечном счёте, доверить ИИ выполнение ответственных задач пользователя.

Читать полностью…

Как там в Сан-Франциско (c)

Атмосфера в Сан-Франциско сейчас кажется лихорадочной. Разрыв в уровне благосостояния здесь сейчас самый огромный из всех, что я когда-либо видел.

За последние 5 лет группа примерно из 10 тысяч человек — сотрудников компаний Anthropic, OpenAI, xAI, Nvidia, Meta (и других, чья судьба пока неясна), а также основателей стартапов, накопила капитал, достаточный для выхода на пенсию, значительно превышающий $20M (это примерная оценка).

Всем, кто находится за пределами этой группы, кажется, что они могут всю жизнь работать на хорошо оплачиваемой (но приносящей менее $500K в год) должности, и так и не достичь этого уровня благосостояния.

Что еще хуже, сейчас в самом разгаре волна массовых сокращений.

– Марк к завтра (среда, 20 мая) увольняет ещё 10% сотрудников

Многие инженеры-программисты ощущают, что их профессиональные навыки, как дело всей их жизни, больше никому не нужны, потому что благодаря ИИ их работа изменилась буквально в одночасье.

В результате:

1. Карьерная лестница теперь кажется «не тем зданием», по которому стоит карабкаться

Все пытаются перестроиться под новые карьерные «траектории»: стоит ли самому стать основателем стартапа? Не поздно ли сейчас устроиться в Anthropic или OpenAI? Стоит ли переходить в сферу ИИ? Акции какой компании в следующий раз вырастут в цене в 10 раз? Люди требуют роста зарплат и всё чаще меняют места работы.

2. Царит глубокое чувство неудовлетворенности самой работой (и её будущим)

Зачем вообще работать за «копейки»? Будет ли моя должность существовать хотя бы через несколько лет? Многие чувствуют себя беспомощными. Повсюду, особенно среди молодежи, слышны разговоры о формировании «постоянного низшего класса» — людей, обреченных на вечное отставание.

Трудно сосредоточиться на качественном выполнении своих обязанностей, когда в голове крутится мысль: «Эх, если бы я устроился в Anthropic пару лет назад, я бы уже мог выйти на пенсию!»

3. Менеджеры среднего и высшего звена чувствуют себя парализованными

У многих из них есть семьи, и им кажется, что у них уже нет ни энергии, ни нужных связей, чтобы просто взять и «основать свою компанию». Особых навыков работы с ИИ у них тоже, как правило, нет. Они видят очевидные тревожные знаки: во многих компаниях происходит «вымывание» среднего управленческого звена.

4. Богатые люди тоже не особо счастливы

Те, кто уже «добился успеха», тоже испытывают глубокое чувство утраты цели и смысла. Некоторые из них всего за несколько лет, без какого-либо плавного перехода, прошли путь от дохода менее 150 тысяч долларов до капитала свыше 50 миллионов.

Это переворачивает все жизненные планы с ног на голову. А для некоторых, как известно, «сравнение с другими — главный похититель радости». Для некоторых это побег в Нью-Йорк, чтобы «жить полной жизнью». Другие же создают компании «просто так», часто просто ради статуса, потому что никогда не представляли, что к 30 годам будут обеспечены.

Я понимаю, что многие читающие это насмехаются над «шампанскими проблемами» Кремниевой долины. Общество искажено в этом технологическом пузыре. То, что часто считается благополучным в любой другой части мира, здесь — это полная ерунда.

В отличие от многих других мест, в районе залива Сан-Франциско стаж работы, интеллект и трудолюбие всегда были лишь косвенно связаны с результатами.

По иронии судьбы, частым побочным эффектом этих мучений является запуск тех самых продуктов, которые обогащают всех, в надежде, что и вы сможете проложить себе путь к экономическому просветлению с помощью вайбкода.

– Что до "остальной" Америки – атмосфера вокруг отрасли ИИ немного напряженная, большинство людей триггерит ИИ от корпораций (особенно в сочетании с роботами), отторгая потребление ИИ-контента, а всех, кто работает в ИИ-отрасли с небольшой долей холода и подозрения называют AI guys (tech bro и crypto guy из прjшлого теперь звучат даже как-то тепло и дружелюбно).

Читать полностью…

Сначала нам нужно признать: средний PM — глубоко посредственный. И все мы сделали наше лучшее худшим (c) Tom Verrilli, Whatnot

Ключевые элементы философии продуктовой команды и стратегии Whatnot:

– Любой может строить, но не любой принимает решения, которые работают. Если PM не может принять решение на месте, не дожидаясь пяти уровней согласования — ему не место в этой команде.

– Никакого «разделения на слои», PM не стоит над командой, а работает внутри неё как равный. Если ты не участвуешь в создании кода, общении с клиентами, поддержке и решении реальных проблем — твоя ценность стремится к нулю.

Продукт рождается из тьмы непонятного. PM должен быть в гуще этой тьмы

– Проверка реальностью обязательна. Любая идея проверяется самой маленькой возможной аудиторией. Без этого шага она не идёт дальше. «Мы просто уверены» — это не аргумент. Исключений нет.

– PM отвечает за проблему, а не за соответствие техническому заданию. Ты не пишешь спецификацию для разработчика, а формулируешь, какую проблему решаешь для бизнеса и пользователя. Как именно её решать — уже совместная работа с инженерами и дизайнерами. Если ты просто «передаёшь требования», ты не нужен.

– Планы — это не документы, а инструменты синхронизации. Хороший PM пишет план не потому, что «так надо», а потому, что хочет убедиться, что он сам и все вокруг движутся к одному и тому же результату. Если план писать не нужно для ясности, то его не пишут.

– Ошибка — это данные, а не провал. Быстрое развёртывание, быстрое измерение и быстрое решение: оставлять, менять или сворачивать. Пока команда не запускает фичу реально, она не знает, работает она или нет.

Главный враг — «подготовительная активность», которая маскирует движение под прогресс

– Ты либо строишь, либо мешаешь строить. В Whatnot нет места PM, которые только координируют. Каждый PM должен быть в состоянии сам создавать что-то, будь то прототип, аналитический запрос, документация или даже код. Если ты умеешь только говорить, а не делать, то ты не пройдёшь.

– Думай о проблеме, проверяй реальностью, принимай решения на месте и всегда будь в гуще создания, а не над ним.

Читать полностью…

Практические советы по вайбкодингу глазами и словами продакта, часть 3 (часть 2 и 1)

1) Мысли UX/UI, переводя слова на код

От того, насколько правильно сформулировано и построено предложение в твоём промпте, будет зависеть то, насколько правильно будет спроектирована архитектура твоего продукта кодом

Перечитай, пока ты не прочувствуешь всю суть.

2) Сначала. Обсуждай. Архитектуру. Фичи, механики и кода (если сможешь)

Проси 3 варианта решения. Спрашивай плюсы и минусы. Проси перепроверку. Требуй апрув понимания. Архитектура кода дешевле, безопаснее и быстрее в 10 раз до своего написания, чем после.

3) Называй ИИ конкретный файл/компонент/стиль, а не "это/фичу/область/действие"

Слова – друзя продакта, но враги ИИ и точной архитектуры, потому что ИИ не понимает нужной сути слов (напомню, что они для неё вообще как вектора-картинки-токены и цифры) и начинает угадывать контекст, часто делая это неправильно.

В промптах удобно работает привязка мелких фич/механик к названию div class вокруг кнопки/области фичи, которые стоят за ней, благодаря чему ИИ видит фронт, понимает с чём он связан на бэке и синкает весь контекст.

ИИ понимает название фич только на большом и концептуальном уровне, например, если эта фича объёмная и связана с чем-то глобальным, например, анонимный режим публикации контента, которому ты дал явное название Ghost Mode и на которое можно ссылаться, разрабатывая другие фичи. Само собой, все глобальные фичи и их архитектурные особенности должны быть описаны в changes . MD, который скармливаешь ИИ в начале каждого чата.

4) Понимай разницу между "как это должно работать", "что для этого нужно сделать", "как это должно выглядеть"

Когда описываешь задачу, сначала давай контекст по:

а) поведению пользователя;
б) ответному поведению системы;
в) визуалам.

Если смешивать или менять порядок, ИИ начинает сама выбирать что ей фантазировать и в каком порядке...

5) Говори "удали" вместо "убери"

"Удали полностью кнопку и механику" – задача на удаление кода/фичи/механики. "Убери/скрой кнопку" – скрытие кнопки и оставление в коде мусора и механик, которые 100% вызовут конфликты в будущем.

6) Стало хуже – откати. Не пофиксилось – откати и перепиши с нуля

Сломали что-то – сразу сообщай ИИ об этом, иначе если "пофиксим позже" (classic), то уже через час она потеряет контекст и чем дальше уйдёт чат, тем сложнее будет найти в нём то, что предшествовало баге.

Когда описываешь баг, говори в том же порядке:

а) что ты делаешь как пользователь;
б) что происходит на экране,
в) что там в консоли/Sentry.

Поздравляю, теперь ты QA-инженер!

7) Повторяющиеся, симметричные, фрактальные и единообразные числа (и объекты!!!) можно нужно оборачивать в систему единых токенов/объектов/фракталов.

Просто потому, что ИИ любит подстраховываться и ей легче создать новую сущность/класс и наплодить кучу всего (не)связанного, чем найти мэтч с уже имеющимися и объединить их в единую систему.

8) Не тащи всё в один чат

Длинный чат с ИИ теряет контекст с обоих концов. В конце большой сессии (опытным путём выявлено, что это примерно 2-3 больших фичи) проси сгенерировать саммари для нового чата с обновлённой архитектурой, правилами и файловой структурой.

Просто потому что свежий чат с хорошим вводным промптом работает точнее и быстрее, чем перегруженный контекстом старый.

Читать полностью…

Авито приглашает послушать, как ИИ троллил техногигантов 🔥

Поговорят на такие темы, которые обычно не обсуждают на публике, а именно как ошибается ИИ во время обучения и как это может неожиданно повлиять на продукт:

🔴 Как переобучение модели для борьбы с нежелательным контентом неожиданно затронуло неправильные категории.

🔴 Как эволюционировала функция размытия на изображениях.

🔴 Что случилось, когда при запуске новой модели «исчез» ценный список контактов.

🔴 Как ИИ начал спокойно рассказывать пользователю о грамматике мата.

🔴 Почему противодействие недобросовестным пользователям — это работа с неопределённостью, серыми зонами и очень дорогими ошибками.

Если вы DS- или ML-продакт, приходите на встречу, чтобы послушать яркие истории от специалистов из Авито и Яндекса, а после пообщаться и отдохнуть.

🗓 15 мая, 18:30, Москва, офис Авито на Лесной, 7
👉 Предварительно нужно зарегистрироваться

Трансляции и записи не будет, не упустите возможность услышать непубличные истории вживую.

Читать полностью…

Stripe выкатили в паблик свой кошелёк для ИИ-агентов Link

Теперь каждому ИИ-агенту можно создавать одноразовые карты, а на каждую покупку в интерфейсе ИИ будет прилетать запрос с кнопками Approve/Decline. Транзакции в аккаунте ведутся по каждому ИИ-агенту.

– Ещё одна маленькая недостающая деталь и я, наконец-то, полюблю финтех 🍃

Читать полностью…

Вайб-кодинг мозгами и руками продакт-менеджера, новая порция наблюдений и советов, Часть 2 (часть 1):

– Кто-бы мог подумать, но изначально правильно выбранный стэк технологий – залог стабильного ИИ/кода, времени, нервов и токенов.

Нет, я знал это ещё с древних времен, но не думал, что в 2026 ИИ столкнется с той же самой проблемой и vanilla.js (хаха) окажется всё той же самой ванилой по сравнению с тем же React. Теперь я понял всю глубину этого мэма разрабов. Ну не знал я про ванилу, не смейтесь! ))

Поэтому писать проект с нуля на React/другом фреймоворке вместо рефакторинга ИИндийского ванилакода – отличная идея! Ошибок меньше, а если и есть, то находятся и фиксятся в разы быстрее за счёт рамок фреймворка.

– Особенно помогает просить написать ИИ новое тех. задание с учётом всех ранее найденных механик багов, но не используя какой-то один язык программирования, а оставаясь на уровне юзкейсов и общей архитектуры и связей. Далее, это тз можно применять к разных фрейморкам и языкам не переживая, что ИИ затащит в новое какую-то специфичную реализацию из старого языка.

– Разделяй всё. Не только на уровне модулей, но и на уровне написания кода в разрезе механик UX/UI (хотя, возможно, это об одном и том же).

Условный тулбар с переключением разделов, уведомлениями и настройками это 3 разных направления кодинга, несмотря на то, что они в 1 визуальном блоке.

Ты можешь попросить сверстать, ок, но если просишь ИИ скодить бэк и синкать фронт под это сразу, то она тупит из-за обилия зависимостей и связей и начинает костылять и глючить, поэтому иди по шагам по каждой механике/разделу/фиче, тестируй и фикси всё поэтапно и поштучно, а не проси всё сверстать и скодить за один промпт, иначе потом закопаешь себя и ИИ в фиксах всего и сразу. Да и в один промпт-прогон всё равно не влезет.

– Аналогично это и про приоритизацию последовательности кодинга для ИИ.

Образно для понимания: неправильно сначала делать условные уведомления, а потом пилить сущности под них. Это не-ло-гич-но и непоследовательно. Сначала детальная проработка и кодинг верхнеуровневых объектов, сущностей, зависимостей/связей, и только потом окружение и обвесы под и вокруг них.

– Объединяй всё, что нужно/можно. Образно, если у тебя форма комментов и форма создания записи и их use flow един (почему нет?), то тебе нужен единый и один редактор-скрипт-вызов (хз как правильно сказать, яжнеразраб) текста внутри них. 2+ разных функции и вот у ИИ уже 2+ потенциальных места для багов/рассинхрона/конфликтов и провалов памяти.

– Вырезай всё, что неважно. Безжалостно и без мыслей "нууу, ИИ всё равно же, что кодить, пусть пишет". Ей-то всё равно и она напишет, вопрос лишь в качестве ИИ-кода и багов, влияющих на корфичи и количестве тех. долга по ним.

– Даже если ты попросил о чём-то ИИ, то эта дрянь всё равно рано или поздно забывает и начнёт торопится, выдавая тебе свои мысли и советы о том, как бы она всё это уже сделала и реализовала, забивая и размывая себе память и прожигая токены вариантами и догадками. У меня она, походу, чухнула мою профессию, и уже начала гипотезы выдвигать вместо уточнений. Серьёзно, так и пишет: "Гипотеза №1 в том, что это может быть...".

Тормози её! И допом к переспрашиванию её понимания баги/фикса/задачи, проси её написать по ней.... полноценный use case/story.

Так ты увидишь насколько правильно машина видит и понимает весь use flow процесса/продукта, твою задачу, что ограничит и сузит её гадания и, заодно, ты и сам в голове прокрутишь всё это ещё раз.

– Тоже самое про тебя – не ленись читать аннотации и размышления ИИ о том, что она там пилит для тебя. Всё довольно понятно и у тебя у самого в голове структурируется продукт, его сущности и механики. Не всё же на дизайн-системы медитировать.

– Кстати, с дизайн-системами под вайб-кодинг новый приятный трип в виде организации в Figma компонентов, variables, стэйтов и всего прочего, чтобы скормить это потом Claude Code. Новая форма релаксации мозгов. Каеф. Но они там уже Clade Design катнули под дизайн-системы, придётся скоро переучиваться, похоже.

– И, да – я перешёл на эту дрянь.

Читать полностью…

Есть идеи продуктов, которых еще нет на рынке?

Т-Банк ищет ML-продактов, которые работают с LLM/AI и управляют продуктом от гипотезы до продакшена.

Вы сможете:
— превращать бизнес-проблему в измеримую ML-задачу;
— запускать эксперименты с моделями;
— работать в связке с дата-сайентистами, ML-инженерами и разработчиками.

В Т-Банке ценят автономность и предлагают прозрачную систему развития. Работать можно в офисе разных городов России.

Успейте откликнуться!

Читать полностью…

Закрой глаза
Чувствуй как ты дышишь
Всё между дыханием
Воздух и пространство
Слов не существует
Мы знаем Всё
Мурашки – точки мыслей
Линии крови течений
Свет изнутри наружу
Вокруг. "Наоборот"
Всегда – не Время
"ты" – Это, Это – Ты
Будь Водой

Читать полностью…

«Установки по умолчанию» как незримая архитектура нашего мышления, образа действий и продуктов (с)

«Установки по умолчанию» устраняют трение, экономят энергию и позволяют нам двигаться быстро, не переосмысливая каждый шаг. Без них мы бы застряли из-за когнитивной перегрузки.

С ними же мы редко останавливаемся, чтобы спросить себя:

– А имеют ли они всё еще смысл?

И именно в этом заключается риск.

В 2009 году компания BlackBerry была самой быстрорастущей компанией в мире. Ее видение мира было целостным и последовательным. И когда на рынок вышел iPhone, в BlackBerry не поддались панике....

И этот сценарий повторяется гораздо чаще, чем мы готовы признать. Kodak создала первую цифровую камеру и плёнку. Сеть Blockbuster отказалась от сотрудничества с Netflix, поскольку ритуал пятничных вечеров и поход в видеопрокат казался им незыблемым.

Это были лидеры, действовавшие, опираясь на логику, глубокое понимание потребностей клиентов и дисциплинированное исполнение с «хорошим менеджментом» и моделями поведения, закрепляющими существующие «настройки по умолчанию».

Но когда меняются базовые допущения и парадигмы, эти действия лишь ускоряют упадок. Полезная когда-то «настройка по умолчанию», применяемая уже после истечения срока её актуальности, превращается в обузу.

Сейчас мы переживаем очередной этап перезагрузки

Последние пятнадцать лет доминирующей «настройкой по умолчанию» был SaaS. ПО, поставляемое через облако, продаваемое из расчёта на одно рабочее место и монетизируемое по модели подписки.

Теперь же этот фундамент подвергается испытанию со стороны ИИ. Когда агент может оказывать поддержку клиентам, обрабатывать счета, составлять контракты и управлять рабочими процессами от начала до конца, единица измерения ценности меняется.

Вы больше не платите за доступ к ПО. Вы платите за результаты, а ценообразование за рабочее место начинает выглядеть несоответствующим.

Выбор между разработкой ПО и покупкой ПО тоже меняется, когда это ПО можно создавать за недели, а не за кварталы.

Компании, которые справляются с подобными ситуациями, не ждут подтверждений, а подвергают сомнению собственные предположения на раннем этапе, пока у них еще есть время и возможность действовать:

– Netflix делал это, трижды переходя от DVD к стримингу и оригинальному контенту, каждый раз разрушая свою собственную модель до того, как это мог сделать кто-то другой.

– Microsoft, после того как упустила крупные сдвиги в интернете и мобильных технологиях, перезапустила всю систему, сделав ставку на облако и ИИ.

– В Zappos мы прошли через более мелкие версии этого процесса. На ранних этапах навигация определяла пользовательский опыт; затем на первый план вышел поиск; и, наконец, мобильные устройства вынудили полностью переработать дизайн.

Каждый переход был болезненным. Системы ломались. Команды сопротивлялись. Конверсия первоначально падала, и требовались большие усилия и время, чтобы восстановить ее.

Мы понимали, что в этих решениях есть асимметрия. Изменение настроек по умолчанию может быть чрезвычайно болезненным, но эта боль временна. Ибо каждый раз, после некоторого времени на адаптацию и после каждого перехода старая модель всегда выходила на новый уровень по силе, масштабам и перспективам.

Сохранение настроек по умолчанию комфортно, но сохранение неправильных настроек по умолчанию фатально

В настоящее время, на рынке одновременно подвергаются сомнению сразу несколько настроек по умолчанию:

– написание кода;
– люди как единица работы;
– ПО, цена которого зависит от количества рабочих мест;
– статические модели.

Ни одна из этих настроек по умолчанию не исчезнет в одночасье, но в эпоху ИИ период полураспада сокращается.

И какими бы очевидными ни казались "правила по умолчанию", мы всегда должны подвергать их сомнению, потому что в удивительно большом проценте случаев то, что считается истинным, оказывается лишь частично истинным, неточным или просто пережитком мира, которого больше не существует.

То, что вчера было особенностью, сегодня является всего лишь правилом по умолчанию, а завтра может стать ошибкой.

Читать полностью…

Проблема не в ChatGPT

Проблема в том, что никто не учит думать о задаче до того, как написал ИИ.

Просишь разобрать данные — получаешь уверенный текст с придуманными цифрами. Просишь конкурентный анализ — получаешь воду, которую стыдно показать. Закрываешь чат, выключаешь агента, делаешь сам.

Дело не в модели. Дело в подходе.

«Сигнал» — цикл занятий от ProductSense про принципы работы с ИИ, которые остаются, когда выходит новая модель.

– как ставить задачу, а не «задавать вопрос»;
– как проверять результат без перечитывания каждой строки;
– как встроить ИИ в рабочий процесс, а не использовать как Google.

7 занятий по 2 часа. Разбор + практика. Ведёт Юра Агеев, основатель ProductSense и ведущий подкаста make sense.

После занятий заберёте с собой:

– шаблон задачи;
– чек-лист проверки;
– карта того, что отдавать ИИ, а что нет;
– набор контекста про твой продукт;
– описанный процесс для автоматизации.

Бесплатно.

🗓 Старт 21 апреля
👉 signal.productsense.io

Читать полностью…

Два пути, Семь врат

⛩️Путь внедрения новых функций

1. Архитектор определяет задачу как структурированное задание с полным набором: 1) контекста (данных/метрик/кода/отзывов/чего угодно); 2) целями; 3) ограничениями.

↓

2. ИИ-агент декомпозирует задачу, планирует реализацию, пишет код и генерирует собственные тесты.

↓

3. Создаётся запрос на слияние (PR). Он проходит три этапа проверки Claude. Оператор проверяет всё на краткосрочные/долгосрочные риски, а не просто корректность ответов ИИ.

↓

4. CI проверяет типизацию, линтинг, модульные тесты, интеграционные тесты, сквозные тесты.

↓

5. Очередь слияния выполняет перебазирование и выполняет слияние, если оно успешно.

↓

6. Включается контроль функциональности для команды. Постепенное развёртывание в процентах. Мониторинг метрик и обратной связи. Шестифазный конвейер развёртывания продвигает проект по всем этапам исследования/дизайна/разработки/производства с тестированием на каждом этапе.

↓

7. Доступен аварийный выключатель в случае ухудшения работы и автоматический откат для серьёзных проблем.

⛩️Путь исправления ошибок =

1. CloudWatch и Sentry обнаруживают ошибки.

↓

2. Система сортировки Claude оценивает серьёзность, создаёт линейную задачу с полным контекстом расследования.

↓

3. Оператор проводит собственное расследование.

↓

4. ИИ уже провёл ИИ-диагностику и предложил исправления. Оператор проверяет и внедряет исправление.

↓

5. Тот же процесс проверки, развёртывания и мониторинга.

↓

6. Система обработки запросов повторно проверяет ошибку.

↓

7. Если проблема решена, заявка автоматически закрывается.

Оба пути используют один и тот же конвейер. Одна система. Один стандарт.


∞ Петля самовосстановления на основе обратной связи ∞

Это – центральный элемент системы.

1. Каждое утро запускается автоматизированный процесс проверки работоспособности. Claude Sonnet опрашивает CloudWatch, анализирует паттерны (ошибок) во всех сервисах и формирует сводный отчёт о состоянии системы, который отправляется команде через мессенджер (и никому не приходится запрашивать его вручную).

↓

2. Час спустя запускается механизм триажа (система ИИ, которая автоматически оценивает и распределяет поступающие задачи по приоритету, важности или срочности).

↓

3. Он кластеризует ошибки, возникшие в production-среде (на основе данных из CloudWatch и Sentry), оценивает каждый кластер по девяти критериям критичности и автоматически создает тикеты на расследование в системе Linear.

Каждый тикет содержит примеры логов, информацию о затронутых пользователях и конечных точках (endpoints), а также рекомендации по путям расследования.

↓

4. Система выполняет дедупликацию. Если уже открытый тикет охватывает тот же самый паттерн ошибок, система обновляет этот тикет. Если же вновь возникает ошибка, по которой тикет ранее был закрыт, система выявляет эту регрессию и автоматически открывает тикет повторно.

↓

5. Когда инженер отправляет исправление (fix), его обработку выполняет тот же самый конвейер. Три итерации проверки с участием Claude оценивают запрос на слияние (PR). Система CI выполняет валидацию.

6. После завершения развертывания механизм триажа повторно проверяет данные в CloudWatch.

7. Если исходные ошибки устранены, соответствующий тикет в Linear закрывается автоматически.

Так семиэтапный конвейер развёртывания последовательно продвигает изменения через среды разработки и production, выполняя тестирование на каждом этапе.

⚠️ Каждый ИИ-инструмент отвечает за выполнение лишь одной конкретной фазы и ни один инструмент не пытается взять на себя абсолютно всё.

Этот ежедневный цикл формирует "петлю самовосстановления", в рамках которой ошибки выявляются, проходят триаж, исправляются и верифицируются с минимальным участием человека.

«ИИ будет создавать запросы на слияние, а человеку останется лишь просматривать их, чтобы убедиться в отсутствии каких-либо рисков».

Входите тесными вратами, потому что широки́ врата и пространен путь, ведущие в погибель, и многие идут ими; потому что тесны́ врата и узок путь, ведущие в жизнь, и немногие находят их.

Читать полностью…

Эпоха SaaS меняется, а вместе с ней и роль тех, кто управляет её решениями

Мы видим, что происходит с теми же Figma и Notion – ИИ-индустрия автоматизирует создание интерфейсов и функционала сервисов (и сами сервисы) за считанные дни, поэтому растет ценность специалистов, способных проектировать сложную простую логику процессов и управлять продуктом как Системой.

Чтобы стать тем самым «оператором-оркестратором», особенно в ИИ-сфере, нужны передовые знания и много практики.

22 апреля в 19:00 мск на онлайн-дне открытых дверей магистратуры «Управление продуктом в цифровом бизнесе» ИТМО в партнерстве с Яндекс Практикумом будут обсуждать, как собрать необходимые специалисту навыки системно.

👉 Зарегистрироваться на встречу

Разберут образовательные треки, дисциплины и то, как вообще сейчас выглядит актуальное обучение управлению продуктом. Для тех, кто хочет грамотно рулить продуктами в эпоху ИИ эта программа маст-хэв.

Читать полностью…

👆 P.S. И да, о чём бы с удовольствием подискутировал про стресс в айтишке с молекулярным биологом Сергеем Харитоновым:

– Яркое холодное освещение ночью и блэкаут днём – самое плохое решение для "ночных тимлидов" какое может быть, и такой подход лишь усугубляет негативные ощущения, что, собственно, Сергей и подтвердил в конце – оно не работает на долгосрок (в отличии от тимлидов).

Долгосрок – свеча рядом с экраном/ноутом, блики света от огня на стене которой идеально заменяют естественный(!) свет Солнца, которого нет ночью и успокаивают глаза-мозг. Просто потому что в свете Солнца много есть чего. Оно же есть в огне. Смотри в огонь, будь сам огнём, Огонь-Внутри-Тебя 🔥

– Днём можно спать при свете Солнца и блэкаут-шторы не нужны (читай – они только вредят). Спи днём также, как спишь ночью – с обычной шторой или без. Все эти попытки обмануть себя приводят лишь к одному – мозг-глаза-сознание всё равно знают, что его пытаются обмануть, их не обманешь, от этого только хуже.

– Спать можно дважды в сутки по 4 часа без вреда для здоровья. Говорю об этом как практик с 10+ летним опытом стабильной работы с полуночи и до 8 утра. Со здоровьем всё в порядке (тьфу х3). Спать 10+ часов я тоже могу и люблю, при правильном мышлении и подходе, переключение между режимами вообще не чувствуется, потому что режимов-не-существует.

– Пить магний вредно, как и пить любые витамины. Пить витамины – это дисбаланс. Лучше витамины есть органикой через постоянно полезную пищу и травы и качать ей то самое "нейробиотическое чувство" (но я называю это по-другому).

А магний лучше всего усваивается через кожу нервами водой в ванне с английской солью, которая его и содержит (рекомендую миксовать с розовой гималайской). Добавь темноту и снова огонь, и вот уже эффект Х10.

– Физические тренировки и мышцы – очень тонкая тема в контексте разгрузки ими от стресса. Знаю много случаев, когда под воздействием стресса физическое переходило в фанатическое и люди гробили своё пошатнувшееся здоровье ещё больше с мыслью "сожгу стресс спортом". В итоге, выгорание и стресс уходят на более глубокий ментально-физиологический уровень и бетонируются там тренировками.

Ключ в медитации, дыхании и фасциях. Баланс и Тишина внутри тебя 😌

Читать полностью…

Бэдтрип эпохи Web 2.0

Поймал вчера короткий бэдтрип в попытке начать работать с чистым Wordpress. В сознании сразу пронеслась куча воспоминаний из эпохи web 2.0, когда всё делалось руками: от контента до кода. А бэдтрип возник даже не из-за боязни чистого листа или сложности с кодом, нет (нет ничего прекраснее чем чистый белый лист).

Устанавливая нулёвую сборку WP, вдруг осознал (вспомнил), что большинство продуктов эпохи 2.0 характерны одним свойством – структурностью и ограниченностью во всём: от кода до механик работы с данными, которая лишала нас, как пользователей, той «магии» ПО и данных, на которую, на самом деле, они способны. И нам приходилось всё допиливать руками разработчиков, постоянно выслушивая сначала про те или иные технические ограничения тех времён, а после них и просто про ограничения времени.

(моя любовь в этом плане к Wordpress была безгранична, как и безгранично кол-во комьюнити плагинов к этому чудесному движку).

Традиционным продуктам 2.0 не хватало внутренней и внешней свободы механик и данных и UGC, которую даёт (и так жаждет) ИИ.

Мы, как пользователи, это всегда чувствовали, мы были недовольны этим, но нам приходилось пользоваться старыми продуктами, потому что не было ИИ.

А бэдтрип возник из-за того, что даже спустя 20 лет, в Wordpress до сих пор нет решения, которое бы позволяло продавать статьи на сайте поштучно (я не говорю уже даже про то, чтобы их можно было поштучно сдавать для чтения в аренду).

...Основная бизнес-модель контента.
Миллионное комьюнити.
20+ лет развития продукта.
Решений нет...

...ИИ написала плагин с моих слов за 5 минут.

Во Вселенной, где единственной постоянной является Хаос перемены, метод проверки гипотез и создания продуктов должен быть настолько быстрым, что на это должна уходить всего одна минута/один час/один день/неделя.

Проверка идей, развитие продуктов и написание кода в стиле 2.0 – это не просто медленно. Это, blyat, очень медленно.

(Фух, отпустило)

Читать полностью…