Николай Андреев | сайты для бизнеса

Как оценить стоимость разработки и почему “там же на пару часов” почти никогда не пара часов

Есть одна фраза, которую разработчики слышат регулярно: «Да там же вроде на пару часов работы». Обычно речь идёт о чём-то действительно небольшом с точки зрения клиента – добавить кнопку, новое поле в форме, поменять расчёт,
подключить интеграцию или чуть-чуть изменить существующий функционал.

И я прекрасно понимаю, откуда это берётся. Клиент видит конечное изменение – была одна кнопка, стало две. Логично предположить, что разработчик просто открыл нужный файл, дописал несколько строк, нажал «сохранить» и пошёл пить кофе. Было бы неплохо, конечно.

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

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

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

Особенно весело бывает с чужими или старыми проектами. Ты открываешь код с мыслью «сейчас быстренько посмотрю», а через час уже сидишь и пытаешься понять, почему изменение одного поля внезапно влияет на отчёт, уведомления и какую-то функцию, которую вообще писали пять лет назад. И главное – трогать страшно, потому что оно каким-то чудом до сих пор работает.

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

Конечно, бывают задачи реально на двадцать минут. Бывают на два часа, и оценка сразу попадает почти идеально. Но если разработчик сначала говорит, что ему нужно посмотреть проект и разобраться в связях, это обычно не попытка раздуть смету – он просто ещё не знает, насколько глубоко закопана та самая «маленькая кнопка».

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

ужно выписать процесс, который сегодня делает человек, посчитать потраченное время и посмотреть,

Боты в Telegram и MAX – полезный инструмент или очередная игрушка для бизнеса

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

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

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

Похожая логика работает и во внутренних системах компаний. Если руководителю или сотруднику регулярно нужно получать однотипную информацию, проверять статус задачи, смотреть данные по объекту или быстро отправлять результат работы, Telegram или MAX вполне могут стать удобным интерфейсом к основной системе. При этом сам бот ничего не «решает» отдельно – он просто даёт быстрый доступ к уже существующей логике CRM или ERP.

Есть и более приземлённый сценарий, который мы встречаем постоянно. Менеджеру каждый день пишут люди с одинаковыми вопросами, он уточняет несколько параметров, считает стоимость и потом переносит всё это в систему. Если этот сценарий почти не меняется, бот может собрать исходные данные сам, сделать расчёт по заданной формуле и передать менеджеру уже нормальную заявку, а не очередное «Здравствуйте, сколько стоит?».

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

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

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

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

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

Перед разработкой бота я бы вообще начинал не с Telegram, MAX или выбора очередного фреймворка. Сначала н

Почему автоматизация иногда выгоднее ещё одного сотрудника

Представим довольно обычную ситуацию – в компании растёт количество заказов, заявок или документов, а вместе с ними растёт и объём ручной работы. Сотрудник утром открывает таблицу, потом проверяет несколько чатов, переносит данные в другую таблицу, считает какие-то суммы, формирует отчёт и вечером понимает, что завтра всё повторится заново.

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

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

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

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

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

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

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

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

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

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

Есть проекты, в которых пока вообще нечего монетизировать, и именно поэтому они мне интересны

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

Сейчас на «Звездах Памяти» вообще нет коммерции. Там нет рекламы, платных свечей, подписок или каких-нибудь хитрых способов заставить человека оставить деньги. Возможно, когда-нибудь появятся дополнительные функции, которые помогут проекту существовать и развиваться, но сейчас задача совсем в другом.

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

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

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

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

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

«Звезды Памяти» пока именно такой проект. Я не знаю, какой именно он станет через несколько лет, сколько там будет людей и во что в итоге вырастут созвездия, которые мы сейчас только начинаем собирать. Но мне нравится, что сегодня его смысл можно объяснить без бизнес-модели, рекламного кабинета и расчета окупаемости – мы просто пытаемся сделать место, где память о людях не растворяется среди старых фотографий, переписок и забытых страниц.

Как я придумываю новые интернет-проекты и почему половина идей так и остаётся идеями

У меня новые проекты обычно появляются вообще не потому, что я специально сажусь вечером и начинаю «генерировать стартапы». Чаще всё происходит намного банальнее – сталкиваюсь с какой-нибудь неудобной штукой, вижу ручной процесс у клиента или замечаю проблему, которую почему-то все давно считают нормой. И почти автоматически появляется мысль: а ведь это можно как-нибудь автоматизировать.

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

Самая простая часть во всём этом – придумать саму идею. Намного сложнее потом ответить на неприятные вопросы: кому это реально нужно, готов ли кто-то за это платить, где искать первых пользователей и почему они вообще должны выбрать именно твой сервис. На этом месте часть прекрасных задумок начинает выглядеть уже гораздо скромнее.

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

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

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

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

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

Полмесяца блога – и вот что оказалось самым сложным

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

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

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

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

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

Ещё я заметил интересную штуку – постепенно становится проще рассказывать о собственной работе без попытки каждый раз изображать большую экспертную статью. Можно просто взять один реальный случай, объяснить, что произошло, рассказать своё мнение и закончить на этом. Мне такой формат даже нравится больше, потому что в нём остаётся нормальная жизнь, а не только правильные советы от человека с очень серьёзным лицом.

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

Как автотесты однажды снесли мне продовую базу

Есть ошибки, после которых ты просто исправляешь код и работаешь дальше. А есть такие, после которых внезапно появляются новые жизненные принципы, дополнительные серверы и лёгкая нервная реакция на слово «бэкап».
Одна такая история случилась у меня во время разработки delniki.ru. Проект тогда уже был живым – пользователи регистрировались, писали статьи, размещали объявления, загружали фотографии, и контента постепенно становилось довольно много. То есть это уже была совсем не пустая тестовая площадка, которую можно спокойно пересоздать за десять минут.

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

Мда, момент был довольно неприятный, потому что я прекрасно понимал масштаб произошедшего. VPS тогда использовалась недорогая, автоматических серверных бэкапов на ней не было, а мои локальные копии оказались довольно старыми. Git прекрасно спасает код, но пользовательские статьи и загруженные фотографии он, к сожалению, обратно из воздуха не достаёт.

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

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

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

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

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

SEO без магии: что реально работает для малого бизнеса

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

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

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

Отдельная история – локальный бизнес, потому что там запросы обычно намного конкретнее. Человеку редко нужен абстрактный подрядчик где-нибудь в России, ему нужен тот, кто работает именно в его городе или регионе. Поэтому запросы вроде «строительство домов в Тюмени», «ремонт квартир в районе» или «грузоперевозки по области» могут быть намного полезнее бизнеса, чем попытка воевать за какой-нибудь огромный общий запрос.

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

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

Поэтому обычная нормальная работа с сайтом уже может дать вполне заметный результат.

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

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

Наверное, самое важное здесь – перестать относиться к SEO как к разовой настройке, которую кто-то однажды сделал и забыл. Спрос меняется, конкуренты меняются, появляются новые услуги, новые страницы и новые вопросы клиентов, поэтому сайт приходится постепенно развивать вместе с этим. Зато даже простая системная работа часто даёт результат именно потому, что многие конкуренты не делают даже её.

Что я первым делом проверяю, когда ко мне приходит чужой сайт на аудит

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

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

Следом я всегда проверяю путь до заявки, потому что на хорошем оффере всё не заканчивается. Я смотрю, где находится кнопка, сколько шагов ведёт до формы, видно ли телефон и удобно ли написать с мобильного. Иногда сайт вроде бы выглядит прилично, но чтобы оставить заявку, человеку нужно пройти маленький квест.

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

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

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

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

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