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

Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что-то делать: все вокруг внедряют, конкуренты вон что-то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.

Это был, кажется, пятый такой звонок за месяц.

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

Так вот, если коротко - не надо бежать.

Сам я не специалист по нейросетям. Много лет вожусь с базами данных в банках, в ритейле, в системной интеграции, и работа моя: смотреть, как данные живут в настоящих, не презентационных компаниях, и решать, что из задуманного взлетит, а что разобьётся об реальность. Через этот фильтр я и предлагаю взглянуть на нынешний шум вокруг локальных LLM, RAG и «корпоративных помощников».

Представьте: у вас упал прод, и никто не знает, как поднять. Проблема в коде, который писал один человек. А он – недоступен. Или вообще уволился. И вот за вашим плечом вырастает фигура начальника. Затем – начальника начальника. Вы выдергиваете на созвон всех: разрабов, девопсов, тестеров и устраиваете мозговой штурм . Кто-то смотрит код, кто-то логи. А решения все нет. Брр….

Меня зовут Иван, я тимлид. Мне важно, чтобы на проекте не было таких «факапов». Я работаю над устойчивостью команды к рискам. 

Потеря знаний – серьезный риск. Печально, если никто не знает, как работает фича или как устранить инцидент. Для снижения риска я использую матрицу компетенций конкретного проекта. В матрице нет места сферическим знаниям типа «Асинхронности», «SQL», «Паттернов». Только конкретика: «Делал релиз», «Разработал отчеты».

Меня этот инструмент как-то раз серьезно спас, когда ротировалась половина команды. Bus Factor ≥ 2 позволил не потерять критичные знания на проекте. И хотя мой опыт несёт флёр Капитана Очевидности, я рискну им поделиться. Потому что хочу помочь командам, у которых до сих пор Bus Factor = 1.

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

Меня зовут Александр Костюченко, я системный аналитик в Точка Банк. В статье расскажу, как применить стратегию «Голубого океана» на примере рынка бухгалтерских сервисов для ИП, чтобы повысить лояльность пользователей и вывести продукт в среду без конкуренции.

Ошибочным будет пытаться рассмотреть разработку программного обеспечения с момента его реализации и внедрения. В литературных источниках по этому поводу говорится, что жизненный цикл программной системы начинается с момента понимания необходимости в ней и завершается ее заменой на аналогичные или более новые образцы [1-2]. Более того, проекту имплементации предшествуют активности предпроекта, включающие бизнес-кейс, проведение тендера и, наконец, заключение договора на внедрение, а завершается все задачами поддержки имплементированного решения и прекращением его применения.

Анализ программного продукта через призму его жизненного цикла позволяет увязать бизнес-потребности организации и технические возможности их воплощения [3-4]. В проектах разработки высокосложного программного обеспечения жизненный цикл рассматривается с точки зрения репетиций внедрения, что позволяет понизить риск неуспешного продуктивного запуска. При этом вопросам построения масштабируемой, гибкой и отвечающей запросам бизнес-пользователей корпоративной ИТ-архитектуре в классических проектах имплементации программных систем уделяется меньшее внимание.

Отдельное научное направление, отличающееся по содержанию от типовых подходов к разработке и внедрению программного обеспечения и обращающее должное внимание к ИТ-архитектуре, формализовалось в методологии TOGAF [5]. Жизненный цикл программного продукта с точки зрения принципов TOGAF сопровождается непрерывной и устойчивой взаимосвязью между бизнесом, разработкой приложений и ИТ-архитектурой для их развития, что является существенным преимуществом в конкурентной борьбе.

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

Анализ 22 ведущих российских продакт-курсов (Karpov Courses, GoPractice, Skillbox, Яндекс Практикум, программы ВШЭ и других) показал: ни один из них не покрывает все семь ключевых практик доведения проекта до результата. За более чем десять лет менторства продактов я вижу один и тот же паттерн снова и снова — продакт отлично знает, что именно надо делать, но теряет ритм на этапе реализации.

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

Десять инженеров на архитектурном ревью. Один экран, один набор данных, сорок минут обсуждения. Потом каждый пишет саммари для команды.

Саммари получаются разные. Не в деталях — в ключевых выводах.

Это не проблема протокола совещания.

Стивен Порджес в 1988 году работал с данными кардиомониторинга новорождённых в интенсивной терапии. Он смотрел не на патологию — он смотрел на норму. На здоровых детей. И заметил странную вещь: вариабельность сердечного ритма у разных детей в одинаковых условиях покоя вела себя по-разному. Не случайным образом — паттерно. Будто у каждого сердца был собственный почерк, заложенный ещё до того, как ребёнок научился говорить, читать или заполнять психологические тесты.

Порджес назвал это «вагальным тонусом» и потратил следующие двадцать лет, пытаясь объяснить, что это значит.

Он объяснил. Но объяснение поставило под вопрос большую часть того, что мы думали про типологию личности.

«Слушайте пользователя». Это главный совет продактам последние десять лет. Дельный совет. Но он не помогает, когда в команде все слушают и приносят разные решения, противоречащие друг другу. Слушать вы умеете. Решать, кого из своих слушать, нет.

Причина в том, что у продакта есть четыре проверенных методики: теория потребностей, Jobs to be Done, мотиваторы, оценка ценности. Каждая хороша. Каждая отвечает на свой вопрос. Любая из них может оказаться правильной для вашей задачи. И именно в этом проблема.

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

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

Большинство российских коллег и компаний до сих пор планируют роудмепы и фичи на 6-12 месяцев вперёд. В Anthropic за это время успевают выпустить продукт, переделать его, выбросить половину и выпустить снова. Релизы продуктов и критических фичей выходят - е-ж-е-д-н-е-в-н-о. Кэт Ву, глава продукта Claude Code, проводит сотни собеседований и говорит, что почти все кандидаты имеют устаревший подход и мышление. Не потому что они плохие специалисты, а потому, что просто рефлексируют опыт в профессии, которой больше нет.

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

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

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

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

Но при этом просмотр видео почти не ощущается как усилие. А вот написание текста, анализ или сложная задача - да.

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

Управление hardware-проектами редко похоже на классический IT-менеджмент. Здесь нельзя бесконечно двигать сроки, спокойно менять требования по ходу и рассчитывать, что ошибку получится быстро исправить в следующем релизе. В этой сфере слишком многое завязано на жесткие этапы, взаимозависимость команд и высокую цену любой поздней правки. 

Меня зовут Дарья Капустина, я — старший менеджер проектов в департаменте беспроводных технологий связи YADRO. В статье расскажу, как я пришла в управление hardware-проектами и чем такая работа отличается от привычного проджект-менеджмента в software.

В этой статье показываю, как мы устранили хаос в воронках продаж ВКонтакте. Когда два разных чат-бота конфликтуют в одном паблике, бизнес теряет лиды и спамит клиентам. Разбираем под капотом (n8n + Postgres), как построить жесткую маршрутизацию трафика, сэкономить на кастомной разработке бэкенда и спасти конверсию промо-акций

Привет, это Илья, технический директор 2PEOPLE IT. Иногда бизнесу хватает готовой CRM, таблиц и пары интеграций. Но со временем процессы усложняются: данные живут в разных местах, отчеты собираются руками, сотрудники обходят систему через Excel и чаты.

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

Если сейчас слышишь «проект на нейросетях», чаще всего это очередной чат-бот или AI-ассистент. Денис в феврале 2025 года искал что-то другое — задачу, где нейросети дадут результат, который без них не получить. В какой-то момент он увидел в ленте рекламу детективной настольной игры и понял, что вот этот продукт можно построить на нейросетях так, как раньше никто не делал.

Денис автор проекта True Crime Games, детективной игры в Telegram, где подозреваемые отвечают в реальном времени и не отличаются от обычных аккаунтов в чате. В команде он сам, жена и сестра. К маю 2026-го, через восемь месяцев после запуска, было продано более 800 копий игры по $40, выручка ~$30000. 

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

Эта ситуация знакома любой крупной проектной организации. Для одного заказчика дверь должна иметь определённый набор параметров и уровень детализации, для другого — совершенно иной. Раньше приходилось создавать копии каталогов под каждого клиента. Это быстро превращалось в беспорядок: одни и те же BIM-компоненты дублировались по разным папкам, терялась актуальность, а на оптимизацию уходило большое количество времени. Специально для решения этой задачи в Family Manager, системе для управления библиотеками BIM-компонентов, появился функционал «Стандарты».

Налоги на наш бизнес за последние два года выросли в пять-шесть раз. Продавцам мы тоже поднимаем зарплату — за эти годы фонд оплаты труда почти удвоился. Аренду нам переписали вверх, как и всем — рынок недвижимости за эти годы сильно вырос. Оборот при этом в два раза не вырос. Мы работаем на то, чтобы просто удержаться на месте.

При этом у нас 32 магазина в одном городе, больше 100 сотрудников, оборот около 40 млн в месяц и примерно 20% чистыми. Ближайший конкурент держит 20 точек. Рекламы у нас почти нет, она запрещена законом. Ассортимент у всех плюс-минус одинаковый.

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

У Брюса Уэйна есть деньги, влияние и ресурсы.

У Бэтмена — скорость, гибкость и гаджеты на все случаи жизни.

Но по отдельности один без другого не может: без Брюса неоткуда взять технологии, а без Бэтмена они не имеют смысла. Только вместе они закрывают проблемы, с которыми поодиночке не справились бы. Гибридная инфраструктура работает (примерно) так же...

Статья написана на основе интервью с Еленой Власовой, основательницей бренда женской одежды больших размеров Pluffy Queen.

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

В 2021 году я купила в Турции на обычном рынке комбинезон. Очень интересный — в российских магазинах такой было сложно найти. Я стала носить его, показывать в блоге, и подписчицы снова начали спрашивать: «Где купила?». И тут меня осенило: а что, если сшить такой же комбинезон и продать? С этого все и началось.

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

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