Что происходит, когда продукт строится не из метрик, а из идеи. История «Сфер» (Рубрика #ProductManagement)

Этот доклад рассказал мой коллега, Иван Турлаев, который уже больше 8 лет развивает мобильные приложения в Т-Банке. Доклад был посвящен созданию и внедрению новой концепции банковского приложения – «Сферы». Предпосылка проста: современные банковские приложения устроены одинаково. Счета, карты, платежи, кредиты – все разложено по привычным категориям. Банки, ориентируясь на метрики и копируя друг друга, выпускают однотипные решения. Но мы решили взглянуть на приложение не со стороны компании, а со стороны клиента и подумать, а что если сгруппировать сервисы не по банковским продуктам, а по жизненным потребностям человека? Так возникла идея «Сфер». Эта концепция родилась не на основе цифр или бизнес-планов - она появилась из стремления сделать сервис понятным и полезным для человека.

Придумать смелую идею мало, ее нужно реализовать. Разработка «Сфер» потребовала объединить усилия множества разрозненных команд. В T‑Банке разные направления (карты, кредиты, платежи, страховки, путешествия и др.) имели свои цели и метрики. Объединить их вокруг новой концепции оказалось непросто. Нужно было убедить менеджеров и разработчиков принять общую идею и найти с ними общий язык. При этом бросить текущие проекты было нельзя.

Проекту помог единый vision, который был подготовлен командой в качестве наглядного концепта нового интерфейса. Увидев цельный образ будущего продукта, разработчики и менеджеры смогли эффективнее взаимодействовать. Обсуждения сместились с узких показателей на пользовательский опыт: фокус на том, как сделать удобнее человеку. Единый дизайн-концепт выступил «клеем», объединяющим команды. Важно было регулярно сверяться с изначальным замыслом и быть настойчивым.

Основой был дизайн-концепт. Команда сознательно отошла от банковских шаблонов интерфейса. Цель - сделать так, чтобы интерфейс говорил на языке жизненных ситуаций, а не банковских продуктов. Дизайнеры экспериментировали с навигацией и визуальным стилем, уходя от перегруженных списков и меню. На главном экране пользователь сразу видит ключевые сферы своей жизни вместо длинного перечня услуг. В итоге, на первом этапе в приложении T‑Банка появились четыре первые «Сферы»: «Шопинг», «Дом», «Авто» и «Путешествия». Каждая стала единым центром для своей темы, объединяя все связанные сервисы банка и партнеров. Например, «Дом» собрал в одном месте оплату коммунальных услуг, страховку жилья и покупки для дома. А «Авто» объединил все для автовладельцев: от штрафов и заправки до страховок и ТО. Такой подход резко отличался от традиционного: прежде эти операции были разбросаны по разным разделам, а теперь клиент решает задачу целиком, не переключаясь между вкладками.

Для инженеров проект «Сферы» тоже стал испытанием. Нужно было интегрировать множество разных систем – внутренних и внешних – в единое целое. Фактически команда создала платформу по принципу супераппа, где разнородные модули работают согласованно ради общего сценария. Архитектуре потребовалась гибкость: унифицированные API, общая навигация, единая система уведомлений - всё для цельного UX. Решения по backend и frontend принимались с оглядкой на задуманный пользовательский опыт, чтобы техническая реализация не испортила UX.

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

#Management #Design #Engineering #Leadership #Project #Metrics #Philosophy

Программирование смыслов (Рубрика #AI)

Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать.

Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам
1) Как всё началось
В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает.
2) Поворотный момент
В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи.
3) Что именно сделали (и где)
- Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов.
- Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение.
- Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы.
4) Машинное обучение как конвейер
Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей
- Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления.
5) Какие проблемы были и как их лечили
- Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры.
- Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают.
- В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код.
6) Принципы ранжирования и ответов
Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха.
Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Вот пример того, как роботы помогают в quality assurance. Пока я рассказывал про генерацию тест-кейсов агентами, повышение test coverage через генерацию юнит тестов, коллеги рассказали про настоящую робо-руку, что занимается настоящим ручным тестированием банкоматов:)

[1/2] The 7 Most Powerful Moats For AI Startups (Рубрика #Startup)

Интересный выпуск ребят из Y Combinator, в котором они разбирают книгу «Seven Powers: The Foundations of Business Strategy» (2016) авторства экономиста Хамильтона Хелмера. В этой книге описана концепция «moat» (конкурентного «рва») – устойчивого преимущества, защищающего бизнес от конкурентов, по аналогии с рвом вокруг замка. Несмотря на то, что книга вышла в 2016 году на примерах компаний вроде Oracle, Facebook и Netflix, ее идеи о типах moat остаются актуальными и для современных стартапов (в частности, AI-стартапов).

Хелмер выделяет семь видов устойчивых источников преимущества, которые позволяют компаниям долго удерживать высокую эффективность и защищаться от конкуренции
1. Scale Economies (эффект масштаба) – снижение издержек на единицу продукции по мере роста объёмов. Пример: компания с огромной инфраструктурой, как Amazon или UPS, может доставлять товары дешевле за счет массовости операций
2.Network Effects (сетевые эффекты) – ценность продукта растёт с увеличением числа пользователей. Классический пример – соцсети: они становятся ценнее, когда в них больше друзей. Аналогично платёжные системы (например, Visa) выигрывают, если их принимают больше магазинов
3. Counter-Positioning (контр-позиционирование) – стратегия, при которой новая компания предлагает такую модель или продукт, что лидеру рынка трудно скопировать из-за конфликта с его текущим бизнесом. Например, AI-стартапы могут брать плату за выполненную работу вместо лицензий на пользователя, подрывая модель SaaS-компаний
4. Switching Costs (издержки переключения) – пользователю дорого или сложно перейти к конкуренту, что удерживает его. Например, когда все данные и логика компании завязаны на Oracle, то миграция на другую СУБД крайне сложна и затратна. В эпоху SaaS таким же «липким» оказался, например, корпоративный CRM Salesforce
5. Branding (сила бренда) – клиенты выбирают продукт благодаря бренду, даже если есть аналог. Бренд формирует доверие и узнаваемость, что конкуренты не могут быстро воспроизвести. Интересно, что OpenAI показал Google силу бренда: у Google огромная аудитория и технологии (модели Gemini), но OpenAI с нуля сумела построить доминирующий бренд в AI благодаря ChatGPT, обогнав по популярности продукты Google.
6. Cornered Resource (эксклюзивный ресурс) – компания получает эксклюзивный доступ к ценному ресурсу, который трудно или невозможно заполучить другим. Примеры: патенты, уникальные алгоритмы, договоры. Например, Nintendo защищается эксклюзивными персонажами/играми, а в современном AI-пространстве примером служат компании с доступом к уникальным данным или контрактам: Palantir за годы работы получила особые контракты с правительством и доступ к секретным данным – такой ресурс недоступен новичкам (кстати, я уже рассказывал про книгу CEO Palantir).
7. Process Power (процессное преимущество) – долгосрочное преимущество от уникального бизнес-процесса или организационной практики, крайне сложно копируемой. Обычно формируется со временем и редко встречается.. Классический пример – Toyota со своей системой бережливого производства: ее производственные процессы десятилетиями давали фору конкурентам.

Отдельно ребята из Y Combinator добавляют еще speed (скорость). Они считают, что для стартапа на ранней стадии важнейшим «moat» является скорость исполнения. Этого фактора нет в списке Хелмера, но он «должен был бы там быть». В начале пути скорость разработки и доставки продукта – фактически единственное защитное преимущество стартапа. Пока большая компания раскачивается, стартап, работая в авральном темпе, успевает завоевать рынок.В крупной корпорации множество согласований, уровней менеджмента и бюрократии, из-за чего выпуск новой фичи занимает месяцы. Стартап же способен релизить улучшения за дни или часы. Пример – AI-стартап Cursor (интеллектуальный редактор кода): его команда практиковала «one-day sprints» – полный цикл разработки за один день!

Практические выводы из подкаста в продолжении.

#AI #Engineering #Software #Management #Leadership

[2/2] The 7 Most Powerful Moats For AI Startups (Рубрика #Startup)

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

1. Не начинать со «рва», начните с продукта. Сначала решите реальную проблему клиента и найдите product-market fit (соответствие продукта рынку). Не стоит отбрасывать идею стартапа только потому, что вы не видите сразу долгосрочного конкурентного преимущества - оно может сформироваться по мере роста через технологии, данные, бренд и т.д. Иначе говоря, «moat» – вещь защитная, сперва нужно что защищать. Эту мысль подчеркивают и цитатой Питера Тиля:
Competition is for loser
в смысле, надо стремиться найти уникальность, но не парализоваться страхом конкуренции на старте

2. Скорость и фокус – оружие стартапа. Главный козырь малой команды – быстрота решений и отсутствие бюрократии. Делайте упор на скорость разработки, частые итерации, тесную связь с пользователями. Это язык, понятный каждому инженеру: меньше совещаний – больше кода в продакшн. Применяя agile в экстремум (ежедневные релизы, как у Cursor), стартап может наработать большое отрывное преимущество, пока гиганты раскачиваются. Идея «Speed as a Moat» особенно резонирует для технических команд, где культура быстрых экспериментов и деплоя может решить судьбу продукта.

3. Классические “силы” никуда не делись – учитесь их распознавать. Инженерам и менеджерам важно понимать, какое преимущество формируется у их продукта: сеть, масштаб, lock-in, бренд или др. Например, создавая API или платформу, вы можете строить network effect – с каждым новым интегрированным клиентом ценность вашей платформы для всех растет. Разрабатывая сложную инфраструктуру, можно заложить process power, как это сделал Plaid или Palantir, где ценность в отлаженном процессе интеграции данных. Добавляя функционал, повышающий издержки переключения, вы удержите клиентов (пример – персонализация и память в AI-сервисах создают привязку пользователей). Руководителям продуктов стоит мыслить в этих категориях при развитии стратегии.

4. Новые времена – новые проявления moat. Менеджерам полезно осознать, что с появлением ИИ появились и новые источники данных и эффектов, усиливающих классические moats. Например, данные пользователей стали топливом для алгоритмов, и те компании, кто собирает больше данных (не жертвуя качеством), получают экспоненциальный рост преимущества (их модели умнеют быстрее). Это своего рода data network effect. Также, AI позволяет стартапам сразу выходить на глобальный рынок (меньше барьеров локализации), что ускоряет брендовый эффект – вспомним взрывную известность ChatGPT. Таким образом, техдиректорам и CTO стоит держать руку на пульсе этих трендов, чтобы понимать, куда вкладываться: в сбор данных, в улучшение алгоритмов, в создание экосистемы вокруг продукта и т.п.

В итоге, знание этих терминов про конкурентные преимущества дает общий язык инженерам и бизнесу. Термины вроде network effect, switching cost, moat перестают быть непонятными абстракциями. Для инженерных команд это шанс лучше понять стратегию компании, а для руководителей – донести её «на языке шаблонов». Такой взаимопонимание повышает шансы, что стартап не только быстро выстрелит, но и сумеет закрепиться, выстроив надежный ров вокруг своего «замка»

#AI #Engineering #Software #Management #Leadership

Meet For Charity & Нить Добра (Рубрика #Charity)

Уже традиционно я решли поучаствовать в аукционе Meet For Charity, где предметом аукциона является встреча со мной. За обедом/ужином я готов буду поговорить на разные темы, включая +/- любые из тех, что я поднимаю в этом канале. Сама встреча будет в Москве и я постарюсь, чтобы это было в первую рабочую неделю ноября:) Собранные по итогам аукциона средства будут направлены в фонд "Нить добра".

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

#Charity

2 гига спустя - эпизод четвертый (Рубрика #Podcast)

Вышел четвертый выпуск подкаста с лайтовым обсуждением интересных тем двумя ведущими из Т-Банка: Антоном Костериным и автором этого канала. Мы успели обсудить следующие моменты

- Мягкая сингулярность от Сэма Альтмана (эссе Сэма, что я уже разбирал раньше)
- Просвещение и ИИ (научная статья, что я уже разбирал)
- Конец эры мегаработодателей (см. мой разбор)
- Чат-боты как новый канал роста и монетизации (см. мой разбор)
- Реорганизация AI в Meta, запрещенной в России организации (см. мой разбор)

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Management #AI #Software #Engineering #Reliability #Processes #Productivity

За гранью реальности: игровой фестиваль прямо в офисах Т-Банка

В воскресенье 9 ноября в офисах Т-Банка в Москве и в Питере пройдет гик-фестиваль настольных и ролевых игр.В этот день соберутся герои ролевых игр, мастера и любители настолок, чтобы разгадывать загадки, побеждать и много смеяться. Фестиваль проходит для
- IT-специалистов, которые хотят поиграть в настольные игры, пообщаться и найти единомышленников
- Тех, кто слышал про D&D и другие настольные игры, но пока не пробовал
- Тех, кто любит смотреть на косплей или участвовать в косплей конкурсах
- Тех, кому исполнилось 18 леи
Для желающих попасть на фестиваль, кто не является счастливым сотрудником Т-Банка, надо заполнить форму (сотрудникам можно зарегаться через внутренний Т-Календарь).

В Москве и Питере будут следующие активности
- Настольные игры и настольно-ролевые игры
- Тематические фотозоны
- Ярмарка игровых товаров в Москве и квиз про настольные и ролевые игры в Питере
- Косплей дефиле в Москве и бинго для гостей в Питере
- Мастер-класс по покраске фигурок в Москве и по покрасу миниатюр в Питере
- и многое многое другое

Чат фестиваля доступен в telegram: https://t.me/tluck_fest
Количество мест ограничено — всего 300.
После регистрации надо будет дождаться подтверждения участия, что придет на почту

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

P.S.
Полгода назад у нас уже проходил фестиваль настолок.

#Games #Culture #Software

Research Insights Made Simple #18 Review of "AI in SDLC report" by IT One & Skolkovo (Рубрика #AI)

Обсудили исследования от IT One и Сколково вместе с Дмитрием Немовым, директором по развитию и продуктам IT ONE. Дима - один из авторов этого исследования, что позволило копнуть в цели исследования, методологию, результаты. В общем, мне было очень интересно общаться с Димой и я надеюсь, что вам тоже понравиться выпуск. И если он вам зайдет, то поучаствуйте в исследовании про влияние AI на SDLC от Т-Банка

Кстати, сами результаты исследования от IT One и Сколково доступны здесь, плюс есть мой разбор в двух постах: 1 и 2. А в этом выпуске мы обсудили следующие темы
- Введение и тема выпуска
- Предпосылки: зачем это исследование
- Структура и методология исследования
- Мировая практика и этапы SDLC
- Сквозные инструменты и внутренняя платформа
- Автоматизация задач и роль доменных специалистов
- Как мерить продуктивность: опросы vs метрики активности
- Ассистенты и автодополнение - норма в 2025 году
- Платформенные решения: ИИ как ядро стратегии
- 2024→2025: адаптация и ожидания vs реальность
- Российские тренды: централизованный ModelOps и пилоты
- Агентные и мультиагентные подходы
- Изменение ролей в командах и доверие к коду
- Платформа для измерения эффектов (утилизация, impact, cost‑benefit analysis)
- Переход от пилотов к продукту и выбор кейсов

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#AI #Engineering #Architecture #ML #Software #Economics #Software