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

Самая дорогая ошибка 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. Мы для теста создали отдельную страницу на тестовом сервере, закинули туда все это дело. Думаете, работает? Хер там. Вообще никак. По вашей…

В общем, вчера клиент прислал "виджет", который ему ИИ сгенерил. Попросил вставить на сайт. Набор php/css/js/html. Мы для теста создали отдельную страницу на тестовом сервере, закинули туда все это дело. Думаете, работает? Хер там. Вообще никак. По вашей задаче вывод простой: проще с нуля написать, чем разбираться, что за хрень там нейронка наваяла. Такое ощущение, что надо полгодика-годик переждать. Когда это иишное говно начнет массово сыпаться, тогда опять программисты будут нужны. Либо ИИ таки научится нормально код писать — и тогда всем пипец, на завод))

В этот раз гонка для нас не задалась. Первый спец участок прошли отлично, очень плотная конкуренция с соперниками: прям ошибся, потерял минуту - тебя обогнали. Это интересно. Второй спец участок тоже шли хорошо, нас впереди осталось два экипажа, которые шли нос к носу. Но буквально за полтора часа до финиша веткой пробиваем радиатор. Антифриз выливается. Машина начинает греться. Всю питьевую воду заливаем туда. Мало. Начинаем черпать из луж и заливать. Под давлением пробор расширяется. Пытаем забить его отверткой, потом сучком. Чтобы не так текло. Вроде как получается, но ненадолго. Смотрим время - 20км впереди просто по дороге, но уже лишь 15 минут на доезд. Это надо ехать со средней скорость 80км/ч без остановок. По факту выше. А нам надо каждые 5 минут доливать воду, которой нет. Увы, звоним товарищам, уезжаем на тросу, получаем DNF (Do Not Finish). Уходим вниз таблицы среди конкурентов. Расстроены. Не повезло. Ну что ж, будем смотреть, как нам это аукнется, когда начнем ремонт делать. Перегретый двигатель такое себе.

Сайт использует cookie-файлы, чтобы сделать ваше пребывание на нем максимально удобным. Оставаясь на сайте, вы даёте своё согласие на использование cookie-файлов. — пошли нафиг, не дам! Доступ к рабочему столу, файлам, банковским счетам для иишечки — пожалуйста дорогой держи. Где сломалась логика?)

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

В общем, Сбер решил, что ручной кодинг больше не нужен. И это не просто слова. Разработчики массово забивают на обычные чаты с ИИ и переводят все на полный автопилот. За три месяца спрос на стандартные запросы и строчки кода упал на 67 процентов. А популярность автономных агентов взлетела почти в 5 раз. Инженеры больше не копаются в мелочах. Они просто скидывают системе задачу целиком: напиши, проверь, задокументируй целый модуль. И точка. Результат — объем генерации кода вырос в 30 раз. Технология прижилась настолько, что сейчас на 95 запущенных агентских задач приходится всего 5 простых запросов в чат. Это уже не тренд, а реальность. Джунам пора учиться писать не код, а техзадания. Иначе мимо :)

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