Управление продуктом *

На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

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

Чтобы решить проблему, мы решили внедрить в жизненный цикл разработки концепцию DoR (Definition of Ready) и DoD (Definition of Done). В этой статье я расскажу: чем DoR и DoD отличаются от критериев приемки и почему их важно не путать, как не превратить полезный инструмент в бюрократическую обязаловку, какие узкие места могут возникнуть при внедрении концепции.

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

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

Данная статья является переводом откровений Гельдрейха о работе в Valve и некоторых других «самоорганизующихся» компаниях (представленных в виде, без преувеличения, «учебника по выживанию»), с некоторым форматированием для более удобного чтения. Имейте ввиду, что это рассказ об условиях работы на Западе (США), и некоторые советы могут выглядеть очевидными или странными.

Привет! Меня зовут Игорь Федорчук, я руковожу разработкой в направлении «Монобренды» в GRI.

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

Это первая статья о том, как мы пересобирали процесс разработки в GRI — от получения запроса от заказчиков до выкатки в прод. В этой части я разберу роли (тимлиды, техлиды, TPM), зоны ответственности и общий флоу. Во второй части покажем, как мы приземлили это в Jira и метрики, а в третьей — как масштабировали поставку: релизы, код-ревью и инциденты.

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

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

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

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

В этой статье я поделюсь опытом, кейсом из моей практики в российском ритейле. Ко мне обратился заказчик с проблемой. На производстве чипсов (СТМ в Краснодарском крае) возникали проблемные возвраты целых партий картофеля от производителей по причине брака 80–90%. Внешний осмотр показывает, что картофель снаружи весь в чёрных пятнах. Сами производители утверждали, что отправляют картофель качеством не превышающим 5% брака, и ссылались на отчёт сюрвейера.

Проект требовал присутствия в формате 90%, поэтому с заказчиком мы определились с посещением двух поставщиков и самого филиала по производству.

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

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

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

«Когда регулятор — лучший продакт» — это был верхний слой. Выводы без данных.

Сегодня представляю полный PESTEL-анализ карьеры CPO в российском финтехе на 2025–2026: 28 факторов, от ключевой ставки и импортозамещения до agentic AI и зарплатных вилок. Для тех, кто предпочитает разбираться самостоятельно, а не читать чужие выводы. Всё по ссылке.

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

Проблема в том, что базовые LLM — это не юристы, не эмпаты и не HR-директора. Это генераторы вероятного текста, чья главная цель — услужить пользователю. Даже если пользователь просит нарушить закон или базовые нормы морали.

Чтобы доказать это, я провел Red Team-тест: притворился некомпетентным HR-директором российского ритейла и дал топовым моделям задачи «с двойным дном». Результат: 65% нейросетей сгенерировали тексты, которые гарантируют визит Трудовой инспекции и репутационный суицид в СМИ.

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

<habracut />

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

Меня зовут Андрей Васючков, я - стратегический маркетолог, член Гильдии маркетологов России.

В B2B-маркетинге есть классическая проблема: компания годами вливает бюджеты в контекстную рекламу и SEO, но заявки обходятся слишком дорого, а до коммерческого предложения (КП) и сделки доходят единицы. Отдел продаж винит маркетологов за «мусорный трафик», маркетологи ругают продажников за то, что те «сливают лидов».

Примерно с такой вводной мы начали работу над проектом компании «Стальпром-Оборудование». Перед нами стояла задача: увеличить конверсию по всей воронке (из посетителя в лид, из лида в КП, из КП в сделку), но в условиях замороженного бюджета на продвижение. Спойлер: мы это сделали за 6 месяцев, не меняя сам продукт.

Недавно знакомый PM попросил рассказать “Что значит отвечать за качество?” в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.

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

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

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

Долгое время у меня был вопрос вокруг продакт‑менеджеров. Они кто — создатели или менеджеры?

В слабых, «фичевых» командах продакт часто больше администратор: согласовать, приоритизировать, свести всех вместе. В сильных командах продакт — это уже соавтор продукта. Он не просто управляет задачами, он влияет на то, что и зачем мы делаем. Это ближе к роли создателя, хотя и не такой «чистой», как у инженера или дизайнера.

Люди процесса это не те, кто делает продукт. И не те, кто развивает тех, кто его делает. Это те, кто отвечает за то, как всё должно происходить.

Scrum masterа, специалисты по внедрению фреймворков, product ops в определённой интерпретации. Их зона ответственности — процесс, инструменты, ритуалы, стандарты.

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

Статья написана на основе интервью с Андреем Бобковым, кофаундером и CTO QQ Coffee.

Мы обжариваем кофе высокого класса в Подмосковье, около 10 тонн в месяц. 90% продаж идёт в кофейни, рестораны и офисы, остальное через интернет-магазин и маркетплейсы. В команде 25 человек. Я пришёл в компанию как аккаунт-менеджер, работал с заказами и клиентами, а со временем взял на себя всю IT-часть.

Практически всё ведём в МоемСкладе это ERP-система для малого и среднего бизнеса. Заказы, склад, производство, финансы, аналитика. За четыре года накопилось больше 150 тысяч документов, 3500 контрагентов и 3500 товаров.

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

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

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

Поучаствовать в рубрике мы пригласили двух экспертов в B2B-IT маркетинге, которые основали онлайн-школу Go to Market Academy — она фокусируется на продуктовом маркетинге для B2B IT-продуктов.

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

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

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

Добрый день. В этой статье поделюсь следующим опытом: как мне удалось сэкономить очень много денег для известного крупного ритейла.
Ко мне обратилась одна из крупнейших торговых сетей России с проблемой следующего характера. На её распределительных центрах (РЦ) Заказчику поступал товар от производителя — огурец сорт «Мева». Заказчик, разгружая у себя товар в количестве 32 поддонов весом по 600 кг и вывозя его электрокаром из кузова авто, получал падающие и рассыпающиеся поддоны вместе с огурцами. При этом опалетка каждого поддона рвалась. В результате возникали серьёзные потери на каждом РЦ именно с этим поставщиком-производителем.
Заказчик тратил время на сбор продукции и возврат обратно поставщику, а также терял в прибыли на каждом РЦ крупные суммы.
Что было решено? Я посетил один РЦ ритейла во время приёмки данного товара от производителя. Также было решено посетить день формирования партии и отгрузки на складе производителя. На выяснение истинной причины было затрачено 7 дней.
Что сделано с моей стороны:
-Заказчик предоставил копию договора поставки с производителем. -Изучил условия в договоре.
-Заказчик предоставил фото- и видеоматериалы происходящего на своих РЦ (как падает паллет).
-Договорился о днях присутствия на РЦ.
-Договорился с производителем о дне присутствия на складе производителя.
-Изучение, анализ, фиксация процессов на РЦ и складе производителя с помощью фото и видео.
Моё присутствие, наблюдение и анализ на РЦ Заказчика подтвердили, что паллет с огурцами разваливается при малейшей тряске или повороте электрокара. Особенно когда электрокар аккуратно съезжал с кузова, а именно в моменте, где всегда происходит небольшой скачок. Это стандартный технически заложенный скачок — без него никуда, так устроен процесс отгрузки и разгрузки. Мы попробовали аккуратно вывезти паллет и поставить его на весы, но при простом развороте электрокара весь поддон разваливался. Предположительно, проблема была не в РЦ и не в сотрудниках на электрокарах.

Я протестировал 20 CRM-систем и отобрал те, которые действительно стоит выбирать в 2026 году.

В обзоре — сервисы для малого и крупного бизнеса, e-commerce, общепита и open-source решения с обзором функций и тарифов.

Менязовут Роман Михайлович, я аналитик процессов. Я работаю методом полевого расследования. Это значит: не просто читать отчёты, а пройти всю цепочку своими глазами, зафиксировать каждый шаг, найти точку разрыва. В этом мне помогают простые инструменты: фотофиксация, хронометраж, блок‑схемы в Draw.io и анализ документов.

Ко мне обратилась крупная торговая сеть, ритейл с проблемой: томаты «Черри» от постоянного поставщика приходили с механическими повреждениями. Сюрвейеры работали, претензии писали, но брак не уходил. Задача была — найти причину истинную причину.

Ритейл, закупал томаты у двух тепличных комплексов в России. Проблема была только с томатами «Черри»: трещины, вмятины, мятые плоды. Поставщик говорил: «Это логистика, водители виноваты». Сеть не верила, но доказать не могла.

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

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

“...А единственная перспектива у продвинутого парня в этой стране — работать клоуном у п********.
— Мне кажется, — ответил я, — есть и другие варианты.
— Есть. Кто не хочет работать клоуном у п********, будет работать п*******м у клоунов. За тот же самый мелкий прайс.”
В. Пелевин Empire V

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

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

И Cursor, и Claude Code пришли к одному ответу - субагенты. Но реализовали его по-разному