Эмпатия в инженерном лидерстве: уроки Sarah Drasner

Проблема: команда растет, а понимание кода падает

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

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

С генерацией кода проблема проявляется быстрее. ИИ действительно может дать рабочий результат за минуты, но читабельность для человека часто страдает: лишние абстракции, разные стили в соседних файлах, комментарии ради комментариев, и главное - нет объяснения «почему так». В vibe-coding сценариях, когда фичи собираются через чат, скорость легко обгоняет ясность, если заранее не договориться о правилах.

Обычно нехватка ясности видна по симптомам:

• в ревью обсуждают стиль и догадки, а не смысл и риски;
• «не трогай этот код» становится нормой даже для критичных частей;
• онбординг превращается в квест, и новички зависят от одного-двух «знающих»;
• баги повторяются в одних и тех же местах после мелких правок;
• в спринтах копятся «технические хвосты», которые никто не берется оценить.

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

Developer empathy на практике: что это в работе лидера

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

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

Полезная проверка: «Сможет ли средний разработчик в команде безопасно внести правку в это место через две недели?» Если ответ «нет», эмпатичный лидер не ругает людей. Он меняет условия.

На практике это проявляется в небольших, но регулярных действиях: вы задаете рамки задачи (что точно важно, а что можно отложить), просите простые объяснения без «магии», убираете лишние согласования, но не отпускаете контроль рисков. И фиксируете договоренности письменно, чтобы их не приходилось держать в голове.

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

Есть сигналы от разработчиков, которые лучше не игнорировать, даже если формально задачи закрываются:

• вопросы повторяются, потому что ответ нигде не закреплен;
• люди избегают «опасных» модулей и просят «пусть автор сделает сам»;
• в ревью спорят не о сути, а о догадках: «я думаю, тут так задумано»;
• исправления занимают больше времени, чем новая функциональность.

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

Коммуникация, которая масштабируется, а не шумит

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

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

Вопросы тоже важно задавать правильно. Цель не «поймать ошибку», а быстрее найти корень. Хорошо работают вопросы про наблюдения и границы: что именно видим, где и с какого момента, что изменилось перед этим; что уже исключили, какие допущения делаем, что считаем нормальным результатом.

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

Удобный формат короткого статуса (в чате или в таске) выглядит так: контекст (1-2 предложения), прогресс (что сделано и что проверено), риск, следующий шаг с владельцем, и один конкретный запрос о помощи.

Пример: «Генерируем экран авторизации в TakProsto и приводим к единому стилю. Проверил валидацию и тексты ошибок. Риск: разные требования к полям у веба и мобайла. Следующий шаг: согласовать поля и обновить промпт, владелец - я. Нужна помощь: подтвердите обязательность номера телефона».

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

Документация работает, когда вы относитесь к ней как к продукту: у нее есть пользователь (ваша команда), сценарий (быстро понять и сделать), и цена ошибки (потерянные часы на вопросы и ревью). Это прямая часть эмпатии: вы заранее снимаете боль людей, которые еще не знают контекст.

Обычно не читают длинные «вики обо всем», манифесты и списки правил без примеров. Читают то, что помогает выполнить задачу сегодня: запустить проект, понять решение, исправить инцидент, сделать правку в одном модуле.

Минимальный набор, который почти всегда окупается:

• README проекта: что это, как запустить локально, где смотреть логи, как прогнать тесты.
• ADR (Architecture Decision Record): короткая заметка о важном решении и почему так сделали.
• Гайд по стилю: соглашения по именам, структуре папок, ошибкам, логированию (с примерами).
• Runbook: «если случилось X, делай Y» для дежурства и типовых сбоев.

Чтобы новый человек понял за 15 минут, пишите от задачи к результату. Сначала ответ на вопрос «что я получу после этих шагов?», затем самый короткий путь, и только потом детали. Хорошее правило: одна страница - одна задача. Страница, которая пытается научить всему, обычно закрывается после первого абзаца.

Темы лучше разносить по отдельным страницам: как поднять окружение и проверить, что все работает; как добавить эндпоинт или экран по шаблону; как обновить зависимость без поломки сборки; как катить релиз и как откатить назад; как оформлять изменения, если часть кода сгенерирована ИИ (что комментировать и где).

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

Обучение и онбординг: быстрее, чем нанимать еще людей

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

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

Форматы, которые реально передают знания

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

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

Чтобы не перегружать сильных разработчиков, менторство лучше делать ролью, а не подвигом. Помогает простое ограничение по времени (например, 2-3 часа в неделю), единая очередь вопросов и правило: ментор объясняет один раз, а затем добавляет знание в заметку или шаблон, чтобы следующий раз был быстрее. Так вы выращиваете новых менторов: вчерашний новичок через месяц уже ведет мини-лекцию по своему участку.

Как понять, что это работает

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

Если вы используете TakProsto для быстрого прототипирования, добавьте в онбординг отдельный блок: как читать и править сгенерированный код, где искать ключевую логику и какие части обязательно перепроверять руками. Тогда скорость растет без потери понимания.

Плейбук: как делать ИИ-сгенерированный код понятным людям

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

До генерации: договоритесь о правилах

Если задать стандарты читаемости до того, как просить модель писать код, половина хаоса исчезает.

• Одна фича - один небольшой PR, без правок «заодно».
• Ясные имена: не data2, а userProfile, не handle, а saveDraft.
• Один модуль - одна ответственность: хранение данных, UI, интеграции, но не все сразу.
• Явные входы и выходы: что функция принимает и что гарантирует.
• Ошибки и крайние случаи описаны сразу, не «потом разберемся».

Во время генерации: требуйте объяснений, а не только код

Попросите ИИ сначала описать архитектуру в 5-7 предложениях: какие компоненты будут, кто за что отвечает, где границы. Затем - пример использования: как вызывается модуль, какие параметры ожидаются, что возвращается. Если объяснение туманное, код почти всегда будет таким же.

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

И обязательно требуйте тесты. Минимум - один тест на «счастливый путь» и один на пограничный случай. Пограничный случай лучше выбрать заранее самим: пустой ввод, нулевое значение, недоступный сервис.

Последний шаг - документация в том же PR. Даже короткая заметка «как запускать» и «как расширять» окупится.

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

Ревью и контроль качества: правила для ИИ и людей

Ревью ломается, когда превращается во вкусовщину или чтение чужих мыслей. Если в коде есть ИИ-фрагменты (например, сгенерированные в TakProsto), важнее всего одно: команда должна понимать, что именно сделано и почему.

Начните с «ворот качества», которые не обсуждаются в каждом PR. Они снимают большую часть споров еще до ревью и делают ожидания прозрачными:

• автоформатирование и линтеры, одинаковые для всех репозиториев;
• минимальный набор тестов (юнит и хотя бы один интеграционный на критичный путь);
• проверка типизации или сборки (React, Go, Flutter - по проекту);
• политика по секретам и конфигам (ничего чувствительного в коде и логах);
• лимит на размер PR (большое изменение делить на шаги).

Дальше включается человеческая часть. Хорошее ревью не «ищет ошибки», а проверяет понимание и поддерживаемость. Это особенно важно там, где ИИ мог сгенерировать правдоподобный, но хрупкий код.

Полезные вопросы к автору (и к ИИ-частям) простые:

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

Если никто не понимает реализацию, это не «провал автора», а сигнал процесса. В таком случае лучше остановить мердж и попросить переписать с упором на ясность или сделать короткий прототип с тестами и пояснениями. Часто лучший ход - заменить «умное» решение на скучное, но очевидное.

Спорные моменты фиксируйте коротким ADR: проблема, варианты, решение, последствия. Один экран текста может сэкономить недели повторных обсуждений и ускорить вход новых людей.

Типичные ошибки, которые ломают доверие и скорость

Команда «тормозит» чаще не из-за технологий, а из-за ощущения непредсказуемости. Если сегодня код можно понять за 10 минут, а завтра за час, доверие к процессу падает, а вместе с ним и скорость.

Первая ловушка - принимать ИИ-генерацию как готовый ответ. Когда результат не читают и не уточняют, в коде остаются скрытые допущения: странные имена, лишние слои, неочевидные зависимости. Потом это превращается в загадки на ревью и в баги в проде. Особенно больно, когда генерация затрагивает и фронтенд, и бэкенд: вроде бы «работает», но никто не может объяснить почему.

Вторая ошибка - мешать в одном PR все подряд. Фича, рефакторинг и «заодно почистил» создают туман. Ревьюер не понимает, что проверять: поведение, архитектуру или стиль. В итоге он либо пропускает важное, либо начинает спорить по мелочам. Оба варианта убивают темп.

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

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

Пятая - учить только новичков. Мидлам и сеньорам тоже нужен рост: новые паттерны, договоренности по ИИ, навык объяснять решения. Иначе они становятся узким горлом.

Чтобы не скатываться в это, помогают простые привычки: делать PR с одной целью и понятным описанием «что меняется и зачем»; просить автора коротко объяснить ключевое решение словами, особенно если код сгенерирован; фиксировать стиль и подходы в живом документе и обновлять его после спорных ревью; писать минимальные заметки сразу (как запускать, где точки входа, какие ограничения); планировать обучение для всех уровней: разборы реальных PR, короткие внутренние лекции, парное программирование.

Простой пример: команда делает React-интерфейс и Go-сервис, часть кода генерируют в TakProsto. Один большой PR «добавил оплату и чуть почистил» проходит со скрипом, а через неделю никто не может быстро найти, где именно проверяется лимит. После пары таких случаев люди начинают бояться менять систему. Исправляется это не героизмом, а ясными маленькими шагами и привычкой объяснять решения человеку, а не только машине.

Быстрые проверки перед мерджем: чеклист понятности

Перед Merge полезно проверить не только «работает ли», но и «поймет ли это человек». Понятность - это скорость команды через неделю и через три месяца.

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

• Сформулирована ли цель изменения одним предложением в описании PR (что стало лучше и для кого)?
• Понятно ли, где ответственность: какой модуль затронут, какие границы у изменений (что намеренно не трогали)?
• Есть ли быстрый способ проверить поведение: тест, простой сценарий запуска или ожидаемый результат в двух строках?
• Обновлены ли заметки: README, гайд или короткое пояснение решения, если добавлен новый подход или настройка?
• Сможет ли новый разработчик за 10 минут объяснить, что делает код, где вход и выход, и почему так сделано?

Чтобы пункт про «10 минут» не был абстракцией, используйте мини-проверку: автор PR просит коллегу, который не трогал модуль, вслух пересказать логику по файлам. Если коллега путается, чаще всего не хватает имен, комментария к нетривиальному месту или короткого примера.

Для ИИ-сгенерированного кода полезно «приземлять» изменения сразу: переименовать сущности на доменные слова, удалить лишние обертки и оставить один абзац объяснения рядом с самым хитрым куском. В TakProsto это проще делать сразу после генерации, пока контекст в чате свежий.

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

Реалистичный пример: как команда теряет и возвращает ясность

Команда из 6 человек делала внутренний сервис: React на фронте, Go и PostgreSQL на бэкенде. Чтобы ускориться, они подключили генерацию через чат (в том числе в TakProsto) и за первую неделю закрыли много задач: формы, CRUD, интеграции, базовую авторизацию.

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

Поворотным моментом стал инцидент: мелкий фикс валидации сломал обработку ошибок, и откат занял полдня. После этого лидер договорился не про запреты, а про правила, которые делают код объяснимым.

Что они поменяли:

• любой ИИ-сгенерированный блок сопровождается коротким объяснением: что делает и почему так;
• PR стали маленькими: один смысл, один модуль, без смешивания рефакторинга и фич;
• в описании PR добавили секцию «Проверить»: 2-3 сценария, которые должен пройти ревьюер;
• спорные решения фиксируют ADR на полстраницы: контекст, решение, последствия;
• если автор не может объяснить код простыми словами, задача считается незаконченной.

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

Следующие шаги: маленькие изменения, которые дадут эффект

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

Выберите 2-3 правила читаемости и внедрите их уже на этой неделе. Они должны быть проверяемыми на ревью и одинаково применяться к ручному и ИИ-коду. Например: понятные имена, один уровень абстракции на функцию и короткий комментарий к неочевидным решениям.

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

• «Как работает»: 5-7 предложений о потоке данных и ключевых решениях.
• «Как менять»: где безопаснее править, какие есть ограничения, как проверить.

Запланируйте короткую сессию обучения (30-40 минут) по вашему плейбуку для ИИ-кода. Не лекцию, а разбор 1-2 свежих PR: что было непонятно, как переписали, какие подсказки в промпте помогли. В конце договоритесь об одном общем паттерне и начните применять сразу.

Если вы делаете приложения через TakProsto, имеет смысл заранее зафиксировать требования к структуре и стилю в planning mode: какие модули должны быть, где границы, как называются сущности, какой формат ошибок и логов. Это снижает шанс получить «работает, но никто не понимает». Для безопасных экспериментов помогают снимки и откат, а для командного ревью и доводки в привычных инструментах - экспорт исходников.

Через две недели измерьте эффект простым вопросом: «Сколько минут нужно новому человеку, чтобы уверенно объяснить этот модуль?» Если время не падает, уточняйте правила, а не добавляйте новые.