Иван Гринкевич - О dИИgital вслух

Зачем тратить на это деньги, если всё и так работает?

Эту фразу я слышу от финдиректоров чаще, чем "здравствуйте"))

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

И вот важный момент. Финдиректор не жадный и не враг. Он просто думает на другом языке. Ему все равно, насколько кривая архитектура у корзины. Ему не все равно, сколько денег эта корзина теряет.

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

1) Взяли каждую проблему из аудита отдельно.
2) Под каждую собрали исследования - как такая штука бьет по конверсии, по продажам, по скорости запуска акций, по рискам простоя.
3) Перевели все в примерные деньги. Сколько теряем сейчас и сколько перестанем терять.
4) Свели в таблицы. Скучные, нудные, но понятные человеку, который считает деньги.

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

Кстати, цифры лежат на поверхности, их надо просто приложить к своему проекту:
- по исследованию Stripe разработчики тратят около 42% времени на поддержку и разгребание старого кода, а не на новое. Грубо: команда из 5 человек - двоих вы оплачиваете за то, чтобы стоять на месте;
- Google и Deloitte посчитали, что ускорение мобильной версии всего на 0,1 секунды дает ритейлу +8,4% к конверсии;
- по данным ITIC для 90% средних и крупных компаний час простоя стоит больше $300 тыс. А пиковые продажи уже на носу.

"Все и так работает" - это как с машиной. По гонкам знаю: едет она ровно до того момента, пока не перестанет. И обычно это случается за полтора часа до финиша)))

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

Подозрительно низкая ставка подрядчика - это не удача, а сигнал тревоги

За годы участия в тендерах на разработку и поддержку ecommercе проектов вывел для себя простое правило: если ставка подрядчика заметно ниже рынка, радоваться рано. Сначала надо понять, за счет чего она такая. Очень высок шанс что с запросом скорее всего вернутся снова через какое-то время.

Недавно участвовали в одном тендере - разбежка прайсов на MVP разработку была стоимостью от 30тыс до 400тыс евро. Наш оффер где-то по серединке, может чуть ниже середины. И вот общаюсь я с head of ecom, который это все получил. И у него мысли такие касательно тех кто ниже рынка:
1) Либо у команды есть прям готовый продукт под запрос. Но зная специфику проекта - не может быть, там очень интересный кастом.
2) Либо в смете что-то пропустили. Вот это чаще. И откровенно плохо для обеих сторон. Когда студия поймет что промахнулась и недосмотрела - начнет резать углы и будет тратиться время на это, что повлияет на качество проекта.

Короче в проигрыше все.

Кстати, ряд ecom директоров с кем общаемся - просто выкидывают самые низкие предложения и самые высокие и смотрят подрядчиков в районе медианы. Или среднего арифметического. Что тоже может вызвать споры.

Поэтому при выборе подрядчика на ecom-проект я рекомендовал бы смотреть не на самую низкую цифру в тендере, а на то, может ли команда внятно объяснить, из чего она складывается. Если объяснить не может - не идти дальше, каким бы привлекательным ни было число в смете. Ну то есть детальная смета проекта должа быть. И там можно увидеть, отражены ли ключевые моменты. Да, скучная и нудная таблица, но видно что наш проектом работали, изучали. Если что-то упустили - есть шанс увидеть обеим сторонам. Потому что потом “не было было в смете но было в тз” - хороший повод для долгих споров.


Помимо низкой ставки, конкретно мы еще стараемся всегда смотреть чуть вдаль. Какие перспективы у проекта в рынке? Куда он может дальше вырасти? Как он может расшириться и какие ресурсы понадобятся в будущем на его рост? Сейчас с рядом текущих клиентов активно планируем бюджеты работ на 2027 год - куда будем идти и расти. Это партнерская работа и подрядчик - это один из главных партнеров head of ecom. Но это этом чуть позже.

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

Отрицательный экономический рост!
ИИ оставит всех без работы!
Нас заставят пользоваться Max! 😱

Звучит как приговор? Ха-ха, нет.

Пока одни паникуют, я и 29 других ИТ-директоров спокойны. Почему? Потому что мы умеем:

🔹 Находить выход там, где другие видят стену.
🔹 Искать позитив в любом негативе.
🔹 Превращать кризис в точку роста.
🔹 Дружить с ИИ, а не конкурировать с ним.
🔹 И да, оставаться в уютном TG, даже когда все вокруг кричат про «Max».

В папке собраны 30 самых стойких, веселых и (да, черт возьми) сексуальных профессионалов индустрии! 🕺💼

Это не просто список. Это люди, которые прошли путь «с самых низов» до владельцев бизнеса и футбольных клубов (у нас есть и такие!).

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

Если слова Digital, IT и AI для тебя — не просто набор букв, а то, с чем ты сталкиваешься каждый день — эта папка станет твоим счастливым билетом. 🎫

🚀 Успевай забрать папку, пока кризис не наступил! (Шутка. Или нет?)

Когда открываешь сайт, который вчера навайбкодили 😂

Бюджеты внедрения ИИ в бизнесе и ecommerce в частности

Прочитал исследование MWS AI - и оно прямо ложится на разговоры, которые у нас с клиентами идут каждый квартал при планировании бюджета. Средний годовой ФОТ команды, которая внедряет и сопровождает ИИ в крупном российском бизнесе, - около 108 млн рублей. Цифра, о которой стоит подумать до старта проекта, а не после.
Считали по московским зарплатам: ML-инженер Middle - около 400 тысяч в месяц, Senior - 550, технический руководитель - 800. И это чистый ФОТ, без инфраструктуры, лицензий и прочего.

Но вообще стартовать можно скромнее: ядро из четырёх человек под проверку одной бизнес-гипотезы - рекомендательный движок, динамическое ценообразование, ИИ-подбор в каталоге - укладывается примерно в 35 млн в год. Звучит подъемно для пилота. А вот дальше начинается то, что обычно не попадает в изначальную презентацию для CFO: переход от пилота к промышленной эксплуатации добавляет к ФОТ ещё около 60%.

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

Николай Тржаскал из fabricaONE.AI говорит об этом прямо, и мы видим то же самое на своих проектах: запустить ИИ-агента или рекомендательную систему - это половина дела. Дальше начинается самое неочевидное в бюджетировании и самое дорогое - сопровождение.

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

Что это значит на практике для ecom: бюджет на ИИ-инициативу нельзя защищать по стоимости запуска - его нужно защищать на 2–3 года вперёд, с учётом эксплуатации. Иначе через год у вас есть работающий пилот, команда, которая под него собрана, и обязательства перед бизнесом - а денег на это в финплане следующего года попросту не заложено.

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

А как у вас считают ИИ-бюджеты: отдельно пилот и отдельно эксплуатация - или вссе одной строкой на старте?

Почему простая доработка, которая должна была выйти за 2 дня, внезапно занимает 2 недели

Наткнулся на исследование Rebound Bytes - и оно прямо бьет по больному: за последние полтора года стоимость поддержки кода, написанного нейросетями (!!!), выросла в 4 раза.

Для нас, кто ведет e-commerce разработку в крупных проектах, это не абстрактная техническая метрика - это скрытая статья расходов, которая не видна в моменте, но потом бьет по бюджету разработки сильнее, чем экономия на скорости запуска фич.
Механика простая. ИИ всё чаще не генерирует решение под задачу, а тянет одни и те же куски из обучающих данных. Дублей в коде стало на 48% больше. А рефакторить и приводить в порядок написанное стали на 60% реже - просто потому что "надо было ещё вчера".

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

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

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

А это исследование меня триггернуло, потому что прямо сейчас один клиент пришел к нам с идее заменить часть команды разработки на ИИ, срезав тем самым 40-50% костов. И пусть нейронка ведет и поддерживает архитектурно и технически сложный проект, а людей будем подключать изредка. Что будет дальше - несложно предположить исходя из вышеописанного.

Ваш подрядчик чинит баги или делает вас героем? Это разные подрядчики

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

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

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

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

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

Перед тем как выбрать подрядчика, задайте себе один вопрос. Какое-то количество багов он починит за месяц/два/полгода, а что вы сможете рассказать своему руководству через три месяца совместной работы? Ответ на этот вопрос и определит, кого стоит нанимать.

Бодрого понедельника, подписчеги)

В пятницу вышло крутое исследование. Прочитал только сегодня) Но, думаю, будет интересно многим из тех кто меня читает. Речь про статью Ани Карауловой о кризисных явлениях в российской IT-отрасли в 2026 году. Аня провела 105 личных глубинных интервью с владельцами и руководителями студий разработки и диджитал-агентств. 220 часов работы - только вдумайтесь в этим цифры!

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

В целом, по цифрам всё грустно. 82% респондентов говорят о падении выручки в 2026-м относительно того же периода 2025-го. О росте заявили только 12%... 

Но самое ценное, на мой взгляд, сейчас объясню. Все счастливые истории выглядят одинаково, а разница в том, кто изначально встал на путь улучшений с запасом, а кто уже в моменте пытается вырулить. То есть кто-то учился/вкладывался и разруливал заранее (рост), а кто-то тушил пожары и ходил сам по граблям (падение). Место для задумать.

Потому как если отбросить цифры и не пессимиздеть, можно увидеть, что статья предлагает руководителям повод для саморефлексии. Даже с пунктами на подумать. Какие решения вы по привычке принимаете в одиночку? Где стоило бы позвать внешнюю экспертизу? И как перестать откладывать изменения, которые давно назрели.

По сути это про то самое “точить топор, а не пилить”. Когда ощущение белки в колесе уже не отпускает. И тут вопрос не в том, падаешь ты или растешь, а в том, находишь ли время посмотреть на свой бизнес со стороны.

Дополните картинку, камрады. Относительно 2025 падаете или растете?) Можно в личку пообщаться )

Есть один момент, который редко проговаривают вслух.

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

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

И тишина.

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

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

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

Что с этим делать?

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

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

А у вас было такое - сделали действительно сильную работу, а предъявить оказалось нечем? Или наоборот, научились "продавать" техническую стабильность наверх так, что это реально усиливало вашу позицию?

Bus factor = 1. Это не про автобусы, это про ваш бизнес.

Представьте: завтра утром ваш ведущий разработчик, который знает о проекте всё, присылает заявление. Не потому, что вы плохие, а потому что он вырос и хочет new challenges. И вы остаётесь один на один с кодом, который писался годами. Страшно? Должно быть, если не готовы.

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

Пора паниковать? Может и пора, первый раз когда-то так и было. А потом разобрали, сделали вывод, начали готовиться. На всех проектах.
Документация. Не просто «readme», а живая база знаний: архитектурные решения, схемы интеграций, инструкции по деплою, контакты смежных команд. Когда потом новый разработчик пришел, он за первую неделю прочитал все и задавал уже не глупые вопросы, а уточняющие. Онбординг минимальный по таймингу.
Распределение задач - заблаговременно. Как только стало понятно, что лид уходит, мы пересобрали кто что делает. С его помощью, под его руководством, но перераспределили. Его задачи разбили на куски, которые потянут остальные ребята. Это не произошло в спешке - мы пересматривали распределение ролей еще до его последнего рабочего дня.
Назначили Исполняющего обязанность лида. Не того, кто просто “старший по возрасту”, а того, кто уже давно погружался в смежные модули и (важное!!) готов был подставить плечо. Он взял на себя коммуникацию с заказчиком и координацию команды.
Параллельный поиск. Мы не ждали, пока он уйдёт, чтобы начать искать замену. К моменту его ухода у нас уже был почти готовый оффер для кандидата. Кстати, он нам помогал собесить тех кто будет вместо него.


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

Я к чему. Наличие документации на проекте, это крайне важный фактор. Это про безопасность, и про скорость, и про качество.

попалось на просторах)))

P.S. Можем помочь по 1с если ИИ-шечка не вывозит)))

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

Но если с озоном повторится история вб, то стоит ли ждать роста спроса на собственные интернет-магазины? Вроде бы логично что да, но есть один момент.

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

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

Релиз — это не событие, это рутина. Но как сделать его безопасным для выручки?

Какое-то назад мы готовили для клиента (сеть магазинов электроники) обновление ядра корзины. Любая ошибка в оформлении заказа стоит дорого, тут объяснять не надо.

В процессе подготовки я в очередной раз убедился, что работа над e-commerce проектом - это всегда баланс между "хотелкой" бизнеса и "процессами" ит-отдела.

Обычно есть два основных сценария. Первый наш любимый, "Релиз без сюрпризов":
1) Безопасность превыше скорости: Даже если задача "горит", она не летит в прод без прохождения всех кругов тестового ада. Потому что "горящий" прод - это потерянные деньги.
2) Автономность: Когда вчера лег GitHub по всему миру (там много чего у майкрософта полегло вчера), многие коллеги потеряли время. У в большинстве проектов свой GitLab, поэтому можно продолжать спокойно работать, пока остальные пьют кофе. Для бизнеса это даже не заметно. Сбои чужих продуктов. (на минуточку - даже у таких гигантов эти самые сбои бывают)
3) Мониторинг: Мы настраиваем оповещения так, чтобы при сбое обмена с чем-либо мы знали об этом раньше, чем менеджер клиента.

Почему я это пишу? Вроде ж база
Потому что вижу тенденцию (второй основной сценарий): многие e-commerce директора соглашаются на хаотичную разработку ради скорости. “Сделайте быстро, потом починим”. Вот это, вот это и вот это. И компот.

Но в e-commerce "потом" не наступает. Приходит пик нагрузки, и все "технические долги" превращаются в "потерянные заказы". Потому важно вовремя сказать СТОП и прийти к релизам два раза в неделю, а лучше раз в неделю. Понятное дело, что критикалы чинятся сразу же. А то еще подумаете что отвалившийся обмен будет неделю ждать релиза. не будет)))

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

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

Самая дорогая ошибка eCommerce-директора

И это не про технологии. Это про то, как вы смотрите на свой IT-продукт.
Вот что я вижу постоянно
Директор считает, что если на сайте “все работает” - нет 500-х ошибок, корзина не падает, оплата проходит - значит, проект здоров. Значит, можно расслабиться и заниматься только маркетингом.

Нет.
Отсутствие багов "не равно" здоровый проект.
Это как сказать: “У меня нет температуры, значит, я в идеальной форме”. При этом холестерин зашкаливает, сосуды в плачевном состоянии, а организм не способен пробежать и ста метров без одышки.
Так и с вашей платформой.

Здоровый eCommerce-проект - это не тот, где ничего не ломается. Это тот, который быстро меняется.
Быстро внедряет A/B-тест.
Быстро запускает новую механику акций.
Быстро интегрируется с маркетплейсом, который вчера объявил о новых правилах.
Быстро реагирует на поведение пользователей.

А если ваш проект “стабилен” только потому, что в нём никто ничего не трогает три месяца - это не стабильность. Это окаменелость.

И в тот момент, когда конкурент с более “живой” архитектурой запустит фичу за неделю, а вам понадобится квартал - вы проиграете. Не потому что у него лучше дизайн. А потому что у него здоровая “сердечно-сосудистая система” продукта.

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

Что делать?
Перестаньте спрашивать разработку: “Когда починят баг?”
Начните спрашивать: “Сколько времени займёт внедрение вот этой штуки? И почему так долго? (если действительно долго)”
Первый вопрос лечит симптомы. Второй — диагностирует болезнь.

А вы как думаете: может ли проект быть "здоровым", если в нём редко что-то меняется? Или я слишком категоричен?
Жду в комментариях - особенно если у вас есть истории, когда “стабильность” обернулась упущенной возможностью.

Почему маркетинг начинает ненавидеть разработчиков
Это очень жизненная история. Я вижу ее раз в месяц, если не чаще.

Маркетолог врывается в чат:
- Ребят, конкурент запустил акцию "2+1" на весь ассортимент. Нам надо срочно так же, иначе провалим месяц. Завтра нужно!
Разработка:
- Так, стоп. У нас нет механики "2+1" на уровне корзины. Надо править логику расчёта, переписывать интеграцию с 1С, проверять на мобилках. Это два спринта. Минимум месяц.
Далее начинается ад...
Маркетинг: "Вы вообще не понимаете бизнес! Завтра дедлайн, а вы мне про спринты!"
Разработка: "А вы вообще не понимаете, как работает код! Завтра - только если колдовать!"

Обвинения летают в обе стороны. Маркетологи считают разработчиков тормозами, которые сидят в своей башне из абстракций. Разработчики считают маркетологов истериками, которые "сами не знают, чего хотят, а если знают то хотят чтобы это было готово вчера".
И вот тут самое важное: проблема вообще не в людях.

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

Рынок меняется каждый день. Ваша архитектура - крайне долго.
И пока вы будете искать "виноватых" между отделами, конкурент, у которого эта механика внедрена за два дня через админку, уже съел вашу выручку.

Что делать?
Перестаньте устраивать разборки "кто кого не понимает". Начните мерить не "кто виноват", а "сколько времени занимает внедрение необходимой типовой маркетинговой механики".
Если запуск акции требует вмешательства разработки и занимает больше недели - у вас не конфликт отделов. У вас архитектурный тупик. И он лечится не командообразованием, а инженерией.

Здоровый eCommerce - это когда маркетинг и разработка не дерутся, потому что у маркетинга есть рычаги, а у разработки - спокойные вечера. (как же их иногда не хватает)

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

Как понять, что ваш интернет-магазин уже стал заложником технического долга

Еком активно сваливает с маркетплейсов, которые не менее активно подкручивают гайки, добавляют/снимают разные условия.

Молодцы оказались те, кто не закрыл свой собственный магазин, а хотя бы оставили его жить как есть. И теперь стартовать/возобновлять все проще и в плане “догнать технологии”, и в плане банального seo-продвижения.

А есть же еще пласт незавершенных/забытых работ, которые возможно даже где-то хранятся. А возможно потеряны навсегда вместе с контактами подрядчика, который делал вам проект.

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

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

По нашему опыту, такое может занимать 3-6 месяцев для относительно небольших проектов, и до года на крупных.

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

Почему интернет-магазины перестают развиваться после 3–5 лет работы?

Сначала все быстро. Красиво делается, быстро, релизы идут, все круто.
Но все меняется, требования бизнеса тоже. Простые быстрые вещи сделаны. Появляются новые задачи, которые требуют больших переделок. Но бизнесу всегда надо “вчера”. Что делает большинство команд? Да, начинают ставить костыли. И вот здесь уже вылазят проблемы: нет документации, все в памяти разработчиков, не очевидные зависимости (стукнул по колесу - дверь отвалилась).

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

Увы, такие проблем вижу из проекта в проект. Нет ресурса на рефакторинг, нет ресурса на улучшение того, что для инвесторов не видно. Но когда оно начинает сбоить - видно становится сразу всем. И этот “показ” стоит дорого, намного дороже чем если бы сразу закладывались в такого рода работы.

Для бизнеса это потеря скорости. Далее может быть либо поэтапный план восстановления проекта с минимум нововведений (первичная цель - стабилизация), либо все к херам снести и построить заново. Мы по возможности практикуем первый вариант- в этот момент бизнес может работать, пока на отдельных серверах проект стабилизируется и ночами аккуратно выкатывают обновления, с последующими тестированиями. Это чтобы head of ecom утром судорожно не играл в тестировщики)

(все описанные выше события выдуманы и не имеют отношения к реальности :D )
Правда?)) ахахах)))

Друзья, привет! Нужна помощь))

Мы делаем исследование сравнения разных ИИ-моделей (ChatGPT, Deepseek, Kimi, GigaChat, YandexGPT и т.д.). Хотим прогнать их через реальные бизнес-задачи, а не абстрактные вопросы.

Скиньте, пожалуйста, примеры ваших реальных промптов, которые вы пишете в нейросети как маркетолог или руководитель e-com.

Интересует буквально всё: от написания офферов и генерации гипотез для рекламы до составления ТЗ и анализа прайсов конкурентов. Напишите, для чего вы это используете (контекст) и что именно пишете.

Чем больше конкретных формулировок, тем полезнее будет наше исследование для всего рынка. Спасибо!

Немного о маркетплейсах - что делать селлерам?

Итак, склады сгорели, выплаты от вб под большим вопросам, страхования товара нету. К чему это может привести?
1) повышать цены на товары. Халява с дешевыми товарами закончится. Когда в офлайн точке ты видишь цифры в 1.5-2 раза дороже чем на вб/озоне - вот это будет срезаться, бизнесу надо будет компенсировать убытки. Хотя бы частично
2) Недоверие к складам. Вы не застрахованы, в один момент можно много потерять. Диверсифицируйте склады.
3) Думаю, многие уже задумались о возвращении к розничным точкам продаж и к своим собственным интернет-магазинам.

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

Ах да, всех снова ждут локальные свои склады при магазинах. 
Под это дело как раз в соседнем чате сбросили ссылочка почитать  https://vc.ru/marketing/3034709-kak-izbezhat-zavisimosti-biznesa-ot-it-monopoliy 

А если у вас уже есть свой проект, можем помочь его развивать и расширять.

Позавчера я написал пост про то, как клиент скинул сгенерированный ИИ-набор файлов (PHP/CSS/JS/HTML), который на тестовом стенде отказался работать начисто. Вывод был прост: проще переписать с нуля, чем разбираться в этом «цифровом мусоре». Некоторые его восприняли в стиле “ха-ха, нейросеть тупая”.
Но давайте разберем эту ситуацию как инженерный вызов и новые реалии жизни.

1. Почему виджет не работает?
Прежде чем орать на нейросеть)) Давайте посмотрим на код как разработчик (в прошлом я им и был). В 90% случаев причина не в «тупости» ИИ, а в контексте.
- ИИ генерирует «сферического коня в вакууме». Он пишет код, не зная, что у вас на сервере.
- Конфликт зависимостей. К примеру, нейросеть написала класс на чистом JS, а ваша сборка (Webpack/Gulp) жрет CommonJS, или наоборот, использует устаревший jQuery, а ИИ напихал функций, которые ломают эту всю красоту.
- Стили. ИИ использовал CSS-классы, которые конфликтуют с классами проекта, или он дал z-index: 99999, который перекрывает жизненно важные объекты на проекте.

Вывод: Вам не нужен отладчик, вам нужен Адаптер. Неправильно говорить «ИИ нагенерил херни». Правильно — «Мы не подготовили среду для восприятия его кода».


2. Что править, чтобы ЗАРАБОТАЛО?
Если вы хотите использовать код от ИИ, не используйте его. Любой ИИ-код — это черный ящик. Если вы не программист конечно же. Но что делать в конкретной ситуации?
- Правим на странице: Создаем единую точку входа. Например, обертку-загрузчик, которая подтягивает его стили и скрипты только на конкретном URL, изолируя их от глобальных конфликтов. Ну либо ручками вычищаем конфликты. И то, и то трудозатратно, да.
- НЕ правим генератор у клиента. Это бесполезно. Клиент всегда будет использовать ChatGPT или Claude. И в текущих реалиях чем дальше тем больше. Мы должны адаптировать под реалии, а они быстро меняются.

Чтобы маркетолог мог накидать виджет, дизайнер — поправить цвета, а прогер — не плакать, процессы должны эволюционировать.

Сразу надо понять! Если вы любите приходить к программистами с идеями, которые уже сгенерированы ИИ, то с этим тоже надо уметь работать. Со временем промпты станут лучше и качество скриптов улучшится. Захочется разогнать этих всех программеров, у самого же отлично получается))) Не спешите)

3. Что должны понять «умные дяди» (Руководители)?
Вот главный инсайт, который вы просили.
ИИ — это не разработчик, а Стажер-скоростник. Он пишет код со скоростью света, но с качеством стажера-джуниора, который не знает вашего контекста.
Ваша задача — не запрещать ИИ, а выстроить конвейер валидации.
- Для мозга: Смиритесь, что код от ИИ — это черновик. Время, потраченное на отладку его кода, сейчас закладывается в спринт как отдельная задача «Адаптация ИИ-решений».
- Для организации: Инвестируйте в MCP-серверы (Model Context Protocol). Это позволит вашей корпоративной нейросети видеть вашу документацию, структуру БД и API. Тогда нейросеть будет генерировать код, который теоретически может работать без правок, потому что она будет знать структуру вашего проекта.
- Главная цель: Научить ИИ не писать код с нуля, а «код-ревьюить» легаси. Пусть он подсказывает, как вставить новый виджет в старую архитектуру.

Итог: Вместо того чтобы ругаться на сломанный виджет, создайте отдельный сервис-адаптер. Через месяц у вас будет не «куча мусора», а «фабрика прототипов», где любой менеджер за 5 минут соберет страницу, а разработчик потратит 15 минут на ее «причесывание» под стандарты, вместо 2 часов написания с нуля.

"Мы не переписываем код нейросетей. Мы учим их писать наш код."
Вот что нужно внедрить.