Технический продакт менеджмент с Ильёй Безделевым

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

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

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

В преддверии уходящего 2024 года, я решил сделать небольшой фейл.

Вчера весь вечер работал, чтобы дать себе нормально отдохнуть первую неделю января и не думать о работе.

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

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

Всех с наступающим! 🎄

Кто-нибудь знает какие фреймворки для мобильных приложений используют Т-Банк, Сбер, Озон и Авито?

Приложения выглядят одинаково как под копирку. Стало интересно.

А как прошла ваша неделя?

P.S. Я чёт надеялся, что удалённого кода будет больше, чем нового. Но я добавил пару фич по ходу дела, поэтому не вышел из меня мега-сеньор, который удаляет кода больше, чем пишет.

В тему предыдущего поста.

ChatGPT умеет генерировать новые и видоизменять существующие SVG!

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

<svg width="100" height="80" viewBox="0 0 100 80" xmlns="http://www.w3.org/2000/svg">
<path d="M10 20 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
<path d="M10 40 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
<path d="M10 60 H90" stroke="black" stroke-width="8" stroke-linecap="round" />
</svg>

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

Это улёт, ребята. Я в восторге.

Год назад нам бесплатно сделали сайт. На тот момент у нас не доходили руки и кстати попался молодой парень, который предложил поработать забесплатно, за опыт.

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

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

Но оно кагбэ работало да и ладно.

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

Пока Арнаб колесит по западному побережью в роадтрипе, подготовлю ему PR на 2000 строк, который можно не ревьювить.

Потестим в проде.

«Ваши любимые фильмы»

Осирис против бетховена

С чат жпт не нужны никакие психоделики.

Как мы дожили до такого интернета?

Всегда был оверачивером. Знаете какая самая большая проблема у оверачиверов?

Мы считаем себя недоачиверами.

Всегда ощущение, что можно больше. Что что-то упущено. Мало.

Можно сказать «не парься». Но это как сказать человеку с РПП «ну ты просто перестань есть». Как сказать алкашу «ты просто перестань пить».

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

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

Жить в настоящем.

В бизнес-жаргоне много военных терминов. Есть они и в айти.

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

В книге The Pragmatic Programmer, Дейв Томас и Эндрю Хант говорят о применении этого подхода к разработке. Вместо того, чтобы пилить софт пошагово и сразу правильно, сначала нужно создать его каркас, работающий от и до (end-to-end).

Не просто прототип на выброс, а именно каркас. Условно фронтенд на реакте с одним полем в форме и кнопкой, при нажатии на которую триггерится API на бэкенде, который переправляет данные в какой-нибудь легаси сервис, который пишет в базу данных. Всё очень примитивно, но функционально помогает проверить, что данные "текут", политики безопасности работают, технические возможности валидированы. Мы видим, что "пули" летят в верном направлении.

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

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

Меня спросили в комменте типа «не пойдешь в русский тех?»

Я подумал, подумал и наверное пошел бы куда-то пилить API-first продукт для разработчиков как CPO.

Мне пришло понимание, почему я не воспринимаю российский big tech как tech. Для меня весь российский tech кроме Яндекса — это "бизнес с айти", а не "technology".

Я как-то слышал фразу от сотрудника раннего Амазона, что до появления AWS, Амазон по большому счёту был интернет-магазином с отделом разработки.

Только когда Амазон начал создавать новые технологии и платформы — свои ЦОД, электронные читалки Kindle, облачные сервисы, Alexa — он стал по-настоящему технологической компанией. Только тогда непосредственно технологические разработки стали либо продуктом, либо платформой для продукта, которые очень сложно скопировать, не имея технологий.

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

Это крутые бизнесы, но их конкурентное преимущество — в процессах, маркетинге и партнёрствах. Приложения и сайты попросту отражают эти процессы.

Команда сильных программистов сможет скопировать стек Авито, Т-Банк и Озон (смогут ли они достигнуть масштаба — это другой вопрос, скорее всего, нет). Однако, команда сильных программистов не сможет скопировать и создать с нуля поиск Яндекса, операционную систему Windows (Microsoft), LLM (OpenAI), Kubernetes (Google), Lambda (AWS) или фреймворк React (запрещённая соц сеть), когда в мире ещё нет аналогов, которые можно скопировать.

Помимо умения писать код и комбинировать современные технологии в продукт, такие платформы требуют глубокой технической экспертизы в узком домене. И дело даже не в том джун программист или синиор. Требуется другой подход — программисты в компаниях с ИТ-отделами решают прикладные задачи, а в настоящем tech есть группы людей (далеко не все!), которые занимаются computer science и создают то, чем потом пользуются все.

Я был в нескольких митингах с Марком Брукером, создателем AWS Lambda, у которого больше патентов, чем у кого-либо в Амазоне. Сейчас он Distinguished Engineer (его коллеги по цеху в Амазоне, это такие люди как Джеймс Гослинг, создатель Java). Это человек с другой планеты. Он по-другому мыслит.

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

Меня задолбали подписки.

Есть сервисы, на которые не жалко тратиться ежемесячно. YouTube Premium, ChatGPT, Google One, Spotify, Metacast, Bear, 1Password, iCloud, GitHub— я использую эти сервисы почти каждый день и платить за них мне не западло.

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

Сегодня смотрел API для отправки емейлов пользователям SendGrid, Resend, Postmark. У них всех ограниченный бесплатный тариф, а потом сразу скачок на $20 в месяц за базовый план, в который включены десятки тысяч емейлов, которые мне не нужны.

Адекватная стоимость для меня была бы в районе 2-3 долларов в месяц или даже меньше.

Но ценообразование облачных сервисов - хитрая штука.

Слишком много тарифов - пользователь запутается и вообще ничего не купит. Купит у тех, у кого проще.

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

Фиксированные тарифы - как подписки на спортзал.

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

К счастью для вендоров большинство платных пользователей пользуются от силы 20% лимита. Их платежи почти полностью - валовая прибыль (gross margin, выручка за вычетом стоимости инфраструктуры). Так и живут на «сдачу».

В поисках необходимого мне сервиса для отправки емейлов (для подтверждения адресов электронной почты, напоминаний об ивентах и т.п.), я вспомнил про старый добрый Amazon Simple Email Service (SES), который берет по 10 центов за 1000 отправленных емейлов. SES, наверняка, сильно уступает по фичам и удобству SendGrid, но для моего use case они не нужны. А ради более низкой стоимости можно немного потерпеть неудобства на этапе конфигурации.

У меня нет цифр, но я больше чем уверен, что сервис сам по себе убыточный (с учетом стоимости сотрудников для его поддержки), но он является ценным компонентом экосистемы AWS.

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

Потыкаюсь в SES и отпишусь. 5 лет не пользовался AWS. Уверен, что интерфейс за это время стал только хуже 😬

Сегодня целый день потратил на прохождения курса Learn Next.js от создателей фреймворка (компания Vercel).

Курс покрывает создание веб-приложения с данными в Postgres и аутентификацией. Также немного затрагивается TailwindCSS. Для прохождения требуются основы TypeScript и React.

Мне зашло, рекомендую. Голова гудит, но закончил курс за день, почти не отвлекаясь и это меня радует.

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

Вчера оформил платную подписку на ChatGPT Plus за $20. Цена, конечно, кусачая, но ощущение, что я отбил эти деньги за один вечер.

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

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

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

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

Запостил их на LinkedIn. Посмотрим как пойдут.

Также использовал чат для формирования summary эпизода и списка топиков с таймкодами. Я раньше тратил на это не то чтобы слишком много времени, но меня раздражала эта работа, я отвлекался и выходил из состояния потока.

Ещё использовал чат, чтобы разобраться с математическими концепциями из олимпиадных задач. Разница между бесплатной и платной версией - как между BMW и трехколёсным велосипедом. Причем, на русском языке!

Покодить с платной подпиской еще не успел. Жду не дождусь завтрашнего рабочего дня.

Кейс о том, как на первый взгляд простое изменение в UX оказывается весьма непростым из-за технических ограничений.

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

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

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

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

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

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

Этот поезд ушёл. Поэтому работаем с ограничением, которое существует.

С точки зрения UX возникают осложнение, которого не было заметно на поверхности.

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

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

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

Вариантов несколько, один дороже другого.

В итоге мы решили, что на нашем масштабе это edge case и можно пока отложить оптимизацию (есть такой термин "преждевременная оптимизация" (premature optimization) — запомните его, разработчиков бесит, когда продакты его используют).

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

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

@ilyabezdelev_blog #техническийпродактменеджмент

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

Делаете так же?

TIL: Термин «гериатрический миллениал» — человек, рожденный в начале 1980х. Если ты миллениал-гериатрик, ставь 🙈

Зумеры и бумеры могут поставить 😀

Остальные - будьте людьми, ставьте ❤️ в знак поддержки.

Зарплаты айти-специалистов в центром федеральном округе. @banksta

Интересно что здесь нет продакт менеджеров. В России они не считаются айтишниками?

Возвращаюсь к теме кодинга в моей жизни.

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

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

Сегодня утром, когда я гулял по мрачному утреннему Питеру под саундтрек Егора Летова, всё встало по полочкам.

В своей карьере я достаточно рано ушёл от того, чтобы делать работу своими руками, но я всегда искал возможность что-то запилить — писал запросы в SQL, создавал разного рода дашборды с нуля, делал сайты для себя и на сторону. Это удовлетворяло потребность в созидании.

Плюс, я много времени уделял музыке. В моей взрослой жизни было 3 года, когда я каждый вечер и выходные сочинял и записывал музыку, занимался вокалом, играл в группе.

А потом настала точка, после которой я потерялся.

В 2018 году, родился мой младший сын. Жизнь встала вверх ногами. Я бросил музыку. Я стал уделять меньше внимания работе + работа стала более интенсивной (мы запускали AWS Chatbot в 2019), и я перестал работать руками от слова совсем.

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

Последние 6 лет меня просто захлестнуло хаосом. В круговороте дел я стал больше "управлять" (a.k.a. "выгребать") и меньше "делать" вопреки своей природе.

Месяц назад моя психика сказала "хватит" и сказала "созидай-ка ты 100% времени". И таким образом произошло возвращение к корням.

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

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

В конце туннеля всегда есть свет. Даже если туннель — это впадина, рано или поздно вы упрётесь в дно, развернётесь и пойдёте обратно к свету.

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

Питер в 16:00 👇🏻

Добрые люди: Ты взвоешь в Питере зимой без солнца.

Я: Я жил в Сиэтле 7 лет, меня таким не напугать.

Питер в 9 утра: 👇🏻

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

Накидайте каких-нибудь смешных мемов в комменты что ли.

Тем более, я вас скоро оставлю тут одних на две недели. Давайте расставаться на веселой ноте.

Теперь обращаю внимание кто использует мебибайты.

Скрин из npm

Читаю отзывы на внешний жесткий диск на Озоне. Сначала поржал, а потом узнал что-то новое для себя.

Задуматься заставил коммент про двоичную систему. Я поржал над формулировкой, но при этом понял, что автор хотел сказать — производители считают террабайт как 1000 гигабайт, а гигабайт как 1000 мегабайт, что "съедает" объем.

Я знал что есть разница между MiB и MB, но я всегда думал, что мебибайты — десятичные, а мегабайты — двоичные.

Оказалось, что правильные термины для "двоичных" размеров — мебибайт (MiB), гибибайт (GiB), тебибайт (TiB).

Но операционные системы испокон веков называли двоичные единицы объема мегабайтами, гигабайтами и террабайтами. На скрине в Озоне Windows использует ГБ, а на втором скрине мой MacOS показывает объем диска в GB.

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

Я всю жизнь считал, что производители HDD просто читеры-округлятели и что мегабайт = 1024 кб.

TIL что мы все (все же??), начиная от программистов до производителей ОС, неправильно используем термины.

Одни только производители "винтов" используют их правильно. А мы обманываться рады.

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

Никто мне не рассказал про git. Сам я его не нашел.

Git - это как микро-сейвы в играх. Убил монстра - сохранился.

Попробовал убить, но он тебя ранил? Сделал load из сохраненки, попробовал снова. И так итерация за итерацией.

Я же кипятил море кипятильником. Гигантские кодовые базы без VCS (version control system) заставляют думать по-другому. Всё нужно сделать сразу правильно. Ничего полноценно не откатишь.

А я люблю делать быстро и тяп-ляп, чтобы проверить в правильном ли направлении иду. Git для этого идеален.

Была бы моя воля, я бы внедрил git во все аспекты жизни.

Это всё сопровождается ощущением, что я реально делаю что-то МОЁ.

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

Психую, когда что-то не получается. При этом понимаю, что это легко фиксится знаниями.

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

Я схватываю всё на лету. Так было всегда. Ну, кроме рекурсии и указателей в C…

В 41 год пришло ощущение, что пора вернуться к истокам. Весь 2024 год — про возвращение к корням.

Охренеть же.

Посмотрим продержится ли это до утра. А пока перед сном почитаю The Pragmatic Programmer.

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

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

Тупо не знал что читать и делать, чтобы стать лучше.

Конечно, я уже не буду работать миддл кодером на кого-то. Деньги не те, да и подчиняться продактам и миддл менеджменту я бы не хотел.

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

Остаётся работать над своими проектами и может позже в карьере метнуться куда-то на СТО. Как крайний вариант — отвечать за продукт в каком-нибудь глубоко-техническом продукте для разработчиков, где можно кодить, чтобы потестить.

Уже спросил у Арнаба и Джона Крикета (крутой знакомый чел, который учит программистов в UK) посоветовать книги по паттернам. Буду нагонять упущенное.

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

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

Кто-нибудь разобрался как отказаться от ВСЕХ подписок Т-Банка разом?

Меня уже два раза отписывали от рассылок и звонков через чат, но в почте вот так. Чистый инбокс для меня важнее запаса икры.

Потом я пошёл в кофе-шоп работать.

Прямо на выходе меня попросили поменять батарейку в таракане-роботе. Не смог найти батарейку. Пришлось распечатывать раскраску на принтере.

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

Мамин сон — это святое.

Потом началась срань. Я пропустил из-за чего, но там было всё начиная от взаимных оскорблений и заканчивая пинками.

Миддлу, который только-только получил повышение, доверили делать code review джуна, который тоже хотел повышения.

Потом младший заявил, что тоже не хочет есть.

Другой джун увидел, что коллеге дали поблажку. Но опыта ещё не хватает, чтобы понять разницу в задачах.

Ничто так не прокачивает софт скиллы, как стресс и непредсказуемость родительства.

Кейс сегодняшнего утра:

Старший сказал, что не хочет есть на завтрак гречку и попросил чего-нибудь сочного.

Первая мысль: у нас чё тут ресторан?

Вторая: Ты же будешь голодный в школе.

Вслух: Тебе огурцов порезать?

За кадром: вспомнил себя в 12 лет. Тебя подняли в 8:30 утра в школу. На улице ещё ночь. Есть вообще не хочется.

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

(Я сам съел гречку 🤷‍♂️)

Был ещё и P.S. - гречку с вечера придумала жена и возмутилась, что она была не съедена.

Кейс реальной жизни: продакт, не участвующий в разработке.

У меня на языке вертится песня SOAD, где есть упоминание "blue sky", но я не могу вспомнить её названия.

Обратился к ChatGPT за помощью. Как можно видеть на скриншоте, в песне этих слов нет. Когда я сказал ему, что там нет таких слов, он сказал "You're right!"

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

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

Зарегался на Bluesky. Наш build-in-public контент на английском теперь будет там. Там есть ощущение комьюнити среди инди-хакеров и бутстрапперов.

От LinkedIn с его инфлюенсерами и политически заряженного X уже все устали. Threads с его алгоритмической лентой таким как мы тоже не зашел.

Мой профиль: https://bsky.app/profile/ilyabezdelev.bsky.social

Оффтоп: питерские троллейбусы делают звук «пиу-пиу» как в звездных войнах на морозе.

Подняли мне настроение с утра!

Разработчиков передергивает, когда кто-то говорит, что фичу сделать "легко" или что фича "простая".

Можно разобрать кейс «простой» фичи на примере кликабельных таймкодов в моем приложении. Казалось бы, что тут сложного? Откуда 37 коммитов, 500 строк изменений, 173 коммента на пулл-реквесте и конфликт с СТО?

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

Мы выбрали пойти по простому пути и сделать всё на фронте. Но всё равно вышло 500 строчек кода изменений. Где мы недооценили сложность "простой фичи"?

Задача была в следующем — если видим в описании эпизода текст в формате (HH:)MM:SS, это таймкод. При нажатии на таймкод, играем эпизод с этого времени.

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

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

1) Пришлось дополнять и рефакторить виджет, который отображает описание эпизода.

а) Та-дааам... Типичная и очевидная проблема — виджет не "знал" ID эпизода, без которого не создашь ссылку. Пришлось добавлять дополнительные параметры и передавать их в виджет извне.

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

2) Пришлось рефакторить валидацию таймкодов в уже существующем модуле, который мы используем в другом месте. Там столкнулись с другими сложностями. Не хочу утомлять деталями (было связано с null safety в языке Dart), но с первого раза это не сработало, пришлось откатывать рефактор обратно и писать отдельный валидатор.

3) Столкнулись с похожей проблемой в генерации внутренних ссылок. Пришлось рефакторить другой модуль.

4) Пришлось измененять то, как мы открываем ссылки. Раньше все ссылки открывались во внутреннем браузере, а mailto: ссылки открывались в почтовом клиенте.

а) Таймкоды мы заменили ссылками в определенном формате и их нужно было перехватывать, чтобы открывать внутри приложения. Пришлось писать "перехватчик" (handler).

б) Так как описание эпизодов подкастов может содержать ошибки, нужна дополнительная валидация ID.

в) При нажатии на таймкод, поведение отличается:
— Если эпизод уже играет, нам нужно просто поменять позицию воспроизведения в плеере.
— Если эпизод не играет, нужно сначала загрузить эпизод в плеер, а потом уже поменять позицию воспроизведения.

Вот так.

Поэтому никогда не стоит говорить разработчику, что что-то "просто". Лучше спросить "как ты оцениваешь сложность?" а потом внимательно слушать.

И всё ради вот этого - в Metacast теперь можно кликать таймкоды в описании эпизода и прыгать на интересный кусок подкаста.

Фича пока в бете. Выкатим через неделю.

Итог «простого изменения» ради быстрой фичи:
- 500 измененных строк кода в 8 файлах
- 36 коммитов
- 173 комментария (самое большое из всех наших PR за полтора года)
- 2 часа на телефоне
- Неучтенное количество сообщений в чате
- Неделя календарного времени

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

Есть поговорка — “when in Rome, do as Romans do” — в Риме делай как Римляне.

Наверное, из-за того, что мне в жизни приходилось очень много переезжать (10 квартир и 3 школы к 16 годам), я научился очень хорошо подстраиваться под среду.

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

До сих пор себя за это прощаю 🙈

Сложные разговоры с разработчиками

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

Фича была в OKR на ноябрь как "stretch" — это означает, что мы делаем её только если мы закончили всё, на что мы закоммитились. Но я решил всё равно её запилить заодно с другой фичей в том же файле...

Это всего лишь несколько строчек кода, у меня пара часов до конца рабочего дня... What could go wrong??

Мы оба согласились, что фичу лучше было запилить в другом месте (на бэкэнде вместо фронтенда), но упёрлись в камень преткновения.

Суть разногласия можно свести к фундаментальному принципу "что мы приоритизируем — скорость релиза или правильность кода?"

Его поинт был в том, что, добавляя лишний код на фронт, мы делаем код приложения сложнее, чем нужно. Это в свою очередь создаёт проблемы при тестировании и обновлении зависимостей (в прошлый раз он потерял 3 дня на обновления, сломавшие приложение).

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

СТО: На бэкенде это почти так же легко, как на фронте. Почему сразу не сделать правильно?

Я: "Просто" зависит от того, кто делает имплементацию. Для тебя это просто, но ты занят другими, более приоритетными и сложными задачами. Я почти не писал код для нашего бэкенда и мне подтребовалась бы минимум неделя + твоя помощь, чтобы это сделать. Твоё время очень ценно и я не хочу тебя отвлекать.

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

СТО: Но это усложняет фронтенд... (мы начали ходить кругами)

Я: Этот код будет легко вырезать и заменить новым на бэкенде.

СТО: Зачем это нужно, если можно сразу сделать правильно?

Я: Но я уже сделал как сделал. Код на 90% готов. Давай шипнем уже.

СТО: Ок, но сделай X, Y & Z.

Я: Ок.

Этот диалог занял почти час с различными ответвлениями и эмоциональными реакциями.

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

Работая со мной, мой СТО испытывает давление по скорости имплементации. Мы — не Амазон, где можно годами обтачивать код напильником. Нам нужны пользователи, готовые платить за ценность. Если бы мы оба были перфекционистами, мы бы до сих пор ничего не запустили в проде.

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

@ilyabezdelev_blog #разработка

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

У меня есть подруга, которую чуть не выслали обратно в Россию, после того, как её команда пожаловалась на неё в HR в Великобритании. Ей повезло, что это закончилось тем, что компания наняла ей коуча, благодаря которому она смогла увидеть свои неадекватности и вырасти.

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

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

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

За последний год я вынес для себя, что для стартапов не подходит ни тот, ни другой подход.

Токсичная "справедливость" разрушит отношения с кофаундером и первыми сотрудниками. Все и так в постоянном стрессе. Надо друг друга поддерживать.

"Нежный" подход слишком долгий. Люди не всегда с первого раза понимают суть такого фидбека, а на повторение нет времени.

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

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

"Мне не нравится, потому что..."

"Я прямо скажу, что я категорически не согласен, потому что..."

"Давай не будем тратить на это время, надо по-другому, потому что..."

Моё второе правило — не обвинять. Мы все совершаем ошибки. Когда кто-то прав — "ты прав", когда кто-то накосячил — "мы косякнули". Мы все в одной лодке.

Третье правило — взаимное уважение. Не повышать голос, не выказывать презрение, сдерживать раздражение.

Четвёртое — контекст имеет значение. Иногда человек в раздрае (у всех есть жизнь помимо работы) и давить на него "честностью" — не лучший вариант.

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

Большинство проблем решаются сами по себе, если их активно не решать.

@ilyabezdelev_blog #софтскиллы

Нужен совет от гиков по рабочим местам.

В Штатах у меня был монитор Dell 27" (не изогнутый). Меня в принципе всё устраивало. В офисе был Dell 32" изогнутый, мне не зашёл его размер. Не люблю крутить головой. По той же причине мне не зашла работа на 2 мониторах.

Хочу купить монитор. Выбор между двумя 27-дюймовыми самсунгами — G5 (изогнутый) и G3 (обычный плоский).

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

Мой основной юзкейс для монитора — экран поделённый пополам.

1) Слева IDE, справа терминал и симулятор/браузер с приложением.

2) Слева браузер с таблицами, справа среда для SQL.

3) Слева среда обработки аудио, справа браузер с гугл доком для заметок.

4) Слева Google Meet, справа гугл док с заметками.

Я не совсем представляю как это будет выглядеть на изогнутом 27" мониторе.

P.S. Не хотелось бы тратить слишком много.

Я почти созрел на платную подписку на ChatGPT. Пользуюсь им каждый день для написания кода.

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

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

Когда увидел «мы всё переделали», мне захотелось ответить «уже боюсь!»

«Все переделали» обычно кайф только для разработчиков самого приложения. Какой разработчик не любит рефактор?

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

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

Интересно в целом вы как пользователь как бы отреагировали на «мы всё переделали» в приложении, к которому вы привыкли?

У меня кровь в жилах стынет.

P.S. Я об этом уже писал. Создатель Overcast до сих пор разгребает последствия редизайна.

Критерий для выбора CTO — он способен указать разработчикам Flutter на конкретную строку их кода с багом.

Он не знает, что я слежу за этим и охереваю, проникаясь к нему ещё большим уважением как к специалисту.

В корпорации есть два типа людей:

1) Те, что оптимизируют рост. Херачат, играют в политику, подстраиваются под культуру, становятся частью культа.

2) Те, что оптимизируют, чтобы их не уволили. Делают минимум, играют в политику, подстраиваются под культуру, становятся частью культа, херачат только при возникновении опасности.

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

В корпорации не нужно 100% инициативного персонала. Кто-то должен сидеть на веслах.

С 2009 года я практически не читал книги и статьи на русском языке, переключился полностью на английский.

Я всегда думал, что быстро читаю на инглише, но как-то раз мы вместе с сыном читали книгу и он читал раза в полтора быстрее меня. Я офигел. Жена даже думала, что он придуривается…

Когда вернулись в Россию, меня сильно потянуло на литературу на русском. Сразу заметил, что читать очень комфортно и я читаю на русском не медленнее, чем мой сын на английском.

Потом настал момент истины.

На днях начал читать Neverwhere Нила Геймана (на русском Никогде) и прочувствовал разницу.

На русском я как рыба в воде. Только успеваю перелистывать страницы.

На английском я как пловец-спортсмен. Быстро, но требуются усилия.

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

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

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

На русском всё буду только читать.

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

Ребенок попросил показать как я выглядел в 18 лет. Смотрели старые фотки и свело олдскулы. На этой фотке меня нет, это мои друзья. Я фотографировал их мультиплеер. Не могу вспомнить, что это за игра.

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

1) С утра не за что было схватиться едва продрав глаза.

2) Пришлось его поставить на зарядку минимум минут на 30, что даст время спокойно приготовить завтрак и даже поесть в кругу семьи.

Не благодарите.

P.S. Это, конечно же, непрактично… Хотя кто знает. На эти мысли меня натолкнуло отсутствие розетки рядом с кроватью и встал выбор: поставить телефон заряжаться далеко от ложа или же дать ему разрядиться и зарядить утром?

Фокус, фидбек и раздражение

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

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

Меня всегда бесило, когда, выкроив пару часов на покодить, мой СТО Арнаб присылал code review со 100500 комментариев, на которые у меня уходило ещё полдня, а то и больше.

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

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

Сейчас, я дал себе месяц не заниматься ничем кроме кодинга и очень сильно поменялось отношение к фидбеку и к Арнабу.

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

Я даже получаю удовольствие от хирургически точечного рефакторинга!

То же самое происходило когда я писал продуктовые документы, работая в Гугле и Амазоне.

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

Потом так же выделял полдня-день на работу с фидбеком. Накапливал обратную связь и садился писать следующую итерацию.

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

Now playing: Skid Row - Slave to the Grind

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

Инструкции для отзывов в Авито, наверное, написаны по тому же принципу 🙈

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

Я 15 лет не жил в России и пропустил всё развитие интернет-сервисов. Некоторые вещи меня до сих пор шокируют.

Инсайт дня — для фаундера с СДВГ ранние стадии стартапа это 🔥, потому что все и сразу, видение, идеи и т.п. Средняя стадия стартапа, когда везде пожары — это бесконечный стресс.

Природа СДВГ такая, что, чем больше хаоса, тем он более парализующий и, как следствие, тем больше хаоса и так далее. Бонусом тревожность, что приводит к ещё большему бездействию в хаосе.

Это спираль вниз.

Я решил попробовать эксперимент на ноябрь.

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

Посмотрю как это будет отражаться на самочувствии.

Accessibility a.k.a. a11y

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

— Людям с ограниченным зрением (в т.ч. слепым) нужно иметь возможность включить огромный шрифт и использовать скрин-ридеры для навигации.

— Людям с ограниченным слухом нужны субтитры и незвуковые индикаторы действий (вибрация и вспышка например).

— Людям с дальтонизмом нужна другая цветовая гамма.

— Люди с травмами рук или отсутствующими пальцами/кистями не смогут воспользоваться некоторыми горячими клавишами (по этой причине Microsoft убрал раскорячистое сочетание Ctrl-Alt-Del) или даже мышкой/трекпадом.

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

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

Крупные компании уже делают accessibility обязательным требованием для своих новых продуктов и вкладываются в переделку старых. Но что делать стартапам и маленьким компаниям, у которых нет ни ресурсов, ни понимания, как надо?

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

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

Мне кажется, это займет ещё лет 10. Время есть, но начинать об этом думать стоит уже сейчас.

@ilyabezdelev_blog

Субботний оффтоп / изучаем английский с моим старшим сыном-нэйтивом.

Вчера смотрели вместе Star Wars VIII и я узнал от него новое выражение — “plot armor”, дословно “броня сценария”.

Плот армор происходит, когда героев вот-вот должны убить, но тут же из ниоткуда появляется кто-то, кто их спасает, на злодеев рушатся стены и т.п. Они спасены сценаристом.

В Звездных Войнах, снятых Диснеем, этого так много, что даже 12-летний пацан морщился и говорил, что это кринж.

Зная, что главный герой не может погибнуть в принципе (в конце концов, она же должна быть в 9-й части), начинаешь смотреть фильм более скептически. Типа «ну да, сейчас прилетит волшебник в голубом вертолете…» Саспенс пропадает.

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

Другая крайность — это фильмы-безнадеги, например, Дорога перемен с ДиКаприо и Уинслет. Они более правдоподобные и больше цепляют. Правда, их не посмотришь с детьми.

Может, Стар Ворс стал детским фильмом?

Оффтоп: Залип на ютубе на интервью с известными людьми. Этих ребят сразу даже не узнал. Не мог не заскринить.

Такой пацан из 90х и его партнер из фильма «Гений».

Сможете угадать кто это, перед тем как узнать в этих мужичках Limp Bizkit?

10 лет после окончания Wharton, стоил ли MBA времени и денег?

Пришло приглашение на встречу выпускников по случаю 10-летия выпуска моего класса в Wharton. Это заставило порефлексировать о том, что же мне дала бизнес-школа с позиции времени.

1) Работа в американском бигтехе. Бизнес-школа дала возможность с лёгкостью получить работу в Амазоне. Работодатели сами за нами гонялись.

2) Погружение в американскую культуру small talk и нетворкинга. Это было некомфортно, больно, но того стоило. Это привело меня в том числе к психотерапии.

3) Погружение в американскую hustle culture, где все е.ашат и конкурируют за место под солнцем (улыбаясь друг другу фейковыми улыбками, я тоже так умею).

4) Навык анализа огромного объема сложной информации. Я каждый день читал страниц по 80 разного рода статей, кейсов и научных публикаций просто чтобы сделать домашку и подготовиться к обсуждениям в классе. Я никогда в жизни ни до, ни после столько не читал.

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

6) Расширенный взгляд на жизнь. Одна из моих лучших подруг в школе (от слова "друг") была девушка с синдромом Аспергера. Она сдала GMAT на недостижимые простому человеку 800 баллов и решала в уме дифференциальные уравнения. Социально она была весьма сложная. С ней я научился лучше принимать людей.

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

8) Нетворк. Все, кто никогда не учился в бизнес-школе, в первую очередь говорят про нетворк. А вы попробуйте его постройте в чужой культуре, будучи интровертом. Я не могу сказать, что у меня сильный нетворк из Вортона. Я могу написать любому выпускнику, но я пользовался этой возможностью не более раз 10.

В итоге, стоило ли это того? 100%.

Стоит ли тебе идти на МВА? Нет однозначного ответа. Ты же не можешь заглянуть на 10 лет вперёд и посмотреть, где ты окажешься.

@ilyabezdelev_blog #mba

Апгрейды инструментов для разработчиков

Если кто-то из вас здесь работает над тулзами для разработчиков — IDE и SDK — не делайте то, что делает Apple.

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

Обновление 8 гигов, только скачивание и установка могут занять минут 15-30, после чего у нас при разработке на Flutter обычно что-то ломается и не работает с первого раза. Приходится чистить кэши, читать stack overflow и танцевать с бубном.

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

Понятно, обновления нужны и не всегда всё проходит гладко.

Косяк Apple в том, что они тебя заставляют обновляться не тогда, когда это удобно тебе, а по их расписанию. Например, когда ты привёл ребёнка на спортивную секцию, где нет интернета и хотел часок покодить...

При установке обновлений любого характера, а особенно для тулзов, мне нравятся паттерны:

— Пропустить версию (skip this version). Даёт тебе возможность доработать на текущей версии и обновиться в будущем, если тебе будет удобно.

— Установить на следующем запуске (install at next launch). Все обновления скачиваются и подготавливаются автоматически, но устанавливаются только при следующем перезапуске приложения.

— Установить ночью (install at night). Такое я видел только на уровне операционной системы. Очень удобно, когда софт может обновиться ночью. Главное, чтобы утром не было такого, что нужно что-то нажать, чтобы продолжить, и застрять ещё на полчаса, пока обновление не завершится.

Этика в продакт менеджменте

Как-то наткнулся на пост в Линкедин, который восхвалял порносайт Only Fans. Автор писал что-то из серии «это конечно п.здец, но как продакты они супер крутые. Смогли найти лазейку в психологии людей, эксплуатируют её в свою пользу и сделали выручку $1,3 млрд в 2023.»

Типа, а че такого. Люди падки на такой контент и они этим воспользовались.

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

Почему я это вспомнил и какое отношение это имеет к продакт менеджменту?

На подкасте Diary of a CEO вышел эпизод про порнографию и её влияние на людей, особенно, мужчин и отношения в парах.

Вот что я для себя вынес про эксплуатацию и негативное влияние на общество:

— Молодые люди все чаще прибегают к порнографии вместо того, чтобы найти партнершу.

— Короткое порно используется как механизм для выработки дофаминов. От этого вырабатывается зависимость.

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

— На сайтах, где порноинфлюенсеры разговаривают с аудиторией типа Only Fans, у людей вырабатывается так называемая парасоциальная связь («односторонняя дружба»). Появляется эмоциональная связь, которой не было с неинтерактивной порнографией, из-за чего рушатся отношения в реальной жизни.

— На этих же сайтах используются AI боты, которые подсаживают потребителей на дофаминовую петлю. В крайности бот ведет себя как настоящая девушка, может обидеться, манипулировать и т.п.

Были и другие моменты, я не буду их все перечислять.

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

Оптимизация продуктов на локальный максимум (метрики, которые вы отслеживаете) может иметь колоссальный эффект вовне. Это называется negative externality.

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

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

Поэтому нужно регулирование со стороны государства.

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

Продукты создают люди. Такие как мы с вами. И всегда встает вопрос — на что ты готов ради денег?

#дружескийпиартайм

Хочу порекомендовать канал Продукторий Владимира Меркушева, экс-продакта из Avito, Yandex и других компаний. Если вам нравится, когда всё кратко и по делу, мне кажется, вам зайдёт.

Посты, которые были интересны лично мне:
— Когнитивные искажения продакта - прям жиза из жизни продактов, живущих инстинктами и рефлексами вместо анализа и метрик.
— Об онбординге в новый домен - как не утонуть в море информации и подойти к онбордингу как к процессу.
— Ключевой фактор при выборе работы для продактов - краткая выжимка опроса 5000 продактов Ленни Рачитского (The Lenny's Podcast/Newsletter). Вывод - самое важное в новой работе - это стабильная зарплата, а не доля в компании.

Спалю контору — с днём рождения меня 🎉

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

Такова жизнь. Каждый должен пройти свой путь. Наломать своих дров.

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

Моя задача — провести его через становление. Помочь. Направить. Моя цель сейчас — объяснить ему, что заточенным топором дрова колоть куда легче.

В этом была моя трансформация из 20-летнего в 40-летнего. Фокус сместился с себя на других. С брать на давать.

Мне 41. Начался пятый десяток. И ощущение, что это новый, качественно иной этап. И нет сожалений ни о чём, особенно, о том, что что-то не попробовал.

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

Ещё 40 лет вот этого? Зачем тогда вообще жить?

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

Впервые за 41 год у меня ощущение, что я дома. И это был лучший подарок именно к этому дню рождения 🦂

ПАЛКА О ДВУХ КОНЦАХ

На заре моей карьеры, когда я работал в DHL в нулевых, мне очень повезло — я работал в очень сильной команде дата аналитиков, которые научили меня моделировать структуры данных для анализа и создавать трёхэтажные SQL-запросы.

Благодаря им, у меня сложилась модель того, как "правильно". Правильно — это создать структуру данных с максимальным количеством выверенных деталей, а потом уже из неё строить отчёты.

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

Это позволяет не просто считать KPI, но и почти мгновенно углубиться в них и выяснить причины задержек. Можно даже взять номер накладной и скинуть его конкретному человеку на месте, чтобы он объяснил, что происходит.

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

Это работало реально круто и я неоднократно применял этот подход в будущей работе.

Я мало об этом рассказываю — первый год в Амазоне я вместе с Арнабом, моим нынешним кофаундером, создал внутреннюю систему для анализа поведения пользователей в веб-админке AWS. Там я продолжил оттачивать методологию из DHL, анализируя данные по использованию облачных сервисов.

Я начал делать то же самое в Metacast, но быстро понял, что делать аналитику "правильно" требует времени, которого у нас в стартапе просто нет. Данные из Firebase+Google Analytics в кривом формате, какие-то события попросту теряются из-за наших собственных багов и у нас нет инфраструктуры для создания дата пайплайнов (и нет желания и денег сейчас что-то прикручивать).

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

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

Недаром есть выражения "старую собаку новым фокусам не научишь" и "old habits die hard". Бывает очень сложно отойти от устоявшегося подхода и начать делать то, что всю жизнь считал браком и ленью.

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

Оффтоп-высер...

В РФ я уже неоднократно сталкиваюсь с т.н. "техническими причинами", которые прикрывают косяки поставщика и ровным счётом ничего не объясняют мне, как покупателю.

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

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

Когда они позвонили назначить встречу в третий раз, у меня уже пропало желание пользоваться услугами этого банка. Я предложил им как-то компенсировать неудобства. Например, подарить мне этот стикер бесплатно, на что мне ответили, что это нужно решать с горячей линией.

Стикер стоит всего-ничего — 700 рублей (7 USD). Мне не жалко, но я хотел проверить насколько в процессах банка заложена клиентоориентированность и ответственность за свои (повторяющеся) косяки.

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

Наткнулся на функцию планирования смерти в iOS. Очень удобно.

Весь наш семейный архив фото хранится в моем iCloud. Жалко будет потерять в случае чего.

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

Когда я проводил собесы в Амазоне и Гугле, я всегда говорил, что мы ищем в кандидате, перед началом интервью.

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

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

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

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

Может возникнуть справедливый вопрос — если сказать кандидату слишком много, он же "адаптируется" и будет придумывать на ходу?

Для этого есть защита, заложенная в процесс интервью.

В Амазоне на часовом интервью мы можем фокусироваться всего лишь на 2-3 вопросах по опыту. Это значит, что мы будем копать очень глубоко в один-два кейса.

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

@ilyabezdelev_blog #карьера

Та же концепция в графическом виде от моего товарища Джона Крикета.

1) Делать хорошо недостаточно.
2) Нужно себя продавать.
3) Но и не забывать делать хорошо.

Now Playing: Dreaming by System of A Down

Чем быстрее вы поймете, что ваша работа не говорит сама за себя, тем быстрее вы начнёте расти. По-другому в организациях это не работает.

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

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

Одно другому не противоречит, а помогает.

В любой организации всё всегда строится на взаимоотношениях.

Компании не апрувят документы. Их апрувят люди.

Компании не покупают продукты и не заключают сделки. Их заключают люди.

Компании не нанимают людей на работу. Их нанимают люди.

Не забываем об этом.

Я представляю продактов, которые защищают такие фичи тем, что они приносят конверсии и деньги.

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

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

Места на воркшоп по Амазоновской методологии Working Backwards закончились.

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

Лист ожидания.

У меня осталось 4 места на завтрашний воркшоп по Working Backwards.

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

Вот так он должен был выглядеть.

Я вообще с опаской теперь покупаю на Озоне. Куча подделок и брака.

Вот он. Источник детских слёз.

Рейтинг моих нелюбимых и любимых российских приложений.

Нелюбимые приложения:

— В Сбере и Т-Банке я только перевожу деньги. Мне не нужны вообще никакие другие функции, особенно бесконечные уведомления и мегамаркеты. Говорят, у нас самый классный финтех. Наверное, стоит добавлять "был"? Не считая удобства переводов по СБП, мне больше нравится приложение Chase Bank.

— Внутри Озона есть банк 🤯 В него я периодически попадаю, нажав на уведомление о том, что возврат товара зачислен обратно на Озон Карту. На Озоне куча говна. Сегодня ребёнку доставили мягкую игрушку, у которой голова пришита вверх ногами... Были слёзы, сопли и возврат.

— Яндекс Гоу... можно я просто вызову такси, а? Мне не нужна ни лавка, ни скамейка из маркета.

Любимые приложения (конечно же, однозадачные):

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

Принимаю рекомендации.

Когда я только вернулся в Россию, я писал, что меня бесят супер-аппы. До сих пор подбешивают, но я стал чуть лучше понимать их подноготную.

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

Условно, раньше продавали всем подписчикам рингтоны и викторины по СМС, а теперь у МТС можно даже сервер арендовать. Деньги есть, пользователи есть, авось что-нибудь да выстрелит.

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

Таким образом, мега-апп отталкивается не от удобства для пользователя, а от организации бизнеса и общества в целом.

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

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

Я не говорю, что в мега-аппах нет ценности. В них есть ценность за счёт экономии денег. Тот же Яндекс+ даёт доступ ко многим разным ништякам, но удобно ли то, что в Яндекс Гоу можно заказать продукты на дом? Я не уверен.

Утрировано, но жизненно. Анти-икигай.

Начало 👆🏻

Когда вопросы заканчиваются, у нас четыре потенциальных исхода: 1) аппрув, 2) условный аппрув — всё норм, но нужно добавить инфу, которую попросили, 3) нужно доработать и прийти снова и 4) отклонено.

4️⃣ Финализация документа

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

@ilyabezdelev_blog #продактменеджмент #бигтех #amazon

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.6: Ревью документов

Предыдущие части про культуру создания продуктов в Amazon: 1, 2, 3, 4, 5.

Самое любопытное для новичка в Амазоне — это то, как проходит ревью документов.

1️⃣ Формат документа

Если люди встречаются в офисе — документ распечатывается. Документ может запросто быть 50 страниц со всеми приложениями. Ты распечатываешь сотни страниц в нескольких экземплярах и сшиваешь их. Это такая медитация, занимающая полчаса. И не дай Бог найти ошибку, которую ты хочешь исправить перед презентацией...

Если люди встречаются онлайн (или кто-то звонит на митинг, проходящий в офисе), у них есть электронная копия документа в приложении, где можно оставлять комменты. В моё время Амазон использовал свой собственный сервис WorkDocs и тул Quip от Salesforce. Не знаю чем они пользуются сейчас. Идеальные тулы для таких ревью — Google Docs или Microsoft Word 365, но Амазон не пользуется облачными инструментами конкурентов.

2️⃣ Чтение

Ревью длится 1 час. Первые полчаса все сидят в тишине и читают документ.

Если кто-то начинает комментировать, на него коллективно шикают. “Тишина! Идёт ревью!” Шикнуть могут даже на VP. Такое иногда бывает, если человек новенький в культуре и ещё не стал частью культа. Новым людям некомфортно полчаса сидеть в тишине. Во всех других компаниях митинги — для того, чтобы “тереть” и спорить. В Амазоне не так.

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

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

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

У меня обычно во время ревью с руководством сводило спазмами живот 🙈

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

3️⃣ Обсуждение

Когда люди заканчивают читать, начинается обсуждение.

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

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

Все обсуждения максимально объективны и справедливы. Люди стараются использовать данные и не говорить голословно (это часть культуры). Никто не спорит в сердцах, никого не оскорбляет и не говорит субъективные суждения. Если в группе Амазоновцы со стажем, то любая дичь будет сразу же пресечена.

Когда тебе задают вопрос и ты не знаешь ответа, все ожидают, что ты скажешь “я не знаю, дам ответ к такому-то числу”. Никого не интересует твоя сообразительность на месте. Булшит видят сразу и пресекают в корне. Не знать — нормально, пытаться выкрутиться — нет.

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

Продолжение 👇🏻

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.5: Иерархический процесс ревью

Читайте предыдущие части про культуру создания продуктов в Amazon: часть 1, часть 2, часть 3, часть 4.

Каждый PRFAQ проходит множество итераций и несколько раундов ревью. Любой более-менее важный документ идёт на уровень твоего менеджера + 1. Особо важные документы идут вплоть на уровень VP, SVP и даже CEO (я напишу о своём опыте презентации Энди Джесси, нынешнему СЕО Амазона, в отдельном посте).

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

1️⃣ Как правило, первую версию PRFAQ ты показываешь людям из своей “двух-пиццевой команды” — менеджеру команды разработки, техническим лидам, дизайнеру. Если PRFAQ влияет на другие продукты, то также вовлекаются смежные команды и зависимости. Если работаешь над платформой, то на самом раннем этапе вовлекаешь команды, которые будут зависеть от этой платформы.

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

2️⃣ Далее обычно идёт ревью с твоим менеджером. Это может быть руководитель продуктовой команды или руководитель руководителей разработки (об орг. структуре тоже напишу позже). На это ревью в том числе приглашаются менеджер разработки, тех лид, дизайнер, другие продакты из команды (если им это релевантно), принципал продакт менеджер организации (моя последняя роль в Амазоне) и принципал инженер.

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

3️⃣ Следующее ревью, как правило, происходит с директором (это около 100 человек в подчинении, включая разработку и продактов). На этом ревью обычно присутствуют большинство тех, кто был на предыдущих — руководитель продактов, менеджер разработки, его менеджер, принципалы и зачастую тех лид команды, отвечающей за разработку. На таком митинге может запросто быть 10-12 человек.

Для большинства PRFAQ на этом всё заканчивается.

4️⃣ Далее идёт ревью с VP (как правило, 1000+ человек) и выше. На таких митингах может быть до 20 человек, включая всех руководителей и директоров по линии продукта, разработки и дизайна, руководителей смежных организаций и т.п. На этом этапе также могут быть приглашены юрист, финансист и маркетинг.

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

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

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

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

👉🏻 Шестая часть

—
Ещё можно вписаться в воркшоп по созданию продуктов по методике “Working Backwards” компании Amazon в эту субботу 26 октября. Осталось 12 мест.

@ilyabezdelev_blog #amazon #продактменеджмент #бигтех #amazon

👆🏻👆🏻👆🏻
Так, кстати, появляется легаси, если его потом не чистить.

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

У нас с командой только что был очень важный разговор.

Для создания новой фичи в Metacast, мы меняем структуру данных, на которой держится одна из уже существующих фич.

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

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

Казалось бы — супер, всё хорошо, изи...

Не так быстро. Есть нюансы.

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

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

Второй вариант — более понятный и лёгкий.

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

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

Второй вариант проще для разработчиков, но хуже для пользователей.

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

Они стали смотреть данные — кто на какой версии и как они обновляются. Я сказал, что это неважно. Мы знаем и так, что некоторые отключают автоматические обновления (я это видел в гугле работая над мобильными SDK — некоторые пользователи Андроида не обновляются месяцами, это боль!)

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

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

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

@ilyabezdelev_blog #техническийпродактменеджмент #мобильнаяразработка

Прикольное интервью с Токовининым у Глеба Соломина. Забавно, как в некоторых местах это звучит как разговор 20-летнего с 40-летним, где 40-летний не стесняется на это указать.

Веселая часть, где Соломин говорит, что «20-летние более эффективные», а Токовинин ему в ответ «у них полно энергии, но они ничего не умеют».

Я перестал играть и у меня тут же нашлось время на бег 🏃‍♂️

Когда ты геймозависимый (на мобильнике), ты начинаешь внедрять в жизнь неэффективность.

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

По отдельности это все выглядит незначительным, но имеет серьезный эффект.

На коротком горизонте, ты в про.бе по разным делам, сам того не замечая. Когда они накапливаются, ты бегаешь в мыле. Стресс, все дела.

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

Если кто-то не понял, что такое «транскрипция» в подкастах. Это вот так — вместе с аудио есть стена текста.

Понравилось что-то — сделал заметку, потом можешь перечитать, переслушать или заскриншотить для себя.

Я уже не могу без этого слушать подкасты! Кажется, что что-то упускаю.

На русском правда работает на 3-. На английском и испанском - на 4+.

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

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

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

Кто захочет скачивать приложение с 4 отзывами, даже если это 5 звезд? У приложения с 50 отзывами уже больше шансов, а уж тем более у приложения с 500 отзывами. Это “социальная валидация”. Мухи на плохой мёд садиться не будут, ведь так?

Независимо от того, слушаете вы подкасты или нет, вы можете поддержать наш проект 5-звездочным рейтингом в Apple App Store и Google Play.

Спасибо ❤️

Когда я ушёл с работы в Гугле, Арнаб ушел из Амазона, и мы начали работать над Metacast, мы думали, что сможем запуститься за полгода и с весьма продвинутым функционалом.

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

Причины было две:

1) В существующей экосистеме приложений для прослушивания подкастов у пользователей есть определённые ожидания, которые нельзя игнорировать.

Когда мы выкатили v0.1, которое умело делать только "фишку" — показывать транскрипты, которые можно читать, сохранять и помечать закладками, некоторые сказали "всё классно, но я хочу слушать подкасты быстрее".

Мы добавили изменение скорости. Они сказали — “всё супер, но я хочу более точное регулирование скорости.” Мы добавили и это. Вопрос скорости наконец-таки закрыт, но на него ушло 2 недели.

Другие сказали — "всё супер, но мне нужен таймер для отхода ко сну" (над этим Арнаб работает сейчас). Или "мне нужно, чтобы работало в Android Auto" (сделали). Или "всё здорово, но как я могу добавить подписку на платный подкаст"? (на очереди) Кто-то хотел автоматическую миграцию из уже существующих приложений (мы сделали простой вариант и этого).

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

Я уже писал про table stakes — минимальный функционал для MVP на устоявшемся рынке. Мы понимали, какие table stakes на нашем рынке, но их разработка оказалась значительно сложнее, что ведёт меня ко второму пункту.

2) Всё оказалось значительно сложнее.

Мы не первый год в разработке, но даже нас удивила сложность всего, что мы делаем. На поверхности мы бы оценили всё, как “средняя сложность”. На деле всё оказалось 2х.

Сказалось то, что ни у кого из нас не было опыта мобильной разработки. Набивали шишки по ходу дела. До сих пор набиваем.

Проблемы были и на бэкенде. “Не работает подкаст Х” (проблемы были с http headers) или “не импортируется подкаст Y” (разные причины) — когда ты работаешь с 4 миллионами подкастов в открытой экосистеме с кхм-кхм “гибкими” стандартами, что-то где-то не работает с первого раза, пока не подточишь напильником.

Продолжение 👇🏻

🎓 Воркшоп: Создаём продукты по методике “Working Backwards” компании Amazon

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

Ведущий воркшопа: Илья Безделев, ex-Principal Product Manager в Amazon Web Services в Сиэтле в 2015-2020гг. Продуктовый лид в AWS UX Platform, отвечающей за весь пользовательский интерфейс AWS. Запустил с нуля продукт AWS Chatbot, сервис для быстрого развёртывания виртуальных машин и внутреннюю платформу аналитики данных. Неоднократно презентовал свои PRFAQ Энди Джесси, нынешнему СЕО Amazon.

Пройдя воркшоп, вы научитесь:

1️⃣ Искать и коммуницировать ценность продукта, используя подход “5 вопросов” и написание пресс-релиза в Амазоновском стиле.

2️⃣ Убирать неопределённость для стейкхолдеров при помощи детального документа FAQ, выводящего вас из зоны комфорта.

3️⃣ Давать экологичную, но справедливую обратную связь во время ревью документов. Мы также поработаем над тем, как принимать обратную связь и внедрять её в документ.

4️⃣ Создавать процессы ревью продуктовых документов, которые вносят ясность, устраняют самодурство и приводят к более продуманным продуктам на выходе.

5️⃣ Декомпозировать PRFAQ в роадмап и артефакты для разработчиков. Мы увидим, как из “кораблей, бороздящих космическое пространство” получается реалистичный роадмап и набор задач для MVP.

Формат: Для каждого модуля я буду давать теорию и примеры из своей практики, потом мы будем вместе писать документы и их обсуждать. Будьте готовы к интерактиву со включенными камерами и двусторонними диалогами. Я планирую взять не более 25 человек, чтобы обеспечить камерный формат.

📆 Когда: Суббота, 26 октября 2024 с 10:00 до 14:00 по Москве.
📷 Где: Google Meet, запись будет доступна только участникам воркшопа.
💰 Стоимость: 5 тыс. рублей переводом на Сбер или $60 иностранной картой/PayPal.

Как вписаться?
Заполните форму тут. На почту придут реквизиты для оплаты и инвайт.

Если есть вопросы, пишите мне в личку @ilyabezdelev.

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

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

Таким образом, тебя мотивируют возвращаться как минимум 5 раз в день. Когда открыл все пять, тебе дают ачивку в виде 3 золотых слитков. Соберешь 8 других ачивок (за то, что дрифтишь, летаешь, сыграл 3 гонки и т.п.) и получаешь ачивку за достижение 9 ачивок и ещё золота…

Расскажешь это не игроману, на тебя посмотрят как на дебила 🙈 но эта херня работает!

Здесь остальной коммент про механики в игре: https://t.me/c/1401899176/11291

Удалил с телефона е.учую игру, от которой я потерял сон и приобрел тревогу.

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

Более того, я понимаю механики, которые они используют в игре. Они гении. Они сделали казино внутри гонок. Бесконечное уважение к ним, как продуктологам. Презрение как к людям.

Я, 40-летний мужик, не мог слезть с этой иглы. Даже ввалил в игру около $100, чтобы не было рекламы и (курам насмех) купить недостающие машины и (двойной насмех) золото.

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

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

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

Судя по постам на сабреддите NFS No Limits, я такой далеко не один. Эта игра разрушает жизни тех, кто не может себя контролировать… подозреваю, таких игр множество. Я просто попал на одну из тысяч.

— Всем привет. Меня зовут Илья и я геймоголик.
— Привет, Илья.

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.4: PRFAQ как культ внутри компании

Четвертый пост из серии про процесс “Working Backwards (from the customer)”, так же известный как PRFAQ. Рекомендую сначала прочитать первую, вторую и третью части, чтобы была полностью понятна суть.

Итак…

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

Чтобы раскрыть тему процессов, мне потребуется несколько постов. Начну с самого важного — безоговорочной стандартизации на одном процессе во всей компании, в которой работает 1,5 миллиона сотрудников.

Амазон настолько привержен PRFAQ и процессу Working Backwards, что каждый сотрудник безоговорочное принимает PRFAQ как должное.

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

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

У каждой команды обязательно есть PRFAQ для их продукта. Это работает как магия.

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

Это очень эффективно.

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

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

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

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

Любые попытки поменять этот процесс не приветствуются и всячески не поощряются. Всех, кто пытается поменять процесс, культура попросту выдавит.

“Кто к нам с powerpoint-ом придёт, тот знает, где дверь” (с) народная мудрость. В Амазоне запрещены слайды.

P.S. Тема настолько интересная, что заслуживает теоретического + практического воркшопа. Детали анонсирую сегодня-завтра. Предварительно в следующую субботу 26 октября в 10:00 по Москве (онлайн).

👉🏻 Пятая часть

@ilyabezdelev_blog #amazon #продактменеджмент #бигтех

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

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

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

Лайфхак от Тима Ферриса — make before managing. Создавай перед тем как «управлять».

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

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

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

Это я тоже сегодня попробовал. Выше писал о результате. Сделал за 2 часа подкаст. Остаток дня был в хаосе, но у меня нет ощущения, что я про.бал свой день, потому что я сделал важное дело за один присест. Даже не налил себе чаю и не ходил в уборную, пока не сделал.

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

На том же подкасте послушал интервью с ультра-правым журналистом Беном Шапиро.

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

Выбирая из двух, тип А все-таки в большем профите по жизни.

Слушаю интервью с Дэвидом Гоггинсом, мега-бегуном, бывшим морским котиком и пожарником.

1️⃣ Зашла мысль о том, что для дисциплины нужны условия.

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

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

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

2️⃣ «Дисциплина ест мотивацию на завтрак» — это перефразирование знаменитой фразы Питера Друкера (культура ест стратегию на завтрак).

Мотивация — это скоропортящийся продукт. Она тухнет. Дисциплина нет.

3️⃣ Каждую секунду ты принимаешь решение идти дальше или нет. Слабость в эту секунду => годы сожалений.

Классное интервью. Я вчера послушал половину, пока бегал в 9 градусов по Питеру. Пробежал больше, чем когда-либо (почти 5 км в темпе 7,5). Сегодня начал день с того, что «съел лягушку» через силу и сделал то, на что у меня обычно уходит день, за 2 часа. При этом ещё успел помедитировать (обычно у меня не хватает на это времени).

Когда подходишь к жизни из позиции дисциплины и контроля, получается неполучаемое.

Я потерял хватку в ковид. Сильно расслабился, ушел в духовное. Давно уже хочу «вернуться в строй», но не хватало Гоггинса, который накричал на меня вчера в ухо на подкасте и дал заряд для того, чтобы собраться.

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.3: FAQ и Appendix
(первая часть, вторая часть)

Неотъемлемая часть PRFAQ — это FAQ. В сумме пресс-релиз и FAQ составляют не более 6 страниц: 1 страница пресс-релиз и 5 страниц частых вопросов и ответов.

FAQ — это моя любимая часть процесса. Это просто список из 100500 вопросов с короткими ответами. Вопрос-ответ, вопрос-ответ. Каждый ответ обычно не больше абзаца.

FAQ делится на две секции: вопросы пользователей и вопросы стейкхолдеров.

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

Сколько он стоит? Как мигрировать с другого приложения? Возвращаются ли деньги при отмене подписки? Какие форматы данных поддерживаются?

И так две-три страницы сплошных вопросов. Любой вопрос, который возникнет — пишем сюда и отвечаем.

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

Какие у нас косты? Сколько человек должно это поддерживать? Как это интегрируется с платформой Х? Как это масштабируется? Какие алгоритмы шифрования используются? С какой страны мы начинаем запуск? Почему мы думаем, что это взлетит?

В итоге у нас 5 страниц вопросов и ответов, которые мы генерим сами "из головы", в ответ на фидбек на ревью (задали вопрос — включили на него ответ, чтобы на следующем ревью его уже не было) и из шаблонов.

На некоторые вопросы ответы могут быть очень длинными. Например, нужно приложить таблицу с моделью P&L. В таких случаях в ответе просто ссылка на "приложение Х", которое приложено в этом же документе.

Приложения (Appendix) могут быть любой длиной. На моём опыте их страниц 20-30. Там разного рода расчеты ТАМ, скрины дизайна, P&L, детальное саммари касдевов и т.п.

Всё это — PR, FAQ & Appendix — в одном файле, который можно распечатать или переслать, не теряя важную информацию.

Подытожим:

— Пресс-релиз описывает проблему пользователя и её решение. Он про ценность.

— FAQ про то, чтобы всеобъемлюще описать стоимость, функционал, интеграции, стратегию выхода на рынок и т.п. в сжатом формате.

— Appendix про то, чтобы доказать, что проблема есть, показать ценность и предоставить детали для всех цифр в документе.

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

👉🏻 Четвёртая часть

@ilyabezdelev_blog #продактменеджмент #бигтех #amazon

Боковым зрением прочитал это как «Gluten morgen». Было бы классное название для магазина традиционной немецкой выпечки.

Кого-нибудь ещё бесит новый интерфейс в фотках в iOS 18? Стало элегантнее, но пздц неудобно. Визуальный дизайн в ущерб UX.

Мне только что рассказали про прикольную практику — приглашать в середине спринта на встречу с командой (продакт + разработка + дизайн) пользователей, которым можно показать промежуточный прогресс по фиче.

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

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

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

А что так можно было?

По четвертому пункту — он важен не только для того, чтобы доказать вышестоящему руководству и разработке, что это стоит делать. Это нужно в том числе для тебя самого. Чтобы ТЫ был уверен в своём предложении.

Если ты будешь уверен, ты сможешь это продать кому угодно. Если ты сам не уверен, то почему тебе должны выделить под это ресурсы?

Ещё один классный подкаст — интервью с Борисом Зарьковым, основателем ресторанов The White Rabbit Family. Из его ресторанов я несколько раз был в Горыныче. Там классные бутеры, пицца и сервис.

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

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

В ресторанах текучка до 100% в год. Представьте себе полную смену команды за 12 месяцев… 🤯

В худшие годы у них была текучка 300%. Три раза сменяется состав людей 🤯 🤯 🤯

Он дрючит своих управленцев за высокую текучку и лишает их бонусов.

Классное интервью с Андреем Стыскиным, который был главой Яндекс Поиска, а теперь — директор в Амазоне (плюс-минус 100-150 человек в подчинении).

Он так рассказывает про культуру Амазона, что я обливаюсь ностальгическими слезами и хочу обратно. Его опыт соответствует моему, все по делу говорит. I approve.

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

Слушаю и тащусь.

Два самых частых вопроса, которые мне задают — почему я вернулся из США в Россию и как продакту прокачать технические навыки.

Увидев сколько существует продуктовых каналов, возникла мысль занишеваться и чуть больше сфокусироваться на техническом продакт менеджменте (темы последних постов).

Я не нашёл ни одного нишевого канала про технический РМ, может не так ищу?

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

Плюс-минус контент канала попробую сделать таким:

— 50% посты связанные с технической частью, работой с разработкой, хардскиллами.
— 30% в общем про продакт менеджмент, преимущественно из моего опыта в американском бигтехе. Рубрика "а как там у пиндосов?"
— 20% сочинения на свободные темы, делающие мой канал моим. Когда-нибудь отвечу на вопрос, который мне последнее время задают чаще всего...
— Бонус: Скоро возобновлю подкаст с интервью. В себя до конца приду после переезда, куплю звуковые панели и начну искать гостей.

В связи с этим возникла мысль также и переименовать канал в "Технический продакт менеджмент с Ильёй Безделевым".

Как вам такое название?

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

Приветствую фидбек. Можно в комменты, можно в личку @ilyabezdelev.

В ближайшее время тут будет несколько постов с рекомендациями других продуктовых каналов. Меня добавили в группу, состоящую из 80 человек с каналами про продакт менеджмент с >1к подписчиков. Многие значительно больше моего. Есть интересные, притом, что я о них никогда раньше не слышал.

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

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

Прикол. Походу у Басты на артворке песни стоит реклама. Такого в Спотифай я ещё не видел. Нативненько!

Ну или где-то в сети происходит подмена изображения. Это было на телефоне жены, сам я ещё не смотрел откуда ноги растут.