На чём нельзя экономить при создании сайта: как я обсуждаю сокращение бюджета

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

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

Сначала выясняю задачу, потом считаю работу

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

Клиент может не разбираться в разработке. Это нормально. Для того он и пришёл к специалисту. Моя работа — объяснить, предложить разумный вариант, иногда поправить первоначальную идею.

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

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

Адаптивность у меня входит в работу по умолчанию

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

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

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

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

Подготовка изображений — тоже работа

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

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

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

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

Текст обсуждаю через содержание, а не через торг за знаки

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

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

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

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

С чужими сайтами тоже сначала разбираюсь

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

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

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

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