Код это примерно треть работы. Остальное: дизайнер, который не видит ограничения железа; менеджер, которому «нужна одна кнопка»; коллега, который пишет так, будто за ним гонится дедлайн 2015-го.
На созвоне снова спрашивают, почему это так долго. Хочется в монахи. Не надо. Надо научиться говорить так, чтобы после разговора было ясно, что делать.
Я видел сильных разработчиков, которые пять лет сидят мидлами. Код у них нормальный. Ломается другое: техдолг не умеют назвать ценой задержки, на ревью уходят в оборону, на встрече либо молчат, либо язвят, боятся спросить. После middle техника даёт примерно пятую часть роста. Остальное упирается в людей.
Три версии одной мысли
Если не можешь объяснить концепцию человеку без IT, сам её недопонял. Race condition звучит как диагноз. Два процесса правят одну запись, как два человека один Excel: кто-то потеряет правки. Это уже можно нести на встречу.
Перед разговором готовлю три слоя.
Бизнесу: рефакторинг укоротит вывод новых фич примерно на 30%.
Проджекту: модуль авторизации сейчас связан так, что любое изменение занимает три дня. После разборки будет день.
Команде: выносим логику из контроллеров в сервисы, синглтоны меняем на внедрение зависимостей, закрываем тестами.
Техдолг директора не греет. Скорость вывода фич греет. Слой выбирается по тому, кто сидит напротив, а не по тому, какой слой красивее звучит.
Сначала услышать, потом обещать
Большинство ссор в команде начинается с того, что люди услышали разное.
Нужно срочно добавить экспорт в Excel. Клиент просит.
«Хорошо, сделаю» через неделю вскрывается как экспорт с фильтрами, макросами и пляской. Нормальный ответ: кнопка выгружает текущую таблицу в .xlsx? Какие поля? Есть требования к формату?
Когда собеседник замолчал, я считаю до пяти. Часто он ещё не закончил. Перебитый недосказанный хвост потом всплывает багом в постановке.
Ревью без крови
Комментарий «это ужасный код, переделай» учит прятаться, не писать лучше.
Нормальный комментарий держит три вещи: что уже работает, что ломает чтение или тест, как починить.
Логика обработки верная, валидация на месте.
Метод делает слишком много: парсинг, проверка, запись.
Давай разобьём на три. Проще тестировать.
Могу скинуть пример из payments.
«Ты написал нечитаемый код» закрывает разговор. «Мне трудно понять processData(). Можно комментарий или разбить?» оставляет дверь. «Здесь нужен Strategy» звучит как экзамен. «Как смотришь на Strategy, если типов обработки станет больше?» оставляет выбор.
Когда продакшен уже лежит
Ты сломал продакшн! Из-за твоего коммита половина пользователей не может войти!
«Это не я, ревью прошло, почему нет тестов» раздувает пожар. Сначала откат, потом разбор. «Ситуация критическая. Сейчас rollback, через 20 минут скажу, что случилось и как закрыть дыру.»
Вопрос «кто накодил» в эти минуты бесполезен. Нужны два других: что сделать сейчас и что не пустит это завтра.
Плохие новости во вторник, не в пятницу в шесть
Менеджер не должен узнавать о срыве за десять минут до дедлайна.
По пятницам в 18:00 звучит: «не успел, задача сложнее». По вторникам в 11:00: «архитектура API другая, чем казалось. Реалистично пять дней вместо трёх. Режем функционал или двигаем срок?»
Раз в неделю я сам пишу статус, пока меня не спросили.
Сделано: API экспорта отчётов, пять багов спринта, ревью PR #234 и #235.
В работе: рефакторинг аутентификации (60%), завтра синк с фронтом по новому API.
Блокеры: нет доступа к staging-базе, не согласована структура ответа с дизайном.
План: закончить рефакторинг к пятнице, начать PROJ-456.
Блокер в таком письме решается быстрее, чем блокер, который человек носит в голове до стендапа.
Новости делю на три полки. Зелёные: план держится. Жёлтые: риск есть, я его вижу. Красные: нужна чужая рука или решение. Жёлтые надо выкладывать, пока они не покраснели.
Встреча на одно решение
Двухчасовой созвон на десять тем обычно не рождает ни одного решения. Тридцать минут на один вопрос рождают задачу с именем.
Если собираю сам, в инвайте уже есть повестка.
Тема: схема уведомлений
Время: 30 минут
Кто: бэк, фронт, PM
1. Текущая схема хранения (10)
2. Варианты (10)
3. Решение и задачи (10)
Подготовка: схема БД, список требований фронта
Результат: план рефакторинга с оценками
Когда разговор уезжает на цвет кнопки, я кладу вопрос в отдельный список и возвращаю встречу к решению, ради которого всех созвали. Цвет кнопки подождёт свой слот.
Три трудных типажа
Человек, который всё знает лучше, обычно затыкается, если дать договорить, повторить его тезис и спросить, как это лечит конкретную дыру Y. Потом оба варианта на бумагу: плюсы, минусы, без театра.
Молчуна на общей встрече бесполезно ждать. Прямой вопрос по имени, тема заранее, разговор один на один. Часто он стесняется группы, а не мысли.
Вечный критик без альтернативы остаётся критиком, пока его не попросить решить ту же задачу самому. «Как бы ты сделал» либо рождает вариант, либо снимает позу.
С чего начать на этой неделе
Одной техники хватит. Пауза в пять секунд на всех созвонах. Или одно ревью без обвинения. Или один статус в четверг, пока у вас не спросили.
Через две недели будет видно, стало ли меньше сюрпризов. Если нет, техника не прижилась, а не «коммуникация не моё».
На второй месяц я обычно добавляю еженедельный статус и одну встречу с повесткой в инвайте. На третий: одно объяснение неразработчику и один конфликт, который закрыли откатом и разбором, не поиском виноватого. Метрика грубая и живая. Менеджер сам спрашивает апдейт. Коллеги зовут на разговор не потому что «надо», а потому что после тебя ясно, что делать. Джун приходит не только с кодом.
Книжки тут вторичны. Розенберг, Crucial Conversations, Fournier полезны, если уже есть своя сцена, на которую их класть. Без сцены это ещё один конспект. Сцена уже есть: экспорт в Excel, прод в пятницу, статус во вторник.
