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

Сисадмин сахарного завода в 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.

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

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

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

В последние два года разговор об AI-агентах почти везде начинается одинаково. Берётся большая языковая модель, к ней подключаются инструменты — поиск, CRM, почта, база знаний, API — и дальше предполагается, что модель сможет сама выбрать нужный инструмент, вызвать его и на этом решить задачу.

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

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

Иными словами, между «модель умеет вызвать инструмент» и «получился надёжный корпоративный агент» лежит отдельный инженерный слой. 

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему tool calling сам по себе не делает ИИ корпоративным агентом, как эту проблему решает наш подход Agent Loop и как этот цикл устроен в реальной enterprise-среде.

Или как дизайнеру продукта решать проблемы бизнеса и причём тут заводы с конвейерами.

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

Поддавшись природному инстинкту дизайнера, ты открыл графический редактор и начал перерабатывать экраны: сократил количество экранов, обновил визуал, переписал тексты, сделал CTA контрастнее. Вроде бы всё стало лучше и понятнее. Но спустя время, когда пришла пора оценивать результаты работы цифры не сдвинулись: люди всё так же доходят до конца онбординга и закрывают приложение, не включая триал. Ты в замешательстве — время и ресурсы потрачены, а цель не достигнута. В какой момент что-то пошло не так?

Привет я продуктовый дизайнер в Альфа-Инвестициях, хочу поделиться знаниями о фундаментальной вещи, которая лежит в основе продуктового дизайна и гораздо важнее навыков UI, ведь кто будет пользоваться вашей красотой, если пользователь не видит ценности всего продукта в целом? Обо всём по порядку.

Привет, Хабр! Меня зовут Данил Зарипов, я занимаюсь продуктовой экспертизой в Positive Technologies. Эту статью мне помог подготовить мой коллега Кирилл Маслов — наш эксперт по направлению Asset Management. Мы решили не искать лёгких путей и выбрали тему, которая большинству из вас хорошо знакома. Казалось бы, что нового можно сказать про домены, пусть и с точки зрения безопасности? 

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

Как это часто бывает в информационной безопасности, самое знакомое скрывает множество нюансов. Давайте разбираться!

Выбирая LLM для своего первого пет-проекта, я случайно создал бенчмарк для LLM "Испытание Дали" по трем параметрам: качество, скорость и стоимость. Этот бенчмарк позволил мне найти оптимальную LLM для встраивания в продукты моей компании Флаг Софт. Возможно, вас тоже заинтересуют его результаты.