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

Меня зовут Владимир Финк, я генеральный директор INTEKEY и это история о том, как боль логистики и провалы автоматизации привели меня в системную интеграцию. Последние 20 лет своей жизни я занимаюсь тем, что заставляю вещи двигаться. Не в философском смысле, а в самом что ни на есть прямом: из точки А в точку Б, быстрее, дешевле и чтобы на выходе получился неиспорченный товар и довольный клиент.

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

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

Давайте по порядку, с самого начала.

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

В итоге именно они — а не рациональность — нередко определяют поведение пользователя и влияют на ключевые метрики продукта: от конверсии и CTR до CSAT и удержания.

В этой статье мы рассмотрели travel-tech через призму поведенческой психологии и собрали распространённые когнитивные эффекты, которые встречаются на пути пользователя — от поиска направления до посадки в самолёт. Рассказали:

• как эти эффекты проявляются в реальных сценариях; 

• как их диагностировать с помощью данных и исследований; 

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

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

Если отращивать бороду, то через 3-4 недели она начинает дико колоться. Кожа раздражается, и на этом эксперимент часто заканчивается.

Потом, когда борода уже длинная, масло всё ещё нужно, потому что волосы колят того, кого вы целуете.

Натуральные масла часто превращают её в жирный блин.

Поэтому мы взяли силиконы. Целых четыре. Наша компания работает с полимерами ещё со времён НИИ полимеров в 90-х, поэтому есть некоторый опыт с такими средами. И стали экспериментировать.

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

Как мы делали масло без масло, которым хочется пользоваться, — рассказываем под катом.

Недавно я тут на Хабре написал цикл статей про «Запрещенные фразы для ИТ-менеджера». Это фразы которыми неопытные менеджеры пытаются отбиться от неожиданных задач, и это же фразы, от которых почему то плохо заказчикам, бизнесу и начальству.

Там я разбирался почему плохо, и почему фразы:

— Этого нет в ТЗ!

— Этого нет в должностной инструкции!

— У меня нет на это ресурсов!

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

Каждая статья собрала больше 10 000 прочтений, и в каментах к каждой был вопрос: «Окей, чел, если так говорить нельзя, то как можно? Расскажи и покажи на примерах, раз такой умный!»

Это — мой ответ на вопрос, а заодно — легкая шпаргалка, которую можно сохранить и применять постоянно, отправляя тем, кто этого подхода еще не знает.

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

Основана она на моем личном опыте (см профиль), на опыте менеджеров, у которых я этому учился и на опыте менеджеров, которых я этому учил сам, как РПО и ментор.

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

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

Рассмотрим практический разбор слабых мест в технических заданиях на разработку систем, сервисов и т.д.

Идеальное ТЗ — утопия, но многие болезненные моменты и конфликты на стадии приемки можно предсказать и минимизировать. Часто они возникают не из-за злого умысла, а из-за слепых зон в документе.

Как повысить доступность оборудования для работы по предназначению и сократить издержки 

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

Границы предиктивной аналитики: почему датчики не видят всей картины 

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

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

TL;DR

Научил бота генерировать PDF-файлы, перенёс "мозги" с GPT-4.1-mini на GPT-5.1 с web search, добавил методику анализа в системный промпт, разобрался с Structured Model Output и собрал JSON-схему.

Теперь модель возвращает структурированный ответ, стабильно верстается HTML+jinja шаблон, и собирается PDF-документ.

Проверил на примере статьи с Хабра. Основной пайплайн работает исправно. Эксперимент продолжается.

Бывало ли такое, что вы ведете долгий проект вместе с агентом, ставите задачи ИИшке, а она только и делает, что топчется на месте, создавая выдуманные переменные и плодя кучу дубляжей файлов с приставками _fix, _final, _corrected?

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

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

Классические театры часто строились во времена, когда об инклюзивности не задумывались. Однако сегодня даже легендарные сцены адаптируют пространство под нужды всех зрителей. Яркий пример – Большой театр в Москве. При грандиозной реконструкции, завершенной в 2011 году, архитекторы и строители заложили специальные решения для зрителей с инвалидностью. В театре появились:

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

Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.

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

"Claude, создай мне воркфлоу в n8n" — работает или хайп?

Я настроил Claude Desktop для работы с n8n. Две недели тестил. YouTube обещает магию. Реальность оказалась сложнее: он теперь джун, а я слежу, чтобы не накосячил.

Что работает: анализ воркфлоу, поиск узких мест. Что не работает: создание сложных процессов, редактирование без глюков.

В статье — инструкция по настройке + честные выводы.

Максим Курбатов, руководитель продукта BIM Inspector (ПИК Digital)

В современном проектировании BIM-модели становятся всё более сложными, а требования к их качеству — строже. Проверка соответствия модели внутренним стандартам, ГОСТам и регламентам — неотъемлемая часть рабочего процесса. Однако ручная или полуавтоматическая проверка быстро превращается в узкое место: десятки правил, сотни элементов, часы ожидания результата.

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

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

Меня зовут Андрей Шумаков, я scrum-мастер, а также куратор по розничному бизнесу в центре развития гибких практик разработки и внедрения продуктового подхода в ПСБ. Мой интерес к настолкам в том числе рабочий: я создаю бизнес-игры. В этой статье расскажу, как создал бизнес-игру с помощью искусственного интеллекта. Scrum-мастера, берите на заметку! Под катом объясню в деталях, как составить хороший промпт и какие именно задачи поручить ИИшке, чтобы она не галлюцинировала излишне, не путалась в контексте и выдавала результат, который потом можно итерировать своими руками. Поехали!

ArchiMate, являясь языком проектирования архитектуры, предоставляет чёткую систему взаимосвязей между объектами. Эта система задаёт возможные варианты отношений для конкретной ситуации и контекста. Учитывая универсальность языка, это огромное преимущество — с его помощью можно описать как бизнес-архитектуру, так и системную, и технологическую.

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

Представьте: вам поручили спроектировать систему, обрабатывающую персональные данные. Требования размазаны по пулу статей НПА, а за ошибку грозят миллионные штрафы. Как структурировать эту сложную область и убедиться, что вы ничего не упустили? В этой статье я на примере положений ФЗ «О персональных данных» (далее по тексту – ФЗ) покажу, как язык ArchiMate помогает превратить юридический текст в четкую архитектурную схему. Такой подход помогает выявить пробелы в требованиях, наглядно согласовать их с заказчиком и заложить основу для проектирования ИТ-решений.

Помню, в далеком 2014 году, когда я  примерял на себя роль проджекта, частенько срывался на продакта: «Мы же договорились! У нас дедлайн через неделю, команда уже работает! Зачем ты снова все меняешь?!»

Он спокойно отвечал что-то типа: «Есть новые данные из исследований пользователей: эта фича не подходит. Зачем делать то, что заведомо не будет работать?»

Я был уверен: продакты - это самодуры и саботажники, которые не понимают важности сроков и бюджетов. Они вечно всё переделывают, задают свои «зачем» и «почему», вместо того чтобы просто дать команде работать.

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

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

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

Привет! Это моя первая статья на Хабре, а к ее созданию меня подтолкнуло решение кейсов для отбора на стажировку от Т-Банка - я проделывал большой объем работ, но фидбека по кейсу не получал, лишь сухое "Спасибо за участие! К сожалению..." и т.д. Подобная фраза никак не помогала мне прогрессировать, находить точки роста и выявлять ошибки в моем решении, поэтому я решил выложить результат работы здесь в надежде на обратную связь от читателей - было бы очень приятно и познавательно услышать, что можно улучшить или доработать. Приятного чтения!

Привет! Я Олег Бугримов, руковожу командой разработки ML-платформы в Авито. В статье расскажу, почему мы решили делать ML-платформу и какие инструменты у нас уже есть. Материал будет полезен ML-инженерам и техлидам, которые хотят сократить время на рутину, обеспечить команду единым набором инструментов, а также повысить качество и скорость разработки ML‑решений.

Сегодня расскажу о том, как подружил бота с GPT через OpenAI API.

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

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

Привет! Меня зовут Андрей Старостин, я DS-инженер в аналитической платформе в Авито. В этой статье я расскажу об устройстве и внедрении сервиса-ассистента на основе искусственного интеллекта для упрощения работы с аналитическими данными в нашем продукте M42 внутри Trisigma.