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

Статус «Готово» врёт «Закрыть задачу» может означать совершенно разные вещи: закончил, передал дальше, перестал делать, отложил до завтра. Часто ловлю тему, когда кто-то кому-то говорит «Готово», но в реальности это не то, чего ожидают. Примеры Разработчик говорит «Готово», когда написал свой кусок кода и отдал в тесты, но весь функционал ещё не вылез на прод. «Готово», когда фича уже на проде, но в A/B-эксперименте собирает данные. «Готово», когда раскатано на всех, но через пару-тройку месяцев не сняты повторные цифры, о которых договаривались. И ведь не обязательно кто-то врёт. Хотя и такое бывает. Просто один говорит про код, второй про запуск, третий про результат. А слово у всех одно. Дальше недопонимание, набросы, потеря энергии. Почему так Потому что мы варимся в разных контекстах и взгляд на «Готово» у каждого свой. Что делать на уровне задач Договориться о критериях готовности. На стол/бумагу/джиру/конфлюенс: - Что именно должно быть готово? - Кто принимает результат? - Что происходит после этого и кто подхватывает дальше? В разработке часть этой договорённости закрывает Definition of Done (DoD): общие критерии качества готового результата. Но кто принимает результат и что происходит дальше, тоже нужно проговорить. Что делать на уровне команд Проговаривать смысл слова «Готово». Объяснять, что вы как продакт вкладываете в это понятие. И выяснять, что под ним понимает команда. Калибруетесь несколько итераций и потом понимаете друг друга с полуслова. P. S. А какой статус по задачам в вашей работе врёт чаще всего? Напишите в комментариях. #инструментыпродакта

Отладочный режим, который стал игрой Всё началось с отладочного режима, позволяющего отматывать время назад. Команда превратила эту возможность в главную механику ритм-шутера, который впоследствии получил две номинации IGF и награды за дизайн и звук. За четыре года разработки версии для PS3 небольшая команда успела написать 748 тысяч строк кода, создать собственный движок и поработать по 80 часов в неделю. Игра вышла, получила хорошие отзывы критиков, а студия после релиза фактически развалилась. Один из сооснователей выгорел и ушёл в найм. Никакого громкого скандала или провала игры. Как технически сильная команда дошла до такого финала? Разобраться в истории помогают постмортем с GDC и модель командных ролей Белбина.

Когда то давно я прочитал книгу «Гении и аутсайдеры» Малкольма Гладуэлла. Там есть интересная история об авиакомпании Korean Air, которая в период с 1988 по 1998 год потеряла в авиакатастрофах 6 самолетов. Гладуэлл связал эту проблему с культурными особенностями корейского общества - жёсткая иерархия мешала общению внутри экипажа. Второй пилот и бортинженер могли заметить ошибку командира, но не решались прямо ему об этом сказать. Вместо «мы в опасности, нужно срочно что то делать!!» получалось вежливое замечание, на которое командир не реагировал. В западной и русской культуре такой проблемы нет. Если у самолёта заканчивается топливо, то говорить вежливыми намёками точно никто не станет. Но тем не менее в обычной работе мы тоже регулярно разговариваем так, что порой нам трудно понять друг друга. Вот пример из жизни: На совещании руководитель спрашивает начальника отдела снабжения: — Что у нас с 35-й фольгой? В переводе - У нас на складе заканчивается эта позиция. Хватит ли её до следующей поставки или производство встанет? Снабжение отвечает: — Контейнеры забукировали на 22-е число. В переводе - Мы работаем, стараемся, процесс идёт! Помог ли этот диалог понять, когда фольга поступит на склад и хватит ли запасов до её приезда? Никак. Тем руководителем, который спрашивал про фольгу был я, и с тех пор многое что изменилось. Отдел снабжения создал понятную систему, которая помогает планировать закупки, отслеживать сроки поставок и запасы сырья. Если какого-то материала может не хватить, система подсвечивает проблему заранее. В компании создан глоссарий, где собраны все термины, которые могут быть непонятны новичку. Все руководители регулярно проходят обучение. В том числе учатся ставить и контролировать задачи. А я стараюсь задавать правильные вопросы, чтобы получить нужный ответ. Если кого то интересует тема коммуникаций в команде, то я рекомендую хорошую книгу на эту тему «The Culture Map: Breaking Through the Invisible Boundaries of Global Business» (в русском переводе «Карта культурных различий. Как люди думают, руководят и добиваются целей в международной среде») Она про международные команды, но поверьте, такие же проблемы есть и в наших коллективах. Часто авторы книг (как и авторы многих тг каналов🙂) подтасовывают факты ради эффектного контента. Я полагаю, что Гладуэлл в своей книге сильно преувеличил значение культурных особенностей корейского общества. Другие авторы много раз после этого обсуждали тот пример с Korean Air, и пришли к общему мнению, что большое количество катастроф было связано с низким качеством подготовки пилотов авиакомпании. Поэтому следующий пост будет про обучение работников. Как организовать обучение так, чтобы на выходе получить лояльного, квалифицированного и мотивированного человека? Какое соотношение теории и практики оптимально? И как развивать работника дальше? Не переключайтесь Незаметный бизнес

Как использовать мессенджеры для повышения ярости в команде Если ты нормальный продакт менеджер, то ты никогда не удовлетворен уровнем ненависти к себе. Тебе всегда хочется больше. Самый простой способ довести команду - использовать мессенджеры. • Пользоваться функцией меншена отдельных людей недостаточно. Активно используй everyone и here, чтобы показать, что твой вопрос важен. • Голосухи. Ну это классика. Но ты можешь пойти дальше: ставь задачи на разработку голосухами, так ты шокируешь даже тимлидов, которые думали, что повидали все в своей жизни. • Напиши «у нас серьезная проблема» и пропади. Это создаст ощущение драматичности момента, чтобы подчеркнуть что проблема реально серьезная. • Кидай ссылки на статьи и посты без своих комментариев. Кто не понял к чему это - его проблема. В идеале, чтобы статья была недельной давности. • Если решил отправить скриншот, то только фоткой экрана монитора дрожащей рукой. Камера телефона гораздо лучше передает цвета да и это тупо удобнее. • Обращайся «коллеги», потому что ты же коллегам пишешь. • Капс. Невозможно довести команду, если ты не пользуешься капсом. Каждый дополнительный восклицательный знак к капсу - плюс 1 пункт к ярости команды. СРОЧНО удваивает накопленную ярость. • Если одно сообщение можно разбить на 10 (например, в сообщении 10 слов) - сделай это. • Если потенциал групповых чатов исчерпан, переходи на личку. Используй треды в личных сообщениях, чтобы дезориентировать собеседника. • Пиши «У НАС ЛЕЖИТ САЙТ!!!!!!!!!!!». Спокойная команда никогда не добьется значимых результатов. Великие воины побеждают только в состоянии ярости.

Йоу, герои 🖖️️️️️️ врываемся бодро в новую неделю 🚀️️️️️️ У нас на курсе Product Heroes Существует глоссарий метрик. Там всё чётко и ясно: что считаем, зачем считаем, как это связано друг с другом. Ловите, кстати, ссылочку, возможно, вам будет полезно: https://heroescamp.notion.site/199dba1806234e7ea5aa630545b0188a А для хорошего настроения отправляю вам глоссарий моих личных мемов.😉️️️️️️ 🐱 Тревожные котики Тревожных котиков надо успокаивать и гладить. Гладятся они промежуточными результатами, понятным процессом и понятным результатом на выходе. 🌬 Писать против ветра Сомнительное удовольствие. Особенно когда пытаешься переспорить человека и резко поменять его картину мира. 🕶 Розовые очки Это не когнитивные искажения. Это стратегический выбор вашей компании. 🧟 Франкенштейнизация Когда мы напилили сто-пятьсот фичей, а сценарий человека так и не работает. ➖ Операция вычитания Вот будут наши ожидания. Вот будет реальность. Операция вычитания. 🎬 Классика жанра Команда сделала фичу, не посмотрела на сценарий, получила ноль результата. Классика жанра. 🧩 Фичи, фичи, фичи Когда в продукте много всего, а человеку всё ещё непонятно, что делать. 🐦 Птичьи стереотипы старшей группы детского сада Профессиональный жаргон, за которым часто прячется непонимание сути. 🤐 У людей по умолчанию нет желания вам писать Пользователь не обязан разбираться, куда нажать, писать в поддержку и искать решение. 😰 Все тревожные. Выжили только тревожные. Без комментариев Пополняйте, если я что-то забыл.👌️️️️️️

Коварная память кодинговых агентов Быстрый рекап. В современных агентах по дефолту включена память, которая работает конкретно для вас. Поэтому со временем появляется ощущение, что оно работает все лучше и лучше. Иногда это приводит к казусам, когда что-то сильно меняется и агент работает по старинке, но если следить за чистотой и регулярно вызывать что-то типа /doctor в клод коде, то все будет норм. Такая схема хорошо работает для конкретного человека, но работает плохо и даже вредит при работе в команде. У каждого человека начинает копиться свой набор правил, который во многом дублируется, но при этом не распространяется на команду и не меняется синхронно при изменении чего-либо. В итоге мы получаем ситуацию, когда у новых людей все работает не так хорошо, а хорошие практики перестают распространятся или делают это медленно и не равномерно. Я в какой-то момент, когда увидел очередное "я понял, сохраню в память", психанул и запретил ему это делать. Он этот запрет тоже положил в память 🙂 Поэтому пришлось закатать рукава и проработать схему запрета в AGENTS.md. Можно сказать, а почему бы не выключить ее совсем? Есть таки таки вещи, где она нужна и где я не хочу сильно думать. Возможно там есть настройка которая позволяет память менять по проектно (щас пост опубликую и проверю) и тогда вопрос может быть решен кардинально. Какой у вас опыт с памятью? Telegram | YouTube | AI Клуб | Внедрение AI

Когда команде разработки готовят некую новую задачу, функцию продукта, это надо сначала понять и описать. Есть такой подход для командной работы - Event Storming. Это шумное сборище интенсивный воркшоп для исследования сложных бизнес-доменов. Помогает создать единое понимание бизнеса у разработчиков, аналитиков и заказчиков. По классике это происходит на большой стене с помощью стикеров. Команда выстраивает цепочки бизнес-процессов во времени (слева направо). Стикеры могут быть такие: 🟧 События (Domain Events) — факты, которые уже произошли (глагол в прошедшем времени). 🟦 Команды (Commands) — действия, запускающие события. 🟪 Агрегаты/Системы — то, что выполняет команду. 🟨 Акторы — люди или внешние системы, инициирующие действия. Пример из жизни: заказ такси. Процесс поулчается такой: 🟨 Пассажир нажимает кнопку в приложении. 🟦 Команда: «Создать заказ». 🟪 Сервис заказов принимает её. 🟧 Событие: «Заказ создан». 🟦 Команда: «Назначить водителя». 🟧 Событие: «Водитель назначен». 🟧 Событие: «Поездка завершена». Зачем это нужно? 🔹 Единый язык: cтирает границы между бизнесом и IT. Все говорят на языке домена. 🔹 Поиск дыр: cразу видны пробелы в логике, дублирование функционала и узкие места. 🔹 Фундамент для DDD: легче начать проектирование микросервисов и Domain-Driven Design. Подробненько всё расписано тут и тут. #process

Есть асимметрия, которую постоянно наблюдаю в командах. Многим чужая работа часто кажется проще своей. Со стороны аналитик "написал запрос и нарисовал график", QA "прогнал кейсы и завёл баги", а ML-инженер "запустил обучение и посмотрел метрики", но спроси того же человека, почему его собственная задача едет уже третью неделю, и выяснится, что там легаси, зависимости, смежники, корнер кейсы и ещё десять подводных камней, которых снаружи не видно. Чужую работу мы видим по результату, свою - изнутри процесса. У аналитика снаружи остаётся график, а сырые данные не видно, регулярно ломающийся пайплайн скрыт от зрителя, о трёх неверных гипотезах и запросе, который пришлось переписать четыре раза, внешние признаки не говорят. В своей же работе именно из этого и состоит большая часть времени. Часто в этом винят actor-observer bias: своё поведение мы объясняем обстоятельствами, чужое - качествами человека. Популярная теория, которая не прошла проверку мета-анализами. Оказывается, это лучше обьясняется другими двумя эффектами. Первый - correspondence bias: по чужому видимому поведению мы слишком легко делаем вывод о самом человеке и недооцениваем ситуацию. "Задача простая, значит они просто медленные". Второй - self-serving bias: собственные неудачи мы гораздо охотнее объясняем внешними обстоятельствами. Достаточно удобная комбинация, где сложность своей работы мы знаем во всех деталях, а сложность чужой просто не наблюдаем. При этом собственные издержки кажутся следствием объективных проблем, а чужие следствием чужой неэффективности. Поэтому "да что там делать" - почти всегда плохой сигнал, говорящий нам о глубине собственного понимания этой задачи. Если работа других людей выглядит тривиальной, разумнее сначала предположить, что большая часть процесса тебе просто не видна. Лучшее лекарство - контекст, а за контекстом надо "на гембу". Несколько часов рядом с хорошим QA, аналитиком или инженером часто дают больше, чем лицезрение движения тикетов. Похожая история и со сроками. В одном эксперименте про planning fallacy студенты в среднем ожидали закончить диплом за 34 дня, хотя по факту тратили 55. Даже максимально драматичный и негативный сценарий оказался в оценках оптимистичнее реальности. Поэтому оценку чужой работы полезно дисконтировать так же, как реальность это регулярно делает с нашей.

Безопасная культура Чтобы нормально работать с ошибками, нужно создать культуру психологической безопасности в компании. Безопасная обстановка позволяет открыто обсуждать ошибки. В результате ошибки проще убрать, проще разобраться с тем, как сделать так, чтобы подобные ошибки не повторялись в будущем. В культуре где принято обсуждать ошибки, люди могут сосредоточится на работе, а не на том, что про них подумают другие люди или начальство. В свое время Эми Эмодсон изучала вопрос как командная работа влияет на количество ошибок. Первый этап работы показал очень интересную зависимость: более продуктивные команды в больницах ошибались чаще. Это противоречило логике. После некоторых раздумий, Эми решала проверить гипотезу, что в более продуктивных командах сотрудники будут рассказывать про большее количество ошибок. В результате они начали второй этап исследования, где, в том числе ошибки фиксировал независимый участник, а не сама команды. И в опросник для команды включили вопрос: «Если вы совершите ошибку в этом подразделении, это не будет воспринято против вас». Выяснилось, что так и есть. В командах была совершенно разная атмосфера. Где-то люди открыто объявляли об ошибках — медсестры говорили что «определенный уровень ошибок неизбежен», поэтому для хорошего ухода за пациентами необходима «система ненаказуемости».В других отделениях было практически невозможно открыто говорить об ошибках, медсестры объясняли, что совершить ошибку - значит «попасть в беду» или «оказаться на скамье подсудимых». Они рассказывали, что, если что-то шло не так, они чувствовали себя ничтожными, «как двухлетние дети». #ЧФ #ошибки #психбезопасность

Как мы набросали 3 новых продукт за 3 часа На прошлой неделе с командой работали оффлай и в последний день решили сделать хакатон. Было офигенно! Рассказываю что успели: 1. Задача была – повеселиться, выйти немножко за рамки текущего продукта и "дать себе волю". Не было надежды что что-то из этого можно будет использовать в проде Разбились на 3 команды и делали 3 новых версии для продукта: - Маймит для HRов - Маймит для Sales - Маймит для исследователей У нас давно есть идеи вертикализации, тк сейчас продукт слишком для "всех" Короче поверх текущего Маймита за 3 часа нужно было - закасдевить клиента из воронки - навайбкодить решение, - показать решение клиенту, получить от него фидбек На выходе получили три работающих прототипа, каждая команда провела всем демо Из интересного: В sales-сегменте два агента работали параллельно: Fable и GPT 5.5 xHigh. Фейбл по итогу оказался более консистентный текущему продукту, гпт чуть больше нейрослоп (промпт был одинаковый) Для команды это было прикольно двумя вещами: - посмотреть какие подходы в работе с coding agent эффективнее: кто-то потратил половину времени на план и огромный промпт-цель. Кто-то делал итерациями и 5 параллельными агентами (оказалось хуже) - познакомиться и повзаимодействовать глубже с ребятами из команды, тк были и разрабы и сейлзы условно Результаты хакатона будем развивать дальше в продукты (дай бог). То, что получилось нельзя вчистую использовать в проде, но теперь точно будет легче тк есть вижн, первые черновики и проработка мероприятие зашло команде, немножко напоминает подготовку вечернего мероприятия в лагере – все торопятся, азарт, идеи и вот это всё. В комментах покажу pdf в sales-сегменте для сравнения от Fable и GPT 5.5 xHigh