Почему senior-разработчики и бизнес не понимают друг друга

Знаете, что меня всегда удивляло?

Когда бизнес спрашивает у senior-разработчика: «Почему так долго?», а в ответ слышит что-то про архитектуру, технический долг и «сложность системы». И все — разговор закончился. Бизнес не понимает, разработчик не может объяснить, и оба остаются в своих окопах.

Две петли, которых не видит бизнес

Автор статьи предлагает интересную модель — две петли, которые существуют в любом бизнесе. Именно они определяют, как мыслит бизнес и как мыслит разработчик.

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

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

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

ДВЕ ПЕТЛИ БИЗНЕСА
──────────────────
Петля 1: Вывод на рынок          Петля 2: Поддержка сервиса
┌─────────────────────┐          ┌─────────────────────┐
│  Неопределённость   │          │     Сложность       │
│         ▼           │          │         ▼           │
│  → Скорость ▼       │          │  → Стабильность ▼   │
│    неопределённости │          │    системы          │
└─────────────────────┘          └─────────────────────┘
         │                               │
         └───────────┬───────────────────┘
                     ▼
         Бизнес работает ОБЕИМИ
         петлями одновременно

Почему senior-разработчик — это «избегатель»

Вот здесь становится интересно. Автор статьи выделяет два типа senior-разработчиков.

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

Второй тип — мои любимчики. Это те, кто постоянно спрашивает: «А нам это точно нужно? Может, пока обойдёмся? Давайте добавим потом, когда станет важно». Автор называет их «избегателями», «упростителями», «переработчиками». И знаете что? Это комплимент.

Потому что senior-разработчики, которые работают во второй петле — с реальными пользователями, с работающей системой — они боятся сложности. Не потому что они ленивые, а потому что они понимают, что сложность — это враг стабильности.

Отсюда и коммуникационный провал

Теперь вы видите проблему? Бизнес живет в первой петле — им нужна скорость, им нужны фичи, им нужно «быстрее». А senior-разработчик живет во второй петле — ему нужна стабильность, ему нужно «помедленнее».

Когда бизнес спрашивает: «Почему нельзя сделать быстрее?», разработчик отвечает: «Потому что система станет сложнее». И для бизнеса это звучит как оправдание. Как будто разработчик просто не хочет работать.

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

Но вместо этого получается: «Слишком сложно».

Почему AI раскалывает разработчиков

Автор статьи приводит интересный пример — реакция на заявления про AI. Помните, когда начали говорить, что AI заменит разработчиков? Так вот, среди senior-разработчиков мнения разделились.

Те, кто работает в первой петле — делает прототипы, экспериментирует, выводит на рынок — они видят: да, AI реально ускоряет разработку. И думают: «Да, нас скоро заменят».

Те, кто работает во второй петле — поддерживает продакшн, думает о долгосрочной стабильности — они видят: AI может сгенерировать код, но кто будет поддерживать этот код через два года? Кто будет разбираться в тысячах сгенерированных файлов?

Они оба правы. Просто они смотрят на разные петли.

Что с этим делать

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

Когда мы запускаем новый продукт — это первая петля, тут нужна скорость, можно экспериментировать, можно писать быстро и грязно.

Когда продукт уже работает и приносит деньги — это вторая петля, тут нужна стабильность, и «быстро» уже не значит «хорошо».

Вместо «это слишком сложно» можно говорить: «Сейчас в системе 50 интеграций. Если добавим ещё одну, время на поиск проблем вырастет на 30%. Это риск для клиентов, которые платят нам каждый месяц».

Вместо «нам нужен рефакторинг» можно говорить: «Сейчас добавление новой фичи занимает две недели. После рефакторинга — три дня. Инвестиция окупится за три месяца».

Это не про то, чтобы «говорить на языке бизнеса». Это про то, чтобы показывать последствия. Бизнес понимает риски для клиентов. Бизнес понимает деньги. Senior-разработчики просто должны связать технические решения с этими вещами.

Вместо вывода

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

Оказалось, мы просто в разных петлях.

И знаете что? Лучший senior-разработчик — это не тот, кто знает все технологии. Это тот, кто умеет переключаться между петлями и объяснять, почему в одной ситуации нужно ускоряться, а в другой — тормозить.

Это сложный навык. Но без него никакие технологии не спасут.

Ссылки

• Статья «Why senior developers fail to communicate their expertise» на nair.sh — оригинальная статья, вдохновившая этот материал