PM Live | проджект и продакт менеджмент — дайджесты и вакансии PM в Телеграме
Почитать:
Комикс «Спринт без смысла, тикеты без души»
Нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое.
Стратегия маркетинговых побед Netflix
если разложить, стратегию Netflix на компоненты, получится вот что:
- Удачная бизнес-идея. Стать первым прокатом DVD-дисков с отправкой почтой в США было смелым решением, которое полностью окупилось.
- Поразительная гибкость и бизнес-чутьё. Благодаря своевременному переходу к потоковому вещанию Netflix живее всех живых. Упомянутый выше Blockbuster, например, прекратил своё существование в 2014 году.
- Персонализация. Подбор не только фильмов, но даже заглавных изображений по предпочтениям пользователя.
- Эксклюзивный контент. Собственные сериалы-рекордсмены по количеству просмотров, телешоу и видеоигры, уникальные комбинированные форматы.
- Надежность сервиса и высокое качество видео. Минимизация количества сбоев и отказов.
Эффект IKEA: история о том, как не надо вносить изменения
Сегодня — перевод и разбор классной статьи инженера, технического директора и основателя стартап-инкубатора Limbe Labs и лаборатории Red Hat Джереми Брауна. Он рассказывает о том, как эффект IKEA (тот самый эффект, когда мы особенно ценим то, что сделали сами) может работать, и как иногда он больно бьёт по управлению изменениями.
По обе стороны коллекшена: как я собирал чужие долги
Как выглядят должники в 2020-е
Перед тем, как посмотреть продукт, давайте посмотрим, как выглядит типичный должник. Вот несколько ярких портретов:
- Апатичный (45 лет, 965 дней просрочки): бывший бизнесмен, оказался в сложной ситуации из‑за здоровья, не справился с долговой нагрузкой и очень хочет чтобы ему пошли навстречу.
- Растерянный (60 лет, 75 дней просрочки): привык, что есть постоянная работа и доход, которым можно закрывать кредиты, но одним днём его уволили. Что делать с ситуацией пока не понимает.
- Бунтарь (30 лет, 235 дней просрочки): не доверяет банкам, которые связаны с государством. Уверен, что в любой момент может вернуть долг, он всего‑то 11 000.
- Добросовестный (55 лет, 339 дней просрочки): семьянин, уже год не может устроиться на постоянную работу из‑за возраста. Себя в студенческие годы я бы отнёс к этой же группе, хоть и был моложе условных 55 лет. Я старался не пропускать платежи без крайней необходимости.
Поиск мотивации в скучных задачах
Личный опыт «вайб-кодинга» глазами руководителя разработки
Я попробовал v0, Replit, Lovable, Bolt.New, Firebase, Trae, Cursor, Windsurf, Gemini Code Assist, MS Copilot, Continue…
Поворот туда: историй о том, как бывшие юристы, врачи и логисты стали менеджерами проектов
Семь лет в тестировании на инженерных и тимлидских позициях в аутсорсе и продукте. Баловалась скраммастерингом параллельно с основной ролью. Потом у меня в жизни приключилось обнуление — я развелась, ушла с работы, осталась без жилья, кота, друзей. В общем, начала с чистого листа.
В тот же момент поняла, что больше не хочу зарабатывать ничем из того, что делала раньше. Подушка безопасности позволила некоторое время подумать, я взвесила свои наклонности и карьерную историю и решила податься в проектный менеджмент.
Свое представление о профессии дирижера я почерпнул из открытых источников, полагаясь на мнение экспертов, изложенных в публичных интервью (ссылки ниже). К этим представлениям добавил свои аналогии из хорошо знакомой мне профессии ИТ-управленца. Весь текст ниже я построил в формате вопросов и ответов.
Продукты
CTO: рынок, стратегия и инженерная культура
Я не считаю, что главный инструмент CTO — это власть и ресурсы, а люди, время и деньги — это валюта, за которую он «покупает» будущее компании. При таком подходе CTO превращается в «распределителя ресуров между юнитами» ради большего результата за меньшие деньги — и, на мой взгляд, это плохой CTO.
Расскажу про литературу, которая повлияла на развитие моих профессиональных компетенций: впереди и разговоры с мамой, и база по найму «тех самых» спецов, и бизнес-модели, без которых в нашем деле никуда. Одной идеальной книги для продакта нет, поэтому я собрала разноплановую подборку (есть даже одна художественная книга): от основ для новичков до продвинутых техник для тех, кто хочет прокачать конкретные навыки.
Не «я решил», а «давайте обсудим» — Open Decision Framework
В открытой дискуссии лучшие идеи естественным образом получают поддержку, независимо от того, исходят они от сеньора или джуна. Такой подход снижает риски принятия ошибок из-за «эффекта начальника», позволяет проверить больше гипотез.
Agile и затянувшийся кризис разработки ПО
Я впервые столкнулась с Agile, когда устроилась работать в библиотеку. Меня наняли, чтобы помочь запустить новый центр цифровых гуманитарных исследований, и время от времени я взаимодействовала с командой разработчиков библиотеки – мы создавали инструменты для поддержки проектов. В этой команде было около шести человек, и я сразу заметила, что они работают иначе, чем сотрудники из других отделов.
Пост-осмотр авто в каршеринге — это возможность для пользователя зафиксировать состояние машины после аренды. В приложении Ситидрайва это выглядело так: клиент завершал аренду, получал чек, а потом в отдельном экране приложение предлагало «по желанию» сделать пару снимков. Неудивительно, что большинство пользователей просто пропускали этот этап. При этом в начале аренды есть предосмотр — пользователь может зафиксировать уже имеющиеся повреждения до поездки.
Как мы систематизировали работу с техдолгом в своей QA-команде
Стратегия распределения задач. Благодаря увеличению количества QA появилась политика распределения ресурсов. В команде используется стратегия разделения задач между QA: если один занят бизнес-задачами, то другой QA берет в работу задачи по техдолгу. Такой подход хорош еще и тем, что благодаря регулярной смене деятельности работа не превращается в однообразную рутину.
Игры без победы: новый тренд в геймдеве
Когда мы думаем об играх, почти автоматически предполагаем, что у них есть цель. Победить. Пройти. Достичь чего-то. Но в последние годы на поверхность выходит другой подход — игры, в которых нет привычной структуры выигрыша и проигрыша, игрока не торопят, не оценивают и не говорят, когда он «молодец». Это не баг, а фича — и именно такая, которая говорит о взрослении индустрии.
Как не попасть в продуктовую ловушку и перезапустить продукт
В итоге, мы попали в продуктовую ловушку: искренне считали этот рынок вполне освоенным, развивали продукт в соответствии с запросами наших пользователей, а по факту рынок оказался другим. Смежным, похожим, но другим. И значительная часть целевой аудитории просто не попадала к нам в воронку. Если посмотреть топ облачных провайдеров 2022 года, там нет компаний, которые традиционно начинали как хостеры. При этом почти у каждого хостера в продуктовой линейке есть что-то облачное.
Data-driven в одном iGaming проекте: когда культура работы с данными не приживается
Решения принимаются на ощущениях и экспертизе, изменения в продукте приводят к неожиданным сценариям и результатам. Например: решили добавить функционал реферальной программы. Пользователи быстро сообразили где уязвимость и вывели пару десятков тыс. $. Кажется, не хватило проверок, моделирования и челленжа механик.
Ещё пример: провели акцию для активации пользователей, но те, кто был не активен, не включились, а те, кто был активен принесли вдвое меньше прибыли — играли на бонусы по акции. Не хватило анализа механики акции и теста проведения.
Это лонгрид для b2b продактов о том, что делать для успешной работы sales driven в продукте.
За пределами фичей и метрик: место концептуализации в разработке продуктов
Повторяемость, рациональность, научность. Круто же?
Но если продуктовый подход рассматривать не как лозунг, а как ежедневную практику, то мы сталкиваемся двумя трудностями.
- Трудность первая: цикла на самом деле нет.
- Вторая: проверить только одну гипотезу за раз невозможно.
Вы выложили код на GitHub. Настроили GitHub Actions CI/CD. Добавили красивый README. Возможно, даже собрали несколько звёзд. Но через месяц понимаете: никто не использует ваш проект. Знакомо? Мне — очень. Так было с моим пет-проектом Wunjo на GitHub в ранних стадиях. Сейчас он приносит мне доход.
Проблема обычно не в коде. Проблема в том, что между «проектом для себя» и «продуктом для других» лежит пропасть. В этой статье расскажу, как её преодолеть, что вообще считается продуктом, и как привлекать первых пользователей через Product Radar. После прочтения вы сами поймёте, хотите ли вы монетизировать свой Open Source.
Как убить архитектуру за три спринта: практическое руководство
Проекты не взрываются из-за одного неправильного решения. Они взрываются из-за уступок. С каждым «пока так сойдёт», с каждым «сначала выпустим, потом подчистим».
Архитектуру убивают не баги и не форс-мажоры. Её убивает слабость команды и неспособность защищать свои принципы перед давлением срочности и очередных невнятных хотелок.
Смерть разработки продукта как мы её знали
Когда я была ребёнком, я обожала «Капитана Планету» — тот самый мультфильм 90-х, где пятеро подростков с волшебными кольцами (Земля! Огонь! Ветер! Вода! Сердце!) объединялись, чтобы сражаться с экологическими злодеями.
В своё время мне казалось, что сериал был невероятно оригинальным. (Персонификация планеты в виде аквамена в трико?!)
Я тогда ещё не знала, что смотрю на старый добрый архетип, который позже повторят «Могучие Рейнджеры», «Юные Титаны», «Мстители» — и, конечно, технологические продуктовые команды по всему миру.
В течение десятилетий традиционная техкоманда выглядела так:
Разработчики (3–5 человек) + продакт-менеджер + дизайнер = построено что-то классное.
Иногда к команде добавляли ещё кольца: Продажи! Данные! Маркетинг! Поддержка клиентов! Исследования пользователей! — чтобы сражаться с более крупными злодеями, при этом стараясь следовать «лучшему правилу»: эту группу должно быть возможно накормить двумя пиццами.
Экскурс в историю Agile и Kanban, или Топ 10 причин перейти на итеративно-функциональный метод
Итеративно‑функциональный метод и одноименная платформа создается в России с 2024 года. Agile был создан как ответ на косность Waterfall. ИФ Метод, в свою очередь, как ответ на фактическую импотенцию Agile практик и превращение его в своеобразную религию. Единственное сходство двух подходов — это итеративность, которая не является оригинальной идеей Agile. ИФ Метод строится на трех главных понятиях — итерации функции (фичи), самой функции и очередях итераций. ИФ Метод не признает никакой философии, ценностей или принципов — это маркетинговая чушь, которую используют, чтобы продать вам книги, курсы и консультационные услуги. ИФ Метод не использует канбан‑доски, имея оригинальный способ визуализации работы.
Проекты
Проджект-менеджер каждой из команд решает, в какой релиз взять ту или иную доработку, сделанную в его команде, вносит информацию в общий график, договаривается с другими командами о датах релизов и ресурсах CI/CD инфраструктуры.
В дни, когда релизов несколько, PM совместно с тестировщиками координирует их очерёдность или договаривается об объединении релизов.
Как мотивировать профессионалов
Подход Арнольда Бейссера частично соответствует юнгианской позиции в том, что изменения происходят через принятие и осознание, а не через давление и насилие над собой.
Скрам-мастер vs мастер реальности
А еще не раз даже было так, что читаешь новую методологию, в рамках нее видишь кейс, который уже решали +- также, но по наитию, и тут же для него видишь термин)) и думаешь “вот какие мы молодцы! так вот, что мы, оказывается, используем”)) (например, так было у меня с LeSS и жаль, что в том случае я слишком поздно добралась до манифеста).
Задача трёх тел. Почему B2B-бэклог — это физика, а не математика
Зачем я придумал новый фреймворк определения приоритетов задач и как мне помогло «пу-пу-пу»
Чтобы мои усилия не закончились на единственном случае применения, я продолжу использовать ПУПУПУ в случае «прилёта» незапланированных задач в течение года.
Как довести фичу до продакшена без боли: пошаговый гайд
В этом посте мы разобрали первые пять шагов, которые помогают команде начать работу над фичей с минимальным хаосом и максимальной ясностью: от первичного обсуждения и архитектурного планирования до технического дизайна и стратегии тестирования. Это тот самый фундамент, без которого любая разработка рискует превратиться в бесконечную доработку на проде.
Заговор разработчиков против корпораций: работа с командой
У Техлида была фраза (к сожалению, не смог найти то видео), что он мечтал попасть в Google, чтобы оказаться рядом с лучшими инженерами, а в итоге оказался в команде с кучкой идиотов, которые «заботали» алгоритмические задачи.
Как не сливать бюджет на управление. Кейс разработки калькулятора для определения проектов
Главной проблемой была именно разрозненность и отсутствие общей системы. Мы постоянно «латали дыры», заново решали одни и те же задачи в разных контекстах, но не могли увидеть единую картину и двигаться в едином направлении.
Нужно было что-то менять на кардинально новое. Мы начали искать подход, который помог бы объединить отдельные инициативы в единую осмысленную систему. И здесь наше внимание привлёк подход Capabilities-Based Planning (CBP), про который мы узнали из TOGAF.
Аналитика
Почему ваши схемы бизнес-процессов не читают
Короткий ответ — потому что чаще всего их невозможно читать.
Длинный — очень часто схема процесса написанная в любой нотации довольно нечитаема, даже короткая, на ней много запутанных мест, много разных шрифтов, непонятно что значат все эти разноцветные прямоугольнички, ромбики и кружочки. Поэтому основные потребители отказываются читать или читают с неохотой и большими временными затратами, ругаются и не хотят больше видеть никаких схем.
Когда у вас есть BPMN, сгенерированный ИИ, вы можете передать его другому ИИ-агенту, обученному исполнять BPMN, чтобы запускать новый экземпляр процесса по мере необходимости. Но обучение и запуск ИИ-агентов — это дорого и относительно медленно. Использовать ИИ для того, чтобы делать то, с чем давно справляются масштабируемые, гиперэффективные BPMN-движки — пустая трата ресурсов.
Гораздо эффективнее, стабильнее и надёжнее запускать ваши процессы BPMN на этих проверенных движках. Современные BPMN-системы должны стать «исполняющей средой» для ИИ. То же относится и к другим ключевым стандартам автоматизации — CMMN (Case Management Modeling and Notation) и DMN (Decision Management Notation). У Flowable, например, есть клиенты, которые запускают миллионы экземпляров BPMN и CMMN каждый день.
Для архитекторов и аналитиков: шаблон описания архитектуры приложения (34 страницы пользы)
Углубляясь в тему проектирования архитектуры познакомилась с книгой «Архитектура программных систем» и шаблоном описания архитектуры ПО Эоина Вудса и Ника Розански. Чтобы уложить по полочкам материалы книги и сохранить полезный артефакт перевела шаблон, дополнила примерами из книги, личного опыта в ITSM и материалами The TOGAF® Standard, Version 9.2.
Overall sentiment of the comments: Gratitude
D7 — не показатель: ищем правду
Сегодня поговорим про ретеншн — ту самую метрику, от которой часто пляшут все продуктовые команды. Вы знаете: «вернулся через 7 дней» (D7) — и сказано, что мы класс.
Но на деле класс ломается, как только продукт усложняется. В этой статье рассмотрим, почему классический D7 retention не работает, как построить настоящие кривые удержания через когорты, в чём разница между recurring vs one-shot поведением, какие есть альтернативные метрики и сравним три метода на примере.
Документация по-взрослому: Given/When/Then для реальных проектов глазами системного аналитика
В этой статье 7 типовых конструкций Given / When / Then, которые:
- покрывают различные распространенные кейсы
- превращаются в понятные тест-кейсы
- не разваливаются на проде
С примерами, пояснениями, подводными камнями и шаблонами. Это, конечно, не покрывает все возможные сценарии, но дает направление, в котором ты должен смотреть.
Гайд по бизнес-метрикам в Grafana для аналитиков
Эта статья — пошаговая инструкция для тех аналитиков, кто без скиллов в BI пытается к утру сделать бизнес-метрики в Grafana, имея только доступ к ней.
Поспорить
Халява приходит в программирование (ответ на «Халява уходит из программирования» )
Потерянные чуваки каким-то чудом оказались в $СЕЙЧАС и не знают, что с этим делать. Кого-то на собеседование выгнала мамка. Кто-то может в 40 лет осознать, что врач скорой помощи — не лучшее занятие для построения семьи. В классификации этот пункт только потому, что таких людей реально много, и они все могут считаться профессионалами: им есть чего про себя сказать, и им очень нужны деньги. Это не плохо и не хорошо само по себе. Кстати, все мои знакомые врачи, ушедшие в IT, сейчас на высших управляющих должностях
Что станет после внедрения AI?
Потерянные получают огромный бонус в том, что нейронки — это идеальные учителя начального уровня. Они помогут и с профориентацией, определением плана обучения, проконтролируют результаты. Им можно бесконечно задавать вопросы.
Почему до сих пор ни один ИИ не может написать даже простой проект сам?
ни один ИИ‑агент, включая крупных игроков, не пишет даже простой проект (15–30 файлов) самостоятельно, даже если скормить ему супер-идеальное «ТЗ» и направляющие (Аля «Назначение Роли») во всякие «Rules» подобные механизмы.
Что я только ни пробовал подавать на вход, чтоб получить идеальный выход:
- Назначение роли в Project Rules
- Цель проекта в Project Rules
- Стек технологий и фреймворков в User Rules
- Ограничения и запреты в User Rules
- Принципы проектирования в User Rules
- Документацию в Docs
- Идеальный промпт на 47+ тысяч символов
- Не идеальный, но подробный промпт на 10 тысяч символов
Виртуальность импортозамещения как следствие периферийного капитализма
Такой подход— это не романтика революций, а прагматизм. Если для скачка нужно временно пожертвовать либеральными химерами
Посмотреть:
Внедрение изменений: как это делает большой бизнес ⏱️30 минут
Методологий может быть много, но инструментарий должен включать в себя конкретные шаги и сроки их реализации. Поговорим про подход консалтинга и крупного бизнеса для реализации запланированных инициатив и принятия бизнесом и сотрудниками изменений.
Business Analyst to Product Manager ⏱️45 минут
Трудности при переходе и как помочь себе в этом процессе.
Переход менеджера в ИТ: ожидания и реальность ⏱️1 час
Как попасть в ИТ в 38 лет? Из офицера-подводника в айтишники — реально ли это? Чем опыт в прошлой сфере будет полезен в ИТ? Какая разница между стройкой и ИТ? Весь путь от руководителя в сфере строительства до руководителя в ИТ-проектов.
Карта реализации историй. Технология осмысленной работы с детальными требованиями ⏱️1 час 30 минут
Истории настолько мощная практика, что от нее ни в коем случае нельзя отказываться. Вместе с тем, их инструментарий настолько давно не развивался, что пришло время это исправить.
Карта реализации историй дает аналитику, исследователю и проектировщику утонченную структуру для бесед с пользователем, бизнесом и командой разработки. Пользовательские истории в ней эволюционировали до рабочих историй, а время на запись содержательных историй сократилось.
Всё о найме СА в 2025 году: Интервью с рекрутером ⏱️1 час 30 минут
Мы пригласили практикующего рекрутера обсудить самые актуальные вопросы найма системных аналитиков в 2025 году.
Copy-Paste в менеджменте: почему менеджмент — это не доказательная медицина ⏱️45 минут
Если бы врачи действовали как большинство современных менеджеров IT-проектов, то назначали бы лекарства и процедуры по принципу «а вдруг поможет» или просто потому, что «у соседа сработало». В отличие от доказательной медицины, где решения обоснованы исследованиями, управленческие практики в IT нередко копируются из чужих успешных кейсов или собственного прошлого опыта без доказательств эффективности.
Формулирование и проверка гипотез ⏱️1 час
Правильное формулирование и проверка гипотез — ключевые навыки успешного продакт-менеджера. Ошибочная гипотеза может стоить компании времени и ресурсов, в то время как точная гипотеза существенно снижает неопределённость.
⬅️ Предыдущий дайджест за неделю с 21 по 27 апреля
