2.5 дня, батут работает. Завтра уже буду подключать к backend-серверу. Писать на Swift легко и приятно. Уже успел напороться на особенности работы в памятью в #iOS приложениях. Прикольно.
Читать полностью…
У Моего самого харизматичного кофаундера Рамзеса в инстаграме начали выходить видосы про всякий вайб, отношения, мужские/женские манипуляции и многое другое, рекомендую подписаться (а иначе бан 🤬)
https://www.instagram.com/ramzes_kubinskiy
Кто уже посмотрел, как вам?
День первый, когда Богдан пишет iOS приложения, полёт нормальный
Читать полностью…
Буду благодарен если накидаете в комментариях самые полезные гайды которые вы встречали по:
1. System Design мобильных аппок, особенно в разрезе user data privacy
2. UI, цвета, формы кнопок и анимации - ликбезы по этому всему
3. UX, про привычки и интуитивность
4. Логика экранов приложения, навигация и все такое
P.S. снобские комментарии по типу «ууу на это надо годы опыта» или «ууу надо нанять команду» будут караться анально
Огромное спасибо команде Telegram Apps за публикацию нас в Trending Apps ❤️❤️❤️
Читать полностью…
Уже постил это видео, но напомню вайбы SSI:
https://youtu.be/9iqn1HhFJ6c
Я считаю свой блог относительно небольшим, но для многих 5000 человек это уже планка. Какие факторы повлияли на рост Моего блога?
Я выделяю всего три:
1. Я рассказываю то, чем хочется делиться с другими
2. Меня репостят коллеги по цеху (Игорь, Валера и др.)
3. Я попал в легендарную "AI папочку"...
Папочка – это способ подписаться сразу на подборку из каналов в рамках определённой тематики. На этот раз Меня добавили в подборку которая называется "Product/AI", что довольно логично, с учётом того, что уже около 9 месяцев Я создаю AI-продукт.
Поэтому если вы хотите почитать что-то из блогов, похожие на Мой, чтобы ознакомиться с тем, как работать с ИИ и как делаются продукты, рекомендую:
/channel/addlist/pr7M9cPgdo0zOGE6
Рекомендую к прочтению всем фаундерам, владельцам бизнесов и руководителям – крайне грамотный гайд по построению здоровых продуктивных отношений между партнёрами (и между коллегами), где все друг друга слышат, понимают, доверяют, ценят: https://review.firstround.com/how-to-fix-the-co-founder-fights-youre-sick-of-having-lessons-from-couples-therapist-esther-perel/
Читать полностью…
Делаю ревью новых задачек в Симуляторе DS, написанными новыми младшими авторами и дизайнером. Очень нравится структура, инфографика и гифки 🥰
Читать полностью…
Выложил Miro-доску по unit-экономике сюда: https://miro.com/app/board/uXjVODg5odE=/?moveToWidget=3458764592308797427&cot=14
Читать полностью…
https://fixupx.com/Nick_Franklin/status/1801020298848002447
Читать полностью…
Фреймворк работы с продуктом (June 2024, 1/2)
Когда ты фаундер, у тебя каждый день 100 "важных" задач, и каждый день тебе нужно выбрать максимум 3
Пользователи всегда хотят всё, сразу, да ещё и вчера. Когда ты говоришь "да" чему-то одному, ты говоришь сегодня "нет" 99 другим вещам. Как выбрать, чем заняться в каждый момент времени? Я не скажу, что у Меня уже выработался предельно стабильный фреймворк приоритезации в том, что касается продукта, но кое-какими эвристиками, которыми пользуюсь ежедневно, поделиться могу:
1. У всех задач есть, грубо говоря, 2 источника:
• Внутренний – наши идеи и гипотезы, "приземление" твоего Vision на текущий продукт: замечаешь разницу между ожиданием и реальностью, находишь минимальный зачаток от этой дельты ("MVP"), реализуешь (буквально, сеешь семя) – смотришь как прорастает.
• Внешний – что попросили пользователи (в коммьюнити-чате и на кастдевах). К слову, Я лично немного не вижу смысла сейчас проводить кастдевы в формате "провалидировать свою гипотезу", для Меня кастдевы это больше про "ideas mining", послушать пользователя, что у него болит, что хочет (всё же когда есть на руках продукт или фича, ваши разговоры более предметные). Тем более, когда реализовать MVP какой-то фичи по времени у тебя занимает столько же, сколько бы ты писал код для неё. Только разница в том, что пользователи смогут уже это пощупать, дать обратную связь, накидать кучу идей и пожеланий. И уже реальный опыт пользователей, а не твоя фантазия – будут "ваять" ту или иную идею на практике.
Отсюда важный принцип про скорость в стартапах: "ship fast, ship daily". Это важно и для продукта (быстрые итерации = много шагов улучшения), и для пользователей (понимают, что продукт живой + ты оперативно реагируешь на их пожелания, баги), и для тебя (буквально, привязываешь свою дофаминовую систему к "счастью пользователей").
2. С источниками разобрались. Куда/как собирать задачи?
Копить беклог – штука вредная, примерно как наедать пузо. Если задач становится слишком много, то они копятся просто так, ты забываешь контекст, ты их в конечном итоге не делаешь. В то же время совсем не копить беклог нельзя. Хочется сохранять всё важное и пропускать всё неважное.
• Если задача/фикс занимает пару минут (аля подкрутить промпт или поправить конфиг, это делается сразу, прямо в master и сразу в прод). Соответственно, такие мелочи не попадают в беклог
• Если задачу Я почти наверняка не возьму в работу ближайшие месяца 2, такое тоже не попадает в беклог (если фича/проблема настолько важная, Я о ней подумаю ещё раз, либо пользователи будут просить неоднократно)
• Если задача (например, баг) на какой-то очень редкий кейс, условно, у 1 пользователя из 1000 – такое Я тоже пропущу, потому что impact у такого действия будет мелкий (опять же, если это важно, об этом скажут ещё минимум 2-3 пользователя). Но если Я понимаю, что это будет полезно многим другим, такое берем
Для ведения задач по продукту мы используем Linear, сильно приятнее чем Jira/Asana/Notion/Todoist/etc. Очень удобный интерфейс, своя философия (в хорошем смысле, opinionated software).
3. Классификация
По Kano Model, у задач есть 3 вида:
• Критические баги (если не исправить, пользователи страдают) – "Must Have"
• Новые фичи (если добавишь, привлечёшь новых и обрадуешь старых)
• Улучшения, оптимизации, мелкие баги (вложение пропорционально улучшению UX)
Браться предпочтительно именно в этом порядке (со скидкой на времязатраты). Если что-то сломалось, особенно, что закрывает какой-то функционал, это нужно чинить в первую очередь. Когда делаешь новые фичи, выпускать их в наиболее простой работоспособной форме (помнить, что софт "выращивается", а не строится: разработчик сильно больше похож на садовника, чем на строителя). Докрутить и усложнить всегда можно, важнее всего "замкнуть петлю обратной связи" и начать получать фидбек от пользователей, чтобы знать, в какую сторону улучшать. Наконец, что кажется изначально как баг – часто на самом деле минорное улучшение.
#lifeops
DataChain: идея для стартапа на стыке blockchain и AI
Проблема:
• AI всё лучше генерирует контент – текст/картинки/видео/аудио
• Существуют игроки которые пользуются этим, чтобы от лица авторитетных источников распространяют ложную информацию, fake news; взламывают системы аутентификации по голосу / лицу
• Пользователям всё сложнее отделять зёрна от плевел. Платформы не успевают силами экспертов и полуавтоматической модерации размечать fake-контент до того, как он распространится
Идея:
• OpenAI и другие AI-провайдеры умеют подмешивать в сгенерированные текст и картинки некие "водяные знаки", незаметные для человека, но легко детектируемые бездушной машиной. Аналогичные штуки могут делать фотошопы и редакторы следующего поколения
• Что если зайти дальше и в каждый "юнит контента" (например, кусочек видео или фото) подмешивать такую информацию о совершённых модификаций слой за слоем как в blockchain, чтобы затем платформы могли быстро провалидировать "цепочку транзакций" и понять, это оригинальный контент (уходит ли история модификаций к авторитетному источнику?) – или где-то в промежутке была генерация from scratch (либо, скажем, модификаций было настолько много, что опять же достоверность/оригинальность источника уже становится сомнительной)
• Аналогичную мета-инфу, представляю, можно зашивать в целые датасеты (например в финансовых отчётах или демографических источниках), делая что-то типа "электронной подписи", мол, статистика не была притянута за уши и первоисточники были не тронуты
Пока настраивал Developer Account для приложения, наконец, перевёл свой Apple ID на не-РФ регион. Заодно появился официальный ChatGPT в AppStore.
Первое, что опробовал – вести тот же 1:1, но уже с ChatGPT и сразу на английском. Выглядит как мега полезная привычка, которую легко соблюдать: всё равно уже привык прогуливаться 40 минут пешком до дома, болтая с собой или слушая аудиокнигу. А тут ещё и хорошие вопросы от GPT и к тому же регулярная практика английского (habit stacking как в книге atomic habits). Тестируем.
#LifeOps
А вы говорите, зачем вести блог...
Хочу выразить огромную благодарность всем, кто подписан на канал, особенно всем тем, кто обращается в личные сообщения с очень ценными предложениями и обратной связью. Это очень ценно и вдохновляет.
Вы лучшие 🙈
Маркер мастерства во многих ролях до безобразия похож и заключается в том, чтобы уметь видеть не одно единственно верное решение (как правило, которое занимает много ресурсов) — а видеть весь спектр решений (инструментов), понимать все трейд-оффы, знать что жизненно важно, а чем/кем можно пренебречь – и главное, уметь двигаться между крайностями, от простого к сложному
• В маркетинге: понимает, на что лучше слить бюджет в $100,000, на что в $10,000, на что в $1000, а что можно сделать если бюджета нет
• В разработке/ML: как делать космолет по всем канонам с грамотным кодом, архитектурой (чтобы ещё можно было повыебываться техническими решениями перед коллегами) – а как писать код из говна и палок за пару дней лишь бы работало и закрывало боль пользователя
• В общении: знает как говорить с такими же матёрыми экспертами как и он на профессиональном жаргоне, опускаясь/поднимаясь на любой уровень абстракции – но также может на пальцах объяснить, что делает непосвященному; аналогично: говорить подробно со всеми деталями vs говорить/писать коротко и лаконично, самое важное
• Голос, язык тела: уметь где нужно транслировать статус и властность, в других случаях – располагать и обезоруживать, третьих – шутить, вайбить и отвлекать внимание
Гибкость
Час назад сел писать приложение, вроде бы несложно
Читать полностью…
Короче к нам за полчаса пришло больше лидов, чем за 72 часа с самой жирной рекламы
Читать полностью…
С ноги залетаем со своим вайбом в Рилсы, будем мега благодарны вашим лайкам и репостам 😎
Читать полностью…
https://twitter.com/ssi/status/1803472825476587910
Читать полностью…
Нашёл подборку *токсичных писем* от CEO Apple, Microsoft, Tesla и других корпораций, привожу лишь некоторые из них:
Читать полностью…
Пользователи, даже самые привередливые, уже в восторге от новой фичи Vibe AI 💞
Читать полностью…
Недавно мы писали, что метрики – это основное понятие, которым оперируют аналитики (на самом деле многие DS-специалисты тоже!). Если подниматься на уровень выше, то существует система, объединяющая в себе бизнес-метрики и позволяющая видеть «общую картину» – юнит-экономика.
Если ваша цель – не работа ради работы, и вы стремитесь понимать, какое влияние оказывает на компанию ваши действия, то добавляйте в закладки и включайте наш краткий (да, в случае юнит-экономики – это краткий) обзор на устройство юнит-экономики!
Богдан Печёнкин, соавтор Симулятора DS и фаундер стартапа Vibe AI, разобрался, как соединены между собой основные метрики бизнеса и почему важно понимать полный «круговорот денег» в компании. А ещё на каждую из упомянутых метрик у нас есть задачи в Симуляторе DS, но об этом подробнее вы узнаете уже сами!
Фреймворк работы с продуктом (June 2024, 2/2)
4. Task Batching
Очень помогает группировать разношёрстные однотипных мини-задач и багов в "пакеты" из схожих по тематике (например, баги по симулятору, отладка ответов, улучшения планировщика свиданий и т.д.). Это помогает фокусироваться, делать задачи на "потоке" (не тратишь время не переключение, погружение в новый контекст).
(и наоборот, сильно большие задачи нужно дробить на такие шаги, которые можно закончить и показать за неделю или меньше)
5. Спринты
В Linear очень удобно реализованы спринты (там они называются "циклы"). Это задаёт определённый пульс продукту. Я поставил по привычке спринты в 1 неделю: это достаточно времени, чтобы заделиверить 3-4 каких-то важных улучшения продукта + ещё много мелких фиксов в оставшееся время.
При планировании спринта (что должно занимать 30-60 минут) набираешь задач, чтобы их как раз хватало на твою пропускную способность (например, 50-60 часов). В Linear удобные оценки времени по степеням двойки (1-2-4-8-16) и по дефолту запрет на большие задачи, мануал рекомендует их разбивать на более атомарные.
По окончании спринта кидаю скриншот задач с прошлого спринта пользователям.
___
А как фреймворк устроен у вас?
#lifeops
