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

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

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

Но с каждым днём кубики становятся мельче, а модели — сложнее и реалистичнее. Работа требует всё больше концентрации и времени.

В какой-то момент вы понимаете, что просто не успеваете — деталей слишком много, а скорость конвейера не снижается! Кроме того, надо держать в голове все инструкции для сборки всех моделей.

На первый взгляд — это вымышленная ситуация, разве сборка конструктора может быть настолько неавтоматизированной?

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

За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию.

Компания растёт, продукт усложняется, и в какой-то момент возникает естественное желание разбить всё на отдельные продуктовые команды. Каждая отвечает за свой кусок функционала, свою часть пользовательского пути, свою метрику, свой backlog. На бумаге это выглядит правильно: меньше зависимостей, больше автономии, быстрее принятие решений.

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

Одна команда знает, почему была изменена логика онбординга. Другая помнит, какие ограничения есть у биллинга. Третья когда-то проводила исследование, из которого следовало, что пользователи вообще не понимают текущую модель прав доступа. Где-то это лежит в презентации. Где-то в Notion. Где-то в Confluence. Где-то в почте. Чаще всего — в голове конкретного человека.

Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним.

И это не исключение. Это нормальное состояние большинства организаций.

Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему».

В IT разработке результат дает не один человек, а команда. А в любой команде (даже если она работает на полной удаленке) будут отношения. А где есть отношения, там есть манипуляшки.

Мир неидеален, на солнце есть пятна, не все проекты делаются в срок, начальники орут, исполнители молча соглашаются с невыполнимым и доблестно выгорают - короче, все неидеально.

Но если все так, то как сохранить себя в этом бардаке, как работать максимально эффективно с совершенно разными людьми?

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

Эта статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи тут, на Хабре.

Итак, поехали!

Сисадмин сахарного завода в 2013 году написал для 1С небольшую конфигурацию - автоматизацию весовой для грузового транспорта. Поставил на один завод группы, показал коллегам и на некоторое время про это забыл. Через четыре года случайно прочитал в корпоративном издании холдинга, как инженер другого завода рассказывает, что «доработал и внедрил» на своём предприятии ту же самую программу. Только ни договора, ни согласия, ни даже своего имени разработчик в статье не увидел.

Дальше было больше 8 лет споров. Здесь и уголовное дело, и два отказа в районном суде, две кассации, три апелляции. В декабре 2025 года Тамбовский областной суд обязал ООО «Русагро-Тамбов» выплатить автору 760 тысяч рублей компенсации.

Это дело (№ 33-3839/2025) интересно не суммой. В нём суд принципиально развернул позицию, которую большинство работодателей в IT-спорах до сих пор считает выигрышной. Звучит она примерно так. Разработано на нашем компьютере, с нашей 1С, в рабочее время, значит, наше служебное произведение. В этом деле она не сработала, и логика, которую зафиксировала апелляция, универсальна. Для разработчиков это полезный прецедент. Для компаний это сигнал проверить кадровую документацию до того, как начался спор.

Продакт-менеджер строит продукт. Маркетолог привлекает трафик. А кто отвечает за то, чтобы первое встретилось со вторым и пользователь сказал «да, это то, что мне нужно»?

В статье разбираем три роли, которые часто путают даже опытные команды: продакт, маркетолог и Product Marketing Manager. Без воды и шаблонных фраз — только зоны ответственности, реальные метрики и примеры, где чаще всего ломается взаимодействие.

Привет, Хабр! На связи Денис Захаров, программист. Десять лет назад я сварил себе рабочую станцию в съемном гараже, потому что после операции на позвоночнике не мог работать в обычном кресле, а нормального (и доступного мне) решения на рынке не было. Продавать придуманную мной шайтан-машину я изначально не собирался. Но потом выложил пост в ВК, чтобы похвастаться, кто-то спросил «а можно такое же?» — и понеслось. 

Теперь у меня есть бизнес-партнер,  собственное производство, и за последние 3,5 года мы сделали более 1000 станций. Стоит станция E-station в среднем 250 тысяч рублей, цена регулярно вызывает вопросы в комментариях и дискуссии на тему «есть ли потенциал у такого бизнеса». Сегодня хочу написать обо всем этом подробный материал.

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

Разберу три опоры, устав OpenAI как определение, публичный голос Альтмана в начале 2025 года, инженерный взгляд Лекуна и тревожный, про темп и контроль, у Хинтона. Потом про сроки.

Если вы видели "С этим товаром покупают…", "Попробуйте этот урок дальше" или ощущали необычную точность автоподбора треков в музыкальных сервисах - вы сталкивались с рекомендательной системой.

Но стоит ли конкретному бизнесу вообще её строить? И если да, то с чего начать, чтобы не потратить впустую месяцы инженерного времени на "чёрный ящик", который никто не понимает?

Эта статья написана мной РУКАМИ (не "ИИ") и основана на моём выступлении-вебинаре для инженеров, предпринимателей и продуктовых специалистов. Я не ML исследователь и не публичный спикер - я фулстек-разработчик, который создавал и поддерживал рекомендательные системы в разнообразных коммерческих проектах.

Целевая аудитория - все, кому интересна эта тема.

Каждый раз, когда какой‑то продакт с гордостью говорит: «Я сам собрал прототип за вечер на AI/no‑code», я не вижу в этом геройства. Я вижу главу продукта, который превратился в ещё одну пару рук для дешёвого билдинга. Вижу человека, который перестал быть «мозгами продукта» и стал универсальным солдатом, которого удобно использовать, но невозможно уважать как продуктового специалиста.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»

Санкции 2022 года создали беспрецедентную ситуацию на российском рынке информационных технологий. SAP, один из мировых лидеров в области корпоративных информационных систем, официально прекратил поддержку российских клиентов. Казалось бы, это должно было привести к массовому переходу на отечественные альтернативы. Однако реальность оказалась намного сложнее.

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

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

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

Понимание данных прошло эволюционный путь от структуры хранения информации до ключевого элемента в конкурентной борьбе. Сегодняшние информационные технологии, такие как: искусственный интеллект, машинное обучение, предиктивная аналитика, рекомендательные технологии, существуют благодаря большим данным, анализу данных и стремительному развитию вычислительной техники.

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

Сейчас существует отдельный класс программных систем MDM, ориентированный на управление данными. Ведение основных и переменных данных, НСИ и обработка остатков – все это существенные операции бизнес-процесса над данными. Не так много литературных источников, содержащих анализ именно бизнес-процесса работы над данными, исключая детали нормальных форм, SQL-запросов и прочих технических вопросов. Среди них выделяется свод знаний по управлению данными или DAMA-DMBoK, рассмотрению которого будет посвящена данная работа.

Цель статьи состоит в обзоре свода знаний DAMA-DMBoK по управлению данными и его применения в проектах внедрения ERP-систем. Достижение указанной цели потребует реализации следующих задач:

Цифровые продукты не развиваются в отрыве от среды. И пока проект находится в разработке, меняются приоритеты бизнеса, ситуация на рынке, а исполнитель продолжает работать по уже устаревшему ТЗ. В итоге проект сдан в срок, но результат не решает актуальные задачи бизнеса.

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

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

Привет! Меня зовут Света и я — project manager. Или, по мнению разработчиков, человек, который превращает «надо подумать» в «обещали к пятнице».

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

На самом деле не так важно, какой у тебя проект, потому что картина всегда одна и та же. Проект зачастую начинает ехать не в тот момент, когда «разработчики не вывезли». И даже не тогда, когда «аналитик что‑то недожал» или бизнес в очередной раз опомнился слишком поздно. Он начинает ехать в стену сильно раньше — в тот самый момент, когда кто‑то в команде уже всё понял, но решил пока не портить атмосферу добра и счастья.

То есть уже понятно, что:

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

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

Привет, Хабр!

Я Ирина, в Блоке ИТ-развития инвестиционного бизнеса РСХБ.Цифра помогаю ИТ-командам доставлять ценность бизнесу, содействую оптимизации процессов, повышению эффективности и сплоченности команд, продвигаю Agile-практики.

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

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

Назову его Геннадий. Техлид. В команде за глаза зовут «Ещё Подумаем». Восьмой год в роли. Выбор фреймворка - две недели. Приоритеты спринта - три встречи. Даже «куда идём обедать командой» превращается в опрос в чате.

Геннадий - человек, который всегда знал, как надо. Уверенный. С позицией. Решал сам - это было его.

Перестало работать.

HR считает его выгоревшим, отправляет в отпуск. Он возвращается посвежевшим - ничего не меняется. Вопросы продолжают висеть.

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

Слово есть - в нейробиологии.

Пациент Элиот

В 1994 году нейробиолог Антонио Дамасио опубликовал книгу «Ошибка Декарта». В ней - история пациента по имени Элиот.

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

И Элиот больше не мог выбрать.

Куда пойти обедать - два часа колебаний между двумя ресторанами. Какой отчёт подать первым - парализованная нерешительность. Блестяще рассуждал: перечислял плюсы и минусы, учитывал риски, строил сценарии. Выбрать не мог.

Элиот потерял работу. Потом жену. Потом всё.

В Agile и Scrum есть почти священная заповедь: команда должна быть стабильной, долгоживущей. Люди притираются друг к другу, учатся работать вместе, растёт доверие и предсказуемость.

Но вообще, люди уходят, приходят новые, компания растёт, появляются новые продукты, кто-то выгорает, кто-то засиделся и перестал развиваться.

Хайди Хелфанд, автор книги "Dynamic Reteaming: The Art and Wisdom of Changing Teams", проработавшая в AppFolio, ExpertCity и других компаниях, утверждает: изменение состава команды - это не проблема, а нормальный и правильный процесс, которым можно управлять. Она собрала реальные кейсы и показала, что пересборка команд даёт результаты, которых не может дать стабильная команда.

В прошлом году я пил кофе с одним знакомым (не буду называть его настоящего имени), сказавшим мне, что он «строит бизнес». Я спросил, чем он занимается. Он ответил, что дропшиппингом нефритовых массажёров для лица.

Я попросил повторить.

Нефритовые массажёры для лица.

Он нашёл их на Alibaba по $1,20 за штуку и начал продавать через Shopify за $29,99. Сам он ни разу таким не пользовался. Он даже не знал, для чего они — что-то типа лимфатического дренажа? Снижения отёчности? Он произнёс слово «лимфатический», как будто только читал его и никогда не слышал.

Какой-то чувак с YouTube сказал, что нефритовые массажёры «в тренде», а прибыль по расчётам казалась безумной, поэтому мой знакомый «создал» веб-сайт со стоковыми фотографиями женщин, катающих по увлажнённой коже щёк зеленоватые ролики, и запустил на Facebook рекламную кампанию по $50 в день. Заказчики писали ему на электронную почту, спрашивая, где их товар (отправляется из Гуанчжоу, прибывает через три-шесть недель, иногда намного позже), а он копипастил им ответы, найденные в сабреддите о дропшиппинге. У него был документ Google с готовыми ответами службы поддержки.

Клянусь, он не поговорил ни с одним заказчиком.

Спустя пять месяцев он оказался в минусе на $800.

Он рассказывал мне всё это с таким энтузиазмом, как будто изобрёл колесо.

Я купил ему ещё один кофе, потому что искренне не понимал, что тут ещё можно поделать.

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