Я предпринимаю в IT

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

Я бы смотрел не только на дизайн и тексты. Для нормального аудита сайта нужно пройти весь путь пользователя и проверить: - Как быстро открывается первый экран на мобильном. - Что является самым тяжёлым элементом страницы. - Есть ли лишние скрипты, виджеты, пиксели, чаты, карты. - Прыгают ли блоки при загрузке. - Как сайт реагирует на клики и ввод данных. - Удобно ли пользоваться меню, каталогом, фильтрами и формами. - Нет ли проблем в корзине, checkout или заявке. - Что происходит на слабом интернете и не самом новом телефоне. - Какие страницы реально участвуют в продажах. Как изменения потом измерять: конверсия, заявки, отказы, глубина, скорость, Core Web Vitals...

И это не потому, что менеджеры стали не нужны. Просто покупатель изменился. По данным Gartner, 67% B2B-покупателей предпочитают rep-free experience — то есть возможность разобраться в продукте самостоятельно, без обязательного первого созвона с продавцом. Особенно если продукт сложный: промышленное оборудование, IT-система, интеграция, сервисная услуга, инженерное решение. Клиенту не всегда хочется сразу попадать в воронку продаж. Сначала он хочет спокойно понять: — что вы вообще делаете; — для каких задач подходите; — какие есть ограничения; — есть ли опыт в похожих проектах; — как устроен процесс; — сколько примерно это может стоить; — с кем потом обсуждать технические детали...

И это была очень полезная встреча. Обсуждали не какие-то абстрактные “продажи ради продаж”, а вполне практичные вещи: - как не ломать процесс пресейла; - почему не стоит сразу кидаться в оценку и КП; - как правильно вытаскивать клиента на встречу; - какие вопросы задавать, чтобы понять реальную потребность; - почему созвон часто важнее длинной переписки; - и как не превращать продажу в угадайку. После разговора я буквально сразу провёл три встречи — и поймал себя на мысли, что часть советов уже начал применять вживую...

К нам приходила клиника на SEO-сопровождение. Ответили, обсудили, посчитали. А потом клиент тихо ушёл — видимо, выбрали кого-то другого. Пока разбирался, что можно было сделать лучше, наткнулся на интересную штуку. В медицинских сайтах самое частое узкое место - не SEO-позиции, а конверсия страницы услуги в заявку. Цифры: - Средний медицинский сайт конвертит трафик в заявку на 2–5% (Tebra, First Page Sage). - Сокращение лид-формы с 7 полей до 3 поднимает конверсию формы с ~11% до ~23% - в 2 раза (исследование форм 2026, digitalapplied.com, агрегат 100+ источников). То есть на одном и том же трафике из SEO и контекста потенциал роста заявок чаще лежит внутри сайта, а не в выдаче...

В разработке есть два очень разных типа денег. Первые — проектные. Клиент пришёл, заказал сайт, приложение, личный кабинет, интеграцию, MVP, AR, автоматизацию. Да что угодно. Команда оценила, продала, сделала, сдала. Деньги вроде даже иногда есть, когда проект большой и все сделано хорошо. Но есть проблема: каждый месяц (квартал, год) начинается почти с нуля. Нужно снова искать лиды. Снова продавать. Снова проходить пресейл. Снова ждать предоплату. Снова надеяться, что клиент не передумает, не уйдёт «подумать», не заморозит бюджет. И агентство вроде работает, проекты вроде есть, команда занята — но внутри постоянное ощущение нехватки воздуха...

Есть тонкая грань между «я помогаю человеку сделать работу хорошо» и «я не даю ему нормально работать». Руководитель может думать, что он заботится о результате — проверяет, уточняет, напоминает, просит показать промежуточный статус. А сотрудник в этот момент может чувствовать совсем другое — «мне не доверяют», «за мной следят», «я не могу сделать шаг без согласования». И вот тут начинается конфликт. Пример первый. Задача новая, сложная, с высоким риском. Руководитель чаще спрашивает статус, смотрит промежуточные версии, помогает принять решение. Это не микроменеджмент. Это нормальное сопровождение...

? Сижу и думаю — ИИ уже пишет код, рисует дизайн, собирает интерфейсы, помогает тестировать, генерирует тексты, делает прототипы. И невольно возникает тревожный вопрос, а что будет с заказной разработкой? Моё ощущение, что заказная разработка не умрёт. Но умрёт старая модель, где компания просто продавала "руки программистов" и часы написания кода. Потому что код действительно дешевеет. Типовые лендинги, простые сайты, CRUD-админки, первые дизайн-макеты, базовые прототипы — всё это будет всё чаще собираться быстрее, дешевле и частично без классической команды разработки. Но бизнесу на самом деле нужен не просто код...

На собеседовании с разработчиком всплыла фраза, мимо которой я бы три года назад прошёл, а сейчас зацепился: «к Битриксу же MCP уже подключается». Сказано было между делом. И вот именно эта будничность — самое интересное. Что такое MCP, если коротко MCP (Model Context Protocol) — это стандарт от Anthropic (того самого, что делает Claude), описывающий, как ИИ-ассистент получает доступ не только к своей «памяти», а к живому контексту проекта: репозиторию, документации, базе данных, дизайну в Figma, задачам в Jira, браузеру, CRM. Грубо говоря, раньше ИИ писал код «по памяти и догадкам», а с MCP — по реальной документации и API конкретного проекта...

Каждый раз, когда я открываю чужой (или свой годовалой давности) проект, рука тянется сказать: «да тут проще переписать с нуля». Это почти всегда ловушка. Перепись — это месяцы без новых фич, риск всё сломать и потеря того опыта, что уже зашит в код в виде багфиксов и костылей, про которые ты уже не помнишь, зачем они там. Но иногда переписывать действительно надо. Чтобы не угадывать, я гоняю задачу через 3 вопроса. 1. Что именно болит — код или моё к нему отношение? Если код просто «некрасивый», «не модный», «не на том фреймворке» — это не повод. Это повод сходить выспаться. Если болит конкретно,...

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

В агентском бизнесе есть вечный конфликт. С одной стороны, нужно показывать кейсы. Без них сложно продавать, доказывать экспертизу и объяснять, чем ты отличаешься от других подрядчиков. С другой стороны, почти в каждом нормальном проекте есть конфиденциальность. Данные клиента. Внутренние процессы. Коммерческие показатели. Архитектура. Интеграции. Проблемы, которые клиент не хочет выносить наружу. И тут важно не превращать кейс в слив чужой кухни. На мой взгляд, базовое правило простое: ВСЕГДА нужно согласование. Даже если формально NDA нет. Даже если «мы же ничего страшного не написали»...