{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Личный опыт, управленческие наблюдения и рабочие инсайты", "_rss_description": "Мои размышления о бизнесе, людях, провалах, решениях и выборе. Субъективно, честно и местами болезненно — как оно есть.", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.alexeyit.ru\/tags\/effektivnost-i-psihologiya\/", "feed_url": "https:\/\/www.alexeyit.ru\/tags\/effektivnost-i-psihologiya\/json\/", "icon": "https:\/\/www.alexeyit.ru\/pictures\/userpic\/userpic@2x.jpg?1721902208", "authors": [ { "name": "Петров Алексей", "url": "https:\/\/www.alexeyit.ru\/", "avatar": "https:\/\/www.alexeyit.ru\/pictures\/userpic\/userpic@2x.jpg?1721902208" } ], "items": [ { "id": "150", "url": "https:\/\/www.alexeyit.ru\/all\/kak-upravlyat-riskami-biznesa-i-produkta\/", "title": "Как управлять рисками бизнеса и продукта", "content_html": "

Про риски<\/h2><\/p>\n
\n\"\"\n<\/div>\n

Всем привет. Два прошлых поста подряд, кажется, немного исчерпали запас букв для этого канала. Буду исправляться и стараться писать регулярнее.<\/p>\n

Новости последних дней все видели, поэтому подробно пересказывать их не буду. Для маркетплейса потеря даже крупного склада — неприятность, но всё же малая доля общей инфраструктуры. А вот для селлеров ситуация совсем другая.<\/strong><\/p>\n

Даже если выплаты в итоге покроют стоимость товара — что само по себе не гарантировано, — деньги могут оказаться заморожены на месяцы.<\/strong> А у кого-то на складах лежали товары на десятки и сотни миллионов рублей. В общем, сил всем, кого это затронуло.<\/p>\n

Вероятно, после таких историй усилится тренд на отгрузку с собственных складов и распределение товаров между разными фулфилментами.<\/strong> Возможно, появятся отдельные страховые продукты. Посмотрим, как рынок отработает этот риск.<\/p>\n

Побег с маркетплейсов<\/h2><\/p>\n

На фоне происходящего коллега, который занимается нашим продуктом, задал логичный вопрос: не выстроятся ли теперь селлеры в очередь на выход с маркетплейсов?<\/strong><\/p>\n

Если они уйдут, торговать на площадках будет некому. А если некому торговать, то и наш репрайсер становится не нужен. Логика вроде бы есть.<\/p>\n

Но я слабо верю, что продавцы массово откажутся от маркетплейсов и резко начнут строить собственные интернет-магазины. Скорее рынок адаптируется: кто-то перейдёт на отгрузку со своего склада, кто-то распределит остатки между несколькими площадками и фулфилментами, кто-то застрахует товар.<\/p>\n

Риск никуда не исчезнет, но бизнес найдёт способы с ним жить.<\/strong><\/p>\n

Риски продукта<\/h2><\/p>\n

Я уже писал, что для нашего репрайсера и его аналогов есть два действительно больших риска. Первый — государственное регулирование, которое может серьёзно изменить или вообще зарубить текущую модель. Второй — сами маркетплейсы, которые могут технически ограничить работу подобных сервисов.<\/strong><\/p>\n

Если реализуется один из этих сценариев, вариантов немного: закрыть продукт из-за отсутствия рынка или развернуться в соседнее направление — например, в аналитику или другие инструменты для селлеров.<\/p>\n

Проблема в том, что оба риска потенциально фатальные, но практически неуправляемые.<\/strong> Да, можно заранее вложить время и деньги в запасное направление. Но тогда часть внимания и ресурсов уйдёт из основного продукта, а событие, к которому мы готовились, может вообще не произойти.<\/p>\n

В итоге можно несколько лет готовиться к концу света и пропустить вполне обычные проблемы, которые действительно происходят каждый день.<\/strong><\/p>\n

Вероятность × ущерб<\/h2><\/p>\n

Я это всё к тому, что нет особого смысла постоянно переживать о рисках, которые от нас не зависят и на которые мы почти не можем повлиять.<\/strong><\/p>\n

В первую очередь работать стоит с тем, что с высокой вероятностью произойдёт и при этом может сильно ударить по бизнесу.<\/strong> В самом простом виде приоритет риска можно оценить через произведение вероятности на размер возможного ущерба:<\/p>\n

Вероятность × ущерб = приоритет риска.<\/strong><\/p>\n

Конечно, правильно оценить и вероятность, и последствия — отдельная задача. Но даже такая примитивная модель полезнее, чем обсуждение всех возможных катастроф подряд.<\/p>\n

Коллега посоветовал составить карту рисков. И тут внезапно выяснилось, что её у нас нет ни по продукту, ни в агентстве.<\/strong> Опача. Будем исправлять. Возможно, заодно получится отдельный текст о том, как мы её составляли и что обнаружили.<\/p>\n

Ну и короткое завершение. Кажется, мы вошли во вкус с выставками, поэтому осенью поедем ещё на одну или несколько. Ближайшая — E-Retail Forum 2026, которая пройдёт 22–23 сентября.<\/strong> Осталось не так много времени. Буду рад увидеться и пообщаться лично.<\/p>\n", "date_published": "2026-07-23T13:31:54+03:00", "date_modified": "2026-07-23T13:31:50+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/meteor.png", "_date_published_rfc2822": "Thu, 23 Jul 2026 13:31:54 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "150", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/meteor.png" ] } }, { "id": "149", "url": "https:\/\/www.alexeyit.ru\/all\/reyting-runeta-2026-webest-voshel-v-top-3-e-commerce-top-10-bitr\/", "title": "Рейтинг Рунета 2026: Webest вошел в топ-3 e-commerce, топ-10 Битрикс24 и топ-30 по технической поддержке", "content_html": "

Астрологи объявили неделю двух постов 😊<\/strong><\/p>\n

\n\"\"\n<\/div>\n

Хвастаться, конечно, не очень красиво. Но если иногда не рассказать о своих результатах, то о них никто и не узнает.<\/span><\/p>\n

На днях вышли обновленные рейтинги Рунета, и в этом году мы показали хороший результат.<\/span><\/p>\n

В категории e-commerce заняли <\/span>3 место в среднем сегменте<\/strong>. Здесь, правда, сами себе поставили небольшую претензию. Средним сегментом мы, конечно, занимаемся, но уже около года целимся в верхний. Значит, в следующем рейтинге будем штурмовать уже его.<\/span><\/p>\n

Среди CRM-интеграторов поднялись на <\/span>9 место<\/strong>. Год назад были ниже, так что движение идет в правильную сторону.<\/span><\/p>\n

Отдельно радует направление Битрикс24. Мы остаемся одним из всего <\/span>10 партнеров<\/strong>, обладающих сертификатом <\/span>Битрикс24 Enterprise среднего уровня<\/strong>, а также входим в <\/span>топ-10 партнеров Битрикс24<\/strong> по официальному рейтингу. Для нас это один из самых важных показателей.<\/span><\/p>\n

Еще впервые попали в рейтинг по технической поддержке. Раньше он назывался «Развитие», теперь — просто «Поддержка». Итог — <\/span>24 место<\/strong>. Не первое, конечно, но специалистов в этой сфере очень много, поэтому буду скромно говорить, что мы в <\/span>топ-30 России<\/strong>. Звучит вполне достойно. 🙂<\/span><\/p>\n

Есть и другие отраслевые рейтинги — промышленность, пищевая отрасль и другие. Там тоже уверенно держимся в двадцатке и тридцатке, но это уже приятные бонусы.<\/span><\/p>\n

И напоследок хочется сказать спасибо команде Рейтинга Рунета. За последний год они проделали действительно огромную работу: полностью переработали личный кабинет, сделали более прозрачным сбор и модерацию данных, серьезно улучшили сами рейтинги. Ну и отдельное удовольствие — наблюдать, что творилось в общем чате. 😄<\/span><\/p>\n

Анатолий, Александр и вся команда Рейтинга Рунета — спасибо за ваш труд и удачи в следующих обновлениях!<\/span><\/p>\n

 <\/p>\n", "date_published": "2026-07-01T08:38:55+03:00", "date_modified": "2026-07-01T08:38:51+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/baron.png", "_date_published_rfc2822": "Wed, 01 Jul 2026 08:38:55 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "149", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/baron.png" ] } }, { "id": "148", "url": "https:\/\/www.alexeyit.ru\/all\/stoit-li-uchastvovat-v-ecom-expo-opyt-kompanii-i-rezultaty\/", "title": "Стоит ли участвовать в Ecom Expo: опыт компании и результаты", "content_html": "

Выставки в 2026 работают? <\/strong><\/h1><\/p>\n
\n\"\"\n<\/div>\n

Всем привет!<\/span><\/p>\n

Вот и прошла первая половина года. Как у вас дела с целями на 2026<\/strong>-й? Получилось выполнить хотя бы 50% запланированного?<\/span><\/p>\n

У нас нет<\/strong>. Значит, есть над чем работать.<\/span><\/p>\n

На прошлой неделе мы второй раз в жизни участвовали в выставке со своим стендом — на Ecom Expo<\/strong>. До этого весной были на выставке «Селлеры и Маркетплейсы<\/strong>», поэтому уже есть с чем сравнить.<\/span><\/p>\n

На первой выставке мы получили около 20 лидов<\/strong>. Пока в контракт превратился только один. Если считать только его, стоимость привлечения выглядит пугающе — около 300 тысяч рублей.<\/strong> Но в B2B сделки живут долго, поэтому окончательные выводы делать рано. Часть переговоров еще продолжается.<\/span><\/p>\n

С Ecom Expo впечатления совсем другие.<\/strong><\/p>\n

Посетителей было заметно больше, и это чувствовалось буквально во всем. Мы собрали около 60+ лидов, а количество содержательных разговоров выросло примерно втрое. Основной интерес был к нашему репрайсеру GuardPrice<\/strong>. Забавно, что мы стояли в зале, который больше ориентирован на разработку и интеграции, хотя целевая аудитория продукта в основном находилась в соседнем павильоне с маркетинговыми сервисами. Если бы знали это заранее, выбрали бы другое место. Но даже так люди сами находили наш стенд.<\/span><\/p>\n

По услугам разработки и внедрению CRM тоже были обращения, хотя их оказалось значительно меньше. Это вполне ожидаемо: на подобных мероприятиях все же чаще приходят за готовыми продуктами, чем за заказной разработкой.<\/span><\/p>\n

Если говорить о самой выставке, то не очень понравилась площадка в «Тимирязев Центре».<\/strong><\/span><\/p>\n

Само пространство современное, удобное и выглядит отлично. Но организация сцен оставила вопросы. Они никак не отделены от основной выставочной зоны: нет ни стен, ни звукоизоляции. В результате несколько сцен одновременно создают постоянный фоновый шум. Разговаривать приходится почти криком, и к концу второго дня голос просто заканчивается. Не завидую спикерам — выступать в таких условиях явно непросто.<\/span><\/p>\n

Кстати, еще один практический вывод: удобная обувь — обязательна. Не просто удобная, а максимально удобная. Беговые кроссовки, Crocs<\/strong> или что-то похожее. Два дня почти без перерывов на ногах ощущаются намного тяжелее, чем кажется заранее.<\/span><\/p>\n

По аудитории тоже было интересно. До выставки казалось, что основной поток составят небольшие продавцы и селлеры. На практике среди примерно сотни людей, с которыми мы пообщались, около трети представляли уже достаточно зрелый средний бизнес, а 8–10 компаний — это действительно крупные игроки рынка, которых легко найти в рейтингах крупнейших компаний российского e-commerce. И, что особенно приятно, многие из них интересовались именно репрайсером<\/strong>.<\/span><\/p>\n

Конечно, окончательные выводы можно будет делать только после обработки всех лидов и завершения переговоров. Но уже сейчас могу сказать, что с точки зрения вложенных денег, времени и полученного опыта участие в выставке себя оправдало.<\/span><\/p>\n

Поэтому осенью обязательно повторим. В сентябре едем со стендом на Retail Week.<\/strong><\/span><\/p>\n

Посмотрим, какие выводы сделаем после третьей выставки.<\/span><\/p>\n

 <\/p>\n", "date_published": "2026-07-01T08:28:02+03:00", "date_modified": "2026-07-01T09:08:44+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления", "Репрайсер" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/IMG_2651.png", "_date_published_rfc2822": "Wed, 01 Jul 2026 08:28:02 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "148", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/IMG_2651.png" ] } }, { "id": "147", "url": "https:\/\/www.alexeyit.ru\/all\/chto-na-samom-dele-stoit-za-razvitiem-repraysera-dlya-marketpley\/", "title": "Что на самом деле стоит за развитием репрайсера для маркетплейсов", "content_html": "

«Да это Claude за час сделает»<\/strong><\/p>\n

Всем привет 👋<\/p>\n

\n\"\"\n<\/div>\n

Пишу всё реже, но стараюсь хотя бы раз в неделю появляться здесь. Казалось бы, лето сезон отпусков, а B2B традиционно начинает жить в режиме «давайте после лета». Почти как «давайте после праздников».<\/p>\n

Логично предположить, что свободного времени становится больше. Но почему-то получается ровно наоборот.<\/p>\n

Больше всего времени сейчас уходит на продукт. За кажущейся простотой и популярной мыслью «да это Клод за час навайбкодит» обычно скрывается огромное количество нюансов. И чем глубже копаешь, тем больше понимаешь, что основная работа начинается уже после того, как первая версия заработала.<\/p>\n

Поэтому расскажу про несколько изменений, которые мы сделали в репрайсере за последние месяцы.<\/p>\n

Свои прокси вместо арендованных<\/h2><\/p>\n

С самого начала продукт был довольно автономным и почти не зависел от внешних сервисов. Но одна зависимость всё-таки оставалась прокси<\/strong>.<\/p>\n

Долгое время мы их закупали у сторонних поставщиков. Казалось бы, что тут может пойти не так<\/strong>? На практике многое<\/strong>.<\/p>\n

Мы перепробовали множество провайдеров и сервисов. Где-то была слишком агрессивная ротация IP, где-то качество адресов оставляло желать лучшего. Но главная проблема была в другом отсутствие стабильности<\/strong>.<\/p>\n

Система могла спокойно работать неделю, а потом в самый неподходящий момент прокси просто исчезал на несколько часов. Для репрайсера это критично.<\/p>\n

Поэтому мы решили сделать следующий шаг и перейти на собственную инфраструктуру прокси. Теперь сами отбираем IP по нашим требованиям и контролируем качество работы. Это не самая заметная функция продукта, но именно такие вещи дают реальную надёжность.<\/p>\n

Когда отказоустойчивость перестаёт быть теорией<\/h2><\/p>\n

Продолжая тему стабильности.<\/p>\n

До недавнего времени ядро системы располагалось на инфраструктуре Бегета, и в целом всё работало отлично. Но весной произошло несколько неприятных историй подряд.<\/p>\n

Судя по комментариям провайдера, на магистральных каналах возникли серьёзные проблемы. В какой-то момент одновременно выпали основной и резервный провайдеры. Для большинства проектов это неприятность. Для сервиса, который должен работать постоянно, уже серьёзный риск.<\/p>\n

Самое неприятное даже не в самом инциденте. Самое неприятное, когда такие ситуации начинают повторяться. А у нас это были не единичные случаи, а несколько сбоев подряд с интервалом примерно в неделю<\/strong>.<\/p>\n

После этого стало понятно, что хранить все яйца в одной корзине плохая идея.<\/p>\n

Сейчас мы активно смотрим в сторону Selectel, Яндекс Облака, Reg.ru и других площадок. Параллельно перестраиваем архитектуру продукта в сторону сервисного подхода. Не микросервисы ради модного слова, а разумное разделение системы на независимые компоненты.<\/p>\n

В моём понимании «много сервисов» это не сотни. Уже около десяти независимых сервисов позволяют переживать отдельные сбои без остановки всей системы.<\/p>\n

Апрель и май получились довольно увлекательными, бессонными и местами незабываемыми. Но именно такие месяцы обычно заставляют принимать правильные инфраструктурные решения.<\/strong><\/p>\n

Что ещё делаем<\/h2><\/p>\n

Пока занимались вопросами надёжности, работа над самим продуктом не останавливалась.<\/p>\n

Оптимизировали существующие стратегии, в том числе с точки зрения безопасности. Начали разработку стратегий на основе UNIT-экономики каждого товара. Продолжаем развивать поддержку новых площадок Золотое Яблоко, Лемана ПРО, М.Видео и других маркетплейсов.<\/p>\n

Ну и, как обычно, огромное количество небольших улучшений, которые редко попадают в релизные заметки, но ежедневно делают систему лучше.<\/p>\n

Новый человек в команде продукта<\/h2><\/p>\n

И, наверное, самое важное изменение за последнее время.<\/p>\n

К команде присоединился новый коллега. Я в шутку называю его цифровым разнорабочим<\/strong>. Да простит меня Рома.<\/p>\n

По сути, он будет совмещать сразу несколько ролей: аккаунтинг, project management и product management.<\/p>\n

По мере роста продукта становится всё сложнее держать всё в голове и одновременно заниматься развитием, клиентами и операционкой. Поэтому рассчитываю, что это усиление позволит сделать продукт ещё более стабильным и предсказуемым.<\/p>\n

Впрочем, как и всегда, время покажет.<\/p>\n

Ну и напоследок.<\/p>\n

Если давно хотели пересечься лично, напоминаю, что уже на следующей неделе будет Ecom Expo. Мы будем там со своим стендом. Подробности здесь: https:\/\/t.me\/alexeyitru\/206<\/a><\/a><\/p>\n

Буду рад увидеться и пообщаться вживую.<\/p>\n", "date_published": "2026-06-17T17:07:20+03:00", "date_modified": "2026-06-17T17:10:07+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/iun.png", "_date_published_rfc2822": "Wed, 17 Jun 2026 17:07:20 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "147", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/iun.png" ] } }, { "id": "146", "url": "https:\/\/www.alexeyit.ru\/all\/kogda-pokazatel-stanovitsya-celyu-zakon-gudharta-prostymi-slovam\/", "title": "Когда показатель становится целью: закон Гудхарта простыми словами", "content_html": "

Когда показатель становится целью<\/h1><\/p>\n

Недавно узнал, что у всей этой истории с KPI и метриками есть официальное название — закон Гудхарта<\/strong>.<\/p>\n

\n\"\"\n<\/div>\n

Хотя сама идея для меня новой не стала. За годы работы с проектами постоянно сталкивался с одной и той же проблемой.<\/p>\n

Когда показатель становится целью, он перестает быть хорошим показателем.<\/p>\n<\/blockquote>

И чем дольше в менеджменте, тем больше убеждаешься, что проблема обычно не в KPI. Проблема начинается тогда, когда люди перестают отличать цель от способа ее измерения.<\/p>\n

Ломаем метрики<\/h2><\/p>\n

Почти любой показатель появляется как попытка ответить на разумный вопрос. Как понять, что все работает эффективно<\/strong>? Смотрим производительность<\/strong>. Как понять, что клиенты довольны? Измеряем NPS. Как понять, что поддержка справляется? Следим за скоростью ответа.<\/p>\n

Пока показатель остается инструментом наблюдения, все работает нормально. Но стоит привязать к нему премию, рейтинг или повышенное внимание руководства, и люди начинают оптимизироваться уже не под результат, а под сам показатель.<\/p>\n

Хотите увеличить количество закрытых задач — получите дробление задач<\/strong>. Хотите загрузить сотрудников на 100<\/strong>% — получите очереди и постоянные переключения между работой. Хотите улучшить SLA — получите быстрые ответы вместо полезных. Хотите увеличить количество лидов — получите лиды. Правда, это совсем не гарантирует рост продаж.<\/p>\n

Самое неприятное, что внешне система выглядит успешной. Графики растут, отчеты становятся красивее, показатели улучшаются. <\/p>\n

Цифры как цель<\/h2><\/p>\n

Наверное, поэтому нужно настороженно относится к управлению исключительно через цифры. Без них нельзя управление на одних ощущениях обычно заканчивается не лучше. Но и считать цифры конечной истиной тоже опасно.<\/p>\n

Для разработчика целью является не количество закрытых задач, а создание полезного продукта. Для поддержки не скорость ответа, а решение проблемы клиента. Для бизнеса не количество встреч, звонков или коммерческих предложений, а создание ценности, за которую готовы платить.<\/p>\n

Мне нравится аналогия с автомобилем<\/strong>. Показатели<\/strong> это приборная панель. Скорость, обороты двигателя и уровень топлива помогают понимать, что происходит с машиной. Но если водитель начнет считать целью удерживать стрелку спидометра на определенной отметке, поездка может закончиться довольно быстро.<\/p>\n

Растягивать линейку<\/h2><\/p>\n

Это ситуация, когда человек понимает, по какому критерию его оценивают, и начинает улучшать именно критерий, а не результат. Причем чаще всего это происходит не из злого умысла. Люди просто адаптируются к системе. Если система считает успехом определенную цифру, то именно эту цифру и начинают улучшать.<\/p>\n

Поэтому хороший показатель — это тот, который сложно улучшить без реального улучшения результата. А рядом с любым KPI полезно держать простой вопрос:<\/p>\n

«Если этот показатель вырастет в два раза, станет ли клиенту, проекту или бизнесу действительно лучше?»<\/p>\n

Если ответ неочевиден, то, возможно, мы измеряем не то.<\/p>\n

Забавно, что Чарльз Гудхарт сформулировал свой закон еще в 1975 году. Прошло больше полувека, а большинство управленческих проблем вокруг метрик по-прежнему выглядят одинаково.<\/p>\n

Мы все еще пытаемся управлять реальностью через показатели. А реальность все еще оказывается сложнее отчетов.<\/p>\n", "date_published": "2026-06-04T12:30:28+03:00", "date_modified": "2026-06-04T12:30:20+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/gurh.png", "_date_published_rfc2822": "Thu, 04 Jun 2026 12:30:28 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "146", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/gurh.png" ] } }, { "id": "145", "url": "https:\/\/www.alexeyit.ru\/all\/izmeryaem-b2b-saas-odnoy-metrikoy-pochemu-eto-pochti-nevozmozhno\/", "title": "Измеряем B2B SaaS одной метрикой — почему это почти невозможно", "content_html": "

В какой-то момент и до нас докатилась необходимость начать нормально измерять продукт. Не в формате «ну вроде продажи идут<\/strong>» или «по ощущениям всё неплохо<\/strong>», а цифрами.<\/p>\n

\n\"\"\n<\/div>\n

Сразу оговорюсь: рассказывать про виды метрик, North Star, retention и прочие правильные термины я не буду. Про это уже написаны сотни статей и сняты тысячи видео людьми куда умнее меня. Расскажу лучше, как это постепенно появляется у нас.<\/p>\n

Кажется, мы постепенно переросли стадию подтверждения гипотезы из серии: «О, кто-то действительно готов за это платить деньги»<\/strong>. А это уже немного другой этап. На нем продукт перестает быть просто «интересной штукой» и начинает превращаться в систему, где важно понимать, что именно растет, почему растет и где всё может внезапно начать ломаться.<\/p>\n

И тут начинается самое интересное.<\/p>\n

Одной метрикой<\/strong><\/h2><\/p>\n

Как и многие, вначале хотелось найти какую-то одну волшебную цифру. Посмотрел на неё утром и сразу понял: всё хорошо или пора тушить пожар.<\/p>\n

Но это работает плохо. Особенно если сервис в целом должен функционировать автономно. У нас нет классической истории, где пользователь каждый день открывает приложение, тыкает настройки и проводит внутри по три часа. Поэтому DAU, MAU и прочие красивые графики в нашем случае не всегда что-то реально покажут.<\/p>\n

Потому что клиент может вообще не заходить в систему неделю и это будет означать не проблему, а наоборот: всё работает стабильно.<\/p>\n

В итоге приходит понимание, что смотреть приходится сразу на несколько слоев продукта:
— деньги,
— техническое здоровье,
— поведение клиентов,
— маркетинг,
— стабильность инфраструктуры.<\/p>\n

И только вместе это начинает давать более-менее честную картину.<\/p>\n

Первое, с чего начали<\/strong><\/h2><\/p>\n

Самое очевидное — деньги.<\/p>\n

Смотрим, сколько получили и сколько потратили. Пока в расходах считаем рекламу, серверы, телефонию, покупку ПО и прочую инфраструктуру.<\/p>\n

А вот разработку и развитие продукта сюда специально не включаем. Потому что это уже скорее инвестиции, а не операционные расходы. Иначе можно случайно прийти к выводу, что продукт убыточен просто потому, что вы активно его развиваете.<\/p>\n

Хотя здесь, конечно, у каждого своя логика учета.<\/p>\n

Интересный момент: когда начинаешь регулярно смотреть на финансовые показатели, внезапно выясняется, что некоторые «очевидно полезные» вещи пользы почти не дают. А какие-то мелкие доработки, наоборот, влияют на деньги сильнее, чем ожидалось.<\/p>\n

Неважные технические метрики<\/strong><\/h2><\/p>\n

Для B2B SaaS технические метрики иногда важнее продуктовых<\/strong>.<\/p>\n

Потому что пользователь может простить неидеальный интерфейс. Может простить сложную настройку. Но вот если у него перестала корректно работать автоматизация это уже проблема.<\/p>\n

Поэтому хотим начать отслеживать:
— количеством активных профилей,
— числом товаров под контролем,
— количеством успешных обработок,
— товарами, ушедшими в перерасчет,
— ошибками обработки,<\/p>\n

На практике, думаем, это поможем быстро замечать перекосы на маркетплейсах. Где-то поменялась логика, где-то API начал отвечать через раз, где-то очередной «эксперимент» площадки сломал половину логики.<\/p>\n

Раньше такие вещи замечались через поддержку: клиент пишет, что «что-то странное». Сейчас многие проблемы видно еще до обращения клиента. И это, наверное, одна из самых полезных частей всей истории с метриками.<\/p>\n

Маркетинг<\/strong><\/h2><\/p>\n

Отдельная история — маркетинговые показатели. Смотрим на CAC, органический трафик, количество лидов<\/strong> и пытаемся всё это сопоставлять с деньгами.<\/p>\n

Потому что лиды сами по себе довольно опасная метрика. Их может быть много, но если они плохо конвертируются или быстро отваливаются, ценности в этом немного.<\/p>\n

Вообще, чем дальше, тем сильнее появляется ощущение, что почти любая метрика без контекста легко вводит в заблуждение.<\/p>\n

Можно радоваться росту регистраций и не замечать, что половина пользователей не доходит до запуска. Можно радоваться росту оборота и не видеть, что вместе с ним растут расходы. Можно смотреть на MRR и не замечать, что support уже начинает задыхаться. Цифры без контекста иногда вредят даже больше, чем их отсутствие.<\/p>\n

Самая сложная часть<\/strong><\/h2><\/p>\n

Из экономических показателей пытаемся следить за:
MRR, ARPA, CLTV и TCV<\/strong>.<\/p>\n

Пока без фанатизма, но хотя бы появляется понимание:
— сколько реально приносит клиент,
— насколько окупаются привлечение и поддержка,
— как меняется качество клиентской базы,
— где начинается рост, а где просто увеличение нагрузки.<\/p>\n

В B2B довольно легко получить ситуацию, когда один крупный клиент визуально «рисует» вам отличный месяц. Хотя системного роста при этом может и не быть. Или наоборот: продукт растет очень правильно и устойчиво, но выглядит это скучно и медленно.<\/p>\n

Самая грустная часть<\/strong><\/h2><\/p>\n

Самое забавное, что продукт про автоматизацию, а сами мы аналитику до сих пор собираем почти вручную. Что-то лежит в CRM. Что-то в таблицах. Где-то цифры обновляются автоматически, где-то руками.<\/p>\n

И в какой-то момент начинаешь понимать, что следующая задача — это уже не сбор метрик, а сбор метрик о метриках<\/strong>. Потому что когда данных становится много, появляется новая проблема: как не утонуть в них и не начать принимать решения только потому, что график красиво растет вправо вверх.<\/p>\n", "date_published": "2026-05-20T14:43:03+03:00", "date_modified": "2026-05-20T14:42:56+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления", "Репрайсер" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/0_ZjYSm_q36J4KChdn.jpg", "_date_published_rfc2822": "Wed, 20 May 2026 14:43:03 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "145", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/0_ZjYSm_q36J4KChdn.jpg" ] } }, { "id": "144", "url": "https:\/\/www.alexeyit.ru\/all\/akcii-na-marketpleysah-kak-formiruetsya-cena-i-pochemu-padaet-ma\/", "title": "Акции на маркетплейсах: как формируется цена и почему падает маржа", "content_html": "

Про акции на маркетплейсе и медианную цену <\/strong><\/h3><\/p>\n
\n\"\"\n<\/div>\n

Ни для кого не секрет, что акции на маркетплейсах — это почти главный инструмент продвижения. Дополнительные плашки на карточке, буст в выдаче, рост трафика — все это напрямую конвертируется в продажи. Вопрос только в том, какой ценой.<\/p>\n

В детали типов акций углубляться не будем. Важно другое: в большинство акций можно попасть автоматически, если товар проходит по условиям. Площадка берет медианную цену за последние 1–3 месяца и снижает ее на 10–30%, чтобы сформировать «выгоду» для покупателя. Именно от этой логики дальше строится вся экономика.<\/p>\n

Главная проблема: цена против трафика<\/strong><\/h3><\/p>\n

Если коротко — усидеть на двух стульях не получится. Нельзя одновременно активно участвовать в акциях и жестко удерживать цену на целевом уровне.<\/p>\n

Единственный рабочий вариант — планомерно поднимать медианную цену<\/strong>. Тогда вход в акции будет происходить уже от вашей целевой РРЦ, а не от заниженной базы. Это длинная игра, но других стабильных вариантов нет.<\/p>\n

Отдельно добавляет сложности история с «скрытыми» механиками вроде эластичного бустинга. Формально это тоже акция, но через API ее не видно. Для автоматизации это превращается в серую зону, где система не до конца понимает, что происходит с ценой.<\/p>\n

Как мы работаем с акциями<\/strong><\/h3><\/p>\n

Подход у нас одинаковый для всех маркетплейсов. Разница только в нюансах API.<\/p>\n

Если работа с акциями выключена, система пытается менять цену напрямую. Если после нескольких итераций итоговая цена на витрине не меняется, появляется сигнал: товар, скорее всего, участвует в акции. В этот момент система перестает «биться в стену» и фиксирует ситуацию. Это по сути ручной режим — вы сами решаете, оставаться в акции или нет.<\/p>\n

Если товар оставили в акции, система просто ждет ее окончания. После завершения — автоматически возвращает цену в нужный диапазон. Это безопасный сценарий, но без контроля внутри акции.<\/p>\n

Когда включена работа с акциями по API, начинается уже более точная логика. Система получает список активных акций и проверяет каждый товар — с учетом того, что он может участвовать сразу в нескольких.<\/p>\n

Дальше все упирается в ограничение маркетплейса: есть максимальная цена в акции, которая рассчитывается от медианной. Выше нее подняться нельзя.<\/p>\n

Система считает целевую цену для попадания в РРЦ и сравнивает ее с этим потолком. Если расчетная цена ниже — все просто, мы обновляем цену и остаемся в акции. Но так бывает редко.<\/p>\n

Если расчетная цена выше — есть два варианта. Либо мы выходим из акции и возвращаем контроль над ценой, либо остаемся, но ставим максимально допустимую цену внутри акции. Во втором случае мы жертвуем коридором РРЦ, но сохраняем трафик.<\/p>\n

Что в итоге<\/strong><\/h3><\/p>\n

Акции — это не просто инструмент роста, это компромисс между объемом продаж и маржой. И чем раньше это принимаешь, тем проще строится стратегия. Хоть мы пока не умеем автоматически возвращать товары в «выгодные» акции — слишком много переменных в расчете, но в ближайшее время будет MVP по этому поводу. <\/p>\n", "date_published": "2026-05-05T15:46:39+03:00", "date_modified": "2026-05-05T15:46:36+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/sale-1.png", "_date_published_rfc2822": "Tue, 05 May 2026 15:46:39 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "144", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/sale-1.png" ] } }, { "id": "143", "url": "https:\/\/www.alexeyit.ru\/all\/strategii-cenoobrazovaniya-na-marketpleysah-rrc-konkurenty-yunit\/", "title": "Стратегии ценообразования на маркетплейсах: РРЦ, конкуренты, юнит-экономика и ошибки", "content_html": "

Стратегии ценообразования, о которых все говорят, и как они ломаются в реальности<\/strong><\/h2><\/p>\n
\n\"\"\n<\/div>\n

Продолжаем продуктовую историю. С начала года провели много ВКС, показывали продукт, общались с рынком. Были и небольшие магазины с десятками SKU, и производители с ассортиментом в десятки тысяч позиций. Почти в каждом разговоре упирались в один и тот же вопрос: как управлять ценой.<\/span><\/p>\n

Разберу основные стратегии, с которыми сталкиваемся на практике.<\/span><\/p>\n

РРЦ как ориентир<\/strong><\/h3><\/p>\n

Самая базовая история это РРЦ. Некоторая “идеальная” цена, которую хочется удерживать во всех каналах: офлайн, маркетплейсы, сайт, дилеры.<\/span><\/p>\n

Как она формируется сейчас не важно. Важно другое. РРЦ это ориентир, а не стратегия.<\/span><\/p>\n

Как только появляется реальный рынок, все начинает расходиться. Акции, скидки площадок, серые поставки, давление дилеров. В итоге РРЦ остается на бумаге, а в жизни начинается борьба за фактическую цену продажи.<\/span><\/p>\n

Следование за конкурентами<\/strong><\/h3><\/p>\n

Вторая популярная модель это смотреть на конкурентов и повторять за ними. Выбирается одна или несколько карточек и дальше цена двигается вслед за ними.<\/span><\/p>\n

На первый взгляд логично. Не выпадаешь из рынка, не проседаешь по заказам. Но проблема в том, что вы не знаете, что происходит у конкурента.<\/span><\/p>\n

Он может распродавать остатки, работать в ноль или в минус, завозить товар в серую или просто демпинговать, чтобы выбить других. Да, можно ограничивать диапазон и не падать слишком низко. Но если кто-то целенаправленно идет вниз, эта стратегия все равно проиграет. Вы просто едете следом.<\/span><\/p>\n

Юнит-экономика<\/strong><\/h3><\/p>\n

Третья стратегия это расчет цены через юнитку. Считаем все: себестоимость, логистику, эквайринг, комиссии маркетплейсов, налоги, склад, людей. Добавляем целевую маржу и получаем цену, при которой бизнес зарабатывает.<\/span><\/p>\n

Звучит правильно, но есть нюанс. Такая цена не может быть статичной. Она зависит от десятков факторов и должна меняться вместе с ними.<\/span><\/p>\n

И здесь начинается сложность. Нужно собрать данные, поддерживать их в актуальном состоянии и правильно учитывать в расчете. Мы сейчас как раз двигаемся в эту сторону и готовим такую модель у себя. Посмотрим, как она поведет себя в реальности.<\/span><\/p>\n

Рост оборота и красивые стратегии<\/strong><\/h3><\/p>\n

Отдельный класс решений это “умные” стратегии вроде роста оборота или маржинальности.<\/span><\/p>\n

На бумаге все выглядит убедительно, пока не смотришь внутрь.<\/span><\/p>\n

Простой пример. Есть диапазон цены 100–150 рублей. Ставим цель увеличить оборот. Что делает система. Роняет цену до 100, продажи растут. Когда остаток уменьшается, поднимает до 150.<\/span><\/p>\n

В отчетах все хорошо. Оборот вырос, метрика выполнена. По факту вы просто продали товар дешевле, чем могли. Такие стратегии отлично оптимизируют цифры, но не всегда оптимизируют бизнес.<\/span><\/p>\n

Попытка нащупать спрос<\/strong><\/h3><\/p>\n

Еще одна идея это динамически менять цену и смотреть на реакцию продаж. Подняли, посмотрели. Опустили, посмотрели. Попробовали найти баланс.<\/span><\/p>\n

Проблема в том, что рынок живет не только ценой. Продажи могут вырасти из-за рекламы, сезона, погоды или действий конкурентов. А система в этот момент считает, что это ее заслуга и продолжает двигаться в ту же сторону.<\/span><\/p>\n

Если добавить сюда низкую частоту покупок по многим товарам, становится понятно, что делать достоверные выводы сложно.<\/span><\/p>\n

Что еще <\/strong><\/p>\n

Есть ещё ряд стратегий, которые в классическом ритейле считаются нормой, но на маркетплейсах встречаются заметно реже. Например, ценообразование от канала (channel-based pricing), когда одна и та же позиция стоит по-разному в зависимости от точки продаж, или премиальная модель (value-based pricing), где цена сознательно выше рынка за счёт бренда и позиционирования. В офлайне и D2C это работает, потому что меньше прозрачности и больше контроля над клиентским опытом. На маркетплейсах же всё лежит “на одной полке”, и разница в цене быстро становится проблемой, а не преимуществом.<\/span><\/p>\n

Туда же можно отнести стратегии осознанного демпинга (penetration pricing) или, наоборот, удержания цены относительно лидера рынка (price leadership). Формально это разные подходы, но по сути — попытка занять понятную роль: либо самый дешёвый, либо “как у лидера”. В реальности такие модели требуют запаса прочности и дисциплины, иначе быстро уходят либо в минус, либо в постоянную реакцию на чужие действия.<\/span><\/p>\n

И, наконец, есть более операционные модели — например, stock-based pricing, когда цена зависит от остатков. Логика здравая: ускоряем оборачиваемость или, наоборот, дорабатываем маржу на дефиците. Но на маркетплейсах это упирается в ограничения площадок, акции, комиссии и ту же РРЦ. В итоге все эти стратегии существуют, но применяются точечно и редко становятся основой — слишком много внешних факторов, которые их ломают.<\/span><\/p>\n

Что в итоге<\/strong><\/h3><\/p>\n

Если собрать все вместе, видно простую вещь. У каждой стратегии есть ограничения. РРЦ не выдерживает реальности. Конкуренты непредсказуемы. Юнитка сложна в реализации. “Умные” стратегии дают красивую картинку, но не всегда результат. Эксперименты дают шум. В итоге не существует одной правильной модели. Есть только комбинация подходов и постоянная работа с данными.<\/span><\/p>\n

Куда смотрим дальше<\/strong><\/h3><\/p>\n

Сейчас у себя мы сфокусировались на следующем уровне. Работа с акциями на маркетплейсах.<\/span><\/p>\n

Регулировать цену и выходить из акций, когда это становится невыгодно, мы уже умеем. Следующий шаг понять, в какие акции вообще стоит заходить.<\/span><\/p>\n

Потому что участвовать во всех значит терять маржу. Не участвовать значит терять оборот. И вот здесь начинается самая интересная часть, когда цена перестает быть просто числом и становится управленческим решением.<\/span><\/p>\n

 <\/p>\n", "date_published": "2026-04-23T14:37:12+03:00", "date_modified": "2026-04-23T14:54:28+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/market-1.png", "_date_published_rfc2822": "Thu, 23 Apr 2026 14:37:12 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "143", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/market-1.png" ] } }, { "id": "142", "url": "https:\/\/www.alexeyit.ru\/all\/menedzher-na-avtopilote-pochemu-my-prinimaem-tysyachi-resheniy-v\/", "title": "Менеджер на автопилоте: почему мы принимаем тысячи решений в день и не управляем ими", "content_html": "

Ты менеджер. Просто не осознал этого<\/strong><\/h2><\/p>\n
\n\"\"\n<\/div>\n

Слово “менеджер<\/strong>” давно испортилось. Когда-то это был нормальный термин про управление, принятие решений, сейчас чаще что-то из серии “вам удобно говорить?<\/strong>” или просто размытая должность, за которой непонятно, что стоит. Цифровой разнорабочий. Менеджер по продажам, по клиентам, по развитию, по маркетингу — ролей много, но восприятие у слова стало довольно токсичным<\/strong>.<\/p>\n

Возможно, это только моё ощущение, но я с этим сталкиваюсь регулярно. У себя мы даже сознательно ушли от части таких формулировок. Менеджер проектов стал руководителем проектов<\/strong>, менеджер по продажам — специалистом клиентского сервиса<\/strong>. Не потому что это кардинально меняет суть работы, а потому что снижает раздражение на старте общения и задаёт другой тон взаимодействия<\/strong>.<\/p>\n

Если при этом убрать весь этот налёт, остаётся довольно простое определение. Менеджер — это человек, который управляет процессами, решениями и людьми. И вот здесь начинается самое интересное, потому что если посмотреть чуть шире, то окажется, что это определение подходит гораздо большему числу людей, чем принято думать<\/strong>.<\/p>\n

Есть оценка, что человек принимает десятки<\/strong> тысяч<\/strong> решений в день — часто называют цифру в районе 30–35 тысяч. Точность можно обсуждать, но сам масштаб понятен: решений действительно много, и большая их часть проходит мимо нашего внимания<\/strong>. Мы действуем на автопилоте, опираясь на опыт, привычки и уже сформированные сценарии поведения. Это нормально и даже необходимо, иначе на базовые вещи просто не хватило бы ресурса.<\/p>\n

Но даже если взять небольшую долю — допустим, те самые 5% решений, которые требуют осознанного участия, — это уже сотни точек выбора в течение дня. Что приоритизировать, как ответить, где надавить, а где уступить, на что потратить время, а что отложить. Именно в этих моментах и появляется реальное управление<\/strong>.<\/p>\n

По сути, каждый день мы управляем процессами распеределения своего времени, внимания, энергии и решений. Просто не называем это управлением и не всегда к этому относимся осознанно. Пока всё идёт по привычному сценарию, автопилот работает отлично и экономит силы. Но как только появляется что-то новое или выбивающееся из рутины, он начинает давать сбои, и в этот момент либо включается управление, либо мы просто реагируем на обстоятельства<\/strong>.<\/p>\n

Если посмотреть честно, менеджер — это не роль и не запись в трудовой.Это то, чем мы занимаемся каждый день, управляя своими решениями, временем и вниманием.<\/strong><\/p>\n", "date_published": "2026-04-15T16:37:13+03:00", "date_modified": "2026-04-15T16:38:11+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/pilot.png", "_date_published_rfc2822": "Wed, 15 Apr 2026 16:37:13 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "142", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/pilot.png" ] } }, { "id": "141", "url": "https:\/\/www.alexeyit.ru\/all\/ya-vyhozhu-na-svyaz-na-srednih-volnah\/", "title": "Я выхожу на связь на средних волнах", "content_html": "

Всем привет. Давно не писал, надеюсь вы еще тут, так как телеграм в последнее время работает нестабильно и доступность быстро снижается, но пока он жив. <\/p>\n

\n\"\"\n<\/div>\n

Посмотрим, что будет дальше. Вполне возможно, что однажды мы здесь не услышимся, поэтому чтобы не теряться — буду дублировать тексты в max (https:\/\/max.ru\/id352831751730_biz<\/a><\/a>).<\/p>\n

Если честно, не понимаю негативный шлейф вокруг max. В целом кажется, что ребята активно и быстро накидывают функционал, по крайней мере десктопное приложение обновляется буквально через день. Касательно вбросов про то, что следят, смотрят, читают - мне кажется это больше вбросы, потому что по цифровому следу вас и так при желании найдут<\/strong>. И вопрос в других мессенджерах этого нет? Не думаю. Скорее вопрос в том, кто именно читает, а не читают ли вообще<\/strong>. Ну да ладно, сегодня не об этом. Ну а если мучает паранойя — можно завести отдельное устройство с симкой и без микрофона и камеры.<\/p>\n

Сейчас идет много новостей о том, что ВПН «умирают», их старательно вычищают из сторов для Android и iOS. Операторы связи вбрасывают новости о том, что трафик через VPN будут дополнительно тарифицировать, и прочие вещи, призванные закрутить гайки и ограничить доступ к нежелательным ресурсам.<\/p>\n

В целом я думаю, что да, доступность сервисов уже снижается<\/strong>, но полностью запретить ВПН не смогут. Ведь существует огромное количество сервисов, которым этот инструмент просто необходим для безопасности. Почти на любом крупном проекте доступы в боевую среду идут только через ВПН, используются удаленные рабочие столы и закрытые сети. То есть да, часть самых популярных протоколов будут ограничивать<\/strong>, но технология останется как таковая, потому что она нужна для работы большого числа компаний, в том числе и в госсекторе.<\/p>\n

Есть классические решения вроде OpenVPN он массовый и поэтому хорошо определяется через DPI и часто режется. WireGuard — более современный и быстрый, но тоже уже научились детектить по поведению трафика. Старые корпоративные вещи типа IPSec часто живут, потому что их используют в инфраструктуре компаний. Вся эта история крутится вокруг DPI — провайдеры анализируют трафик, сигнатуры и поведение соединений.<\/p>\n

Вторая мысль — про зарубежный трафик. Обрубить его полностью можно, но это будет очень больно для многих проектов. Ведь любой портал, сайт или интернет-магазин с большой долей вероятности тянет из внешнего мира библиотеки, скрипты, шрифты и другие зависимости, сервера которых находятся за пределами страны. Да, это можно поправить, но не быстро и не дешево.<\/p>\n

Но что делать с обновлениями тех же Windows? Или с сервисами вроде Google Docs и таблиц? Их инфраструктура тоже находится за рубежом. Полное отключение такого трафика ударит уже не по пользователям, а по бизнесу и процессам<\/strong>.<\/p>\n

Поэтому глобально железный купол над интернетом вряд ли появится<\/strong>. Скорее это будет похоже на сачек — отфильтруют то, что на поверхности и используется большинством. Но те, кому это действительно нужно, все равно найдут способы<\/strong>, благо их в интернете более чем достаточно.<\/p>\n", "date_published": "2026-04-02T14:39:17+03:00", "date_modified": "2026-04-02T14:39:08+03:00", "tags": [ "Инструменты и сервисы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/bunker.png", "_date_published_rfc2822": "Thu, 02 Apr 2026 14:39:17 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "141", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/bunker.png" ] } }, { "id": "140", "url": "https:\/\/www.alexeyit.ru\/all\/zamenit-li-ai-programmistov-v-2026-realny-opyt-i-ogranicheniya-a\/", "title": "Заменит ли AI программистов в 2026: реальный опыт и ограничения AI в разработке", "content_html": "

Непопулярное мнение про AI<\/strong><\/p>\n

\n\"\"\n<\/div>\n

Последнее время все ленты просто завалены постами про вайбкодинг, openclaw и прочие штуки, которые якобы заменят программистов, убьют заказную разработку и позволят компаниям разогнать IT-отделы. Хочется немного остудить этот хайп и зафиксировать точку зрения, которая идет немного вразрез с этим инфопотоком.<\/p>\n

Во-первых, AI действительно сильно бустанет разработку и около IT. Если раньше условно от программиста требовали писать 1000 строк кода в неделю, то теперь это может быть 10 000. То же самое с другими специализациями. Но это не про замену, это про изменение рынка<\/strong>. Станет больше кода, больше проектов и больше попыток что-то запустить. При этом в какой-то момент начинаешь ловить себя на мысли, что иногда задачу быстрее и дешевле решить руками<\/strong>, чем пытаться объяснить LLM, что ты от нее хочешь — токены и время на диалог спокойно съедают весь эффект.<\/p>\n

Во-вторых, запуск новых продуктов действительно упростился. Напилить SaaS для тестирования гипотезы за день или даже за пару часов — уже реальность. Мы сами пробовали, и да, это ощущается как магия. Но дальше начинается обратная сторона: безопасность, архитектура, поддержка. Видел кейс, где на вайбкодинг-продукте с интеграцией со Stripe взломали систему и увели платежные данные. Плюс история с BuzzFeed — ставка на AI и в итоге разговоры о риске банкротства. Это хороший сигнал, что сам по себе AI не делает продукт жизнеспособным<\/strong>.<\/p>\n

Дальше интереснее. Чем больше людей пойдут в разработку, тем больше будет кода и проектов. А значит, работы станет не меньше, а скорее больше. При этом у меня пока слабо укладывается в голове, как AI будет стабильно развивать сложный проект. По ощущениям это больше похоже на постоянное переписывание с нуля, потому что в длинных диалогах все еще есть проблемы с контекстом, галлюцинациями и артефактами. А если в проекте что-то правили руками, возникает отдельная проблема — как учитывать эти изменения и не ломать все следующими итерациями.<\/p>\n

Отдельная история — инфляция. Сейчас уже есть инфляция контента, и AI ее только усиливает. С продуктами будет то же самое. Мало просто что-то написать — это еще нужно продать. Дистрибуция, маркетинг, позиционирование никуда не делись. Если продукт не решает реальную задачу, никакой AI его не вытянет.<\/p>\n

Еще один слой — инфраструктура и доступы. Если это что-то маленькое, вроде лендинга, наверное окей дать AI доступ к серверу и базе. Но если речь про нормальный прод с каскадом серверов, балансировщиками, мастер-слейв базами и тюнингом — пока слабо верится, что это можно стабильно делать через агентов. При этом мы уже сейчас отдаем в LLM огромное количество данных, и до конца не понимаем, как это будет использоваться дальше.<\/p>\n

Ну и важный момент. Разработка — это не только код, это услуга. А в любой услуге есть коммуникация, погружение в бизнес, понимание задач и ограничений. Я слабо представляю, что CTO среднего бизнеса скажет: «пойду навайбкоджу себе CRM и B2B-площадку». Скорее он обратится к тем, кто уже это делал.<\/p>\n

Вайбкодинг — это круто, мы сами уже что-то собирали за пару часов, и это реально работает. Но воспринимать это как панацею, которая полностью изменит рынок, — выглядит как перегрев ожиданий. Рынок не исчезнет, он просто станет быстрее, шумнее и местами хаотичнее.<\/p>\n

А как у вас? <\/strong>AI — это уже рабочий инструмент или пока больше про «поиграться и забыть»?<\/p>\n", "date_published": "2026-03-19T10:01:41+03:00", "date_modified": "2026-03-19T10:01:51+03:00", "tags": [ "Личный опыт и размышления", "Технологии и разработка" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/djin.png", "_date_published_rfc2822": "Thu, 19 Mar 2026 10:01:41 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "140", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/djin.png" ] } }, { "id": "138", "url": "https:\/\/www.alexeyit.ru\/all\/chernye-lebedi-v-saas-kak-odin-zakon-i-odin-anons-mogli-pohoroni\/", "title": "Черные лебеди в SaaS: как один закон и один анонс могли похоронить наш продукт", "content_html": "

Иногда ты просыпаешься утром и понимаешь, что твоего продукта может просто не стать. <\/p>\n

\n\"\"\n<\/div>\n

Не потому что плохой код или ушли клиенты, а потому что где-то приняли решение, которое меняет правила игры. 2026 год для нас начался именно так — с двух анонсов, которые теоретически могли обнулить рынок репрайсеров.<\/p>\n

Закон, который мог обнулить рынок<\/strong><\/h2><\/p>\n

С 1 октября 2026 года в России вступает первый закон о платформенной экономике. Он регулирует маркетплейсы, сервисы доставки, такси и другие цифровые площадки-посредники. Государство фиксирует правила для огромного рынка, делая его более прозрачным и управляемым, но при этом не вмешивается напрямую в экономику платформ.<\/p>\n

Маркетплейсы больше не смогут резко менять условия: о повышении комиссий, штрафов и изменении правил нужно уведомлять за 45 дней. Запрещены необоснованные блокировки, вводится обязательная система досудебных споров. Площадка не может снижать цену без согласия продавца — можно установить минимальную цену.<\/p>\n

На первый взгляд — хорошие новости для селлеров. Но если смотреть с позиции продукта, который работает с ценообразованием, возникает вопрос: а не убивает ли это саму потребность в репрайсерах?<\/strong> Если рынок становится «справедливее», если площадки не могут произвольно вмешиваться в цену, нужен ли внешний инструмент?<\/p>\n

Теоретически такой закон мог просто обнулить рынок. Мы даже не считали детально сценарий влияния, но в худшем варианте рынок мог сократиться почти до нуля<\/strong>. Однако фундамент остаётся прежним: комиссии, штрафы и маркетинговые механики никто не ограничивает, а контроль над спросом всё равно у платформ. Формулировки могут поменяться, но монопольная сила площадок никуда не исчезает<\/strong>. Поэтому главный вопрос — даст ли закон селлерам полноценно управлять «зелёной» ценой — скорее всего, нет.<\/p>\n

Репрайсер от Ozon<\/strong><\/h2><\/p>\n

Вторым «чёрным лебедем» стал анонс собственного репрайсера от Ozon для WB и Ozon. Пока это пилот для ограниченного числа продавцов, но сам факт выхода платформы в эту зону — сигнал. Если маркетплейс делает собственный инструмент, логичный вопрос: зачем тогда сторонние сервисы?<\/strong><\/p>\n

Первая обратная связь от селлеров показала, что «зелёную» цену инструмент держит нестабильно — часто уходит ниже. Возможно, это баг, возможно — особенность алгоритма, и его поправят. Про WB пока рано что-то утверждать. Но важно другое: у платформы всегда больше данных и больше контроля над финальной ценой, чем у внешнего сервиса<\/strong>. И если такой продукт доведут до стабильной версии, это меняет рынок.<\/p>\n

История знает немало внутренних продуктов крупных компаний, которые так и не стали массовыми. Вспоминается целое кладбище инициатив того же Яндекса. Поэтому пилот — это ещё не приговор, но сигнал, который нельзя игнорировать.<\/p>\n

Что это значит для нас<\/strong><\/h2><\/p>\n

Самое важное в этой истории — не закон и не Ozon. А то, что SaaS, построенный вокруг платформ, зависит от чужих решений<\/strong>. Сегодня ты оптимизируешь их экономику, завтра они меняют правила или выходят со своим инструментом.<\/p>\n

При этом реальность сложнее и не сводится к драме. У нас есть решение для Яндекс Маркета, и сейчас это сильная сторона. Рынок постепенно движется в сторону модели, похожей на США, где платформы усиливают контроль над экономикой, а выигрывают в первую очередь производители. Если этот тренд закрепится, инструменты управления ценой никуда не исчезнут — просто изменится их роль.<\/p>\n

Черные лебеди в продукте — это не всегда катастрофа. Чаще это напоминание о том, что ты играешь на чужом поле<\/strong>. И если строишь бизнес вокруг маркетплейсов, нужно быть готовым к тому, что изменения извне могут в любой момент закончить историю продукта. Вопрос лишь в том, станет ли это концом или точкой следующего роста.<\/p>\n", "date_published": "2026-02-19T12:26:40+03:00", "date_modified": "2026-02-19T12:26:36+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления", "Репрайсер" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/lebed.png", "_date_published_rfc2822": "Thu, 19 Feb 2026 12:26:40 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "138", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/lebed.png" ] } }, { "id": "137", "url": "https:\/\/www.alexeyit.ru\/all\/matematika-protiv-porogovyh-skidok\/", "title": "Математика против пороговых скидок", "content_html": "

Продолжаем вести историю изменений по продукту. Как вы поняли из предыдущего поста, мы едем с ним на выставку. <\/p>\n

\n\"\"\n<\/div>\n

Посмотрим, что из этого получится. Про экономику обязательно отдельно напишу, когда будут данные и можно будет говорить предметно. А пока — что успели сделать с начала года и какие выводы для себя сделали.<\/p>\n

С аутричем вышла интересная история. Мы его протестировали и пока притормозили. На старте казалось, что выйти на нужных селлеров будет относительно просто, но реальность оказалась сложнее. Достучаться до правильного человека в e-commerce куда труднее, чем кажется изнутри продукта.<\/strong> Это не значит, что канал плохой, но усилий он требует больше, чем мы закладывали.<\/p>\n

Зато отлично себя показывает контекстная реклама. Сейчас получаем квалифицированных лидов примерно по 1500 рублей<\/strong>, и для нашей экономики это рабочая модель. Плюс постепенно начинает давать результат SEO. Не быстрый инструмент, но устойчивый. Параллельно развивали сайт и в итоге перевезли его на Битрикс — редактировать контент становилось все сложнее, а продукт растет, информации становится больше. Нужно было навести порядок, иначе начинаются операционные косты там, где их можно было избежать.<\/p>\n

Также добавили новые направления по работе с Lamoda, Лемана Про и М.Видео. Расширяем покрытие аккуратно, без резких движений, но последовательно.<\/p>\n

Эксперимент с биллингом вместо тарифов<\/h2><\/p>\n

Отдельно расскажу про изменение модели оплаты. Раньше у нас были просто тарифы. Но по факту запросы клиентов оказались слишком разными. У кого-то десятки товаров, у кого-то тысячи. У кого-то агрессивная частота обновления, у кого-то спокойный режим. В рамках фиксированных тарифов это начинало ломать логику.<\/p>\n

Поэтому мы перешли на модель биллинга с баланса от запуска<\/strong>. Теперь у клиента есть счет, а списание происходит по факту использования. По сути — оплата за потребление<\/strong>, а не за абстрактный пакет возможностей. Нам кажется, что это более честная и гибкая модель, но посмотрим, как она покажет себя на дистанции.<\/p>\n

Нелинейные скидки — главная математика<\/h2><\/p>\n

Продолжаем бороться с нелинейными скидками и авторизацией. Если вы продаете на маркетплейсах, то наверняка замечали, что цены могут сильно отличаться для разных покупателей. Влияет регион, выбранный ПВЗ, логистика, персональные механики площадки. Это делает задачу репрайсинга куда сложнее, чем кажется со стороны.<\/p>\n

Мы отказались от индивидуальной авторизации под каждого клиента и перешли к единой авторизации для Ozon и Яндекс Маркета<\/strong>, которая смотрит цены как покупатель в Москве. Пока мониторим стабильность решения. Если покажет себя хорошо, добавим еще 3–5 регионов для сравнения.<\/p>\n

А теперь пример, чтобы было понятно, в чем сложность. Товар на Яндекс Маркете. Передаем цену 5124<\/strong> ₽ — покупатель видит 3293<\/strong> ₽. Передаем 5224<\/strong> ₽ — покупатель видит уже 4112<\/strong> ₽. Мы меняем входную цену всего на 100 рублей, а итоговая цена для покупателя скачет почти на 1000.<\/strong> Это эффект пороговой скидки, и он ломает линейную логику расчета.<\/p>\n

Чтобы работать с такими сценариями, мы разработали новую стратегию расчета с использованием естественного и искусственного интеллекта. Формула стала сложнее и требует большего количества шагов, но зато позволяет точнее подбираться к целевому значению. Важно понимать, что при старте нового профиля нужно 3–4 запуска<\/strong>, чтобы система собрала статистику и вычислила рабочие цены. Это не баг, это этап калибровки.<\/p>\n

Фичи к выставке и упрощение онбординга<\/h2><\/p>\n

К ближайшей выставке допиливаем две функции, которые давно просили клиенты. Первая — возможность принудительного ручного запуска всех товаров или конкретного товара из личного кабинета. Раньше такая опция была только у админов, и это, честно говоря, было недальновидным решением.<\/p>\n

Вторая — упрощенная форма создания профиля. Сейчас интерфейс во многом выглядит как панель программистов для программистов<\/strong>, что не лучшим образом влияет на онбординг. Мы делаем сценарий проще: нажимаешь «Создать», выбираешь маркетплейс, вводишь токен, выбираешь товары, ставишь РРЦ, задаешь частоту обновления — и запускаешь. Минимум лишних шагов.<\/p>\n

При этом даже в текущем, не самом простом интерфейсе, есть пользователи, которые самостоятельно создают и запускают профили без нашей помощи. Это хороший сигнал.<\/p>\n

Движение без иллюзий<\/h2><\/p>\n

Есть и другие мелкие задачи, которые решаем по мере поступления. Продукт постепенно взрослеет. Где-то через эксперименты, где-то через пересборку модели оплаты, где-то через математику скидок, которая на бумаге выглядит красиво, а в реальности ведет себя совсем иначе.<\/p>\n

Работаем дальше. Увидимся на выставке. Буду рад пообщаться лично и обсудить, как у вас устроена экономика на маркетплейсах.<\/p>\n", "date_published": "2026-02-13T09:16:41+03:00", "date_modified": "2026-02-13T09:16:38+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления", "Репрайсер" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/matematic.png", "_date_published_rfc2822": "Fri, 13 Feb 2026 09:16:41 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "137", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/matematic.png" ] } }, { "id": "136", "url": "https:\/\/www.alexeyit.ru\/all\/yandeks-kit-dlya-internet-magazina-chto-eto-kak-rabotaet-i-stoit\/", "title": "Яндекс Кит для интернет-магазина: что это, как работает и стоит ли запускать сайт", "content_html": "

Новое начало маленьких интернет-магазинов?<\/strong><\/h1><\/p>\n
\n\"\"\n<\/div>\n

Кажется, ниша небольших интернет-магазинов на WP и Тильде либо умирает<\/strong>, либо уверенно движется в эту сторону. И нет, это не про вайб-кодинг — он только расправляет крылья, посмотрим, куда его занесёт. Сегодня хочется поговорить про другое. Про Яндекс Кит<\/strong>.<\/p>\n

Мы недавно участвовали в вебинаре для партнеров, кого пригласили посмотреть продукт изнутри. И вот что он из себя представляет.<\/p>\n

По сути, это классический облачный конструктор, очень жёстко заточенный под e-commerce<\/strong>. Не универсальный «сайт обо всём»<\/strong>, а именно магазин. И ключевая ставка здесь сделана на дизайн и на интеграции — то, на чём обычно всё и ломается.<\/p>\n

С этим у Кита <\/strong>как раз всё неплохо. Базовый набор — ровно то, что нужно: обмен с 1С, «МойСклад», Яндекс Маркет, интеграция с Ozon и WB, retailCRM, amoCRM, Bitrix24. Можно подключить свой домен, фирменный стиль по мелочи, всё как положено.
По оплатам — Яндекс Pay и CloudPayments.
По логистике — Яндекс, СДЭК, Ozon Логистика.<\/p>\n

В итоге со старта получается очень приятный и взрослый набор<\/strong>, без ощущения «песочницы».<\/p>\n

Отдельно стоит сказать про одну из ключевых фишек — бесшовную интеграцию с Yandex ID<\/strong>. Что это даёт на практике? Более высокую конверсию за счёт того, что данные пользователя уже заполнены. А если карта привязана — покупка превращается буквально в пару кликов. Для небольшого интернет-магазина это огромная разница.<\/p>\n

Про дизайн. Его можно кастомить, но без фанатизма — и это, кажется, осознанный выбор. Изначально Кит отлично ложится на fashion-сегмент, под который он, по ощущениям, и делался. Если хочется «вау-уникальность» или каких то супер кастомных интеграций — это не сюда. Если хочется быстрее начать продавать — вполне.<\/strong><\/p>\n

Создаётся ощущение, что Яндекс что-то знал<\/strong> про рынок маркетплейсов и волну селлеров, которые оттуда пойдут. Вопрос который был в воздухе: зачем свой интернет-магазин, если можно выложить карточки на маркетплейс и сразу получать продажи? Со своим интернет-магазином нужно думать про маркетинг, трафик, аналитику, повторные продажи. Это сложно и долго.<\/p>\n

Но реальность сейчас такая: если ты продал на маркетплейсах на 5 млн рублей, 2–2,5 млн из них ты спокойно отдал<\/strong> в виде комиссии, логистики и маркетинговых сборов. И тут возникает вполне логичный вопрос — а неужели на своём интернет-магазине нельзя привлечь клиентов хотя бы на эти же 2 млн? При этом данные пользователей остаются у тебя<\/strong>, их можно догревать, возвращать, продавать повторно. А это уже совсем другая экономика.<\/p>\n

Так что рынок разработки интернет-магазинов умер? И да, и нет.<\/p>\n

Этот вопрос поднимался ещё в тот момент, когда маркетплейсы начали активно захватывать рынок. Зачем свой магазин, если это затраты, куча проблем, ресурсы и неочевидная отдача? Ответ пришёл со временем. Свой интернет-магазин — это бренд и прямой доступ к клиенту.<\/strong> А значит, меньше зависимости от правил площадки и чуть более спокойный сон.<\/p>\n

В итоге что получается. Рынок разработки интернет-магазинов не умрёт. Яндекс Кит просто займёт свою нишу<\/strong>, отжав у Тильды, WP и части типовых решений на Битриксе проекты небольших e-commerce. Если нужно что-то сложное, нетривиальное или B2B — вариантов по-прежнему немного, и кастом никуда не денется.<\/p>\n

Со своей стороны мы планируем активно пробовать Яндекс Кит как ещё один инструмент быстрого запуска<\/strong> для небольших e-commerce-проектов, где городить что-то большое и сложное просто нецелесообразно.<\/p>\n

Инструменты меняются. Смысл — нет.<\/p>\n", "date_published": "2026-02-04T10:26:41+03:00", "date_modified": "2026-02-04T10:26:38+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления", "Технологии и разработка" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/Kit.png", "_date_published_rfc2822": "Wed, 04 Feb 2026 10:26:41 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "136", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/Kit.png" ] } }, { "id": "134", "url": "https:\/\/www.alexeyit.ru\/all\/pim-sistema-dlya-e-commerce-zachem-nuzhna-kogda-vnedryat-i-kakie\/", "title": "PIM-система для e-commerce: зачем нужна, когда внедрять и какие бывают решения", "content_html": "

PIM: дорого, сложно. И почему без него иногда нельзя<\/strong><\/h2><\/p>\n
\n\"\"\n<\/div>\n

Праздники закончились, пора вкатываться <\/strong>в рабочий ритм. На праздники был простой план: написать много контента. По факту контента <\/strong>написать не получилось, зато отлично прокачались новые когнитивные связи на падел-корте. Но сейчас не об этом.<\/p>\n

Конец года оказался богатым на проекты, где так или иначе всплывала тема внедрения или серьёзной переработки системы хранения товарных данных. В простонародье это PIM<\/strong>. Product Information Management<\/strong>. Формально PIM <\/strong>почти всегда уже есть. Иногда эту роль выполняет CMS <\/strong>или 1С <\/strong>или какая то иная система. Где-то лежат описания, где-то характеристики, где-то изображения.<\/p>\n

До определённого момента этого хватает. А потом наступает состояние, когда дальше так жить невозможно<\/strong>. Не потому что «так принято», а потому что становится больно<\/strong>. Больно <\/strong>обновлять каталог, больно создавать новые товары, больно выходить на маркетплейсы и поддерживать порядок.<\/p>\n

Когда всё начинает ломаться?<\/strong><\/h2><\/p>\n

Проблемы редко появляются резко. Обычно они накапливаются. Контент начинают править в нескольких системах одновременно. Характеристики дублируются и расходятся. Картинки теряются, переименовываются вручную и живут без связи с товаром. SKU начинают вести себя как отдельные сущности, но управлять ими по-прежнему пытаются как попало.<\/p>\n

В какой-то момент 1С <\/strong>перестаёт быть чисто учётной системой и превращается в неудобный редактор контента. CMS <\/strong>начинает хранить вообще всё подряд. Никто уже не может ответить, где находится «истина», а любое изменение превращается в риск что-то сломать.<\/p>\n

И именно здесь появляется PIM<\/strong>. Не как ещё одна модная платформа, а как попытка навести порядок в данных.<\/p>\n

Зачем вообще нужен? <\/strong><\/h2><\/p>\n

Ключевая мысль, которую важно принять сразу. PIM не заменяет 1С и не конкурирует с CMS. У каждой системы своя роль.<\/p>\n

1С остаётся учётной системой. Там создаются товары и SKU, живут GUID, цены и остатки. PIM становится единым источником товарного контента. Описания, характеристики, изображения, история изменений. Сайт и маркетплейсы в этой схеме выступают потребителями данных, а не местом их редактирования.<\/p>\n

Как только это разделение ответственности зафиксировано, дальше архитектура начинает складываться сама собой.<\/p>\n

Входные требования <\/strong><\/h2><\/p>\n

За последние проекты у нас сформировалась довольно приземлённая памятка с требованиями которые мы выдвигаем при выборе. PIM должен разворачиваться на своём сервере<\/strong>. Желательно быть реализованным на понятном и не экзотическом <\/strong>стеке, чтобы при необходимости систему можно было развивать своими силами. Важно, чтобы модель данных нормально поддерживала работу с товарами и SKU как с разными сущностями. И конечно, чтобы интеграции с сайтом <\/strong>и маркетплейсами <\/strong>либо уже существовали, либо были реализуемы без сверхусилий.<\/p>\n

Если на старте эти требования игнорировать, дальше почти всегда начинается дорогостоящий кастом.<\/p>\n

Akeneo. Классический PIM без сюрпризов<\/strong><\/h2><\/p>\n

Akeneo — это зрелая и понятная PIM-система. Очень хорошо подходит для каталогов с большим количеством атрибутов, сложной структурой и аккуратной моделью данных. У неё сильное сообщество, понятная логика работы и адекватная Community-версия.<\/p>\n

Но важно понимать ограничения. Akeneo почти не решает задачи интеграции с маркетплейсами из коробки. Всё, что связано с Ozon, Wildberries и подобными площадками, придётся проектировать и реализовывать самостоятельно. DAM-возможности в бесплатной версии тоже достаточно базовые. В итоге это отличный фундамент, но с расчётом на последующую разработку.<\/p>\n

Pimcore. Максимальная гибкость, максимальная ответственность<\/strong><\/h2><\/p>\n

Pimcore — это уже не просто PIM, а целая платформа. Здесь можно собрать PIM, DAM, MDM и много чего ещё в одном контуре. Возможности почти безграничны, но за это приходится платить сложностью.<\/p>\n

Для работы с маркетплейсами и выгрузками данных в Pimcore практически неизбежно понадобится Data Director. Это отдельный коммерческий модуль, который позволяет настраивать импорт, экспорт и трансформацию данных без глубокого кода. С ним жить сильно проще, но он не бесплатный и не решает всё автоматически.<\/p>\n

Pimcore отлично подходит компаниям с сильной технической командой и пониманием, зачем им такая гибкость. Без этого внедрение легко превращается в бесконечный проект.<\/p>\n

Ensi PIM. Прикладной подход для e-commerce<\/strong><\/h2><\/p>\n

Ensi — это решение с явным фокусом на e-commerce и маркетплейсы. Модель данных проще, зато сразу ориентирована на практические сценарии. Интеграции с маркетплейсами доступны в коммерческой версии, и это сильно сокращает время выхода в прод.<\/p>\n

Минус здесь тоже очевиден. Меньше универсальности и больше зависимости от вендора. Некоторые функции доступны только в PRO-версии, и при масштабировании важно заранее понимать, на каких условиях система будет развиваться дальше.<\/p>\n

Как всегда важен контекст<\/strong><\/h2><\/p>\n

Главная ошибка, которую мы видим снова и снова, это попытка сделать идеальный PIM сразу<\/strong>. На практике работает только итерационный подход<\/strong>. Сначала выносится контент из CMS. Потом аккуратно отсоединяется контентная часть от 1С. Затем расширяется модель атрибутов. И только после этого имеет смысл активно развивать интеграции с маркетплейсами.<\/p>\n

PIM не нужен всем. Но если ассортимент растёт, маркетплейсы становятся важным каналом, а контент начинает жить своей жизнью, вопрос уже не в том, нужен ли PIM. Вопрос в том, сколько будет стоить отложенное решение.<\/p>\n

 <\/p>\n", "date_published": "2026-01-20T09:33:22+03:00", "date_modified": "2026-01-20T09:33:14+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/PIM.png", "_date_published_rfc2822": "Tue, 20 Jan 2026 09:33:22 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "134", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/PIM.png" ] } }, { "id": "133", "url": "https:\/\/www.alexeyit.ru\/all\/2025-byl-neprostoy-eto-vy-eschyo-2026-ne-videli\/", "title": "2025 был непростой. Это вы ещё 2026 не видели", "content_html": "

Вот и год подходит к завершению, до Нового года осталось совсем чуть-чуть. В целом 2025-й для заказной разработки был непростым — об этом много писали и говорили. <\/p>\n

\n\"\"\n<\/div>\n

Но важно другое: плохо было не у всех<\/strong>. Я думаю, что как только выйдет отчётность, мы с удивлением увидим, что многие выросли, причём опережая рынок<\/strong>.<\/p>\n<\/p>

У нас — в целом всё неплохо. Именно «неплохо», без фанфар. Производство работает, экспертиза на месте, команда живая. Но год очень хорошо подсветил слабые места — прежде всего в продажах и в том, как они устроены. Поэтому мы решили не латать старое, а переписать<\/span> написать стратегию на следующий год с нуля<\/strong>.<\/p>\n

Немного надоела непрогнозируемость традиционных каналов продвижения агентств, студий и продакшенов. Контент, холодные продажи, рассылки — у кого-то это работает и даёт нужную экономику. У нас — нет. Мы пробовали. Честно и не один раз. Поэтому в 2026 мы решили осознанно пивотнуться<\/strong> в этой части.<\/p>\n

Что ещё показал этот год<\/h3><\/p>\n

Первый важный вывод — сидеть на партнёрских лидах, не развивая собственные продажи, очень скользкая дорожка<\/strong>. Как только рынку стало хуже, лидов стало меньше, партнёрки быстро сдулись. И компаниям, у которых это был ключевой канал, стало резко больно.<\/p>\n

Второй вывод — аутсорс тоже не бесконечен. Если ты не ходишь «в баню с нужными людьми», он может закончиться внезапно<\/strong>. И тогда полкоманды остаётся без загрузки. А сейчас людей быстро пристроить уже не так просто. Возможно, мы просто так не умеем, но у нас и нет такой проблемы — но сейчас не об этом. <\/p>\n

Итак, 2026<\/h3><\/p>\n

Осуждать не надо. Заняться этим стоило ещё вчера. Или год назад.<\/p>\n

Первое — медийность.<\/strong>
Мы решили, что топам направлений нужно в это осознанно вкладываться. Начали с собственных каналов и общения внутри профессиональной тусовки. Зачем — станет понятно чуть дальше.<\/p>\n

Второе — выставки и мероприятия.<\/strong>
В этом году я много общался с коллегами, которые активно в них участвуют. По их рассказам — это работает. Даже если делить результат на два, всё равно выглядит разумно.
Участие в выставках с услугами мне всегда казалось сомнительным, но сейчас у нас появился продукт<\/strong>, который можно использовать как флаг и ездить с ним по рынку. Продукт становится формой входа в клиента и поводом для разговора. А так как он из e-commerce, то и контакты там ожидаются более качественные. Так что увидимся на выставках — список мероприятий сейчас как раз формируем.<\/p>\n

Третье — видео-контент.<\/strong>
Это логичное продолжение темы медийности. Чёткого рецепта пока нет. Подкасты — не наш формат, там сложно показать экспертизу. Вебинары нравятся, но это скучный формат и туда нужно активно лить рекламу. EdTech не даст соврать — бесплатные вебинары у них один из ключевых каналов продаж.
В общем, в эфирах вы нас увидите<\/strong>. Первые попытки уже делаем.<\/p>\n

Четвёртое — аутрич по продукту.<\/strong>
Мы пробовали аутрич на услугах, заходили даже с коробочным B2B-решением — цифры были удручающие.
Но когда есть продукт и ты заходишь не «продать», а на кастдев, показатели становятся заметно лучше. Поэтому будем продолжать. Это почти единственный канал, который хоть как-то поддаётся математическому прогнозированию.<\/strong><\/p>\n

И пятое — зачем всё это.<\/strong>
Медийность, видео, продукт — всё это ведёт к выступлениям. Сначала агентские конференции. Чтобы туда попасть, нужно уметь складывать слова в предложения — здесь как раз помогает видео.
А дальше, если всё сложится, можно выходить на клиентские конференции. И самое важное — не платить полмашины за слот<\/strong>, а чтобы звали органически. По моему мнению, выступления со сцены — лучшая стратегия демонстрации экспертизы.<\/p>\n

Про контент от лица агентства<\/h3><\/p>\n

Контент агентства мы решили не сворачивать, но снизить на него фокус<\/strong>. Кейсы — король, они остаются.
А вот экспертные статьи — скорее всё. Каналов дистрибуции почти не осталось: vc кончился, Habr можно, но «такое себе». Поэтому блог компании решили сфокусировать на SEO и GEO-текстах<\/strong>.<\/p>\n

Посмотрим, как это всё сработает и что из этого получится.
План есть. Иллюзий нет. 2026 обещает быть интересным.<\/p>\n", "date_published": "2025-12-24T17:16:27+03:00", "date_modified": "2025-12-24T17:16:24+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/2026.png", "_date_published_rfc2822": "Wed, 24 Dec 2025 17:16:27 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "133", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/2026.png" ] } }, { "id": "132", "url": "https:\/\/www.alexeyit.ru\/all\/chto-takoe-llms-txt-zachem-nuzhen-fayl-llms-txt-i-pochemu-on-ne\/", "title": "Что такое LLMS.TXT: зачем нужен файл llms.txt и почему он не работает на практике", "content_html": "

LLM-боты пришли, а управление пока не завезли<\/h2><\/p>\n
\n\"\"\n<\/div>\n

Ранее я уже писал, что трафик от LLM растёт<\/strong> пока в основном в англоязычном сегменте, но и в зоне .ru они давно и активно индексируют сайты<\/strong>. И, что заметно, в некоторых нишах от туда есть исходящий трафик<\/strong>.<\/p>\n

Но есть и обратная сторона.
На ряде наших проектов мы столкнулись с крайне агрессивным поведением бота от Apple и других<\/strong>. По всем признакам это был их LLM или что-то очень близкое. Он настолько часто и плотно дёргал страницы<\/strong>, что нагрузка на сервер стала напоминать DDoS<\/strong>. В какой-то момент пришлось резать его по IP<\/strong>, иначе прод начинал просто ложиться.<\/p>\n

Банить IP разных ботов руками плохая идея, хоть и реализуемая через WAG. На этом фоне идея «как-то управлять ИИ-ботами»<\/strong> выглядит абсолютно логичной. Так и наткнулись на llms.txt<\/strong> файл, который подают как аналог robots<\/strong>.txt, но не для поисковиков, а для ботов<\/strong>, обучающих нейросети. Мол, можно аккуратно подсказать, какие страницы важные и что именно стоит читать.
Звучит красиво. На практике не работает.<\/strong><\/p>\n

Если упростить, llms.txt это markdown-файл со списком ссылок и краткими описаниями контента<\/strong>. По ощущениям, это что-то вроде sitemap.xml «для ИИ»<\/strong>, только с претензией на новый стандарт. Проблема в том, что:
— у нас уже есть sitemap.xml<\/strong>;
— есть robots.txt<\/strong>;
— и главное нейросети и так умеют читать HTML<\/strong>.<\/p>\n

Показателен комментарий Джона Мюллера из Google<\/strong>. По смыслу он сравнил llms.txt с meta-тегом keywords<\/strong>: формально вы можете что-то там написать, но реальные системы этим просто не пользуются<\/strong>. Если нужно понять, о чём сайт, проще и надёжнее прочитать сам сайт<\/strong>, а не верить декларациям владельца.<\/p>\n

Это подтверждается и практикой. В одном из обсуждений на Reddit ребята анализировали серверные логи порядка тысячи доменов<\/strong> и выяснили, что llms.txt почти никто не запрашивает<\/strong>. Его могут забирать какие-то нишевые аналитические боты, но крупные AI-платформы нет<\/strong>.
Ни OpenAI<\/strong>, ни Google<\/strong>, ни Anthropic<\/strong>, ни Яндекс<\/strong> публично не подтвердили поддержку этого стандарта<\/strong>.<\/p>\n

Откуда вообще взялась эта идея?
Изначально из желания дать нейросетям «чистый» контент без HTML-мусора<\/strong>. Но проблема в том, что LLM уже давно этот мусор переваривают без особых сложностей<\/strong>. Контекстные окна растут, понимание структуры документов улучшается. Через год-два нейросети будут читать сайты почти как люди<\/strong> и необходимость в отдельном markdown-файле исчезнет сама собой.<\/p>\n

При этом реальные задачи в AI-индексации лежат совсем в другой плоскости<\/strong>. Не текст<\/strong> с ним как раз всё более-менее хорошо. Настоящая боль визуальный контент<\/strong>: картинки без нормальных описаний, видео без расшифровок, отсутствие связи между текстом и визуалом. Именно здесь сейчас находится «слепое пятно» для большинства AI-систем<\/strong>, и именно туда логично было бы вкладывать усилия, если говорить о будущем AI-SEO.<\/p>\n

Что имеем на практике<\/h2><\/p>\n

Итого:<\/strong> на текущий момент более оптимального решения, чем WAF, мы не нашли<\/strong>. В существующих реализациях это почти единственный рабочий способ уберечь прод-сервер от наплыва AI-ботов<\/strong>: контроль частоты запросов, фильтрация паттернов и защита на уровне инфраструктуры, а не вера в декларативные файлы.<\/p>\n", "date_published": "2025-12-16T17:12:39+03:00", "date_modified": "2025-12-16T17:12:32+03:00", "tags": [ "Инструменты и сервисы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/mis.png", "_date_published_rfc2822": "Tue, 16 Dec 2025 17:12:39 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "132", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/mis.png" ] } }, { "id": "131", "url": "https:\/\/www.alexeyit.ru\/all\/kak-prodavat-uslugi-b2b-pochemu-rp-prodayot-luchshe-menedzhera-p\/", "title": "Как продавать услуги B2B: почему РП продаёт лучше менеджера по продажам", "content_html": "

Продай мне эту ручку<\/strong><\/h1><\/p>\n
\n\"\"\n<\/div>\n

B2B-продажи — штука небанальная. Длинные циклы, куча согласующих, спецусловия, договорняки, нюансы контрактования… В общем, процесс тот ещё аттракцион. Агенский бизнес — это всё тот же B2B, только местами с большей драмой. Продажи там долгие, сложные и редко идут по прямой.<\/p>\n

На раннем этапе всем этим обычно занимается основатель. Но как только что-то начинает получаться, в голове появляется прекрасная идея: нанять менеджера по продажам. А ещё лучше — сразу РОПа<\/strong>. Он же опытный, соберёт отдел, выстроит воронку, и вот тогда-то лиды польются рекой. Но нет.<\/p>\n

Эта мысль не новая — когда-то давно её вслух озвучивал Михаил Токовинин. Продажи — последнее, что получается нормально делегировать<\/strong>. Мы за десять лет перепробовали почти всё: звонки в полухолодную, рассылки, аутрич, контекст, таргет. Все инструменты рабочие, но у нас — по ряду причин — давали довольно скромный результат.<\/p>\n

Со временем стало очевидно: продаёт только экспертиза<\/strong>. В кастоме человек не покупает “услугу” — он покупает уверенность, что его задачу реально решат. И эту уверенность может дать только тот, кто сам делал подобные проекты.<\/p>\n

Есть ещё одно распространённое искажение: будто экспертизу можно «донести» кейсами и портфолио. И вроде бы да, кейсы помогают. Но клиент всегда задаёт один простой вопрос: “А кто всё это делал?”<\/strong> И вот тут начинается самое интересное — в компаниях всё меняется, команды обновляются, а вероятность того, что те самые герои кейса давно ушли, очень велика. Поэтому экспертиза, переданная через человека, работает в разы сильнее, чем любой PDF с красивыми скриншотами.<\/p>\n

Поэтому сегодня наш процесс устроен иначе. Первичную коммуникацию ведёт аккаунт: собирает бриф, боли, контекст. А дальше мы сразу зовём на созвон менеджера проектов. Желательно того, кто уже сталкивался с похожими кейсами. На встрече мы уточняем вопросы, сверяем ожидания, раскладываем риски. Клиент слышит эксперта, а не человека “между ним и экспертом”. Производство сразу понимает, на что идём. РП может подключить коллег, если нужно. Всё честно и прозрачно.<\/p>\n

У такого подхода, конечно, есть минусы. Команда отвлекается от производства, а часть КП уходит в пустоту — вложили часы, а результата нет. Иногда ломается скорость коммуникации: клиент звонит, а полноценный ответ он услышит уже на встрече. Но альтернативой было бы ещё хуже — обещания, которые потом не совпадают с реальностью.<\/p>\n

Вывод простой:<\/strong> сложные сервисы и кастом продаются только через экспертизу. И показать её можно только через людей, которые эту работу делают. Поэтому у нас лучшая связка — аккаунт + менеджер проектов<\/strong>. Мягко, честно, без иллюзий про волшебных продажников, которые “продадут даже ручку”. В B2B всё куда проще: продаёт тот, кто понимает, что делает.<\/p>\n", "date_published": "2025-12-10T11:36:57+03:00", "date_modified": "2025-12-10T11:36:53+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/Pen.png", "_date_published_rfc2822": "Wed, 10 Dec 2025 11:36:57 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "131", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/Pen.png" ] } }, { "id": "130", "url": "https:\/\/www.alexeyit.ru\/all\/fakap-s-naymom-rodstvennika-realnaya-istoriya-i-vyvody-dlya-ruko\/", "title": "Факап с наймом родственника: реальная история и выводы для руководителей", "content_html": "

Факап №N. Повесть о семейном подряде<\/strong><\/h1><\/p>\n
\n\"\"\n<\/div>\n

Эта история старая и почти вымышленная, но мораль в ней предельно настоящая. Мы тогда были молоды и горячие — не как в самом начале пути, но всё ещё с ветерком в голове.<\/p>\n

Мы взяли в команду юного специалиста — назовём его Владимир<\/strong>. Опыт небольшой, но глаза горят, учится быстро, в коллектив вписался. Год он рос буквально на глазах<\/strong>, и всё вокруг было ровно и спокойно.<\/p>\n

И вот однажды Владимиру<\/strong> приходит идея: у него есть родственник, который тоже хочет войти в IT. А тогда входить в IT<\/strong> было примерно как ходить в тренажёрку после Нового года — модно, но не у всех получалось. Мы поговорили, обсудили риски, прямо сказали, что это инвестиция компании<\/strong>, и что быстрых результатов ждать не нужно. И что есть сценарий, когда стажёр может не закрепиться и ему придется покинуть компанию и обоих терять в этом случае не хочется. Все согласились и приняли правила игры.<\/strong><\/p>\n

Провели условный “тех-собес”, пожали руки — и взяли нового человека.<\/p>\n

Он вливался в работу медленно, но старательно. Прошло полгода, может чуть больше. И в какой-то момент компании стало непросто — нужно было сокращать косты и производственные мощности<\/strong>. А производство, как правило, начинают сокращать со стажёров.<\/p>\n

Сработал я не идеально: резковато, быстрее, чем стоило бы, без предупредительного в воздух. Ошибку свою признаю.<\/strong> Но стажёрам заранее говорилось, что такая ситуация возможна. Решение принято, действия сделаны.<\/p>\n

И вот тут началось самое интересное.
Внезапно я стал «самодурами» и «недальновидными». Владимир, который сам когда-то получил шанс войти в IT<\/strong>, решил уйти вслед за своим родственником. В итоге мы потеряли стажёра — и потеряли уже крепкого специалиста.<\/strong><\/p>\n

Меня эта история тогда задела. Всё ведь было проговорено заранее, все стороны согласились. Но стоило этим правилам вступить в силу, как играть по ним никто больше не захотел.<\/strong>
Ну что ж, бывает. Это тоже часть опыта.<\/p>\n

Что я понял после<\/h2><\/p>\n

Нанимать родственников сотрудников можно<\/strong>, но только понимая, какие риски это создаёт — человеческие, эмоциональные, организационные. Пока всё хорошо, никто этого не замечает. Но когда компании становится сложно, семейные связи начинают влиять на решения гораздо сильнее, чем кажется.<\/strong><\/p>\n

Сегодня такие ситуации воспринимаются проще, рынок другой. Но пару лет назад подобный факап мог стоить нам куда дороже — и в деньгах, и в людях, и в атмосфере команды.<\/p>\n

Давать шанс людям с горящими глазами — стоит.<\/strong> Это часть ДНК, без которой компания превращается в холодную машину. Но после этой истории у нас появились ученические контракты<\/strong> — не для формальности, а чтобы все лучше понимали правила и возможные сценарии, если что-то идёт не так.<\/p>\n", "date_published": "2025-12-05T08:58:03+03:00", "date_modified": "2025-12-05T08:57:56+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/vin.jpg", "_date_published_rfc2822": "Fri, 05 Dec 2025 08:58:03 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "130", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/vin.jpg" ] } }, { "id": "129", "url": "https:\/\/www.alexeyit.ru\/all\/ux-ui-i-ab-testirovanie-pochemu-redizayn-s-garantiey-rosta-konve\/", "title": "UX\/UI и AB-тестирование: почему редизайн с гарантией роста конверсии не работает", "content_html": "

Не так давно общались с одним e-com. У ребят всё в целом нормально, но пришли они с задачей поднять конверсию с условных пяти до семи процентов за счёт редизайна<\/strong>. <\/p>\n

\n\"\"\n<\/div>\n

Посмотрели метрики, текущий UX и все хотелки и быстро поняли: подписываться под такие вещи — это форма самообмана<\/strong>. Никто не может честно гарантировать, что набор изменений в интерфейсе точно даст рост в два процента. Можно верить, надеяться, но это не про управление продуктом.<\/p>\n

Мы предложили идти через мелкие изменения и замеры конкретных метрик<\/strong>. Зацепили гипотезами, показали, что так безопаснее и прозрачнее. Но понимания не нашли. Клиент хотел увидеть в ТЗ формулировку «вырастить конверсию в N раз» и переложить риски на исполнителя<\/strong>. Как цель это звучит красиво, но чтобы под такое подписаться, нужно быть либо слишком самоуверенным, либо рассчитывать на удачу. Мы туда не пошли.<\/p>\n

Отдельная история — как вообще замерять результат. Инструментов море, но важнее другое: понимать, что именно мы ожидаем увидеть<\/strong>. Если, к примеру, дорабатываем карточку товара и добавляем бесконечный скролл с похожими товарами, то конечную конверсию можно смотреть, но толку от этого мало. Она слишком инертная и размазанная. Гораздо честнее заметить рост по количеству добавлений в корзину и глубине просмотра<\/strong> — это и есть прямой эффект улучшения. Но это уже продуктовая логика, а не магия «конверсия выросла — молодцы».<\/p>\n

С технической стороны тоже всё не так романтично. В Битриксе есть встроенные AB-тесты, которые автоматически делят трафик. Работает, но выглядит архаично. Есть Яндекс Метрика и её же Varioqub в базовом виде. Можно развернуть Varioqub on-prem и крутить тесты в больших объёмах. Все эти решения рабочие, но вопрос никогда не в инструменте. Вопрос в том, что мы пытаемся померить и зачем.<\/strong><\/p>\n

И здесь встаёт немой вопрос. Готовы ли вы подписаться под разработку UX\/UI с гарантированным результатом?<\/strong> Для меня это почти как обещание построить дом, который понравится всем соседям, будет вечным, красивым и вообще идеальным при любых вкусах. Так не работает.<\/p>\n

Ну и последняя мысль, которая обязательно всплыла в процессе. Такие работы точно нельзя продавать по модели time & material<\/strong>. Если вам перекладывают риск на достижение результата, то TM размывается, превращается в лотерею и работает против исполнителя. Если уж подписываться под такую историю, выигрыш должен быть действительно значительным, иначе проще сразу сказать «нет».<\/p>\n", "date_published": "2025-12-01T17:52:09+03:00", "date_modified": "2025-12-01T18:16:08+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/gadal.png", "_date_published_rfc2822": "Mon, 01 Dec 2025 17:52:09 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "129", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/gadal.png" ] } }, { "id": "128", "url": "https:\/\/www.alexeyit.ru\/all\/pokupki-v-chatgpt-pochemu-novy-ubiyca-e-commerce-ne-vzletit\/", "title": "Покупки в ChatGPT: почему новый «убийца e-commerce» не взлетит", "content_html": "

Очередной убийца традиционного e-commerce<\/strong><\/h2><\/p>\n
\n\"\"\n<\/div>\n

Сегодня прочитал новость, что в ChatGPT собираются встраивать прямые покупки (сама новость была 29 сентября). Примерно так: пишешь ему «найди красную рубашку», и если есть подходящий магазин с товарами тебя тут же ведут к оформлению заказа и списанию денег. <\/p>\n

Первая мысль была проста: выглядит сомнительно. Магазин в чате?<\/strong><\/p>\n

Есть стойкое ощущение, что IT-рынок каждый год пытается продать идею «покупки там, где покупать неудобно». Telegram Apps еще, уже пробовали. Яндекс экспериментировал с покупками прямо в поиске тоже не взлетело. Наверное было еще очень больше количество эксперементов и на других платформах. <\/p>\n

Теперь очередь ChatGPT?<\/strong> Но чат это не каталог. Нет плитка. Нет списков, фильтров, избранного и все что удобно. Человечество двадцать лет шлифовало UX интернет-магазинов, чтобы стало как-то удобно<\/em>. А тут попытка заменить интерфейс диалогом. <\/p>\n

В России в ближайшее время мы все равно это не получим. OpenAI работает через Stripe, Shopify, Etsy и прочий западный стек.<\/p>\n

Но даже глобально я не вижу здесь преимущества. Покупка в чате не быстрее, не понятнее и ничем не лучше привычного интерфейса. А если тебе покажут “рекомендованную рубашку”, на каком основании? <\/p>\n

Технически реализовать покупку вообще не проблема. Гораздо сложнее другое: как туда загрузить товары так, чтобы алгоритм показал именно твою красную рубашку?<\/strong><\/p>\n

Каталоги это вечная борьба за место в выдаче. Маркетплейсы годами строили сложные алгоритмы ранжирования, а теперь все это хотят положить в голову модели. <\/p>\n

По сути OpenAI делает новый поисковик с кнопкой «купить», что логично при наличии аудитории. Но уже была статистка: даже когда ChatGPT даёт ссылку, почти никто не переходит наружу<\/strong>. Даже если функция покупки была доступна сейчас в РФ, стоит крепко подумать стоит ли отдавать трафик ради заказов из чата.<\/p>\n

OpenAI логично пытается удержать человека внутри своей экосистемы и в этом смысле покупки прямо в чате идеально вписываются в стратегию.<\/p>\n

Новый убийца традиционного e-commerce? Скорее ещё один эксперимент, который выглядит красиво в презентации, но в реальном поведении пользователей мало что меняет. По крайней мере, пока.<\/p>\n", "date_published": "2025-11-25T17:29:18+03:00", "date_modified": "2025-11-25T17:29:16+03:00", "tags": [ "E-commerce и маркетплейсы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/2025-11-25_16-55-57.png.jpg", "_date_published_rfc2822": "Tue, 25 Nov 2025 17:29:18 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "128", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/2025-11-25_16-55-57.png.jpg" ] } }, { "id": "127", "url": "https:\/\/www.alexeyit.ru\/all\/pochemu-klassicheskiy-reprayser-dlya-ozon-i-wildberries-uzhe-ne\/", "title": "Почему классический репрайсер для Ozon и Wildberries уже не работает — и что мы строим вместо него", "content_html": "

SaaS был ошибкой? Возможно. Часть 4<\/strong><\/h1><\/p>\n
\n\"\"\n<\/div>\n

Продолжаю делиться нашим приключением в продуктовой вселенной.
Прошлые главы — раз<\/a>, два <\/a>и три <\/a>— задавали контекст. С тех пор прошёл месяц, и изменений накопилось больше, чем я ожидал.<\/p>\n

Месяц кастдевов<\/strong><\/h3><\/p>\n

За это время провёл около двадцати интервью с бизнесом и людьми, которые так или иначе связаны с маркетплейсами: от продуктовых специалистов до руководителей направлений МП. Хотел понять простую вещь — кто и как управляет ценами, где автоматизация действительно работает, а где все по-старинке.<\/p>\n

И выводы получились неоднозначные. В SaaS-сегменте проблема, ради которой всё затевали, почти отсутствует, вроде. Возможно, идти туда — ошибка. Но мы всё равно проверим — иногда истинная боль прячется глубже.<\/p>\n

А вот в enterprise-историях проблема подтверждается. Каждый решает её по-своему, костылями и полуавтоматом. У селлеров с небольшим ассортиментом всё проще — там хватает существующих сервисов. Я насчитал больше двадцати живых решений, и у каждого свои особенности: ограничение на количество товаров, странные тарифы и отсутствие нормальных интеграций. Всё руками, о связке с 1С или динамическими ценами часто даже не мечтают.<\/p>\n

Сменить позиционирование<\/strong><\/h3><\/p>\n

На фоне всех этих находок стало понятно, что классическое слово «репрайсер» давно умерло. Актуальность была пару лет назад, сегодня это звучит как термин из музейной витрины. Поэтому решили честно обновить концепцию. Теперь это омниканальная платформа мониторинга, анализа и управления ценами<\/strong>.<\/p>\n

Так получается точнее и честнее отражать то, что мы реально делаем — и то, чего нет у конкурентов.<\/p>\n

Что сделали по разработке<\/strong><\/h3><\/p>\n

Перезапустили сайт решения. Хотелось собрать всё на Тильде, но пошли другим путём — сделали максимально примитивно, чтобы проверить конверсию самого подхода. Личного кабинета пока нет, но рассчитываем довести его до ума за ближайшие одну–три недели.<\/p>\n

Параллельно запустили новые стратегии. Пришлось собрать новую схему работы с ценой: учитывать маржу, доставку, бонусы, акции — всё, что влияет на финальный результат.<\/p>\n

Личный кабинет стал чуть красивее обычного орчида, но ещё не тот результат, от которого отваливается челюсть, но в целом окей. Зато сделали авторизацию через email и OTP — СМС подключим позже.<\/p>\n

Интересные находоки<\/strong><\/h3><\/p>\n

Нашли хак на Ozon. Если товар стоит в акции, менять цену нельзя — она пишется, но берётся медианная. Однако если сначала вынуть товар из акции, обновить цену и вернуть обратно — всё работает. Абсолютно легально, пока.<\/p>\n

Построили внутреннюю систему ротации прокси, чтобы они не выгорали пачками. Она следит за состоянием, и если какой-то прокси сгорает, летит алерт, что нужно пополнить запас.<\/p>\n

Добавили альтернативный источник данных — из личного кабинета маркетплейсов. Точность ниже, но скорость выше. Правда, не для всех товаров.<\/p>\n

По мелочам — навели порядок в настройках, закрыли баги, подтянули инфраструктурные детали.<\/p>\n

Что дальше<\/strong><\/h3><\/p>\n

В ближайшее время запускаем рекламу. Начнём с Директа — понятно, что это не самый эффективный канал для нашего типа продукта, но нам нужно проверить прямой спрос, экономику клика и набрать людей на первичный кастдев. Вероятнее всего, этот канал приведёт селлеров с небольшим оборотом — и возможно, у них просто нет проблемы. Это тоже нужно подтвердить или опровергнуть.<\/p>\n

Параллельно будем выходить в аутрич через Telegram, чтобы дотянуться до среднего и крупного сегмента. Тут уже интереснее — посмотрим, что получится.<\/p>\n

В разговоры с экспертами добавился новый блок — прикидка трендов. Что будет дальше?<\/p>\n

API может стать платным. Больно, но не смертельно. Цена персонализируется до безумия — непонятно, что будет с РРЦ и МРЦ. Запрет на изменение цен по API? Сомнительно, но и на это у нас есть запасной вариант.<\/p>\n

Далее по плану. <\/p>\n

Запускаем SaaS.
Доделываем стратегии.
Включаем рекламу и аутрич.
А дальше — посмотрим, что покажут цифры и люди.<\/p>\n", "date_published": "2025-11-19T14:39:32+03:00", "date_modified": "2025-11-19T15:02:23+03:00", "tags": [ "E-commerce и маркетплейсы", "Инструменты и сервисы", "Личный опыт и размышления", "Репрайсер", "Технологии и разработка", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/price2.png", "_date_published_rfc2822": "Wed, 19 Nov 2025 14:39:32 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "127", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/price2.png" ] } }, { "id": "126", "url": "https:\/\/www.alexeyit.ru\/all\/buduschee-it-v-2026-chto-zhdyot-rynok-truda-i-kak-na-nego-vliyae\/", "title": "Будущее IT в 2026: что ждёт рынок труда и как на него влияет AI", "content_html": "

Про маятник рынка IT и AI<\/strong><\/h2><\/p>\n
\n\"\"\n<\/div>\n

Наблюдая в последнее время отраслевые чаты с резюме, отклики на HH и общую динамику найма, можно констатировать: рынок труда в IT ощутимо изменился<\/strong>. Маятник, который последние 4 — 5 лет был на стороне кандидата, уверенно качнулся в сторону компаний. Это видно и по количеству сильных специалистов, которые открыто ищут работу, и по тому, как сокращаются бюджеты на ИТ-инициативы у крупняков — ставка передаёт привет инвестиционным проектам. В результате простое уравнение: вакансий меньше, конкуренции больше<\/strong>. Вроде такая ситуация только в около IT сфере. <\/p>\n

Важно понимать — это временная история. Рынок либо сбалансируется, либо маятник снова уйдёт в сторону кандидата. Горизонт в 1–2 года пока туманен, но подобные перекосы никогда не бывают вечными<\/strong>.<\/p>\n

При этом джунам и мидлам сейчас действительно тяжело<\/strong>. ИИ поджимает, конкуренция выросла, а до HR порой просто не пробиться. Да ещё и сами компании принимают решения о найме куда медленнее. Сильные ребята этого почти не замечают, наверное — дефицит на суперменов никуда не делся, но общий фон стал ощутимо менее комфортным.<\/p>\n

Для компаний же, наоборот, сейчас, пожалуй, самое удобное время за последние годы нанимать “звёзд”<\/strong>. Те, кто год назад даже не повернули бы голову в вашу сторону, сегодня вполне готовы рассматривать предложения. А вот удержать их, когда маятник качнется назад<\/strong>, — вопрос, который остается открытым.<\/p>\n

Параллельно развивается и противоположный тренд. В Reddit, Medium и нескольких других источниках всё чаще всплывают истории о том, что масштабные ставки на AI-автоматизацию не оправдали ожиданий<\/strong>. Там, где компании сокращали людей под лозунгом «теперь всё сделает нейросеть», результаты оказались слабее, чем ожидали. Обычный человеческий интеллект и прямые руки во многих процессах справлялись лучше<\/strong>. И теперь часть тех специалистов, кого спешно оптимизировали, приходится возвращать обратно.<\/p>\n

Понятно, что огромную долю позиций уже никто не вернёт — если автоматизация работает, она и будет работать. Но сам факт интересный: не всё, что громко называли “вот-вот заменит людей”, реально заменило<\/strong>.<\/p>\n

На мой взгляд, эти два наблюдения вполне могут оказаться связанными. Рынок шатнуло сразу в разных направлениях:
— кандидатов стало больше,
— но ценность людей снова стала очевиднее<\/strong>,
— AI показал, возможно, потолок эффективности,
— а компании — на пределе оптимизации, хотя 2026 наверное сдвинет пределы.<\/p>\n

Выводов как таковых не будет. Если говорить про отдельно взятого специалиста, то, пожалуй, единственная спокойная бухта — становиться сильнее<\/strong> в своей отрасли. Прокачиваться до уровня Senior и выше, учиться решать бизнес-задачи, а не просто писать код. В мире, где AI проникает во все сферы, это, кажется, единственная более-менее стабильная стратегия<\/strong>.<\/p>\n




<\/p>\n", "date_published": "2025-11-14T10:59:24+03:00", "date_modified": "2025-11-14T10:59:20+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/Otvlechyonny_paren.jpeg", "_date_published_rfc2822": "Fri, 14 Nov 2025 10:59:24 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "126", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/Otvlechyonny_paren.jpeg" ] } }, { "id": "125", "url": "https:\/\/www.alexeyit.ru\/all\/butik-ili-zavod-kak-masshtabirovat-it-agentstvo-i-pochemu-butiko\/", "title": "Бутик или завод: как масштабировать IT-агентство и почему бутиковая модель перестаёт работать", "content_html": "

Бутик или завод<\/strong><\/h3><\/p>\n
\n\"\"\n<\/div>\n

Недавно в Екатеринбурге прошла конференция — такая отраслевая агентская тусовочка. Сам не был, но слушал эфир фоном на YouTube. И там за круглым столом прозвучал любопытный вопрос: если коротко, то что лучше — быть бутиком с суперэкспертизой и брать дорого<\/strong> или стать большим, но делать «бутиковые» вещи<\/strong> — не конвейер, но всё же завод.<\/p>\n

Ответ, как обычно, не чёрно-белый. В мире гораздо больше оттенков. Но если говорить про меня — сейчас мне ближе не бутиковая история<\/strong>. Потому что некоторые вещи просто работают только на масштабе<\/strong>.<\/p>\n

Масштаб как инструмент<\/strong><\/h3><\/p>\n

Генри Форд не даст соврать: когда у тебя поток задач, ты можешь оптимизироваться, улучшать процессы, шлифовать систему<\/strong>. В сервисном бизнесе, где всё «под заказ» — интеграции, согласования, кастом — кажется, что конвейер не применим. Но это не совсем так. Он просто выглядит иначе.<\/p>\n

Представим, что у нас бутик: десять человек, делаем сложные B2B-проекты, например, для агросектора. Нужен аналитик? Конечно. Но не постоянно — только когда он действительно нужен. А аналитики ведь бывают разные: бизнес, системные, технические, продуктовые. В маленькой команде это, скорее всего, будет универсальный боец — и швец, и жнец<\/strong>.<\/p>\n

То же самое с DevOps-ом, системным администратором, бухгалтером, менеджером, HR-ом и многими другими экспертизами. Чтобы каждая роль приносила пользу, нужен определённый объём задач<\/strong>. На масштабе такие роли выстраиваются в систему — и это уже не лишние люди в штате, а часть работающего механизма<\/strong>.<\/p>\n

Можно, конечно, сказать: «Мы будем платить человеку в простое, а потом отбивать, когда он в деле». Но, если честно, в реалиях 2025 года это почти утопия.<\/p>\n

Аутсорс ≠ команда<\/strong><\/h3><\/p>\n

Да, можно выносить часть функций на аутсорс или парт-тайм, но часто это не то. Это уже не core-команда<\/strong>, не часть ДНК компании. Это как двигатель и коробку передач держать “на подряде”<\/strong> — вроде работает, но ощущение надёжности и контроля теряется.<\/p>\n

Наверное, поэтому мне ближе история про масштаб<\/strong>. Не ради цифр или количества людей в штате, а ради устойчивости и воспроизводимости<\/strong>. Когда процессы не рушатся, если кто-то заболел, и когда каждая роль в команде — не роскошь, а необходимость.<\/p>\n

Бутик — это красиво. Завод — это надёжно. <\/strong>А в идеале — быть умным заводом<\/strong>, который делает бутиковые вещи<\/strong>, но системно.<\/p>\n", "date_published": "2025-11-11T09:52:27+03:00", "date_modified": "2025-11-11T09:52:17+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/butik.png", "_date_published_rfc2822": "Tue, 11 Nov 2025 09:52:27 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "125", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/butik.png" ] } }, { "id": "123", "url": "https:\/\/www.alexeyit.ru\/all\/korporativnye-it-terminy-i-anglicizmy-yazyk-zakazchika-v-b2b\/", "title": "Корпоративные IT-термины и англицизмы: язык заказчика в B2B", "content_html": "

Ихние диалекты<\/strong><\/p>\n

Как у вас с английским? Уже выучили или какой-то другой начали учить?
<\/p>\n

\n\"\"\n<\/div>\n

У меня тоже не очень. На созвонах с англоговорящими людьми — а они, как ни странно, всё ещё иногда случаются в текущих обстоятельствах — я как очень умное животное: всё понимаю, а ответить ничего не могу. Сижу, смотрю и киваю. Наверное, это нарабатывается практикой. Но сегодня не об этом.<\/p>\n

Диалекты профессий<\/strong><\/h3><\/p>\n

Многие профессиональные сферы — стройка, финтех, медицина, и IT не исключение — со временем обрастают сленгом, англицизмами и прочими артефактами.<\/p>\n

Вот только верхушка айсберга: CAPEX, OPEX, MVP, MLP, скоринг, комплаенс, чекаут, PIN, юнит-тесты, легаси, BRD, PROD, витрина, домен, CI\/CD, релиз.<\/p>\n

Половину из этого можно спутать с названиями таблеток.<\/p>\n

Но тут дело не в понтах. Просто внутри каждой профессии появляется свой язык — короткий, удобный, понятный тем, кто “в теме”. И если ты в этой среде, ты начинаешь говорить так же. Не потому что хочешь казаться умнее, а потому что это быстрее и точнее.<\/p>\n

Почему без «своего» языка не договориться<\/strong><\/h3><\/p>\n

B2B-бизнес — это про людей. Чтобы договориться, нужно уметь общаться. А чтобы общение было продуктивным — нужно говорить на одном языке. Мысль не новая, даже старая: «Говорите с заказчиком на его языке». <\/strong>Но по факту это единственный способ, чтобы вас поняли.<\/p>\n

Если мы говорим про микробизнес — там всё просто и по делу: “надо, чтобы работало”. В малом и среднем бизнесе — уже веселее, но всё ещё понятно. А вот у крупных компаний начинается корпоративный диалект.<\/p>\n

У CTO — свой. У продукта и проджекта — свой. У владельца домена — свой. У e-com-директора — тоже свой. А заказчик, как правило, не один. И нередко они между собой говорят на разных языках — а роль переводчика достается тебе.<\/p>\n

И это не плохо. Кто-то скажет, что корпоративный язык вырождает речь. А по мне — наоборот: он заставляет язык жить. Он отражает реальность, как она есть: чем сложнее процессы, тем богаче язык.<\/p>\n

Лучше переспросить, чем не понять<\/strong><\/h3><\/p>\n

Если чувствуете, что не дотягиваете по “языку” — лучше подготовьтесь. А если не получилось — переспросите, если не понял. Лучше показаться глухим, чем потом неправильно всё сделать.<\/p>\n

Со временем вы начинаете ловить ритм, подмечать термины и внутренние шутки. И вот уже сами спокойно говорите: “закроем спринт, выкатим на прод, метрики глянем на ретро”.<\/p>\n

Так что изучайте корпоративные диалекты — особенно если работаете в IT или B2B. Вероятно, вам понадобятся разные диалекты — не только IT, но и отраслевые: e-commerce, финтех, стройка и так далее.

<\/p>\n

Говорите на «ихнем» — и жизнь станет сильно проще.
А какие диалекты знаете вы?<\/p>\n



<\/p>\n", "date_published": "2025-11-01T16:32:03+03:00", "date_modified": "2025-11-01T16:37:21+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/ostrov.png", "_date_published_rfc2822": "Sat, 01 Nov 2025 16:32:03 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "123", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/ostrov.png" ] } }, { "id": "122", "url": "https:\/\/www.alexeyit.ru\/all\/sdelay-chtoby-bylo-horosho-pochemu-plohie-zadachi-ubivayut-rezul\/", "title": "Сделай, чтобы было хорошо — почему плохие задачи убивают результат", "content_html": "

Давече общался с бывшим коллегой-программистом. Сейчас он работает в продукте — строит там всякое сложное. <\/p>\n

\n\"\"\n<\/div>\n

Ну, как сложное... когда-то нам это казалось чем-то невероятным, а сейчас смотришь — да нормально. В общем, занимается любимым делом, и я за него искренне рад.<\/p>\n

Разговор зашёл о постановке задач. У них всё по учебнику — проджект, продукт, тимлид. Но прилетают задачи с описанием уровня “сделай что-то там, чтобы было хорошо”. И минимум конкретики.<\/p>\n

Дальше — классика жанра. Начинаются словесные баталии, уточнения, гипотезы, и только после нескольких раундов удаётся вытащить из тумана хоть какую-то конкретику.<\/p>\n

Мы с ним посидели, подумали, почему так происходит. Первый вариант — это форма обучения<\/strong>. Типа “пойди разберись, поизучай тему, потом расскажешь”. В целом логично, но если это обучение, то, наверное, стоит так и сказать.<\/p>\n

Второй вариант — перекладывание ответственности<\/strong>. Лид от бизнеса получил задачу в стиле “надо сделать хорошо”, передал дальше — “ну ты там сам разберись”. Если всё сработает — класс, время сэкономили, нервы целы. Если нет — всегда найдётся виноватый: программист не уточнил, тимлид недоспросил, продакт не понял бизнес. И цепочка пошла выше.<\/p>\n

В целом мотив понятен — никто не хочет брать ответственность за то, что изначально непонятно. Особенно если сверху прилетает неясная формулировка, и ты просто ретранслируешь её вниз по цепочке.<\/p>\n

Но таких задач меньше не станет. Нейросети вроде как могут помочь — уточнят, переспросят, допишут ТЗ. Но если смысл размыт в начале, то на выходе будет просто больше текста и та же размытость.<\/p>\n

И вот тут приходится принимать неприятный факт — иногда нужно брать ответственность за то, на что ты не можешь сильно повлиять. Да, риск есть, и да, бывает, что не оправдан. Но если уж столкнулся с такой задачей — лучше потратить время, разобраться, задать вопросы (пусть даже через GPT), чем потом переделывать.<\/p>\n

В конце концов, качество постановки задачи — это форма уважения<\/strong>. И работает это в обе стороны — и когда ты ставишь, и когда тебе ставят. Потому что, как ни крути, все мы работаем с людьми. И хочется верить, что инвестиции, которые ты вкладываешь в проработку задачи, однажды окупятся.<\/p>\n

 <\/p>\n", "date_published": "2025-10-29T10:38:01+03:00", "date_modified": "2025-10-29T10:37:58+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/pers.png", "_date_published_rfc2822": "Wed, 29 Oct 2025 10:38:01 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "122", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/pers.png" ] } }, { "id": "120", "url": "https:\/\/www.alexeyit.ru\/all\/kak-ya-prevratil-krutogo-razrabotchika-v-rukovoditelya-i-poterya\/", "title": "Как я превратил крутого разработчика в руководителя и потерял обоих — история управленческого факапа", "content_html": "

2016–2018: когда нас было девять<\/h2><\/p>\n
\n\"\"\n<\/div>\n

Те годы помню до деталей: нас девять человек, горячие, голодные, без лишней бюрократии. И вот к нам приходит парень — назовём его Антон. В резюме — «веб-разработчик» без узкой специализации. Сказал честно: «Умею немного, но быстро учусь». Конкурентов в офлайне тогда не было вовсе. Взяли.<\/p>\n

Антон рос как на дрожжах. Подхватывал горящие задачи, часто выручал. Мы подтягивали вознаграждение, прокачивали стек, перестраивали процессы. Постепенно стало ясно: доступные у нас задачи и вилка дохода перестали его держать. Он перерос рамки роли и по ожиданиям, и по уровню.<\/p>\n

Поворот не туда: «давай в тимлиды»<\/h2><\/p>\n

Мы начали думать, чем его загрузить, чтобы и человеку интересно, и компании польза. Тогда ещё не было чётких контуров по ролям, «лидство» существовало больше по факту, чем по документам. Мы нарисовали мотивацию, собрали пул задач. Получилось скорее про организацию команды, чем про архитектуру и сложный код — то есть ближе к team lead, а не к tech lead.<\/p>\n

Антон согласился. Формально всё обсудили: цели, задачи, ответственность. На практике — человек просто хотел писать код. Мы этого не услышали. Полгода, примерно год — и однажды вечером он говорит: «Мне пора. Хочу писать код, который штурмует космос, работать над сложными задачами в сильной продуктовой команде».<\/p>\n

Было больно. В Антоне концентрировалось много технологий и контекстов. По деньгам перебить оффер не могли: почти х3 к нашему потолку. Разошлись цивилизованно, договорились о передаче дел. Связь не потеряли — до сих пор общаемся, обмениваемся опытом.<\/p>\n

Ирония судьбы<\/h2><\/p>\n

Самое интересное началось позже. Антон ушёл «от управления людьми» к «божественному коду» — и через год в новой компании его снова подключили к руководству командой. Классическая траектория сильного спеца: чем лучше кодер, тем выше шанс, что его начнут тянуть в менеджмент, нравится ему это или нет. Он уже смеётся: прошёл дорогие курсы по управлению и лидерству, разбирается в людях не хуже, чем в бэкенде.<\/p>\n

Что было не так на нашей стороне<\/h2><\/p>\n

Мы не объяснили человеку логику роли и не проверили, зачем<\/em> она ему. Слушали рынок, KPI и наши потребности, но недостаточно слушали Антона. Ему нужен был фокус на сложном коде, архитектуре, R&D. Мы предложили организационную повестку и «немного кода». В итоге потеряли звёздочку — и это целиком наш косяк.<\/p>\n

Справедливости ради, команда от той истории стала сильнее. Мы формализовали роли, разделили Team Lead и Tech Lead, перестроили грейды и мотивацию. А Антон стал ещё круче как специалист и теперь осознанно совмещает техническую глубину с лидерством.<\/p>\n

Что бы я сделал сейчас<\/h2><\/p>\n

Во-первых, честный карьеркарт: две развилки — Tech Lead<\/strong> (глубина, архитектура, сложные задачи, минимум митингов) и Team Lead<\/strong> (люди, процессы, цели, много коммуникаций). Показал бы риски и рутину каждой траектории, а не только плюсы.<\/p>\n

Во-вторых, прототип роли на 1–2 месяца. Не «назначили и поплыли», а проверили интерес и пригодность в коротком цикле с обратной связью.<\/p>\n

В-третьих, личные мотивы важнее оргструктуры. Если человек горит кодом — дай ему «космос»: тяжёлые проекты, ответственность за архитектуру, время на исследования. Не пытайся «починить» мотивацию окладом и приставкой «лид» в должности.<\/p>\n

Итог<\/h2><\/p>\n

Не повторяйте наших ошибок — внимательно слушайте людей. Карьерная траектория — не таблица в конfluence, а конкретные желания конкретного человека в конкретный момент. Мы тогда этого не услышали и заплатили потерей сильного специалиста. Зато сделали выводы, отстроили роли и научились предлагать путь, который действительно совпадает с мотивацией.<\/p>\n

Эта история чем-то рифмуется с другой — про Фёдора. Если не читали, загляните: https:\/\/t.me\/alexeyitru\/153<\/a><\/a><\/p>\n", "date_published": "2025-10-20T15:35:35+03:00", "date_modified": "2025-10-20T15:43:14+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/star-1.png", "_date_published_rfc2822": "Mon, 20 Oct 2025 15:35:35 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "120", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/star-1.png" ] } }, { "id": "118", "url": "https:\/\/www.alexeyit.ru\/all\/guardprice-reprayser-dlya-ozon-wildberries-yandeks-marketa-lamod\/", "title": "GuardPrice — репрайсер для Ozon, Wildberries, Яндекс.Маркета, Lamoda, М.Видео-Эльдорадо и Аптека.ру", "content_html": "

Недавно пробежала новость: WB снова урезал часть данных<\/strong>, и у половины аналитических систем парсеры просто легли. Наш — работает как часы.<\/p>\n

\n\"\"\n<\/div>\n

А буквально вечером появилась ещё одна — Ozon снова повышает тарифы<\/strong>. Кажется, не в последний раз. Так что продукт, цель которого — сэкономить продавцам и увеличить их долю прибыли на маркетплейсах<\/strong>, пока выглядит чертовски своевременным.<\/p>\n

Путь по граблям<\/strong><\/h3><\/p>\n

Правильный продуктовый путь по гайдам нам по-прежнему не ведом. Мы идём своим маршрутом, через ошибки и эксперименты. И раз уж на сайте пока нет журнала изменений, буду вести его здесь — в блоге.<\/p>\n

С момента прошлого апдейта у нас многое поменялось. Напомню, речь идёт о GuardPrice<\/strong> — сервисе, цель которого управлять ценами на маркетплейсах по разным стратегиям<\/strong>, ориентируясь на собственные цены продавца и реальные цены, которые видит конечный покупатель.<\/p>\n

От коробки к полноценному SaaS<\/strong><\/h3><\/p>\n

Коробочная Enterprise-версия<\/strong> обросла популярными стратегиями вроде «следования за конкурентом», «удержания позиции» и так далее. Но главное — мы окончательно ударились головой и решили делать полноценный SaaS-сервис<\/strong>.<\/p>\n

С подписками, тарифами, личным кабинетом — как и положено. Первый релиз уже совсем близко, и, конечно, не без приключений.<\/p>\n

Поддержка площадок<\/strong><\/h3><\/p>\n

Так как GuardPrice изначально гибкий<\/strong> и умеет работать с любым API для обратной загрузки цен, мы решили не ограничиваться только Ozon и Wildberries. В список подключений входят Яндекс.Маркет, Ламода, М.Видео-Эльдорадо, Аптека.ру<\/strong>, и фактически можно прикрутить любой другой e-commerce<\/strong>, где есть API.<\/p>\n

Есть и отдельный профиль — «стратегия парсинга». Он просто собирает цены без обратной выгрузки. Зачем? Всё просто: можно указать любую ссылку на товар, задать, где находится блок с ценой, и сервис сам соберёт данные. Очень удобно, когда нужно быстро оценить рынок или конкурентов<\/strong>.<\/p>\n

Балансировка и прокси<\/strong><\/h3><\/p>\n

Самая интересная часть — получение реальных цен, которые видит покупатель<\/strong>.
Маркетплейсы всеми силами пытаются это закрыть: антибот-механизмы, проверка user-агентов, капчи,  блокировки IP — полный набор.<\/p>\n

В начале мы сжигали прокси буквально за сутки: вчера работают, сегодня уже бан.
Перепробовали десятки пулов и форматов, пока не поняли, что дело не только в самих прокси, но и в нагрузке по времени, частоте запросов и очередности IP<\/strong>.<\/p>\n

Теперь у нас построена полноценная балансировка нагрузки<\/strong>,  где каждый поток живёт по расписанию. Мы ротируем прокси по группам<\/strong>, проверяем «живость» перед каждым заходом и автоматически выкидываем подозрительные адреса из пула. Так что теперь не выжигаем IP, не теряем данные и не вылетаем в баны<\/strong>.<\/p>\n

Кстати, неожиданное открытие — бан может быть временным<\/strong>. Некоторые прокси действительно «оживают» через сутки-двое. Теперь это тоже учитываем при ротации.<\/p>\n

Дальше — красота, аналитика и новые грабли<\/strong><\/h3><\/p>\n

Из ближайших задач — улучшить интерфейс<\/strong>. Сейчас он функционален, но выглядит как технический кабинет администратора. Хотим сделать понятнее, аккуратнее и ближе к продукту уровня «из коробки». <\/p>\n

Параллельно готовим новые стратегии<\/strong> и полноценный аналитический блок<\/strong>. Было бы странно не использовать тот объём данных, который мы уже накопили и агрегировали.<\/p>\n

Скоро первый релиз.
Дальше — новые рынки, новые функции и, конечно, новые грабли<\/strong>. О них вы знаете, где почитать. Подписывайтесь — впереди самое интересное.<\/strong><\/p>\n", "date_published": "2025-10-15T14:48:40+03:00", "date_modified": "2025-10-15T14:48:34+03:00", "tags": [ "Инструменты и сервисы", "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/price.png", "_date_published_rfc2822": "Wed, 15 Oct 2025 14:48:40 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "118", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/price.png" ] } }, { "id": "117", "url": "https:\/\/www.alexeyit.ru\/all\/reytingi-diplomy-i-drugie-pogony-agentstv\/", "title": "Рейтинги, дипломы и другие погоны агентств", "content_html": "

Сегодня хочу поговорить про рейтинги и конкурсы — всё то, что крутится вокруг разработчиков и интеграторов. <\/p>\n

\n\"\"\n<\/div>\n

Есть отдельный пласт рейтингов вокруг продуктов: Битрикс, Яндекс, интеграторы, маркетинговые — у каждой сферы своя специфика, поэтому их пропустим. Поэтому ниже речь пойдёт именно про <\/span>интеграторо-разработчиких<\/strong> рейтингах, а не про маркетинг, дизайн и креатив.<\/span><\/p>\n

Зачем вообще нужны рейтинги<\/strong><\/h3><\/p>\n

Сами по себе рейтинги —<\/span> вещь полезная<\/strong>. Они хоть как-то структурируют рынок, помогают заказчикам сориентироваться, когда непонятно, к кому идти. Но если заказчик выбирает подрядчика только по строчке в рейтинге — это тревожный звоночок. Чаще всего таким людям стоит не агентство искать, а тендер проводить проводить.<\/span><\/p>\n

Обновляются рейтинги, как правило, раз в год. И в этот момент начинается праздник самолюбия: «топ-1 по разработке», «топ-1 по интеграциям», «лидер региона» — а потом мелким шрифтом: город N, участников два и иногда, часто мелкого шрифта нет. <\/span><\/p>\n

Зачем? Если человек с опытом — он проверит. Если без — обман всплывёт позже, уже в работе. А дальше — минус доверие и плюс проблемы. Хочешь гордиться — напиши прямо: топ-5 по продвижению в Саранске, 2025 год по версии такого то рейтинга. Это честно, наверное.<\/span><\/p>\n

Конкурсы: когда побеждает обложка<\/strong><\/h3><\/p>\n

Отдельная история — конкурсы. По сути, они оценивают дизайн, визуал и упаковку. И все, кто делает сложные вещи — интеграции, CRM, B2B-платформы, автоматизацию, — остаются за кадром. Никто не разбирается в архитектуре и логике, все смотрят глазами. <\/span>Не жалоба — просто факт. <\/strong>Поэтому если у вас внутри <\/span>ракета<\/strong>, упакуйте её <\/span>красиво<\/strong>. Без этого победит лендинг на тильде с двадцатью <\/span>анимациями<\/strong>.<\/span><\/p>\n

Что реально стоит за рейтингами<\/strong><\/h3><\/p>\n

Любой рейтинг отражает не рынок, а кусочек рынка. Сильные студии туда часто даже не подаются: <\/span>лень<\/strong>, <\/span>не видят смысла или не чувствуют отдачи<\/strong>. Поэтому относиться к рейтингам стоит учитывая данный нюанс — <\/span>как к инструменту, а не к истине.<\/strong><\/p>\n

Мы участвуем системно. Причины простые: во-первых, рейтинги часто фигурируют в <\/span>тендерах<\/strong>— это фильтр, который нужно пройти; во-вторых, это способ <\/span>сверить <\/strong>себя с рынком; и наконец, в нашем случае — инструмент, который работает. Все затраты на участие возвращаются кратно.<\/span><\/p>\n

Вместо вывода<\/strong><\/h3><\/p>\n

Рейтинги — не зло и не панацея. Это просто инструмент, который при правильном подходе действительно приносит профит. В конце концов, у заказчика всё решается не цифрой в рейтинге, а тем, как быстро и качественно ты решаешь его задачу.<\/span><\/p>\n



<\/p>\n", "date_published": "2025-10-10T11:15:21+03:00", "date_modified": "2025-10-10T11:15:18+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/general.png", "_date_published_rfc2822": "Fri, 10 Oct 2025 11:15:21 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "117", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/general.png" ] } }, { "id": "116", "url": "https:\/\/www.alexeyit.ru\/all\/esli-by-ya-provodil-tender-kak-vybrat-podryadchika-po-chestnym-k\/", "title": "Если бы я проводил тендер — как выбрать подрядчика по честным критериям", "content_html": "

Про тендеры я уже писал не раз — и про участие, и про подводные камни, и про то, почему большинство из них заканчивается странно или ни чем.<\/p>\n

\n\"\"\n<\/div>\n

Но сегодня хочу поговорить о редком, почти уникальном случае — когда тендер действительно проводят по-честному<\/strong>. Не ради галочки, не чтобы «закрыть процесс», а чтобы реально и объективно сравнить несколько компаний.<\/p>\n

Я задумался: а как бы поступил сам, если бы оказался по другую сторону — на месте заказчика? Наверное, сделал бы это так:<\/p>\n

Ценовые критерии — важные, но не главные<\/strong><\/h3><\/p>\n

Да, цена всегда играет роль. Но делать из неё решающий фактор — наверное нет.
Задал бы цене вес не больше 40%<\/strong>, чтобы отсечь демпинг. Потому что тот, кто сильно занижает смету на старте, потом либо начнёт “добивать” её допами, либо просто уедет в закат и проект не случится.<\/p>\n

Важно смотреть и на условия оплаты<\/strong>: есть ли аванс, его размер, как устроена постоплата. В текущих условиях кредитование проекта подрядчиком выглядит слишком соблазнительно. <\/p>\n

Плюс — я бы посмотрел на численность команды<\/strong>. Если в компании меньше 10 человек, то велика вероятность, что после подписания договора половина команды уйдёт на другой проект — просто потому что ресурсов не хватает. Конечно про типовой набор уставных стоит запросить и посмотреть. <\/p>\n

Неценовые критерии — видно экспертизу? <\/strong><\/h3><\/p>\n

Вот тут, как по мне, и начинается самое интересное.
Если хочется понять, кто реально в теме, а кто просто подает КП без погружения, можно включить несколько пунктов.<\/p>\n

    \n
  1. Мини-концепт.<\/strong>
    <\/strong>Не прошу полноценный дизайн всего проекта — это бессмысленно, особенно в в крупных проектах. Но можно дать небольшой фрагмент<\/strong> — например, форму возврата заказа или карточку товара.<\/li>\n<\/ol>\n

    Сравнить подход, логику, UX. Это покажет, умеют ли ребята мыслить системно, а не просто рисовать красивые кнопки.<\/p>\n

      \n
    1. Оценка задач по времени.<\/strong>
      <\/strong>Попросить оценить три задачи: мелкую, среднюю и крупную.
      Пусть дадут расчёт в часах, с короткой декомпозицией.
      Во-первых, это даст понимание, как команда планирует и оценивает нагрузку.
      Во-вторых, по этим данным потом удобно сравнивать поддержку<\/strong> — ведь именно она обычно идёт после внедрения.<\/li>\n
    2. Технический аудит и роадмап.<\/strong>
      <\/strong>Если уже есть действующий проект, можно попросить сделать мини-аудит: что бы улучшили, что видят рисками, что можно оптимизировать.
      Хорошие подрядчики в теме покажут системность — от инфраструктуры до бизнес-процессов и прочей отраслевой экспертизой.<\/li>\n
    3. Качество самого КП.<\/strong>
      <\/strong>Как оформлен документ, насколько чётко и логично изложено предложение. Даже орфография многое говорит о внутренней культуре компании. Выравнивание строк столбцов, таблиц в документе. <\/li>\n
    4. Кейсы.<\/strong>
      <\/strong>Да, кейсы всегда послать\/запросить, даже похожие. Но зная специфику, я бы не делал на этом сильный упор. В том же e-commerce отраслевой специфики не так уж много.<\/li>\n<\/ol>\n

      Разумеется, пунктов можно придумать ещё десятки. Но тогда придётся строить целую систему с весами, сводными таблицами и многочасовым анализом. <\/p>\n

      Зачем всё это<\/strong><\/p>\n

      Да, такие тендеры — как единороги: о них все говорят, но мало кто видел.
      Но если всё-таки решите провести честный отбор — делайте его не ради отчётности, а ради результата.<\/p>\n




      <\/p>\n", "date_published": "2025-10-07T17:59:04+03:00", "date_modified": "2025-10-07T17:58:59+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/edinorog.png", "_date_published_rfc2822": "Tue, 07 Oct 2025 17:59:04 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "116", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/edinorog.png" ] } }, { "id": "115", "url": "https:\/\/www.alexeyit.ru\/all\/modul-migracii-tovarov-v-internet-magazin-na-bitriks-bystry-pere\/", "title": "Модуль миграции товаров в интернет-магазин на Битрикс | Быстрый перенос с маркетплейсов", "content_html": "

      Продолжу тему из прошлого поста про разработку продуктов. На этот раз мы прыгнули в историю с селлерами — точнее, нас туда уже занесло.<\/p>\n

      \n\"\"\n<\/div>\n

      Маркетплейсы продолжают закручивать гайки. К комиссиям добавляется и НДС. В итоге продавцам становится всё сложнее удерживать маржинальность. У Amazon, например, комиссии на некоторых категориях доходят до 50% — и это уже не страшилка, а реальность.<\/p>\n

      Многие селлеры просто не вывозят в таких условиях и начинают искать альтернативы.<\/p>\n

      Что предлагает рынок<\/h3><\/p>\n

      Рынок реагирует по-своему. Яндекс недавно запустил KIT — по сути, конструктор интернет-магазина, заточенный под fashion-сегмент. Для небольших продавцов логично и дальше использовать тильду или аналогичные платформы. Запустить витрину на 50–100 товаров так можно быстро и недорого.<\/p>\n

      Где возникает разрыв<\/h3><\/p>\n

      Проблема начинается там, где у селлера не сотня, а тысячи или десятки тысяч позиций. Где важна интеграция с 1С, синхронизация остатков, работа с прайсами и автоматизация процессов.<\/p>\n

      Здесь простые конструкторы уже не тянут. А собственный магазин нужен не «через год после долгой разработки», а прямо сейчас, чтобы проверить гипотезу: полетит ли онлайн-продажа вне маркетплейсов или нет.<\/p>\n

      В России из серьёзных платформ по сути остаётся Bitrix и пара его аналогов.<\/p>\n

      Наш кейс и решение<\/h3><\/p>\n

      Мы пошли по пути минимального входа: Bitrix + готовое решение + наш модуль миграции<\/strong>. Такой старт-пакет позволяет быстро запуститься и сразу получить рабочий интернет-магазин.<\/p>\n

      Модуль решает самую больную часть — миграцию контента. Он умеет подтянуть каталог с нужной площадки (Ozon, Wildberries, Яндекс.Маркет, Lamoda) и автоматически разложить товары в Bitrix. Получаем готовую базу, с которой можно работать.<\/p>\n

      Дальше уже можно подключить 1С, настроить синхронизацию и развивать проект. Главное — продавец экономит недели рутинного копипаста и может сразу проверить спрос на своей площадке.<\/p>\n

      Что дальше<\/h3><\/p>\n

      Мы начали писать модуль, потому что такие запросы стали прилетать регулярно. И поняли, что проблема у рынка типовая.<\/p>\n

      Сейчас модуль работает в закрытом режиме. На маркетплейсе Битрикса вы его не найдёте. Но если тема вам актуальна — пишите, обсудим доступ и детали.<\/p>\n", "date_published": "2025-10-03T09:26:13+03:00", "date_modified": "2025-10-03T09:27:38+03:00", "tags": [ "Личный опыт и размышления", "Технологии и разработка" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/b-module.png", "_date_published_rfc2822": "Fri, 03 Oct 2025 09:26:13 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "115", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/b-module.png" ] } }, { "id": "114", "url": "https:\/\/www.alexeyit.ru\/all\/boost-conf-2025-saas-nalogi-i-zachem-agentstvam-bezhat-bystree-r\/", "title": "Boost Conf 2025: SaaS, налоги и зачем агентствам бежать быстрее рынка", "content_html": "

      На прошлой неделе мы съездили на Boost Conf — одну из крупнейших конференций для руководителей digital-агентств и IT-компаний. Два дня в Сколково: место амбициозное, но вайба «Красного октября» там уже нет. Хотя всё равно по-своему прикольно.<\/p>\n

      \n\"\"\n<\/div>\n

      Атмосфера и контент<\/h3><\/p>\n

      Программа была на высоте: много секций, сильные спикеры, темы — хоть разрывайся, столько интересного шло параллельно. Особенно зашли истории про факапы от крупных игроков. Все говорят: «Учитесь на чужих ошибках», но по факту сильнее всего врезаются в память свои.<\/p>\n

      Личные инсайты<\/h3><\/p>\n

      Для себя отметил две вещи: консалтинг и истории о том, как не надо запускать продукты внутри агентств<\/strong>. Актуально — мы сейчас тоже переводим свои наработки в продукт. «Коробка» уже есть и работает на ряде проектов, но мы решили прыгнуть сразу в омут и сделать SaaS. Ждите отдельные посты про этот путь.
      Кстати, если у кого-то есть опыт грамотного расчета тарифов для SaaS-решений — буду рад пообщаться.<\/p>\n

      Встречи и рынок<\/h3><\/p>\n

      Как обычно на конференциях, самое ценное — это встречи. Старые друзья, новые знакомства, рабочий вайб.<\/p>\n

      Если говорить про рынок — картина непростая. Радужных перспектив и планов, как в прошлом году, уже нет. Не сказать, что все готовятся «умирать», но чтобы сохранить темп прошлого года, булочки приходится напрягать сильнее и бежать быстрее.<\/p>\n

      И это ещё не всё.<\/strong> Новый год принесет испытание в виде новых налогов и НДС. Жаловаться уже поздно — в этом году мы с этим живём. И, может, это даже хорошо: на рынке станет чуть меньше фрилансеров-студий «в одном лице». Конкурировать с ними смысла нет, но вот в тендерах точно должно стать просторнее.<\/p>\n

      Тренды<\/h3><\/p>\n

      На хайпе, конечно, всё вокруг внедрения ИИ в любых вариациях. И — неожиданно — CRM. Тут тоже есть куда приложить силы. Если вам нужна помощь — пишите.<\/p>\n

      Финальный акцент<\/h3><\/p>\n

      Вишенкой на торте стал фильм «Старая школа» от Wizards — про то, как строилась индустрия, кто стоял у истоков агентского и студийного бизнеса в России. Фильм — огонь, ждём вторую часть.<\/p>\n

      Итого<\/h3><\/p>\n

      Поездка получилась как сверка часов. Полезно, чтобы держать себя в тонусе и понимать, где движется рынок. Всех был рад видеть — до новых встреч.<\/p>\n", "date_published": "2025-09-29T16:38:01+03:00", "date_modified": "2025-09-29T16:24:50+03:00", "tags": [ "Личный опыт и размышления" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/photo_2025-09-22_10-27-48.jpg", "_date_published_rfc2822": "Mon, 29 Sep 2025 16:38:01 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "114", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/photo_2025-09-22_10-27-48.jpg" ] } }, { "id": "113", "url": "https:\/\/www.alexeyit.ru\/all\/deshyovy-kostyl-segodnya-dorogoy-proekt-zavtra\/", "title": "Технический долг и legacy проекты — как архитектура кода влияет на скорость релизов и стоимость поддержки", "content_html": "

      Мы много работаем с легаси. Основной пул наших клиентов — это проекты на развитие и поддержку текущих систем. И именно здесь как нельзя лучше всплывают два вопроса: стоимость поддержки кода и скорость релизов<\/strong>.<\/p>\n

      \n\"\"\n<\/div>\n

      Стоимость поддержки<\/h2><\/p>\n

      Когда идёт разработка нового проекта — сайта, интернет-магазина, B2B-платформы или чего-то похожего — мало кто думает о том, сколько будет стоить дальнейшее развитие. Решения, которые закладываются на старте, часто не просто не адаптированы под поддержку, они прямо ей сопротивляются.<\/p>\n

      И это, наверное, нормально. Я уже писал, почему веб всё ещё делают плохо. Но ситуация кардинально меняется, когда работаешь с долгосрочным проектом. Здесь нельзя просто «подписать акты, отдать проект и пусть он живёт сам по себе». На таких проектах любой костыль будет использован против вас.<\/p>\n

      Да, можно для отдельной задачи сделать решение быстрее и дешевле. Но это рано или поздно догонит техническим долгом. Поэтому лучше стараться этого не допускать.<\/p>\n

      Архитектура и варианты решений<\/h2><\/p>\n

      Я уже писал, что одна и та же задача может иметь сотни вариантов реализации. Так вот, при выборе решения лучше подумать, как оно ляжет в проект: станет чем-то обособленным или встроится в систему.<\/p>\n

      Да, работа по проектированию и архитектуре увеличивает стоимость конкретной задачи. Но зато в будущем может сберечь от рефакторинга целых блоков (а иногда и всего проекта). Оценить это сложно, но сердце подсказывает: так правильно.<\/p>\n

      Скорость релизов и TTM<\/h2><\/p>\n

      И вот вторая история. Чем хуже код, тем сложнее релизы, тем дольше time to market. А бизнес это ненавидит. Он хочет: придумал задачу — передал идею — вчера уже на боевом проекте. В жизни так не работает.<\/p>\n

      Чтобы улучшить TTM, есть стандартные механики: автотесты, автоматические релизы, организованные процессы.<\/p>\n

      Увидел тут мысль котороая кратко и точно отражает суть.
      Архитектура — это о стоимости изменений. Хорошая архитектура делает изменения дешёвыми. Плохая — дорогими. Если вам кажется, что хорошая архитектура стоит дорого, попробуйте плохую.<\/strong><\/p>\n

      Можно очень сильно автоматизировать процесс релизов, но на это уйдут часы и деньги — не всякий бизнес на это готов. Поэтому TTM всегда компромисс: сколько времени даём на разработку, тестирование и релиз.<\/p>\n

      В идеале релизы должны быть минимальными по времени и маленькими по объёму. Их проще тестировать, проще выкатывать и безопаснее. И лучше делать их чаще, чтобы не копилась очередь и зависимости между задачами.<\/p>\n

      Вывод<\/h2><\/p>\n

      Всё упирается в архитектуру и культуру команды. Можно долго спорить, что важнее — скорость или качество. Но на практике выигрывают те проекты, где удалось найти баланс и встроить его в процессы. Потому что костыль может показаться дешёвым решением сегодня, но завтра он обойдётся куда дороже.<\/p>\n", "date_published": "2025-09-22T10:25:50+03:00", "date_modified": "2025-09-22T10:25:41+03:00", "tags": [ "Личный опыт и размышления", "Управление проектами и командами" ], "image": "https:\/\/www.alexeyit.ru\/pictures\/brigth.png", "_date_published_rfc2822": "Mon, 22 Sep 2025 10:25:50 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "113", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.alexeyit.ru\/pictures\/brigth.png" ] } }, { "id": "112", "url": "https:\/\/www.alexeyit.ru\/all\/uyazvimosti-bitriks-i-laravel-realnye-keysy-i-prostye-mery-zasch\/", "title": "Уязвимости Битрикс и Laravel — реальные кейсы и простые меры защиты", "content_html": "

      Безопасность в IT — как страховка. Пока ничего не происходит, кажется, что можно жить спокойно и не тратить время. Но как только случается атака, всё внимание переключается туда, и гайки начинают закручивать даже там, где это мешает бизнесу.<\/p>\n

      \n\"\"\n<\/div>\n

      Нужно понимать: собрать систему без единой лазейки на 100% в реальном мире почти невозможно, особенно если она подключена к сети. Можно только снизить риск заражения. Если кто-то действительно захочет взломать — он найдёт способ: сотруднику пришлют «милого котика» в письме, домовую сеть взломают или найдут другой вектор. Большинство атак происходят автоматически — боты сканируют сайты, находят целевые CMS и пытаются эксплуатировать известные уязвимости. Если закрыть известные дыры и поддерживать гигиену системы — шансы спать спокойно вырастут.<\/p>\n

      Я знаю, о чём говорю: по диплому у меня «комплексная защита объектов информатизации», и за годы в веб-разработке мы видели всё — от ежедневных DDoS по 2 терабайта трафика до заражённых модулей и майнеров, внедрённых через пакеты.<\/p>\n

      Что реально ломают<\/strong><\/h2><\/p>\n

      Чаще всего достаётся CMS: в Битриксе это модули и готовые решения, которые не обновляются вовремя; в WordPress ситуация ещё хуже. Laravel-проекты тоже не застрахованы: последние пару лет участились случаи заражения через сторонние пакеты, особенно бесплатные.<\/p>\n

      Что работает против уязвимостей<\/strong><\/h2><\/p>\n