Разработчик и деньги бизнеса: почему это меняет всё

Я понял, что что-то изменилось, когда перестал думать «сколько стоит моя работа» и начал думать «сколько стоит моя работа для этого бизнеса».

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

Разница в доходе заметная. В работе — ещё больше.

Исполнитель и owner: в чём реальная разница

Исполнитель отвечает на вопрос «как сделать». Owner — «зачем делать именно это».

На практике это выглядит так. Приходит задача: «Добавь на карточку товара кнопку "Купить в один клик"». Один разработчик смотрит в макет, пишет код, сдаёт. Другой спрашивает: «У нас 28 000 SKU и конверсия 2.1%. На каких страницах кнопка даст максимальный прирост?» Потом смотрит в Hotjar, видит, что 70% отказов — на мобильных при оформлении заказа, и предлагает сначала исправить форму, а не добавлять кнопку.

Это не умнее. Это другой вопрос в начале.

Разница между подходами невидима на спринте, но хорошо видна на квартале — и в позиционировании у клиента.

Ещё один признак: как реагируешь на неясность. Первый пишет в чат: «Уточни задачу». Второй смотрит, что уже есть, строит гипотезу, проверяет дешёвым путём и приносит решение с обоснованием. Гипотеза может не совпасть с ожиданиями клиента, но разговор уже другой.

Как выглядит бизнес-мышление в PHP-проекте

Несколько лет назад клиент пришёл с запросом: «Переписать Bitrix на современный стек. Бюджет $40K. Готовы начать через месяц».

Я мог сказать: «Отлично, подпишем контракт». Вместо этого я провёл три дня в prod-логах.

Оказалось, что магазин делает 40 SQL-запросов на страницу категории. Что LCP на мобильных устройствах 4.2 секунды. Что 68% трафика — мобильный. Что средний чек 3 200 рублей, а конверсия 2.1%.

Дальше посчитал: если переписать полностью, новая версия появится через 8-12 месяцев. За это время магазин продолжает работать на текущем стеке — с теми же проблемами. Если вместо этого оптимизировать запросы через Elasticsearch и перенести фронт на Next.js с Bitrix в качестве бэка, LCP падает до 1.4 секунды через 3 месяца. При мобильной конверсии +23% это конкретные деньги, которые магазин начинает зарабатывать сейчас, а не через год.

Я отказался от контракта и предложил другой проект. Клиент согласился.

Это и есть бизнес-мышление в PHP-проекте: не «как реализовать требование», а «какое решение даёт результат быстрее и дешевле».

Другой пример — фасеты в поиске. Клиент хотел «улучшить поиск», и первый вариант задачи звучал как «добавить фильтры по бренду и цене». Hotjar показал, что существующие фасеты занимают позиции с 14 по 37, а первые 13 — пустые. Цветовой фасет стоял на позиции 22, при том что по нему кликали менее 1% пользователей. Мы переставили фасеты по реальной частоте использования, добавили quick-filter chips над каталогом — и click rate по фильтрам вырос в 2.4 раза, а конверсия из каталога в корзину на 14%.

Задача была одна. Решение — другое. Потому что вопрос был другой.

Три разговора, которые я провёл иначе

Про рефакторинг. Раньше я говорил: «Нужно вынести логику в сервисный слой, иначе код станет неподдерживаемым». Клиент слышал: «Разработчик хочет поиграть с архитектурой». Теперь я говорю: «Сейчас каждая новая фича занимает 6 часов вместо 1, потому что логика перемешана с шаблонами. За квартал это примерно 60 часов лишней работы — около 180 000 рублей по текущей ставке». Разговор становится другим.

Про сроки. «Мы сделаем быстрее, если добавим ещё одного разработчика» — это исполнительская логика. «Критический путь сейчас — интеграция с 1С. Если мы не решим её за две недели, запуск сдвинется на месяц. Стоит ли нанять внешнего консультанта на 1С на неделю?» — это другой разговор. И другой результат.

Про приоритеты. Клиент хочет всё сразу. Я раньше молча расставлял их по своей логике. Теперь спрашиваю: «Что из этого напрямую влияет на выручку в следующем месяце?» Этот вопрос убирает половину бэклога без возражений.

Все три случая про одно: я понимаю, что важно для бизнеса, а не только для кода.

Минимум финансовой грамотности для разработчика

Не нужно быть финансистом. Нужно понимать три вещи — и их хватает.

Первое: на чём зарабатывает этот конкретный бизнес. Если это e-commerce, то средний чек × конверсия × количество сессий = выручка. Если улучшить конверсию на 1%, что это даёт в деньгах? Считается за минуту.

Второе: что стоит задержка. Проект, который опоздал на месяц, лишает бизнес месячного дохода от новой функции — или месячного дохода от магазина, который не открылся вовремя. Цифра конкретная.

Третье: технический долг в рублях, а не в метафорах. «Код плохой» — не аргумент. «Из-за этой архитектуры мы тратим 60 часов в квартал лишнего» — аргумент. Перевёл в деньги — разговор другой.

Это не MBA. Это навык, который отличает разработчика, с которым говорят о стратегии, от разработчика, которому просто передают задачи.

Практика: одно упражнение на следующей встрече

На следующей встрече с клиентом или в следующем планировании — спроси один вопрос: «Если мы это сделаем, что изменится для бизнеса через 90 дней?»

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

Не нужно становиться бизнес-консультантом. Нужно понимать контекст, в котором ты работаешь. Такой разработчик ценится иначе — и ставку выставляет иначе.

Разница между «сколько стоит моя работа» и «сколько стоит моя работа для этого бизнеса» — небольшая на уровне формулировки. На уровне карьеры и дохода — существенная.

Я отказался от $40K, потому что посчитал деньги клиента. Клиент подписал другой контракт. На меньшую сумму, но с лучшим результатом для него. И это именно тот разговор, в который я хочу попадать снова и снова.

→ Про то, как я закрываю риски, а не тикеты: Я перестал закрывать тикеты. Стал закрывать риски → Про технический долг в деньгах: Технический долг в деньгах: как я объясняю рефакторинг без слова «архитектура»