Владеть продуктом, а не только разрабатывать его: три момента, когда я это понял

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

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

Как я работал первые несколько лет

Был хороший разработчик в чужом проекте. Я делал то, что написано в задаче, — и делал хорошо. Тесты, документация, PR без замечаний. Коллеги говорили: надёжный. Клиент был доволен. Казалось, вот как надо работать.

Один раз я добавил форму обратной связи на страницу каталога. Техническое задание выполнил точно. Форма отправляла письма — проверил. Нигде не ломалась — проверил. Сдал в срок.

Через два месяца оказалось: из 400 заявок 380 пришли от ботов. Клиент потерял деньги на обработку, отдел продаж потратил неделю на разбор мусора. Форму закрыли.

Я сделал всё правильно. Тикет закрыт. Проблема не решена.

Момент первый: задача сделана, проблема осталась

Та история с формой меня задела не потому, что я был виноват. Я не был. Никто не сказал «поставь защиту от спама». Я сделал то, что написали.

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

Форма — это интерфейс между бизнесом и пользователями. Я смотрел на неё как на HTML и PHP. Клиент смотрел на неё как на воронку продаж. Мы говорили про разные вещи и не знали об этом.

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

Момент второй: клиент всегда прав — пока проект не ломается

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

На стадии анализа я увидел: 70% пользователей делают ровно один заказ и не возвращаются. Программа лояльности для такой аудитории экономически не работает — нет базы для накопления. Я сказал об этом.

Клиент сказал: нам нужна программа лояльности. Мы строили её для тех, кто вернётся. Я кивнул и сделал.

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

Я сделал всё по ТЗ. Знал, что это плохая идея. Промолчал после первого отказа.

Хороший технический исполнитель говорит один раз — и если ему говорят «нет», кивает и делает. Owner говорит один раз, получает «нет» — и возвращается с другими данными, не с теми же словами. Потому что он несёт ответственность за исход, а не за выполнение инструкции.

Разница не в том, что он умнее. Разница в том, что ему небезразлично, чем кончится.

Момент третий: я отказался от контракта

Третий момент — уже как самостоятельный инженер. Клиент пришёл с запросом переписать Bitrix-магазин с нуля. Бюджет $40 000, сроки полгода. Команда была готова взяться.

Я провёл предпроектный аудит. Нашёл реальную проблему: не архитектура, а 40 SQL-запросов на одну страницу каталога и отключённый кэш. LCP 4.2 секунды. Не потому что Bitrix плохой — потому что три года никто не смотрел в профайлер.

Переписать с нуля за полгода — значит потратить $40K, получить новый долг вместо старого, и через год снова прийти с тем же запросом. Я это увидел и отказался от контракта.

Не потому что не хотел денег. Потому что деньги за заведомо неправильное решение — это не работа, это обман.

Подробнее об этом кейсе я писал отдельно — там про цифры и что мы в итоге сделали. Здесь меня интересует другое: откуда вообще взялась возможность так решить?

Возможность появилась из двух предыдущих опытов. Я знал: задача может быть выполнена правильно — и всё равно привести к потере. Поэтому я смотрел не на задачу, а на систему. И увидел не «переписать Bitrix», а «клиент хочет, чтобы магазин не тормозил». Это разные задачи.

Что изменилось — и что стало сложнее

После трёх этих моментов работать стало и лучше, и тяжелее.

Лучше: я реже делаю правильно по форме и неправильно по сути. Я задаю неудобные вопросы до старта, а не после. Клиенты иногда злятся — но потом говорят спасибо.

Тяжелее: ответственность за результат — это физически больше, чем ответственность за тикет. Когда ты думаешь как owner, то не можешь «просто сдать» то, что знаешь не работает. Это требует энергии, иногда — конфликта. Не все клиенты готовы к такому подрядчику.

Зато легко фильтруются те, кто не готов: они уходят сами.

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

Три вопроса перед каждым проектом

Я ввёл простую практику. Перед тем как взяться за проект — три вопроса:

Первое: что произойдёт, когда это начнёт работать? Не «как это работает», а что изменится в жизни клиента через три месяца после запуска.

Второе: что не входит в ТЗ, но сломает результат? Формы без спам-защиты. Программа лояльности без возвратной аудитории. Переписанный магазин с теми же запросами в базу.

Третье: готов ли я отказаться, если увижу, что это не то решение? Это вопрос про честность — с клиентом и с собой.

Три вопроса — это не методология и не фреймворк. Это просто привычка смотреть чуть дальше конца задачи.

Быть owner-ом — не значит знать лучше клиента, что ему нужно. Значит не соглашаться делать то, что точно не сработает. Это не высокомерие. Это профессиональная честность — такая же, как у хирурга, который объясняет риски операции, а не просто делает то, что просят.

Закрывать риски, а не тикеты — я писал про это отдельно как про инструмент. Три момента выше — про то, как я пришёл к тому, чтобы вообще смотреть на работу так.