Стёпа Потапов

Короче, я навайбкодил своё приложение 😮

🔵Это приложение для фанатов тенниса, вроде меня: подписываешься на теннисиста, за которого болеешь, кидаешь виджет на home screen — и всегда знаешь его следующий турнир, ближайший матч, во сколько и против кого играет

А зачем оно вообще: Нуу .. а почему нет?

🔵Последние полтора года я слежу за большим теннисом, там свой мир: сотни игроков, десятки турниров по всему миру, много неожиданного: топ-50 ракетка может спокойно вынести топ-10. И следить за этим правда интересно, когда есть контекст, который ты понимаешь. А со сбором контекста много всяких проблем: он нигде нормально не лежит, только в тг-каналах, на ютубе и на сайтах в формате новостей, отчётов по турнирам и перфомансу игроков.

🔵Вторая проблема - это турниры: турниров десятки, они проходят разным составом игроком, в разное время, в разных местах и параллельно спокойно может идти несколько турниров, за всем этим неудобно следить и приходится постоянно гуглить, где же будет играть Медведев и какие его ближайшие игры.
Если вы не фанат тенниса, представьте что, условно, ваш любимый Спартак может расщепиться на 5-7 подкоманд и поехать в разные части мира играть весь год. Примерно такой экспириенс переживает человек, который болеет за 5 разных теннисистов одновременно 👍

🔵Собственно, поэтому я и сделал прилу, теперь она, когда не багует, показывает, кто с кем и где когда играет, удобно и даже красивенько!

Подглядеть, что за приложение и последить за тем, как оно будет развиваться → сюда
Багов - куча, идей, что можно доделать - ещё больше

Такие дела, очень собой доволен)
Докачу пару-тройку апдейтов и пойду что-то думать про маркетинг
🐶

⚡️ Раньше всех! Ну почти ⚡️

Прямо сейчас Figma анонсируют возможность для дизайнеров двигаться по следующему флоу:

• Можно сконнектить Figma и Github
• Прямо в Figma посмотреть, как выглядит продакшен, но в формате Code layers (типа фреймов в фигме)
• Обновить фигма-файлы
• И запушить обратно в Github 😍

Выглядит любопытно, но у меня один вопрос:
Эт.. А кто будет ревьюить этот код? ☕️

Как стратегическое перекрывает продуктовое и причём здесь Spotify

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

За это время в Я.Музыке появились видеокарточки треков (не у всех правда), донаты артистам, интеграция с концертами, нейросетевые AI-сеты и недавно - импорт музыки из других стримингов. Вроде неплохо, но если присмотреться, добрая половина - это либо догоняющие шаги, либо интеграции с соседними сервисами Яндекса.

А что появилось за последние пару лет в Spotify:

🔵 качество звука автоматически меняется под интернет/провод/блютуз и его можно настраивать вручную
🔵появился режим Song DNA: интерактивно смотришь, кто вообще создал трек, который ты слушаешь — продюсеры, саунд-дизайнеры, над какими треками ещё они поработали
🔵появился DJ: типо Алисы внутри Спотифая, у которой можно текстом или голосом заказывать что хочешь, и этот диджей в интерактивном формате собирает тебе коллекцию и включает музыку
🔵можно собрать группу с треками и вместе слушать музыку — накидать плей-лист на тусовочный вечер с друзьями
🔵разумеется, радио по треку вы же не думали, что его Яндекс придумал, правда? ☕️
🔵даже видео есть! - Это же супер-логичный шаг для стримингов

Тут нет ничего такого, что Яндекс не осилил бы со своими технологиями и ресурсами. Но Спотифай продолжает развивать продукт, а Я.Музыка продолжает… раскачивать Афишу 😭

Почему так происходит? Настоящей причины я конечно не знаю, но что видно: интеграции с Афишей, Алисой и остальными продуктами есть, а серьёзных продуктовых ставок - ну не особо. Те, что есть, чаще догоняют Спотифай, чем задают какой-то свой вектор.

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

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

Продуктовая фича, как вы понимаете, работает наоборот, но если она не сработает - тебе придётся это как-то объяснять и нести ответственность.

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

А пользователи… а что пользователи? Пользователи постепенно открывают для себя Спотифай 🐻

ноет на продуктовом 😒

Ну ладно ликвид гласс, это неплохо

Узкие места разлетелись

Представьте, что вы нашли джина, достаёте его из бутылки, а он говорит: «Я исполню сколько угодно твоих желаний» — Примерно так ощущается общение с разработчиками в последнее время.
При этом все предыдущие годы производственный процесс оптимизировался именно на скорость и качество разработки и в некоторых компаниях это достигало невообразимых масштабов:
🔵Системные архитекторы
🔵Бизнес-аналитики, чтобы лучше переводить с бизнесового на технический
🔵Системные аналитики, чтобы переводить с технического - на более технический
🔵На двух разработчиков - обязательно один тестировщик
🔵Задачи нарезаем с точностью до метода/функции
🔵Дизайны, конечно, описываем очень(очень!) детально, чтобы каждый корнер-кейс был учтён и отрисован

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

• Конечно, обнаружив сколько-то пространства в спринтах, сначала пойдём рефачить то, что давно было пора уже зарефачить.
• Затем появятся идеи как что-то улучшить или лоу-приорити баги, которые надо будет пофиксить.
• А затем, постепенно, закончатся и они

А что будем делать, если (когда?) часть команды начнёт простаивать по несколько недель? Месяцев?
В общем, есть у меня пара соображений про то, как будут трансформироваться команды в IT компаниях, напишу в следующей части, интересно же

❤️

😏

Всё стало неравномерным

Привет! А давайте немножко подумаем, куда нас все эти AI-движения ведут: как-будто «что-то началось», но уже не в твиттере, а на уровне компаний, в которых мы с вами работаем.

Итак, мы привыкли, что классический процесс разработки - это с десяток отдельных этапов:
🔵Дискавери и всё, что около: исследуем, ищем гипотезы, формулируем идеи
🔵Всё, что предваряет деливери: роадмапы, бэклоги, планирования и оценки задач
🔵Деливери: разработка, тестирование, выкатка в продакшн
🔵Пост-анализ: a/b тесты и мониторинг

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

1. То, что можно заметно автоматизировать
Полностью или частично:
➡️разработчики вроде как уже руками код особо и не пишут, уже больше в code-owner’s позиции.
➡️ тестирование сильно-сильно автоматизируется, есть возможность пользоваться кодовй базой как библиотекой и просто смотреть diff, но не на уровне кода, а на уровне объяснения, что этот код значит.
➡️технические требования больше тоже не занимают так много времени. В общем-то всё, что расположено очень близко к разработке - подвергается заметному ускорению прямо сейчас.

2. То, что автоматизировать пока не получается
➡️ Всё, что связано с decision-making, например, продуктовый дизайн. Так выходит, что в дизайне большую часть времени отнимают не макеты, а ответ на вопрос «как выглядит решение проблемы пользователя», и вот эту часть пока что не автоматизировать.
➡️Вторая часть - это продуктовый менеджмент. Да, можно побыстрее писать продуктовые требования, системные требования, обрабатывать корнер-кейсы, составлять чеклисты, искать референсы и тд.
Но это всё, вообще говоря, существует для того, чтобы на этапе разработки тратить меньше времени и полнее решать задачу, в то время как поиск стоящей гипотезы, принятие решение о том, что делать, а что нет, учитывание разных контекстов - всё еще не автоматизировано. (Если вы продакт и вдруг автоматизировали что-то - напишите мне в личку @stvlpotapov или в комментарии, я бы у вас поучился)

И отсюда получается, что процесс разработки ускорился, но как-то очень неравномерно, что обязательно на нас всех повлияет вдальнейшем.
Что думаете? Приглашаю в комменты поразмышлять вместе, вдруг мне показалось
🙏

Привет!
В Miro завезли прототипирование 😮


Пока простенькое, но тем не менее, довольно прикольно накидывать экран стикерами, а потом смотреть, не расползлась ли логика, нравится 😄

Предиктивная логистика для самых маленьких

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

А это возможно? В целом да, давайте на пальцах разберёмся!
В обычном диджитале (например, в стримингах) рекомендации работают как-то так: собрали признаки пользователей → так или иначе построили предиктивную модель → отранжировали каталог. Вроде понятно.

В екоме же, в отличие от классического диджитала, существует целых два слоя бизнес-логики: это диджитал и логистика
🔵В диджитале - всё то же самое, что и в стримингах: вам советуют то, что больше всего похоже на то, что вы раньше брали. Конечно, не настолько “в лоб”, но всё же.
🔵А вот на уровне логистики есть проблемы - в основном, это стоимость доставки:
➡️ Товары изначально поступают в распределительный центр где-то далеко за городом
➡️ Оттуда - в хабы, их уже побольше и они либо в черте города, либо совсем близко к ней
➡️ Из них - в пункты выдачи заказа
🔵Если вы заказали футболку, она не может сразу поехать из распределительного центра в пункт выдачи, потому что тогда вы, как бизнес, никогда не окупите стоимость доставки. Приходится консолидировать заказы в одну большую гигадоставку до центра выдачи, и ее уже везти.

🔵Допустим, вы большой еком ваши логистические операции уже окупаются, что тогда? Тогда вы можете попробовать не только предсказывать, какие товары пользователь скорее всего купит, но и реально доставлять их поближе к потенциальному покупателю, чтобы доставка ощущалась как “по клику” и стоимость последней мили была не такой драматической.
🔵У такого решения, помимо плюсов, есть куча инженерных и операционных челленджей: от самой логики рекомендаций в приложении - до сборки заказа, доставки его на склады, управления всем этим товаром и возвращением его на базовый склад, если пользователь всё же не хочет то, что вы ему предсказали.

Но тем не менее - Amazon уже сделал такую штуку, поэтому, если вы пользуетесь Amazon, возможно ваша футболка-ниндзя уже дожидается вас на ближайшем складе и ждёт, пока вы ее закажете, наконец-то

🙂

Привет!
Я на Пхукете! Пожелаем мне не обгореть в первый же день

Задумался: а как себя чувствуют все эти бесконечные дата-центры в не холодных странах?
Вся эта влажность, жара, а AGI строить надо ж как-то, неужели нет никаких проблем с этим?

Так вот, оказывается:
🔵оптимальная температура для дата-центров это 18-27 градусов. Если температура выше - приходится тратить больше энергии на охлаждение + выдумывать, как лучше охлаждать помещения.
🔵как вы понимаете, в огромном количестве стран средняя температура заметно выше, легче перечислить места, в которых она норм: это Северная Америка, в рф это всё, что выше Сочи по широте (если грубо), Ирландия, Скандинавия
🔵всем кто южнее - сочувствуем: в 21й стране мира дата центрам слишком жарко. Азия тем временем - это самый быстрорастущий рынок для дата-центров, наверное из-за стоимости доставки серверов, но я не уверен

такие дела ребятки, вот ссылочка на источник, советую почитать!
🐶

Привет!
Сегодня такая новость:
• Примерно 35% населения США использует умные колонки
• Больше половины из этих колонок - это Alexa от Amazon
• С января этого года, пользователи могут забронировать себе путешествия через Алексу, они сынтегрировались с Экспедией - крупнейшей платформой в мире, если что

Ждём, когда Яндекс догадается затащить свои путешествия в Алису, они репортят, что у них там тоже десятки миллионов юзеров

😮😮😮

🚷 Самолёт, который едет со скоростью 8 см в минуту

Довольно часто Boeing приводят в пример, как компанию, которая перестроила все производственные процессы, опираясь на lean подход: где-то в 1990х весь менеджмент компании месяцами обучали мыслить не в категориях своего департамента, а в категориях прибыли бизнеса, предлагали инжениринг менеджерам посчитать ROI и всякие такие вещи.

Но больше всего меня впечатляет история изменения самого подхода к производству, смотрите:

🔵На первой картинке 1990й год, компания собирает самолёты вот так: примерно 23 самолёта в ангаре, работа над самолётами происходит как на любом заводе: приходят работники, набирают себе инструмент, выставляют его рядом с самолётами, начинают работать. Через 2 дня самолёт откатывают к следующей станции автоматически. В случае, если какой-то отдел не успевал, конструкция вокруг самолёта ехала к следующей станции, чтобы закончить работу, обычно, сверхурочно, чтобы успеть попасть в дедлайн и ритм выпуска.

🔵Руководитель сборочного цеха проводит эксперимент: вместо того, чтобы исправлять проблемы каждого департамента по очереди, она отказывается от такого подхода вцелом, и строит производственную линию как на схеме 2 и на картинке 3.

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

Через несколько лет Boeing стал производить один самолёт за 11 дней, вместо 22, а переработки закончились.
Офигеть, да

«Победа» теперь перевозит питомцев в салоне.
Все владельцы чихуа-хуа ликуют 😄

Идея для тусовки с друзьями: купить гусей, полететь Победой

С наступившим!
Загадка:
- Топ-2 приложение по скачиваниям в Нидерландах - это приложение для прогноза погоды! Это в 2026м году, забавно, да?
- А какое приложение на топ-2 по скачиваниям в России?

☕️

отгадка под спойлером на картинке