Сегодня 5 лет в Zalando. В LinkedIn я написал пост благодарности коллегам, собрал свои достижения, но вот что я вам скажу ребята... Кроме нас самих всем плевать на наши достижения. Люди особенно в корпоративном мире заботятся больше о себе и чем выше ты поднимаешься, тем больше это ощущаешь. Поэтому ПРИСВАИВАЙТЕ СЕБЕ ДОСТИЖЕНИЯ! Я переписал пост в LinkedIn 3 раза, потому что боялся "а что подумают эти и те". Плюнул и написал как думал. Нам Программ и проджект менеджерам особенно тяжело, когда мы работаем в связке с Продактам или крутыми Инженерами. Часто мы "временно" на проекте, решил проблему, боль, настроили всё и о нас забыли. Достижения уходят к другим людям, про нас забывают. Так вот, на 5-ый год в Zalando я понял, что нужно забирать достижения себе! И вас к этому призываю. А ещё призываю вас к тому, чтобы вы признали какие вы ахуенные. Например у меня: - Я запустил Feed (чертову ленту в Zalando). Вы прикиньте? - Запустил Борды (аналог Pinterest) - Сделали профайл пользователей Между прочим во многих компаниях только за один такой продукт отвечают десятки и сотни, а я блин побывал везде! - Дальше куча экспериментов с профайлами - Видео в Zalando! Короткие видео. Мы сделали Инстаграмм в Zalando и я лидировал это! Охуеть! - Понимание контентов, алгоритмы, ML- охуеть 2!!! Я всё это делал - Потом я перешёл на самую крупную миграцию за 2-3 года в Zalando и залидировать программу из 8 проектов, с экономией по 3 млн. долларов, репортил CTO, и сделал это ну просто КАК КРАСАВЧЕГ!! ВАХ!!! -Благодаря этому меня поставили на AI топик и теперь я внедряю AI в Zalando для Non-tech. Ебануться))) Общаюсь с Гуглом, Антропик. Мама я в шоке! Там конечно столько политики, но я даю крутой результат и надеюсь меня не дропнут. Короче я очень рад, что я хорош! Причём тут вы? Я написал этот пост на кортизоле и дофамине и конечно каждый день я не думаю так как я написал. Я страдаю, сомневаюсь и мной манипулируют. Хотя бы раз в год нам нужно принять эти достижения и даже лучше чуть-чуть завысить их, мозг всё равно откорректирует. И потом конечно написать в LinkedIn, тегнуть всех (как я и сделал). Вот такая вечная борьба достигатора с синдрома самозванца. Так что 5 лет в Zalando. Я в шоке! Лидом и директором не стал, денег много не поднял, но репутация отличная. Принимаю поздравление и кого зарефералить?) азаза)

Бот на зарплате — Соедините с человеком. — Я человек. — Тогда с тем, кто может что-нибудь решить. На сайте Port возле чата обещают: ответит живой человек. Наличие сотрудника стало фичей :) Идея клевая, пока не вспоминаешь оператора, который двадцать минут повторяет «таковы правила компании». Прорываясь к человеку, клиент надеется найти того, кому разрешено сделать исключение. Продлить тестовый период, пока бухгалтер ищет платежку. Вернуть деньги за случайную покупку. Сказать: «Наш косяк, сейчас починим». А бизнес нанял винтика, запретил ему всё, кроме чтения инструкции, и написал на сайте «живая поддержка». Дороговато обходится озвучка справочника. Хотите утащить клиентов у таких — дайте сотруднику право решать. Например, возвращать до 5000 рублей без согласования. И вынесите это на сайт: «В чате — Маша. Может вернуть деньги без похода к начальнику». Правда, потом придётся разрешить Маше пользоваться этим правом. Вот тут у большинства и закончится вся человечность.

Есть ли у вас для меня вакансия? Я ищу работу Как проджект я сеньор, как техпроджект, наверное, мидл, а как AI-проджект пока джун Последние два года переобуваюсь под ИИ и не скрываю, что мне страшно: если не научусь работать в AI-native команде и не сдвинусь к product builder, мой менеджерский опыт однажды будет невостребован Хочу автоматизировать большую часть своей нынешней работы (например делаю hermes-hub), чтобы задачи доходили до пользователя без моего постоянного вмешательства, а я больше собирал прототипы и проверял гипотезы Если отдельный проджект после этого станет не нужен, значит, хорошо поработал. У меня за плечами 7+ лет в управлении, разработка под Android, команды под 100 человек, свои 2 стартапа и работа напрямую с C-level. В сортах писцов я разбираюсь Поботал в МТС и Яндекс.Деньгах и Twinby. Мне одинаково интересно собрать на коленке Telegram-бота за час и год готовить компанию к продаже инвестору. Ну те масштабы и специфика задач, если мне сказано надо, меня не смущают В Twinby я Product Owner антифрода и, кажется, успешно перевёл три команды на AI-рельсы. Для стартапа Curestry я тащил продуктовку, можно считать меня еще личинкой продакта Ещё руковожу AI Engineers Guild, нас уже 800+, и развиваю AI STP: open-source сервис для управления AI-ландшафтом и нечто вроде Патреона/бусти для разработчиков. Ближайшее - аналог skills.sh Я люблю жёстко пахать и потом хвалить себя за то, как славно всё превозмог. Чем сложнее кейс, тем больше кайфую. Верю, кому-то нужен тревожный перерабатывающий менеджер с техническим прошлым Что забавно: сам консультирую по карьере, менторю людей и даже пилю сервис поиска AI-вакансий job_ftch, а себе собираю отказы от hh до карьерных сайтов. То ли глаз замылился, то ли рынок стал совсем недружелюбным Ищу либо что-то прям сложное, приправленное ИИ, либо что-то ИИ-шное, приправленное чем-то прям сложным По названию вакансии это может быть Senior Technical Project Manager, AI PM или Product manager. Я в Алматы, рассматриваю удалёнку Мой LinkedIn, резюме в нужной форме отправлю по запросу Если у вас есть такой кейс, напишите или познакомьте с командой. За удачную наводку обещаю ящик вкуснющего копченого казы или ответную услугу

Чтобы в продукте появилась новая функция, сначала нужно правильно сформулировать задачу разработчику (ну или нейросети). Один из подходов для этого - метод EARS (Easy Approach to Requirements Syntax). Этот метод позволяет формулировать требования к программным продуктам понятно, структурированно и без двусмысленностей. Разработал его в 2009 товарищ Алистар Мавин для компании Rolls-Royce. Вот, кстати, его сайт, там и про EARS есть. Метод выделяет пять основных шаблонов для описания различных сценариев поведения системы: 🔹Постоянные требования (Ubiquitous) действуют постоянно без условий - [Система] должна [действие]. 🔹Управляемые состоянием (State-driven) активны при определенном состоянии - Пока [состояние], [система] должна [действие]. 🔹Управляемые событиями (Event-driven): срабатывают в момент триггера - Когда [событие], [система] должна [действие]. 🔹Требования с доп. условиями (Optional-feature) применимы при наличии конкретной функции - Где [функция или возможность], [система] должна [действие]. 🔹Требования при нежелательном поведении (Unwanted-behaviour) описывают реакцию на ошибки - Если [нежелательное условие], [система] должна [действие]. Пример: Когда пользователь нажимает кнопку «Сохранить», система должна добавить вакансию в список избранного пользователя. Это требование понятно разработчику, тестировщику и заказчику. Вот тут подробнее. #process

Рефлексия недели Прошло две недели сентября. По плану мы идём минус :5%. От августа отстаём на 8%, а от прошлого года по выручке - на 6,8%. Клиенты продолжают падать, и вот это вызывает у меня самый большой страх. Начали работать с клиентской базой 90+. Так как отдела продаж у нас сейчас нет, задача легла на администраторов и управляющих, всех, кто может к этому присоединиться. И вот что удивительно. Казалось бы, для людей это прямая возможность нарастить клиентский поток, выполнить планы и получить премию. А отнеслись многие к задаче как к формальности, и пришлось прикладывать много управленческого давления, чтобы убедить не писать для галочки. Столкнулись с тем, что сообщения уходят либо устаревшие, либо слишком банальные, серийные. «Мы по вам соскучились». «Не пора ли обновить маникюрчик?». «У нас есть горящие окошки». Ну, вы поняли. Человек не ходил к нам три месяца, а мы ему про горящие окошки. После ряда управленческих пинков ситуация начала выравниваться. Стали писать вдумчивее, работать с клиентом с большей, я бы так сказала, заинтересованностью, и конверсия потихонечку поползла вверх. Второе, что стало очевидно на этой неделе. Проанализировав графики июля и августа, выяснили, что при среднем количестве специалистов в смену 4-5 у нас ровно на единицу меньше. И это проблема многих салонов сети. То есть нам рассказывают, что клиентов нет, а на самом деле весь сезон стабильно не хватало рук. Приняли ряд управленческих решений и поставили задачу, чтобы в сентябре эту ситуацию выправить. Сейчас после сезона вакансии закрывать полегче, и это приоритет номер один у каждого управляющего - составить график так, чтобы рук в смену хватало. И третье, коротко. Какое-то общее состояние расслабленности управленческого состава. Такое ощущение, что после лета никак не могут собраться, и при этом как будто всё хорошо, хотя клиентский поток продолжает падать. Не очень понятно, что это. Вообще, если собрать всю неделю в одну мысль, получается так: мы всё лето думали, что нас бьёт рынок, и это правда тоже. НО! половина того, что нас бьёт, сидит внутри - в неукомплектованный графиках, в формальных сообщениях и неком расслабленном состоянии в том числе.

Задолбали принимать плохие решения Если ты умный, талантливый, красивый руководитель, прекрасно танцуешь и увлекаешься спортом, то тебя раздражает, что твои сотрудники все время притаскивают какие-то идиотские решения. Ты, разумеется, знаешь как правильно и объясняешь им, но в следующий раз ситуация повторяется один в один. И чем больше ты подсказываешь им правильные решения, тем больше они к тебе ходят. Замкнутый круг! Настало время правды, дружище: твои решения кажутся ТЕБЕ лучше только потому, что их придумал ТЫ. Потом ты продавливаешь их и в результате они принимаются. А на самом деле хз вообще как правильно. В результате ты начинаешь больше принимать великолепных решений за своих сотрудников, они теряют волю и начинают бегать к тебе по любому вопросу вообще. Лучшее, что ты можешь сделать в такой ситуации - отвалить от своих людей и дать им возможность решать самим, ошибаться самим и исправлять свои косяки тоже самим. Попросят помочь - поможешь. Если нужно - задашь вопросы, чтобы убедиться что твои ребята продумали все нюансы. Можешь предложить свою идею, но финальное решение оставь за людьми, иначе так и будешь возиться с ними как с детьми и у тебя не останется времени на ведение Телеграм канала.

Ресурсы, на которых строится бизнес Любая идея требует опоры. Без ключевых ресурсов даже самый амбициозный замысел не станет реальностью. Вот что важно: Финансы — стартовый капитал, оборотные средства, доходы. Деньги обеспечивают движение. Интеллект — ноу-хау, бренд, авторские разработки. Это то, что отличает вас от конкурентов. Люди — команда, партнёры, специалисты. От них зависит рост и устойчивость. Материальная база — техника, офисы, транспорт. Без инфраструктуры не будет процессов. Проанализируйте, какие ресурсы особенно значимы для вашей модели. Укрепляя их, вы закладываете прочный фундамент для стабильного и масштабируемого роста Фаундер | Бизнес и Стартапы

Как-то у меня невиданными просмотрами разлетелся рилс, где я говорю, что можно быть добрым и опасным. И советую это каждому руководителю. Друг рассказал, что он эту тему развил дальше, и отслеживает теперь, сколько раз каждый день от своих коллег он что-то требует и сколько раз он хвалит. Про требовать интересное. Для некоторых из нас это самое сложное - быть конкретным и сказать, как я хочу, и что для меня хороший результат. Будто от моей конкретики мир куда-то разрушится и кто-то пострадает. Где-то рядом и похвала: а за что хвалить, а разве и так непонятно, что если все ок, то и реакция моя ок. А люди сложнее, им важно, им хочется, они готовы додумывать, но будут это делать в другую сторону. Так что да, завтра рабочая неделя. Те из нас, у кого счет ноль-ноль в требовать-хвалить, могут потренироваться. А там и люди нас удивят, и чаще положительно удивляют, кстати ❤️

Восемь часов онлайн ≠ восемь часов работы. Зачем мы вообще логируем время сотрудников? Разработчик два часа пишет код, потом закрывает IDE и лезет в документацию, спорит о решении с коллегой, идёт за кофе. И вот на этой прогулке, когда не двигается ни мышь, ни клавиатура, до него доходит, что предыдущий вариант архитектуры вообще не стоит трогать. Самое ценное за три часа случилось там, где ни один таймер ничего не засёк. А контроль присутствия видит совсем другое. Зелёный статус, запущенный счётчик, аккуратные восемь часов в отчёте. Красивая цифра, которая о результате не говорит ровным счётом ничего. Стоит начать требовать эти часы, и человек быстро научится их показывать, без всякого злого умысла, просто подстроившись под правила игры. Ловушка захлопывается тем крепче, чем умнее работа.

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

Автоматизация с умом Не спешите покупать дорогие CRM, если в бизнесе ещё не выявлены самые «трудоёмкие» процессы. Сначала просто зафиксируйте, куда уходит время вашей команды и ваше собственное. Если менеджеры повторяют одни и те же ответы клиентам — создайте шаблоны в мессенджерах. Быстро, просто и бесплатно. Если сделок в месяц меньше 50, вместо сложных систем подойдут Google Таблицы и Trello. Автоматизация — это не мода, а здравый смысл. Чем проще инструмент, тем быстрее он начнёт приносить результат. 👉 Главное — не масштабировать хаос, а сначала навести порядок, а потом усиливать процессы. Маленькие шаги здесь эффективнее громоздких стратегий. Фаундер | Бизнес и Стартапы

Зачем компаниям культура и ценности? Потому что так устроен нормативный контроль. Я в целом конечно немного упрощаю. Но идея имеет обоснование и подтверждения: нормативный контроль как менеджерская стратегия исследуется уже много десятилетий. В чём суть? Можно управлять через формальные процедуры, отчётность, KPI и другие инструменты прямого контроля. Но это влияет на ощущение субъектности и автономности у сотрудников. И плохо работает в задачах, где нужна креативность, инновационность, предпринимательское мышление и другое сложное экспертное поведение. Поэтому американская менеджерская мысль изобрела нормативные способы организовывать людей. Через базовые принципы, почти заповеди, благодаря которым человек может сам принимать решения: как должна быть устроена работа, как формируются отношения и коммуникация, что считается нормой, и как должен выглядеть правильный результат. В какой-то момент эти принципы интернализируются. И тогда огромное количество решений уже не нужно отдельно описывать, согласовывать и контролировать — люди сами понимают что как надо делать. На эту тему есть очень хорошая статья 1992 года — «Design and Devotion: Surges of Rational and Normative Ideologies of Control in Managerial Discourse». Авторы разобрали историю американского менеджмента с 1870-х годов и показали, что рациональный и нормативный подходы сменяют друг друга примерно каждые 30 лет: 1870–1900 Industrial betterment (нормативный) 1900–1923 Scientific management (рациональный) 1923–1955 Welfare capitalism / Human relations (нормативный) 1955–1980 Systems rationalism (рациональный) С 1980-х Organizational culture (нормативный) Они сопоставили эти пять волн с большими экономическими циклами и обнаружили, что рациональные подходы усиливаются в периоды экономического роста, а нормативные — в периоды спада и сокращения. В период экспансии выгоднее инвестировать в технологии. Драйвить идеи автоматизации. Перестраивать производство. Люди не так важны. Но когда отдача от технологий и инфраструктуры снижается и экономика переходит в фазу замедления, бизнес начинает искать в людях новый источник производительности: Как повысить доверие? Как снизить конфликты и противоречия? Как добиться максимально эффективного сотрудничества? Как сделать так, чтобы люди были заинтересованы в целях и успехах компании? Я думаю, что нас ждёт рост популярности нормативных способов управления в следующие десять лет. И рост популярности «культурного» менеджмента. Тут можно возразить: а как же AI? Разве мы не входим в эру процветания и новую большую волну автоматизации — то есть в тот самый период, когда должны побеждать рациональные модели управления? Только если мы верим, что AI и правда запустит новый цикл экономического подъёма. Но мы же не верим? В комментариях оригинал статьи и текстовый саммари.

25 лет со дня 9/11. Дайан Брэди, редакционный директор Fortune, в своей рассылке CEO Daily вспоминает руководителей, которым в то утро пришлось на практике выяснить, что значит управлять компанией в кризис✍️ Джефф Иммельт был CEO General Electric всего второй день. Утром 11 сентября он находился в Сиэтле, где должен был провести встречу с сотрудниками. Перед ней занимался на степпере и в какой-то момент увидел по телевизору, как второй самолет врезался во Всемирный торговый центр. Его предшественник Джек Уэлч в это время был в Нью-Йорке. В телестудии он давал интервью о своей книге Straight from the Gut, когда в первую башню врезался первый самолет. За несколько дней до этого Брэди брала интервью у Иммельта в штаб-квартире GE в Коннектикуте. Он пил диетическую колу, ел претцели и уверенно рассказывал, как собирается руководить одной из крупнейших и самых дорогих компаний Америки. После терактов все рейсы отменили, и Иммельт на три дня застрял в Сиэтле. Работал оттуда, пытался разобраться в происходящем, организовывал помощь сотрудникам. Двое сотрудников GE погибли. Все планы больших преобразований и сделок пришлось отложить. Брэди называет то, что осталось, «менеджментом 101»: звонить клиентам, держать связь с сотрудниками, распределять ресурсы, помогать пострадавшим и действовать по кризисному плану. Говард Лютник в то утро, наоборот, опоздал на работу. Нынешний министр торговли США тогда возглавлял Cantor Fitzgerald. 11 сентября он решил сначала отвезти сына Кайла в детский сад — и поэтому не оказался в офисе. Cantor Fitzgerald занимала верхние этажи Северной башни. Лютник потерял брата и 657 сотрудников — больше двух третей компании. Через несколько недель Брэди встретилась с ним. Она вспоминает, как плакала, пока Лютник рассказывал, что значит в один день потерять больше двух третей сотрудников, а затем пытаться продолжать платить их семьям, когда доходы самой компании рухнули. Cantor Fitzgerald выжила и до сих пор каждое 11 сентября отдает всю выручку за этот день на благотворительность. Саму Брэди редакция 11 сентября отправила в Нижний Манхэттен, в больницы, — искать выживших и брать у них интервью. Но выживших туда не привезли. При этом тысячи людей успели выйти из башен. Многие благодаря Рику Рескорла, отвечавшему за безопасность Morgan Stanley. Рескорла был ветераном Вьетнама и давно считал Всемирный торговый центр возможной целью террористов. Еще за три года до теракта 1993 года он предупреждал о вероятности атаки с помощью заминированного грузовика. После того теракта Рескорла изучил ошибки при эвакуации, составил новый план и заставлял сотрудников Morgan Stanley регулярно тренироваться. 11 сентября это спасло им жизнь. После попадания первого самолета администрация Всемирного торгового центра призвала людей в Южной башне вернуться на рабочие места. Рескорла решил не выполнять это распоряжение и начал эвакуацию. Считается, что благодаря ему из башни вышли около 2700 человек. Сам Рескорла погиб. @karpovaventures✍️

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

Meta* отменяет оценку сотрудников по количеству сожженных токенов В 2025-26 году компания ввела ожидания "AI-driven impact" и присваивала сотрудникам лейблы "AI Native", "AI First" и "AI Enabled" за количество сжигаемых токенов. 26 сотрудников подали на компанию в федеральный суд. Они утверждают, что Meta при увольнениях использовали метрику использоваия AI, а это нечестно это не объективная метрика, не отражающая их достижений. Другие сотрудники изобрели накрутку токенов уникальную технику tokenmaxxing закидывая в AI сложные бессмысленные задачи, целью которых было максимизировать потребления токенов Суд еще не принял решение, но в сентябре 2026 Meta уже откатило AI-driven политику. И продолжает утвреждать, что эти метрики никак не влияли на перфоманс ревью. Мне нравится представлять этих серьезных менеджеров в пиджаках в большой футуристичной переговорке. Они собрались на собрание: — Окей, Джон, ты слышал про AI? — Да, Марк, отличная технология, она поможет нам много заработать. К сожалению, наши работники не желают ускоряться. У них по-прежнему меньше 5 агентов на человека — Джон, а что если заставить каждого сотрудника максимально использовать токены? — Марк, но ведь у нас есть уже есть сторипоинты, дашборды и time-to-market. Разве мы не должны учить их использовать AI и отслеживать ускорение работы по ним? — Бро, это регрессивные метрики отсталого мира, они не Ai First. Пусть жгут токены, авось чето выйдет. — Отлично, давай награждать их медалями AI First и увольнять, если сожгли мало! — Делаем! Сможет ли российской IT не внедрять практики по принципу "Да просто сделаем как в FAANG", увидев конец истории? Или сначала внедрит, а потом отменит, еще и об оптимизации бюджета доложит? Буквально такая же история была с Гигачадом и обязательным использованием GigaChat. А ваш тимлид уже приказал вам жечь больше токенов? *Деятельность организации Meta ризнана экстремистской и запрещена на территории Российской Федерации

Как-то на AI-созвоне участник рассказал на своем примере, кого заменят AI-агенты, а кого нет. Но еще важнее - поделился, почему. Недавно он за неделю в одиночку с Клодом сделал проект, который его команда из шести человек делала полгода. Продакт-лид, с 15-лет стажа, всю карьеру был уверен, что самый важный навык - это собрать команду и четко раздать роли. Потом случилась эта неделя и по его словам, нормально так порвало шаблон. Его метафора и важный инсайт: работа в эпоху AI = уметь круто стрелять из рогатки. Чем точнее видишь цель, умеешь ее сформулировать и направлять нейронку, тем сильнее выстрел. Старый топовый навык - собрать команду, раздать роли и задачи, назначить ответственных - потерял ценность буквально на глазах. Теперь он стал про другое. Заменит ли меня AI? Может, вопрос в другом: насколько четко я умею направлять к нужной мне цели, понятной без лишних слов?

9 новых статей от гаражистов на 🔤🔤🔤 ИИ и автоматизация

👉 10 инсайтов, которые я нашел, когда автоматизировал конкурентную аналитику Маркетинговый аналитик Вова собрал ежедневный пайплайн из Sensor Tower, Similarweb, BigQuery и Tableau. В статье он рассказал, почему смотреть только на установки бесполезно и как находить лучшие креативы конкурентов автоматически. 👉 От текста к смыслу: Embeddings, GPT и многомерные векторы И снова Вова, теперь про то, как связка Embeddings и GPT превращает тысячу разрозненных отзывов в карту бизнес-тем за десять минут, в том числе по отзывам конкурентов. 👉 Роботы работают, пока ты (не) отдыхаешь Android-разработчик Платон о том, как отдал агенту весь цикл доставки кода: свой открытый пайплайн, честное деление задач «агент/человек» и ответ на вопрос, реально ли собрать стартап за вечер (спойлер — нет).

Аналитика, риски и антифрод

👉 Аналитик, который кричал «Волки!» Senior-аналитик Вова о том, как перегруженную систему алертов заменили превентивным поиском мошенников через граф связей: пики нагрузки ушли, качество проверок выросло. 👉 Как автоматизировать работу с рисками Product Owner Настя рассказала, как с нуля с командой собрала риск-операционную систему для операционного департамента инвестплатформы: от MVP с точностью алертинга 15% до 99% и реакции на риск в четыре раза быстрее. 👉 От сервиса к партнерству Руководитель продуктовой аналитики Олег разобрал семь вещей, которые помогли превратить аналитиков из исполнителей в партнеров продукта: 1-1, мотивационные карты, карьерные треки, кор-команду и другое.

Код, продукт и дизайн

👉 Как не захлебнуться в User Stories UX writer и ресерчер Даша о том, как развести пользовательские истории по уровням Кокберна и собрать под них HTML-инструмент с фильтрами, RICE-скорингом и экспортом в Excel. 👉 От потоков к корутинам: примитивы синхронизации в Kotlin (Часть 2) Android-разработчик Никита разобрал семафоры, каналы, SharedFlow, модель акторов и dispatcher confinement с примерами кода и итоговой таблицей «потоки против корутин». 👉 Дизайн за 5 минут. Дайджест августа 2026 Продуктовый дизайнер Андрей собрал главное за месяц: новый логотип Instagram от студии Koto, систему иконок Uber, Skills и ластик в Figma, ребрендинг «Индилайта» и логотип цифрового рубля.

#GarageEight_habr

Умри или сдохни Люблю иногда посмотреть стартап контент на ютубе. История такая: чувак пилит очередной ИИ стартап и пилит про это влог. Все красиво, модно-стильно-молодежно. Наступает момент запуска стартапа, чувак открывает окно продаж, берет day-off на три дня и куда-то там уезжает перезагрузиться. Три, сука, дня. Возвращается в понедельник на работу, и говорит: “ой, продаж меньше чем ожидалось на 60%”. Я про себя думаю: чувак, сидел бы ты работал, может и не проебал бы запуск. Запуск это вообще единственное время в жизни продукта, когда на тебя вообще кто-то смотрит, дальше все привыкнут и всем похер. Если ты делаешь ЛОНЧ как он должен быть – сиди и работай по 16 часов в день, и молись чтобы все прошло хорошо. А если запускать стартап так, как будто ты работаешь в найме на работе, то у реальных варианта у тебя только два – умереть или сдохнуть)

🤔Мысли вслух В этом году по инету разошёлся скрин, где показывались все игры Capcom за 10 лет и баллы к ним: ни один из проект не просел ниже 80 пунктов от критиков. Люди удивлялись: как так, в недавно компанию называли Crapcom из-за кучи слабых тайтлов, а теперь даже новые «айпи» взрывают. Что ж, на это ответили сами разрабы и там прям пример грамотной работы начальства с творческим коллективом. Так после провалов эпохи PS3/Xbox 360 (Lost Planet 2, Monster Hunter Tri, Dark Void, Resident Evil 6) ребята поняли, что следовать чужим трендам было ошибкой. После, в 2009 году, глава EA Джон Ричителло сказал озвучил стратегию для своей компании: «меньше, масштабнее, лучше» — меньше релизов, но больше качества. ЕА этого придерживаться не стали, а вот в Японии слова услышал продюсер Onimusha: Way of the Sword — ему они запали в душу и далее ушли в Capcom. Плюсом ребята начали назначать зарубежных разрабов (Питер Фабиано, Мэтт Уолкер, Ричард Пирс, Навид Хонсари) на старшие позиции, чем сильно отошли от традиций японского геймдева, где яюв основном японцы работают с японцами. В целом пошёл курс на глобализацию: так локализация стала непосредственной частью разработки. Наличие перевода рассматривалось со старта продакшена, а руководитель отдела расширял глобальную аудиторию. Так же компания перестала обещать то, чего не сделает: анонс происходит только при четком плане релиза. Исключение — Pragmata. Так, постепенно, было охарактеризовано понятие «Ощущение Capcom» — единый стиль. Он идёт через разные игры и наблюдается в характерных плавных анимациях, сочных ударах с замедлением на миллисекунды и качественном звуке. Компания перекроила свой подход к играм, прекратила витать в облаках, отстроила узнаваемую айдентику и открылась миру... Вау. Это реально сработало. Возможно даже, кто-то возьмёт с этого пример. 😏Подписаться на IGM

Что ИИ ломает в продуктовой команде и почему старые роли больше не работают Спикер: Андрей Южаков Раньше работа двигалась по цепочке: аналитика → дизайн → разработка → тестирование. Каждый передавал дальше контекст в виде артефакта. С агентами всю цепочку может пройти один человек. С приходом ИИ меняется сама единица работы: вместо отдельного артефакта ей становится клиентское изменение целиком, которое один человек ведет end-to-end, подключая экспертов там, где это необходимо. На примере банковского продукта мы проверили новую модель на большом сценарии в интернет-банке. С помощью агентов удалось самостоятельно подготовить требования, API, UX, архитектуру, бэкенд, фронтенд, gateway и тесты. Первая версия появилась примерно за неделю. Но дальше начали ломаться привычные процессы. Первая поломка: автор изменения больше не обязательно владелец результата. Границы ролей размываются. Менеджер продуктов может написать код, разработчик — придумать и реализовать фичу, дизайнер — самостоятельно внести изменение в продукт. Но возможность что-то сделать ≠ ответственность за качество результата. Например, раньше дизайнер готовил интерфейс, а затем ждал приоритизации и разработки. Теперь он может получить доступ к агенту и репозиторию и самостоятельно внести изменение. Но ответственность за UX остается на дизайнере, а за техническую надежность — на инженере. Поэтому важно определить, кто отвечает за бизнес-результат, клиентский опыт, техническое качество и стандарты — и кто в итоге может сказать: «это можно выпускать в продакшн». Вторая поломка: генерировать мы научились быстрее, чем проверять. Первую версию фичи удалось сделать за неделю, но до продакшна она дошла только через два месяца. Выяснилось, что существует множество стандартов и требований, которые нигде нормально не описаны. Узкое место сместилось с создания решения на проверку его качества: после перехода на новый процесс с агентами до 78% времени стало уходить на code review. Но и это еще не все. Отдельные части решения могли успешно пройти тесты, а после сборки на тестовом контуре начинали ломаться интеграции. Поэтому пришлось пересматривать интеграционные тесты и способы получения обратной связи. Третья поломка: привычные профессиональные роли перестают совпадать с тем, что реально делает человек. Раньше было понятно: frontend-разработчик отвечает за свой участок, backend-разработчик — за свой, аналитик, тестировщик и дизайнер — за свои. Но что происходит, когда с агентом можно сделать работу соседней роли или вообще пройти всю цепочку самостоятельно? В примере банковского продукта мы перешли к модели, в которой один человек ведет изменение end-to-end: от постановки задачи до реализации и проверки качества. Так появилась более широкая роль product engineer — человека, который лидирует клиентское изменение целиком, а не только свой технический кусочек. Такая перестройка вызывает вопросы: «Почему я должен писать тесты?», «Почему должен вести документацию?», «Я буду делать чужую работу хуже». Поэтому просто дать команде агентов недостаточно. Нужно заново ответить на вопрос: за что мы ценим человека в продуктовой команде? Сейчас по новой модели в банковском продукте работают уже восемь команд, а через новый процесс в продакшн провели больше 200 изменений. То, что раньше могло занимать около полугода работы команды, в эксперименте удалось довести до продакшена примерно за два календарных месяца. Агенты могут написать код, сделать дизайн, подготовить требования или тесты. Но они не определят за нас, что такое хороший код, хороший клиентский опыт или надежный продукт. Критерии качества, стандарты и ответственность остаются на людях. Поэтому при перестройке команды важно определить: — кто отвечает за результат для клиента; — кто отвечает за надежность и качество; — кто принимает решение о выпуске; — кто ведет изменение целиком. И еще одно правило: если после ошибки не появилось новое правило, тест или стандарт — скорее всего, мы просто заплатили за эту ошибку и ничему не научились. @productsense

82% менеджеров - случайные. Или даже "accidental", если брать формулировку совместного исследования CMI и YouGov в 2024 году. Эти руководители буквально "управляют вслепую", основывая свои решения на интуиции. Эти же люди повышаются или повышают сами просто из-за хороших отношений (в этом призналось 46% менеджеров), а не профессиональных компетенций, надеются только на свои софты, не имеют организационных навыков. И не имеют ни малейшего понимания о том, как же всё реально работает. И объясняет чуть более, чем полностью, почему современный менеджмент - такой рашен манежмент. Тут, конечно, есть нюанс: речь всё-таки идёт про формальное обучение, а не про оценку квалификации руководителей. Всё верно. И там же даже приводится другая статистика: что всего у 74% директоров формальное обучение всё-таки имеется. Вот только даже формальное обучение имеет мало смысла. Все исследования прямо говорят, что даже MBA, самое элитное и топовое образование никаким образом пользы бизнесу не приносит. И директора с MBA показывают при прочих равных ровно те же результаты, что и без него. А ещё в кризисе и после оптимизаций они гробят бизнес даже чаще. Так что современный менеджмент - мир случайных менагеров. А не профессионалов высшей категории. И эта проблема встречается в крупных и успешных компаниях так же часто, как и в небольших. Разве что понтов и пафоса с навыками пускания пыли в глаза намного больше. P.S. В этом смысле найм - процесс отбора случайных людей случайными людьми по случайным методикам. И обречён не только на уровень провалов в 50+% для директоров, но и на консервацию этой системы.

Вчера мы приняли довольно простое решение, которое, кажется, наконец сняло проблему, из-за которой я нервничала последние несколько недель. Мы сейчас очень быстро развиваем продукт: новая логика, плейбуки, изменения почти каждый день. И в какой-то момент поняли, что каждое новое улучшение может случайно задеть то, что уже хорошо работает у клиента. Не в смысле, что всё ломается, а хуже😄 Клиент привык к определённому процессу, встроил его в работу, а мы меняем логику. Формально продукт продолжает работать, но результат уже другой. И для клиента это выглядит просто: вчера было хорошо, сегодня стало хуже. Очевидно, что так продолжаться не должно. Поэтому мы разделили продукт на две ветки. Первая - стабильная: на ней действующие клиенты. Три недели ничего нового не выкатываем, только исправляем ошибки. Вторая - экспериментальная. Там можно тестировать новые идеи, менять логику хоть каждый день и быстро проверять гипотезы. Если что-то хорошо работает в экспериментальной версии, через три недели переносим это в стабильную. На первый взгляд решение довольно очевидное. Но для меня здесь оказался важный вывод. Теперь у нас есть скорость для тех, кто хочет экспериментировать, и стабильность для тех, кому важно, чтобы просто работало. Интересно, как вы решаете эту проблему у себя? Держите отдельную версию для действующих клиентов или выкатываете всё сразу и уже потом разбираетесь по ситуации?