От переводчика: перед вами — перевод статьи Тухина Наира «Why Senior Developers Fail to Communicate Their Expertise». Автор раскрывает кажущееся противоречие двух главных задач бизнеса — быстро выводить новые фичи на рынок и обеспечивать бесперебойную работу ИТ-продукта. Он описывает вызовы, с которыми в такой системе сталкивается senior-разработчик, и определяет стратегию, с помощью которой разработчик может одновременно решать обе этих задачи. Передаём слово автору.

Что вы скажете о следующем утверждении?

«Будущее разработки ПО — за ИИ-агентами. Нам больше не нужны разработчики, которые тормозят развитие бизнеса»

Если вы сеньор и согласны с этим, я начинаю сомневаться в вашей компетентности (потом объясню почему; тут нет никакой враждебности). Но если вы не сеньор и согласны с этим, то, думаю, вы, скорее всего, правы. Что? Как так? Суть копирайтинга в том, чтобы донести идею до конкретной аудитории. Поэтому для меня, как копирайтера, происходящее очевидно: одно и то же послание всеми воспринимается по-разному.

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

Но минуточку! Многие заслуженные и знаменитые разработчики тоже провозглашают смерть своей профессии. Как же так? Чья интуиция тут права? И в чём причина такого противоречия?

Задача сеньора — избегать проблем

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

• «Я тут новый прикольный инструмент нашёл…»
• «А вот в компании <название компании, не имеющей с нашей ничего общего> делают вот так, так что…»
• «Гляньте пост, там пишут, что это — лучшая практика, нам бы тоже стоило…»

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

А есть и другой тип сеньора:

• «Нам это правда нужно?»
• «А что, если этого не делать?»
• «Может, пока так оставим? Вернёмся к этому позже, когда прижмёт?»

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

Почему? Потому что в профессиональной разработке они ведут охоту на главного монстра — сложность. Особые случаи, if-условия, новые таблицы в БД, новые компоненты — всё это ужасно. Сеньор стремится к минимуму всего этого, кучу времени думая о том, действительно ли новый код так нужен. Ведь добавлять что-то в систему — значит усложнять её.

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

Бизнес боится неопределённости

Давайте для простоты представим бизнес в виде двух циклов.

Вот первый цикл; здесь живут маркетологи, продажники, продакт-менеджеры, гендиректор:

Главная цель этого цикла — пробовать и учиться. Бизнес стремится выводить продукты на рынок, чтобы получить фидбэк и понять, представляют ли они какую-либо ценность.

Для людей в этом цикле главный монстр — неопределённость. Неопределённость жестока, ведь ни одна стратегия не даёт гарантий. Если добавить сюда фактор времени (зарплаты маркетологов/продажников, фонд оплаты труда основателей или данные для продактов), начинает казаться, что единственный способ победить неопределённость до дедлайна — это выкатывать всё на рынок как можно быстрее. Чем больше ты выводишь на рынок, тем больше получаешь обратной связи, тем сильнее (в теории) снижаешь неопределённость.

Этот цикл (все компании с него начинают) — это про скорость в чистом виде.

Но что происходит, когда у бизнеса появляются клиенты?

Сеньорам крайне важна стабильность

Обратите внимание на второй цикл. Клиенты платят за сервис.

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

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

А что ставит всё это под угрозу? Сложность. Из-за неё система становится менее понятной, её тяжелее отлаживать, чинить и объяснять, и в итоге она становится менее стабильной. Растёт сложность = падает стабильность = сеньор не справляется со своими обязанностями = всем плохо, платежи не проходят, все грустят.

Итак, если цель первого цикла — уменьшить неопределённость, то цель второго — совладать со сложностью.

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

Окей, теперь вы, наверное, догадываетесь, к какому ответу на заглавный вопрос я веду.

В зависимости от того, в каком цикле вы работаете, ваша проблема видится под разными углами (вот почему, на мой взгляд, разработчики так по-разному смотрят на ИИ: одни больше задействованы в первом цикле, другие — во втором).

Вот как выглядит история для людей из первого цикла:

А вот как выглядит история для сеньора из второго цикла:

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

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

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

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

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

• Нужно провести опрос? Для этого есть Google Forms.
• Нужно запилить новую фичу, чтобы проверить гипотезу? А что, если просто добавить кнопку в существующий интерфейс и посмотреть, кликают ли на неё?
• Нужен новый сервис аналитики? А для какого такого важного решения эта аналитика нам нужна? Может, начнём с одного решения, одного графика и одной метрики?
• Зачем печь огромный торт? Просто воткни свечку в мой бутерброд!

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

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

Может, попробуем какой-нибудь способ побыстрее?

Слово «побыстрее» показывает, что вы понимаете их главный запрос; «какой-нибудь» намекает, что есть другой путь; «попробуем» предполагает, что решение может быть неидеальным, но вполне рабочим. Эта фраза идеально попадает в потребность бизнеса (скорость для снижения неопределённости) и в то же время оставляет сеньору пространство для манёвра: сократить, переиспользовать, а в лучшем случае — вообще ничего не делать.

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

Но! Есть огромное «но»! Кажется, что с приходом ИИ всё это теряет смысл, верно? Зачем что-то урезать? Зачем переиспользовать? Зачем избегать? Ведь ИИ может написать кучу всего за минимальное время. Однако он пока не умеет делать то, что по-прежнему делают сеньоры. Нести ответственность.

Почему сеньоры — это редакторы, а не писатели

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

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

Так изначально выглядят два бизнес-контура:

А вот как ИИ на них влияет:

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

К счастью, у сеньоров есть пара козырей в рукаве. Один из них — decoupling (разделение). Долгое время только разработчики могли создавать софт. И они отвечали сразу за оба контура.

Одна система на две цели.

А что, если у нас будут две системы, каждая для своей цели?

Аналогия: писатель торопится закончить первый черновик (его ещё называют «черновик потока сознания» — vomit draft), а потом выбирает из него то, что работает, и выбрасывает остальное. После быстрого набрасывания текста идёт редактура. Работа редактора — взять удачные куски и собрать из них что-то цельное.

Что, если сделать одну систему чисто для скорости? В ней бы работали все, кто отвечает за быстрый запуск идей: ИИ-агенты, наш собственный сгенерированный код без ревью, джуны, маркетинг и так далее. Назовём её Speed-версией системы. Она не должна быть прозрачной, её задача — сделать «достаточно хорошо», чтобы выкатить на рынок и собрать фидбэк.

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

Speed-версия позволяет бизнесу быстро учиться на реакции рынка, пока сеньоры не спеша строят «чистовую» версию системы — выверенную и понятную. К тому же дизайн Scale-версии напрямую зависит от того, какие решения из Speed-версии оказались удачными, а какие — нет.

Фичи создаются в Speed-версии, а затем доводятся до стабильного состояния в Scale-версии.

Как это будет выглядеть на практике, может быть, не до конца ясно, но основная идея состоит в том, чтобы добиться чётко оговорённого разделения (decoupling), которое покажет: одно дело — гнаться за скоростью, и совсем другое — обеспечивать стабильность.

Представьте, что вас просят запилить нечто амбициозное, и вы отвечаете: «Без проблем, Speed-версия будет готова через 3 дня, Scale-версия — недель через 6». Они получают желаемое — скорость и движение вперёд. Вы получаете желаемое — время на изучение и проектирование. Как вам? Что скажете, сеньор-разработчики? Или мне стоит называть вас сеньор-редакторами?