Продукт

Как защититься от потребительского экстремизма На маркетплейсах всё чаще встречаются случаи потребительского экстремизма: покупатели подменяют товар муляжами и оформляют возврат, ссылаясь на дефекты или несоответствие описанию. Чаще всего страдают продавцы техники и электроники. Чтобы обезопасить бизнес: — Фиксируйте факт подмены при возврате товара — Подавайте жалобу через платформу, затем официальную претензию — Обращайтесь в суд, если платформа не реагирует Быстрая реакция и грамотно оформленные доказательства помогают не только вернуть убытки, но и сохранить высокий рейтинг, доверие покупателей и стабильность бизнеса. Фаундер | Бизнес и Стартапы

Как заставить зумера со спауном внимания 8 секунд пройти онбординг из 15 экранов? 🤨 кмооооон да никак 😳 В 2026м году медианный completion rate онбордингов по приложениям всего 50%. 50, КАРЛ Посмотрите сессии своих пользователей - едва ли они вдумчиво отвечают на каждый вопрос, наверняка большинство кто доходит до конца пролетает онбординг на автопилоте, не читая ни одного экрана и это уже стандарт индустрии, спасибо тик току и другим платформам шорт контента за клиповое мышление у целого поколения 😂 Ну а чего, представьте показывать восьмилетнему ребенку вместо мгновенной выгоды слайды, которые можно пролистнуть не читая Новые проблемы как обычно требуют новых решений и мне кажется мой друг @eduardbaksheev (Эдик кстати нам оч помогает с дизайном aesty!) придумал интересное решение для своей прилы peri ai (вопросы по женскому здоровью), у него онбординг это чат с персонализированными вопросами и голосовым вводом 🧠 Прокликать такое невозможно - следующий вопрос не появится пока не ответишь, и каждый ответ меняет сценарий. Через минуту апп знает обо мне больше чем классический онбординг узнал бы за 15 экранов и мне лично отвечать было интереснее, чем заполнять форму, так как я получала какой-то отклик после каждого вопроса (но справедливости ради зумер я по нижней границе 😧) Мне стало интересно, где еще это есть и я нашла парочку примеров. Airtable собирает воркспейс из разговора с AI, Clay генерит первый воркфлоу из ответов welcome survey, Pi и Replika знакомятся с тобой как человек, ну и конечно Duolingo вообще ставит урок до регистрации, так что думаю это вполне можно считать новым трендом - персонализированный чат вместо формы ответов на онбординге 🐵 Ну и вишенка на торте - если продукт сам по себе чат, значит онбординг это уже первое использование продукта. Наталкивает на мысли что надо пробовать у себя, мы сейчас как раз первую сессию переделываем - показать функционал и объяснить, что не надо все вещи фоткать отдельно скорее всего будет очень удобно, как будут цифры - поделюсь Ставлю на то что через год чат-онбординг будет у половины consumer аппов, скриньте 😅 @neural_prosecco

2. У разработчиков часто есть паттерн поведения: В важной поворотной ситуации вместо того, что сейчас действительно важно (например, выпустить продукт на рынок) - бесконечно допиливать фичи, чтобы и кофе варило, и шаттлы в космос запускало. И этот паттерн неоднократно повторяется во все поворотные моменты. То есть наличие такого паттерна показывает, что в будущем он будет выбирать допиливать. Например, вместо выпуска продукта на рынок, когда надо захватить долю рынка - продукт допиливается ещё 2 года, пока рынок потерян. И наличие вот этого вектора у фаундера "ещё немного допилить вместо коммерчески важных действий" - важный риск в партнёрстве при запуске бизнеса. Если я вижу такой вектор - я сразу обговариваю, будет ли в важной ситуации фаундер слушать меня как маркетолога и партнёра или будет сбегать в бесконечное допиливание, и будут ли у меня рычаги воздействия в этой ситуации. ИИ видит факты и риски, и даже может построить прогноз (если вы ему сказали, где именно и какой прогноз строить, и на что обратить внимание). Я смотрю на то, как эти факты связаны между собой и что они говорят о будущем поведении системы. Предикторы рисков. И принимаю решение, как мне защищать от этих рисков себя или вверенный мне бизнес. Вы можете увидеть в разборе ИИ плюс-минус те же факты и риски. За вычетом того, что он не увидел, пока я об этом не сказала (а вы, соответственно, не догадались у него спросить). Но дальше - сможете ли вы увидеть те же прогнозы, что я? Примете ли вы на основании этой информации те же решения, что я? Увидите ли, где и как надо подстелить соломку? Если у вас меньше опыта, чем у меня - вы не догадаетесь о части этих вещей подумать или спросить у ИИ. И именно этим отличается опытный эксперт с ИИ - от менее опытного человека с ИИ.

Что с движком? Иногда такой вопрос стал прилетать в комментариях. Решил, что лучше напишу объясняющий пост. Я делал движок для создания 3д игр и относительно регулярно постил отчеты о прогрессе. Движок изначально планировался универсальным и функциональным. А кор-составляющей движка была нативная разработка агентами. Потом я увидел, что почти каждый уже пилит под себя движок. Плюс понял, насколько это глубокая и вечная тема. Что побудило меня сдаться и бросить идею. Но наработки не хотелось просто так сложить в полку, поэтому я сделал пивот в сторону движка для рекламных креативов. Фишка была в том, чтобы он использовался для создания 3д-болванок, по которым генерится видео в ИИ. И в целом получилось что-то интересное. Я начал погружаться в тему глубже, но и это направление пришлось оставить. В какой-то момент я сделал несколько прототипов игр и отправил в одно из топ-издательств. Ребятам понравилось то, что получилось, и мы начали делать итерации. Под издательство я сделал специальный пайплайн, куда вошел и движок. Движок перестал быть фокусом и самоцелью. Потому что реальной потребностью стал именно пайплайн под быструю пересборку прототипов и работу над продуктовыми итерациями. И все это уже не универсальное, а под конкретный жанр. Итерируем уже чуть более трех недель. Вышли на финишную прямую доработок, чтобы провести тест. По данному направлению не хочется что-то загадывать и озвучивать раньше времени. Но мне очень нравится продуктовая работа и использование агентской разработки именно для продуктовых итераций. Надеюсь, что вскоре смогу расскать про это больше. Данная ветка развития мне определенно по душе и нужна. @timurtaepov

Зачем ускорять разработку? Просто через раз вижу этот вопрос, во всех постах про агентов и новую эру автоматического кодинга. Переубедить конечно никого не получится, но написать надо, чтобы получилось структурировано. Погнали. Нет такого количества задач Если вы поговорите не с менеджерами, а владельцами бизнесов, то окажется, что количество идей у них такое, что за всю жизнь не сделать. То что из этого не всегда доходит до низов, проблема размера и процессов, которые тоже пытаются решать, поэтому так много разговоров про sdd и аналогичные истории. Если разработка стала в два раза дешевле/быстрее, становятся экономически оправданными задачи, которые раньше вообще не попадали в backlog. Это никому не нужно В конкурентном мире невозможно сделать продукт до конца и сидеть сложа руки. А конкуренция приводит еще к тому, что кто первый встал, того и тапки. Сегодня вы на высоте, завтра ваш бизнес угрохали потому что вы не успели адаптироваться. Ну если вы работаете у монополиста/госа/стратегического игрока, то можете игнорировать этот пункт 🙂 Фичи не принесут деньги Может принесут, а может и нет, это невозможно обобщать не зная конкретных обстоятельства конкретных ситуаций. Например мы годами не могли сделать b2b кабинет таким как хотели наши клиенты, потому что у нас никогда не хватало ресурсов на эту часть. С помощью агентов мы это сделали и смогли получить хорошие контракты, которые от нас раньше уплывали. Ускорение разработки меняет не только скорость выполнения уже выбранных задач, но и сам набор задач, которые становится рационально делать. Покажите как это сократило фот? По правде говоря у многих сократило. Но последовательность другая. Последние годы у многих были сокращения по экономическим причинам, а потом заморозка найма при одновременном росте производительности за счет ИИ. Поэтому ии больше повлиял не на сокращение как таковое, а на отсутствие найма Покажите как это увеличило прибыль? В экономике есть только два способа растить маржинальность: рост производительности и повышение цены. Когда то массовое внедрение компьютеров и экселя привело к такому же эффекту. Итого Ускорение разработки само по себе не цель. Реальная цель это снизить стоимость изменения продукта, поэтому помимо разработки одновременно ускоряется еще много всего, но об том просто говорят в других местах, куда разработчики не ходят, поэтому у них часто складывается такое одностороннее представление о происходящем Telegram | YouTube | AI Клуб

🎾 как за час навайбкодил прототип > протестил > сменил направление в последний месяц дико влюбился в падел, играю постоянно, и для меня это стало способом не выгорать ну и, как это бывает, в какой-то момент начал смотреть на это уже как продакт стал валидировать гипотезу, что у людей есть частая боль — быстро найти 4-го игрока, когда кто-то в последний момент сливается с игры, из инсайтов - множественные сообщения в чатиках побрейнштормил с гпт, выделил сегменты, подумал про риски, потом пошел в клод и буквально за час навайбкодил простой прототип на джанго с базой данных и вот в процессе понял самое интересное: история, скорее всего, не про b2c в лоб логичнее идти через b2b-модель и делать продукт в первую очередь для клубов, а b2c использовать как канал лидогенерации и тебе не нужно рисовать прототипы в фигме, не нужно сливать сотни тысяч на мвп, чтобы быстро протестировать гипотезу навайбкодил пре-мвп > продолжил в том же направлении или же сменил вектор

Есть тезис, который команды произносят с гордостью: стратегию не пишем, вместо этого быстро проверяем гипотезы. То есть между стратегией и скоростью выбрали скорость, потому что стратегия в этой картине мира что-то долгое и тяжёлое, что мешает бежать. Выбор мнимый. Хорошая стратегия вообще не про то, сколько её строили и сколько нужно строить. Она про то, понимаешь ли ты систему, в которой работаешь: какие в ней причинно-следственные связи, где узкие места, в какой точке небольшое усилие даёт непропорционально большой эффект. Такое понимание можно собрать за неделю, если знаешь, куда смотреть. Можно не собрать и за год. Я уже писал, что гипотеза в научном смысле описывает наблюдаемый феномен и требует экспериментальной проверки, а «сделаем X, получим Y» — это идея. В бэклоге команд, гордящихся скоростью, чаще лежит именно второе. Поэтому если этого самого понимания системы нет, быстрая проверка гипотез превращается в брутфорс идей в надежде, что какая-то стрельнёт. Скорость тут не спасает, ибо пространство вариантов огромное, а выигрышных в нём единицы. И даже когда идея стреляет, на следующем шаге это почти ничего не даёт. Гипотеза в стратегии живёт внутри связанного плана, где несколько линий бьют в один рычаг, поэтому её проверка даёт больше, чем ответ на один вопрос. Подтвердилась или нет, картина системы обновилась целиком. Соседние гипотезы стали сильнее или потеряли смысл. Появились новые данные, которые теперь надо объяснять, и следующий шаг выбирается уже из обновленный картины мира. Идея же ничего не объясняет. Проверил, получил плюс два процента к метрике, порадовался и пошёл к следующему, никак не связанному пункту бэклога. Почему сработало и куда копать дальше, непонятно. Знание не накапливается, и даже десяток удачных идей даёт десять локальных улучшений, которые не складываются в одно большое. Проверять нужно, но без понимания системы проверять нечего, остаётся перебирать идеи и гордо называть это «культурой экспериментов».

Метакогниция и йогачара наблюдают за тобой с твоим продуктом В 1970-х психолог Джон Флавелл обнаржил, что дети с возрастом не просто лучше запоминают, а начинают отслеживать, что именно они запоминают и как они управляют этим процессом. Так в 1979 году появился термин метакогниция. За полторы тысячи лет до Флавелла последователи ветви буддизма Йогачара разбирали тот же вопрос с другой стороны: может ли сознание знать само себя напрямую, или для этого ему нужен ~ещё~один~слой~и~акт~сознания. Обычное сознание устроено простейшими слоями: №1. Слой хранилища Потока, накапливающий следы всех прошлых действий, восприятий и/от объектов; №2. Слой управления-контроля, который берёт этот поток и принимает его за устойчивое «я» или «это»; №3. Слой создания нового восприятия, работающий с текущим действием, восприятием и объектом. Но ни один из этих слоёв не видит Единого-Целого, потому что каждый слой фиксируется лишь на своей когнитивной функции, порождая на каждом уровне те самые когнитивные искажения На практике мы останавливаемся на первом-втором слое, считая это достаточным и принимая первую мысль как решение. И делаем это не потому, что дальше нечего смотреть, а... просто дальше смотреть Некому. Так и получается, что для контроля мышления нужен ещё один слой мышления, для контроля этого слоя следующий, для него ещё один... Кто наблюдает за наблюдателем? Никто-Ничто В йогачаре это называется виджняпти-матра или «только представление». А то, что кажется устойчивым объектом наблюдения, само есть лишь продукт смотрящего "ума". Потому что любая система поддерживает себя, воспроизводя себя заново на каждом шаге и наблюдение за собой средствами самой системы это акт её самокопирования. Сознание смотрит на себя тем же взглядом, из которого оно было сделано, и потому не открывает новый факт, а лишь заново пытается "пересобрать" старый. То, что кажется в этот момент «иным взглядом», сделано теми же слоями, что и всё остальное. Система не выходит за свой контур и не открывает новый взгляд и факт и не создаёт иную версию в момент наблюдения.

Мониторинг конституирует то, что потом контролирует

Пересборка идёт, а нового не прибавляется. Разнообразие нельзя нарастить изнутри если оно не приходит иным извне. Продакты натыкаются на это каждый день, в момент реакции на ситуации или на паттерны, которые сами же копируют и пересоздают прошлыми установками (паттерны и/или реакции?). А в постоянном стрессе тот слой, что должен создавать восприятие текущего объекта, вместо этого достаёт старый готовый слепок из слоя хранилища, и выдаёт его за "новую" реакцию на настоящее. То же самое происходит с реакцией на неправоту Пока слой контроля принимает поток мыслей за устойчивое «я/это/так», любое доказательство против одной из этих мыслей читается мозгом как угроза и атака на всё «я» целиком, и человек упорствует тем сильнее, чем больше доказательств против «этого» «вот так» и «я». Та же слепота определяет умение делегировать задачи Продакт, который не видит, что его «я уверен» и его «я умею» это два разных слоя, путает одно с другим вместо того, чтобы спросить того/То, кто разбирается/умеет лучше него, поэтому замечать моменты подмены тем же слоем, который его наблюдает, очень и очень сложно. Но когда «я» и «это» каждый раз пересобираются заново, неправота перестаёт быть угрозой и становится просто очередной логичной пересборкой под текущую реальность Нужно выйти Туда, откуда видно иначе и где наблюдающий перестаёт быть одним из слоёв, хватающихся за свои функции и оттуда спросить:

Что ощущается? Что изменяет это?

Чтобы понять объект-процесс, нужно стать объектом и процессом. Заметить Это – стать и перестать быть Этим. Существует дзенская загадка: если дерево падает в лесу и рядом нет никого, кто мог бы это услышать, издаёт ли оно звук?

Оценка мелких задач убивает ваше время Типовая ситуация: клиент постоянно присылает небольшие задачи и переживает, сколько времени займёт каждая. Команда начинает оценивать каждую задачу отдельно, согласовывать, потом объяснять, почему не попали в оценку. По факту оценка иногда занимает больше времени, чем сама работа. С маленькими задачами точность вообще плохо работает. Чтобы нормально оценить некоторые из них, задачу надо почти сделать. А если оценивать «на глаз», погрешность по каждой отдельной задаче будет большой. В итоге коммуникация с клиентом превращается не в работу, а в бесконечный цикл согласования бюджета и времени для мелких задач. Что с этим делать: отказаться от точной оценки мелких задач. Учитываем мелкие задачи постфактум. Сделали задачу, зафиксировали, сколько реально ушло. Чтобы клиент на это согласился, нужно немного изменить процесс: 1) Оценка остаётся, но она становится очень примерной: маленькая, средняя, большая задача. Менеджер проекта это может сделать без похода к разработчику. Клиент и Агентство соглашаются, что это грубая оценка. 2) Договориться о месячном лимите. Обычно поток таких задач укладывается в 10-20 часов в месяц. 3) При явном выходе задачи за лимиты или не попадании в оценку - заранее говорим об этом с клиентом. Большие, сложные и непонятные задачи нужно выносить отдельно и нормально оценивать. А поток маленьких задач лучше продавать почти оптом: грубо обозначать размер, следить за лимитом, заранее предупреждать о выходе за ожидания и оплачивать по фактически потраченным ресурсам. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

⚡️Интервью с главным технологом Exponenta Сергеем Красоцким — о тренде на протеин и псевдобелковых продуктах Высокобелковые сосиски. Высокобелковые оладушки. Высокобелковые чипсы. Производители стали выносить количество белка на упаковку творога, хотя он был высокобелковым всегда. С июня 2024-го по июль 2025-го продажи высокобелковых йогуртов и молочных десертов в России выросли в деньгах на 182%, подсчитало агентство NTech. Для сравнения: за то же время продажи всей молочки прибавили лишь 20%. Мы пригласили поговорить о тренде на белок Сергея Красоцкого. Он кандидат технических наук, доцент, руководитель белорусской компании Miltex, которая разрабатывает технологии производства продуктов Exponenta. Почему все больше людей покупают протеиновые продукты, какой белок полезнее: животный или растительный — и как отличить по-настоящему высокобелковый продукт от батончика в манипулятивной обертке? Обсуждаем на сайте: https://www.setters.media/post/intervyu-sergey-krasotskiy-exponenta-trend-na-belok

Что классненького произошло за неделю Личное вперемешку с прикладно-продуктовым. 1. Apple представила фичу, которая позволяет предлагать юзерам перс предложения на этапе отмены подписки. Звучит интересно, классно, что Apple внедряют все больше инструментов взаимодействия с юзерами. 2. Активно качаю кейс-клуб Product Games. Вообще, думаю, теперь просто кейс-клубом его называть некорректно, так как мы покрываем не только подготовку, но и автоотклики. Потихоньку прощупываю, что там на англоговорящих рынках. Поэтому если вдруг меня станет слишком много в LinkedIn, не обессудьте. 3. Тестирую тик-ток на рынке США для одного из моих приложений. Тик-Ток на европейский рынок не дал плодов, но поговаривают, что с американским тик-током все иначе. Let’s see. Уже практически не кринжую снимать танцы на камеру. 4. У меня есть личный Инстаграм, который стал площадкой для соц экспериментов. Одно из любимых развлечений - поднимать неоднозначные темы и тестировать разные триггерящие формулировки. Интересно, как люди: а) быстро обобщают частные вещи б) трактуют информацию из призмы своих загонов. Представляете, какое это поле для манипуляций. Поэтому будьте аккуратны с информацией в интернете. Кстати, русскоязычные и англоязычные соцсети отличаются: в первых мне постоянно напихивают за отсутствие люстры, во вторых никто никогда не поднимал эту тему. Прикольно, да? 5. В очередной раз меня заблочили в Meta 😂 Ситуацию решила, но Meta ads так и не работает. Поддержка meta сама не знает, как решать. 6. Провела пару менторских сессий. Теперь ждём результаты с менти. 7. Занимаюсь остальными продвиженческими штуками: пытаюсь выйти на B2B партнерства с одним из приложений, тюню рекламу. Как-то так. А у вас как? #PG_размышления

50 самых полезных ресурсов для продактов ProductMap - Большая карта знаний и навыков PM: от discovery и аналитики до AI и leadership. Product Compass - Один из лучших структурированных наборов PM-frameworks и competency maps. ProductDo Skills Map - Визуальная карта навыков продакта по уровням и направлениям. Ravi Mehta PM Toolkit - Сильный competency framework для оценки и развития PM. PMwheel - Удобная модель self-assessment и развития продуктовых навыков. GitLab PM Competencies - Реальная корпоративная система уровней и ожиданий от PM. Intercom PM Ladder - Хороший пример карьерной лестницы от PM до senior-level ролей. Reforge - Глубокие материалы по growth, retention, monetization и strategy. Mind the Product - Огромная библиотека статей, кейсов и выступлений по Product Management. SVPG - Marty Cagan: empowered teams, discovery, strategy и product operating model. Lenny’s Newsletter - Практические разборы growth, marketplaces, AI, leadership и product strategy. Product Talk - Teresa Torres: Continuous Discovery, OST и работа с assumptions. Strategyzer - Business Model Canvas, Value Proposition Canvas и тестирование бизнес-гипотез. GoPractice - Одна из сильнейших баз по продуктовой аналитике, retention и unit economics. GoPractice Simulator - Практический симулятор продуктовой работы с метриками и решениями. Product School - Большая библиотека guides, templates и PM-материалов. The Product Folks - Кейсы, frameworks, teardown’ы и материалы для развития product sense. Hustle Badger - Хорошая база по strategy, JTBD, PRD, discovery и product org. PM Skills Marketplace - 100+ готовых AI-native skills и workflows для Product Management. prodmgmt.world - AI-native PM OS: skills, frameworks, workflows и агенты. Productboard Resources - Customer insights, prioritization, roadmap и product operations. ProdPad - Lean roadmaps, outcomes, discovery и product strategy. airfocus - Prioritization, discovery, strategy и Product Ops. Aha! Product Guide - Очень большой системный справочник по Product Management. Jira Product Discovery - Практики работы с ideas, insights, prioritization и discovery → delivery. Pragmatic Institute - Market-driven product, positioning, pricing и GTM. Product-Led Alliance - PLG, activation, adoption, onboarding и retention. Growth Unhinged - Очень сильный контент по SaaS growth, pricing и monetization. First Round Review - Подробные кейсы стартапов по продукту, growth и management. YC Library - PMF, MVP, пользователи, growth и запуск стартапов. Sequoia Articles - Стратегия, рынки, PMF и построение компаний. a16z - AI, SaaS, marketplaces, fintech и новые продуктовые модели. CXL - Experimentation, CRO, analytics и behavioral science. Demand Curve - Практические growth playbooks по acquisition и retention. Growth.Design - UX-разборы известных продуктов через behavioral psychology. Built for Mars - Очень подробные UX teardown’ы реальных продуктов. Nielsen Norman Group - Фундаментальная база по UX, usability и research. Dovetail - Интервью, research synthesis и работа с customer insights. Maze Guides - Usability testing, prototypes и continuous research. Hotjar - Behavior analytics, funnels, user feedback и customer journeys. Mobbin - Огромная библиотека интерфейсов сильных digital-продуктов. Page Flows - Реальные onboarding, checkout, subscription и другие user flows. UserOnboard - Классические разборы onboarding известных продуктов. Amplitude Academy - Бесплатное обучение funnels, retention, cohorts и analytics. Amplitude Blog - North Star, activation, retention и experimentation. Mixpanel Blog - Практическая продуктовая аналитика: funnels, cohorts и retention. ChartMogul - Одна из лучших баз по SaaS-экономике: MRR, NRR, CAC, LTV, churn. Shape Up - Сильная альтернатива backlog-driven разработке: shaping, appetite и betting. ChatPRD - AI-помощник для PRD, discovery, requirements и PM-документов. Atlassian Team Playbook - Практики для alignment, decision-making, goals, retrospectives и командной работы.

Ваши бизнес-процессы всегда будут ломаться, и с этим ничего нельзя сделать 🔵Процессы — это то, как вы делаете повторяющиеся вещи: как передаёте клиента из продаж в производство, как исполняете обязательства, как держите свои стандарты. И вся эта конструкция нахер разваливается каждый раз, когда команда утраивается. Работало на 10 - отвалилось на 30. Работало на 30 - сломалось на 90. Это прям управленческое правило, и с ним, к сожалению, НИЧЕГО не сделать. Просто принимаем, плачем и переделываем процессы заново. В позитивном сценарии у вас к этому моменту уже есть наёмные руководители. Тогда всей этой свистопляской управляют они, а вы смотрите со стороны, как они всё разгребают)) Без руководителей это всё прилетит вам. А так вообще регламенты, чек-листы, оргструктуры и куча других скучных штук, которые душные дяди рисуют в учебниках по менеджменту, это реалии предпринимательства. Первые регламенты появляются ещё людях на десяти, дальше их становится больше и пишут их уже руководители. Но сама привычка и культура создавать процессы должна в компании завестись, и отвечают за неё тоже руководители. Как понять, что бизнес-процессы налажены: 🔵Заходите в чат, а там больше нет сообщений ''мы же это уже обсуждали'' 🔵Вас не дёргают одними и теми же тупыми вопросами 🔵Одна и та же услуга для всех клиентов делается одинаково (как в макдаке: куда ни приедешь, чизбургер везде примерно один и тот же) 🔵Новичок погружается за 2-3 недели вместо 3-4 месяцев: пришёл, прочитал обучалки, сделал по чек-листу, готов работать 🔵И главное, вы перестали тушить одни и те же пожары по кругу А если вы сейчас растёте, заложите время на переписывание процессов. Оно всё равно случится. Вопрос только, по плану или в аварийном режиме, когда всё уже горит...

🔖Заметка из Agile Practice Guide Для распределения ответственности можно использовать RAF! Не в смысле поить всех сладким кофе, а применить модель и определить, кто: 📍Responsible — непосредственно выполняет работу; 📍Accountable — отвечает за результат или принимает решение; 📍Facilitator — поддерживает процесс, снимает блокеры и помогает команде двигаться дальше. Когда это делать: возникает путаница в нюансах выполнения задачи, особенно если в ней участвуют люди из разных подразделений. Ко всем задачам по умолчанию не надо добавлять. 💁‍♀️ Все такие матрицы распределения ответственности плюс-минус похожи, подбирайте под свои нужды. Как по мне, если у вас русскоязычная компания, то лучше подобрать свои, более понятные для всех обозначения. А то Responsible — Accountable это как Output — Outcome. Вроде понятно, но где-то на уровне коллективного бессознательного.

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

Продуктовые наблюдения: Одиссея из всех лошадей На днях мы посмотрели Одиссею Нолана. Очень не плохое кино, я бы назвал это фанфиком на Гомера. Но мы тут не про кино разговариваем, а про продуктовые наблюдения Так вот, после кино мне все сервисы начали подсовывать информацию о: 1. Одиссее 2. Улис (для меня было открытие, что это Одиссей у римлян) 3. Крах брозвого века Все мои любимые авторы сделали видео о... И получается, что эффект научения алгоритмов (когда мне подсвечиваются видео большой давности), а еще желание обуздать медийную волну - приводит к тому, что я погрузился на тему так, что теперь знаю в целом в каких песнях и что пелось и подумываю о том, чтобы прочитать Гомера. А если сервисы и пузырь могут влиять на решение в таком виде, просто подсовывая качественный контент на тему, то вопрос, а могут ли они влиять на все остальное? (вопрос, риторический) Кстати, приходите в комменты, поговорим о кино, как вам? смотрели ? @blackproduct

Не знаю как вы, а я постонно слышу как кто-то заменил себе какой нибудь SaaS, на инструмент, написанный Клодом (или кем то другим). Но доказательств обычно не приводится. Решил провести эксперимент. Заменить что то у себя. Мы платили 60 долларов в месяц за Calendly. Три человека. Сервис букинга встреч с синком с гугл календарем. Куда уж проще, календарь и ссылка на запись. Спросил Клода, есть ли живой open source аналог, он сказал что Cal.com отказался от опенсорса и ничего серьёзного не осталось, позже это оказалось не совсем правдой, но было поздно. Очень хотелось. На самом деле Cal.com в апреле переименовали в cal.diy и отдали под MIT. Хоть лицензию и сделали свободнее, из кода при этом вырезали команды, workflows, insights и SSO, одним коммитом на минус 411 тысяч строк. Вторая строка их же README — strictly recommended for personal, non-production use. То есть ребята сами написали, что в проде это лучше не запускать. Релиза нет с марта, докер-образы давно заархивированы, и чтобы это поднять, нужен сервер с Node и PostgreSQL. Немножко инфры. Решил попробовать сделать своё. Сразу на Cloudflare, там на наших объёмах - бесплатно. Ну и я честно говоря всё ещё их фанат. Начал в субботу. От пустого репозитория до задеплоенного продукта. 127 коммитов, 525 тестов. В будние доделывал по остаточному принципу - 8м проектом. Назвал Punctual. Ну название тоже клод посоветовал. Внутри в том числе то, что у cal.diy вырезали, команды с round-robin и collective, плюс Google Calendar и Microsoft 365, письма с .ics и напоминаниями, REST API, вебхуки и виджет для встройки. И MCP сервер. То есть агентами тоже можно пользоваться и букать встречи. Всё живёт на одном воркере: Workers, D1, Durable Objects, Queues, KV, R2, Cron. Ни сервера, ни базы, ни докера. wrangler deploy в свой аккаунт, минут пятнадцать, ноль долларов в месяц. MIT, без ограничений. Ставьте себе, пользуйтесь. Репозиторий, живьём крутится на punctual.sh. На скриншоте моя страница записи, по ней ко мне можно попасть. Буду благодарен за звёзды. Чтонибудь ещё доделаю. Буду рад PR-ам. Версию для своей команды поднял. Протестировал. Подписку на Calendly отменил. Если вы тоже что то реально заменили - расскажите. Интересно. Сергей Булаев AI 🤖 - об AI и не только