Антон Носков | Разработка для е-ком
СтатистикаРассказываю, как мы — бутиковая команда, строим еком-проекты. Техдир в MONOPLAN @monoplan_team Для связи @anton_noskov
- Последний пост
- 9 июл. 2025 г.
- Последнее чтение
- 11:41
- Постов за неделю
- 0
- Всего постов
- 20
- Тип
- открытый
- Язык
- русский
- Категория
- Технологии
- В каталоге с
- 12 авг.
- 1/24сутки в ленте
- —
- 1/48двое суток
- —
- 1/72трое суток
- —
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
В мае впервые подписали контракт на 2 года, с фикс бюджетом и форматом работы по T&M. Высадили небольшую команду разработки для развития е-ком проекта: php, битрикс, API для мобилки, интеграции (1С, CRM и прочее). У нас: два фулл-стек разработчика, тимлид…
Продолжаем тему: как строить бренд для своего e-commerce и не быть только витриной. Вебинар на тему: Медиа для e-commerce: как стать брендом, а не витриной Кому будет полезно? Владельцам брендов, D2C-командам, e-commerce менеджерам, маркетологам и тем, кто строит свой канал продаж и не хочет зависеть от чужих правил. Участники: Алексей Рожков Основатель и CEO Редакции Рыба — топ-1 контент-агентства по версии Рейтинга Рунета 2025. Эксперт в контент-маркетинге и в построении контентных команд. Эксперт Яндекс Рекламы. Андрей Фролов Основатель eCommerce-агентства MONOPLAN — помогаем онлайн-ритейлу расти и меняться в эпоху маркетплейсов. 🚀 В эфире обсудим: ✅ как интернет-магазину запустить своё медиа ✅ какие форматы реально работают ✅ что это даёт помимо “узнаваемости” ✅ как медиа может поддерживать продажи ✅ какие ошибки съедают бюджеты ❗️Ждём всех уже в четверг, 3 июля, в 15:00 — тут, в канале Monoplan Будет по делу, без воды, с практикой и примерами.
Ребята! Сегодня в нашем канале MONOPLAN будет эфир на дискуссионную тему — нужно ли е-кому свое медиа? Поможет ли оно укрепить бренд и не остаться просто витриной? В виртуальных гостях у нашего CEO Андрея будет Алексей Рожков, Основатель и CEO Редакции Рыба — топ-1 контент-агентства по версии Рейтинга Рунета 2025. Приходите, будет интересно 100%
В мае впервые подписали контракт на 2 года, с фикс бюджетом и форматом работы по T&M. Высадили небольшую команду разработки для развития е-ком проекта: php, битрикс, API для мобилки, интеграции (1С, CRM и прочее). У нас: два фулл-стек разработчика, тимлид, тестировщик. Овнер, проджект и дизайнер на стороне клиента. То есть наша роль технарская: выбор решений, внедрение, разбор инцидентов. Бюджет далеко не космический. Но формат мне очень нравится. Естественно, мы и раньше работали с одним клиентом 2 года (рекорд 7 лет 😱). Но контрактов с фикс бюджетом на такой длительный срок у нас не было. Обычно есть только условная договоренность о бюджете на год. И практика показывает, что нарушить такую договоренность клиенту не трудно (никто не плохой в этой истории, просто факт). Крайне важно, что нам доверяют настолько, чтобы подписаться на два года. Работаем, чтобы таких контрактов стало кратно больше 💪 В последующих постах расскажу, что из себя представляет такая команда и какие-задачи решает. А пока можно почитать наш канал MONOPLAN — эфиры, полезные контент про е-ком и мысли о том, каким должен быть подрядчик по разработке.
видео или голосовое, без подписи
Вот у этих бусиков сегодня годовщина 10 лет ❤️ Это вам не это и не то.. А со знакомства еще +5 годиков ❤️ Жду когда наши отношения наконец переплюнут точку невозврата: жил без нее, меньше чем с ней, еще пара годиков) Каждому в жизни желаю чего-то подобного, не пожалеете 😉 А вы можете оставить свои поздравления в комментариях 👇
online-трансляция Комиссии маркетплейсов растут. Что будет дальше? В 2025 году комиссии у крупнейших площадок подбираются к отметке 30–35% (учитывая логистику, рекламу, бонусы и пр.). Маркетплейсы становятся дорогим арендованным каналом. И брендам пора возвращать контроль — над клиентами, данными и доходом. Когда мы говорим о развитии интернет-магазинов брендов и D2C-проектов, важно понимать, что рост продаж — это не только про трафик и маркетинг, но и про управление отношениями, возврат клиентов и создание своей экосистемы. Сегодня маркетплейсы дают объёмы, но отнимают данные, лояльность и маржу. Если бренд не хочет быть просто “SKU в выдаче”, а стремится к устойчивому бизнесу — нужно строить свою стратегию. Почему маркетплейсы растут, а свой сайт — нет? Как вернуть и удержать клиентов у себя? Что делать, если интернет-магазин — это просто “витрина”, а не канал продаж? Эти вопросы мы обсудим в эфире уже в эту среду, 4 июня, в 17:00 — здесь, в канале Monoplan. Эфир пройдёт в формате дискуссии с обсуждением гипотез и предложений. Наш гость: Илья Илюнин — коммерческий директор интернет-магазина спортивного питания для циклического спорта SPORTFERMA О чём поговорим: - Как бренду отстроиться от маркетплейсов — и зачем это вообще нужно - Почему интернет-магазин не растёт, и как это поменять - Какие каналы, механики и гипотезы реально работают в 2025 - Как удерживать и возвращать клиентов, а не только сливать бюджет на первую продажу - Как синхронизировать маркетинг и продукт — чтобы интернет-магазин наконец продавал - Где найти точки роста, даже если трафик дорогой, а CR низкий Для кого эфир? Для владельцев брендов, D2C-команд, e-commerce менеджеров, маркетологов и тех, кто строит свой канал продаж и не хочет зависеть от чужих правил. 📍Ждём всех уже в среду, 4 июня, в 17:00 — тут, в канале Monoplan Будет по делу, без воды, с практикой и примерами.
Ребята, приглашаю на эфир! Что делать с собственным онлайн-каналом продаж, когда маркетплейсы дают лучший опыт во всём? Какие могут быть способы отстройки от маркетплейсов (и нужно ли отстаиваться?), что делать специализированным и брендовым интернет-магазинам? Наш СЕО Андрей Фролов проведет эфир с представителем российского ритейлера из отрасли спортивного питания, более 5 лет развивающих свой е-ком. Заглядывайте, будет интересно)
Кодеры, которые стали управленцами, на связи? Знаю много людей, начинавших свой путь как разработчики, а в последствии ушедших в продакты, управленцы или построивших свои компании. И добившихся определенных успехов. А я вам кто? Золотой пизды колпак, что ли? Но вопрос открыт, тяжело ли нам, выходцам из разработки, становиться управленцами? Тяжело как всем или по особенному?) Логично, что первый камень преткновения — долго не можешь выбить из башки желание залезть в код, пояснить как надо делать / как не надо и заняться микроменеджментом вместо управленческих решений. Дальше больше. Оказывается надо кого-то увольнять, решения страшные принимать. А если ты тимлид, выходец из той же команды где бывшие коллеги теперь подчиненные? — жесть. Но если говорить о более взрослых проблемах — это неумение или нежелание абстрагироваться от технологического слоя в пользу бизнесового. Оставаться технарем задротом, когда нужно быть ближе к бизнесу, ближе к деньгам и показателям. Деньги зачастую в простых технологиях и процессах. Низкоуровневых, о которых корешам айтишникам не похвалишься. Вижу как предприниматели от мира бизнесменов, могут построить Ит-бизнес без технологий и оно зарабатывает. А мы (технари) при всей своей умности и технологичности зачастую не можем банальный маркетинг выстроить, потому что «я вот сейчас доведу команду / продукт / сервис до нужного мне состояния, еще технологичность подкручу и тогда можно будет». Перфекционизм в перемешку с боязнью обосраться в Ит-поле. Банальное «да всем насрать!» иногда приводит в чувства, но потом снова легко заиграться в технаря. Сам себя ловлю и останавливаю — у тебя есть план Антон, придерживайся, не надо тебе сейчас стек в команде менять. Для тех, кто не в курсе про значение "Золотой пизды колпак": — "Золотой пизды колпак" или "невьебенный бабкин внук" или "большой хуй в мире животных" — о человеке, который себя возвышает над остальными.
В марте стукнуло 10 лет как мы зарегали оошку. Это число абсолютно ничего не значит, потому что зарегать оошку может каждый. А вот сделать из нее бизнес — нет. Прошло не мало лет, прежде чем компания начала превращаться в бизнес. Я бы оценил нас как трехлетку. Но мы не бездействовали, просто были слишком молоды и слишком «ремесленниками». Пахали всегда много, но часто не туда. Зато теперь прозрели и развиваемся системно 💪 как минимум так кажется сейчас, время покажет. Собрал список советов самому себе на следующие 10-лет, чтобы точно не сойти с ума: Планируй — бизнес это таблички. Финансовые, стратегические, маркетинговые все это планы в табличках. Без них можно, но потом не жалуйся. Изобретай — способы и процессы. Хер с ним, что все придумано, тебе не подойдет как есть, переваривай и делай по своему. Заимствуй — ну ты по сторонам то не забывай смотреть, зачем на пустом месте свой велосипед изобретать? Но тоже переваривай и делай по своему. Делай — хули сидишь? Каждый день по кирпичику. Немножко сделал и нормально, похвали себя и иди жить жизнь все офиса. рЕфлексируй — а то так и не поймешь на что 10 лет потратил. Живи — и кайфуй. От мелочей, от процессов, от людей, от собственных решений. На фото мы с партнером по металкоду Андрюхой, в пабе где пили когда были на 10 лет моложе. Куда и по сей день заглядываем) Я искренне не желаю делать этот пост про достижения или провалы. Пусть он будет юморной, как и я. Кто найдет посхалку, получит 100 рублей на телефон и банку клинского 😉 но возможно это..
Вопрос: нужно ли приставать к сотруднику со своими нравоучениями, если видишь, что он в рабочее время хуи пинает, но в целом тянет? На скрине кусочек переписки с товарищем тим-лидом. В разговоре я согласился, что можно забить на данное поведение, лишь бы работу свою выполнял. Но позже осознал, что меня ооочень сильно коробит от данного подхода. Только дисциплина, особенно на удаленке, позволит разработчику в долгосрочной перспективе выполнять свои задачки в срок, с должным качеством и всеми вытекающими. Один-два-три раза прокатит, что он гений, но проебщик (залетаю на 2 часа в день поработать и все успеваю), но на длинной дистанции — нет. Поэтому я, как отец тимлид, менеджер и прямой руководитель, не должен закрывать глаза, на то что дисциплина хромает. Наоборот стоит подсветить человеку, что все видно и так не надо — банально донести свое недовольство и ожидания. Иначе потом придется неприятные разговоры разговаривать, увольнять и вот это все. Можно получить в ответ "Хули ты докопался? Я же вырабатываю, все норм!" — а вот не все норм. Мы по культуре не сходимся. И вырабатываешь ты только пока, но в самый ответственный момент это дело нас подведет. Да, само собой человека не исправишь, если он изначально работает по таким принципам. Но зачем его вообще нанимать? — на испыталке надо успеть это прощупать. Увы, не всегда получается. А если это временная блажь, то можно попытаться пофиксить. PS проебаться можно, но это тоже надо уметь..
CoPilot в битрикс24 расшифровывает созвоны и при этом неистово нахваливает участников. Ну и в чем он не прав? 😅 Теперь я хочу такую встречу, где почти дошло до драки, чтобы потом посмотреть анализ.. А вообще эти анализы и расшифровки столько приколов выдают, каждый день новая галлюцинация. Хоть кому-нибудь пригодилось?
Надо научиться увольнять У каждого руководителя неизбежно наступает момент когда надо уволить сотрудника который «не тянет». Как и о много другом, тут легко только рассуждать. И нихуя не просто делать. От банального отсутствия полномочий у руководителя, те же тимлиды не всегда наделены правами увольнять разработчиков. До страхов «а кто будет делать вместо него, нужно заменять плавно, а бюджета на найм еще одного — нет», «Как же я его уволю, он ведь как родной, у него дети» и тд. И вот это пиздец, тянуть до последнего, когда внутри уже решил, что у сотрудника нет будущего в компании. Кому от этого будет лучше? Команду разработки, где все молодые и амбициозные однозначно надо строить по принципу увольнения. Не бояться расстаться с сотрудником, если он не подходит или перестал подходить — такое ведь тоже бывает, вы все выросли, задачи усложнились, а кто-то остался там же где был год-два назад. Увы. Ловушка в которую я попадал не раз — это тянуть чуваков и чувих, которые серединка на половинку: ответственный, всегда на связи, че то делает. Но при близком рассмотрении — это не тот уровень который тебе нужен. Ты день за днем закрываешь глаза на проблему, лишь бы не принимать сложное решение, не разговаривать неприятные разговоры. Но самое главное, что ресурс на обслуживание сотрудника в компании должен снижаться после онбординга в проекты и процессы. А именно такие ребята, всегда будут его тратить больше нормы — ресурсы тимлида, тестировщика и прочих коллег. Чтобы добиваться нормального качества от них нужно больше менеджмента, больше итераций код-ревью, больше тестирования. Зачем оно тебе? Ps нет, ты никому не искалечишь судьбу, если человек умный — он найдет свое место, а если дурак — его уже ждёт оффер х2 Pss само собой надо соблюдать трудовой кодекс. Тут главное принять решение, остальное формальности
Дать разработчику самому «добежать последнюю милю» Все руководители так или иначе решают вопрос самостоятельности сотрудников. Некоторые с этим справляются хорошо и спокойно ходят в отпуск, на больничный и даже на дачу без ноутбука ездят (это экстрим, честно). Некоторые становятся тимлидами / менеджерами / СТО единорогами, без которых ничего не работает и не решается — то есть справляются так себе. Зато чсв чешут. Но в туалет отойти не могут, чтобы что-то не разъебалось в их отсутствие. Честно говоря, я точно не в первой категории, но и из всех сил стараюсь не оказаться во второй. И вот один из важных принципов выращивания вдумчивых, самостоятельных технарей (и не только их): когда он или она приходят к тебе с вопросом по задаче — не приносить решение, а приносить мысль. Чтобы человек пошел, подумал, вернулся с кривым решением, ты его еще раз подтолкнул в нужном направлении и вот на второй-третьей-четвертой попытке будет то, что сгодится. Зато он сам понял как и зачем. А не получил всё на блюде) И это пипец как сложно, сдержаться от того, чтобы сразу выпалить решение — это же быстрее и сделано будет хорошо, и вообще одни плюсы. Кроме только того, что в следующий раз ты снова получишь подобный вопрос. А когда у тебя в подчинении не 1,2,5 а сильно больше людей — финита ля комедия. Будешь всегда на связи — спать с телефоном, есть с телефоном, мыться с телефоном.. дальше сами додумайте. Короче, растите своих крепких мидлов, на которых держится мир и не будете загнанной лошадью.
Кто такой Антон Носков? А нет такого чувства, что описывать самого себя это странно? Лучше бы пользы принес или шутку подкинул.. Особенно, если собираешься писать в канал «налегке», а потом три дня выдавливаешь новое описание себя. Поэтому очень кратко. В прошлом году я был тим-лидом разработки с амбициями СТО. В этом году я им и остался. Мне есть чему учиться на текущей позиции, так что ок. Писать буду о том, что вижу каждый день — про жизнь тим-лидскую, про процессы в небольшой команде разработки, где каждый воин, каждый машина (которая иногда ломается). Про код иногда. Поныть никогда — тоже иногда. Развернутое описание, что мы за команда и чем вообще занимаемся — есть, и оно пока норм. Этот пост нужен только лишь для выравнивания контекста. Го к шуткам. Заходит как-то тестировщик в бар..
Бизнес: нам нужны крутые разработчики, чтобы пилить нагруженные системы и интеграции Также бизнес: мозно мне курсор в виде сердечка? ❤️ Разработчики: :-|
В последний рабочий день провели общий созвон с командой, подвели итоги, рассказали о самых интересных задачах в этом году. 2024 год можно назвать для нас во многом определяющим: - нашли свою специализацию в развитии еком-систем; - сфокусировались на стэке php, битрикс; - собрали сильную команду разработчиков с фокусом на екоме; - поняли, что такое долгие проекты и как работать с клиентом годами; - построили понятные внутренние процессы; - начали строить отдел тестирования. Сила команды определяет всё! Именно в команде аккумулируется опыт, экспертиза, ответственность, качество решений. В новом году мы продолжим усиливать команду разработки, чтобы просто разработчик стал еком-разработчиком. Усилим наш маркетинг и пиар, будем доносить нашу экспертизу до нужных нам компаний. С наступающим, коллеги! 🎄🎄🎄
Маленький кусочек пятничной рефлексии (про трудности письма) Тем кто читал Мураками «О чем я говорю, когда говорю о беге» знакомы его сравнения написания текста с желчью, которая сжигает изнутри. Он пишет, что если бы не бегал, то написание книг убило бы его (а ежедневные пробежки позволяют выплескивать весь этот негатив. И пробежки у него серьезные — по 10км/ день, 300км/ месяц 😱). Не уверен, что имею право на подобные сравнения со своими «записками», но.. что-то в этом есть. Многократные переписывания, подбор выражений и форм, усилия мысли. Все это как будто жрет, если уж не меня, то время точно. Пишешь, потом переписываешь, потом думаешь, что налил воды и надо оставить только важное — переписываешь. Потом думаешь «ну сухо же!» и еще рерайт. При этом оно затягивает и хочется довести до точки, если не получается — можно и психануть. В итоге столько усилий, импульсивности и прочей суеты вокруг постика. Потом легкий мандраж, чтобы «отпустить» пост в канал. И в конце спрашиваешь себя, а не слишком ли много я думаю об этом?) При том что в большинстве случаев получается заурядно, завладеть чьим-то вниманием целое искусство, зачастую даже негатива никто не напишет. Проще говоря, вымученные, натужные тексты никому не нужны. Есть желание дать себе больше вольности и писать свободнее. Посмотрим, что из этого выйдет.
Приложил руку к краткой статье о том, как мы принимаем проект на поддержку. Наша поддержка – это про долгосрочное развитие проекта. Формирование команды, встраивание в процессы заказчика, квартальные планы. Но прежде чем это всё случится, надо принять проект и не облажаться ввязавшись в большой геморрой (который подается под видом интересного проекта, откуда по чистой случайности сбежал прошлый подрядчик). В статье простой список шагов, которые помогают нам въехать в проект и понять все ли с ним ок. А также подготовить инфраструктуру для старта работ. Вспоминаются времена лет эдак 10 назад, когда всё, что мог передать нам потенциальный заказчик по сайту – это доступ к хостингу (легко до подписания договора, а про NDA вообще никто не знал) и список задач в виде “Не работает интеграция с 1С” – бросает в холодный пот. Современный е-ком сильно сложнее. И чтобы принять проект – нужно попотеть) Читать на VC >>
Time & Material, квартальное планирование, долгие проекты, фокус на одном направлении - всё, что обеспечивает стабильность в работе. Рассказали в статье как отказались от проектной работы в пользу долгих проектов и научились встраиваться в процессы клиента Статья на VC>>