Коллеги, представьте себе сеньора-разработчика. У него есть джун — способный, но вечно попадающий впросак. Сеньор пытается помочь: он сыплет терминами, строит идеальные архитектурные цепочки, приводит неопровержимые доказательства преимущества того или иного подхода. А в итоге видит перед собой хмурого джуна, который упёрся взглядом в монитор и в лучшем случае думает: «Ну вот, опять он самый умный».
Знакомая картина? Каждый из нас в разные моменты жизни бывал и в роли сеньора, и в роли джуна. Проблема не в том, что мы говорим, а в том, как мы это делаем. Мы, айтишники, привыкли, что знание — это сила, мощный инструмент, которым можно починить любой баг. Но на самом деле, знание — это патч. Вы не можете заставить его установиться, ударяя по клавиатуре. Вы можете лишь создать условия: стабильную среду, доверие и готовность системы его принять.
Существует один простой, но удивительно глубокий метод, который помогает превратиться из «самого умного» в мудрого архитектора человеческого взаимодействия. Это принцип Спросить – Предоставить – Спросить из мотивационного интервьюирования (MI).
Шаг первый. СПРОСИТЬ — получаем доступ к системе
Прежде чем залить очередной «патч» знаний, отправьте запрос на подключение. Это кажется мелочью, но это — магия. Фраза «Можно, я поделюсь одним соображением по поводу архитектуры?» — это не просто вежливость. Это sudo-запрос для терминала сознания другого человека.
Почему это работает? Потому что вы признаёте permission другого человека быть root-пользователем в своей собственной системе. Вы не пытаетесь получить привилегии через brute force, а вежливо стучитесь. Когда джун сам говорит «Да, можно», он психологически аутентифицируется и готов принять данные. Он из пассивного end-user превращается в активного участника разговора.
Что ещё спросить на этом этапе?
- «Что ты уже пробовал сделать?»
- «Какие есть гипотезы, почему это не работает?»
- «Какой информации тебе не хватает?»
Вы удивитесь, насколько точную и самокритичную self-diagnostic проведёт ваш собеседник. Он сам составит для вас technical specification своего запроса.
Шаг второй. ПРЕДОСТАВИТЬ — заливаем чистый, документированный код
Теперь, когда вам выдали access token, можно делиться информацией. Но не как с триумфом выпуская мажорный релиз, и не как с угрозой объявляя о критической уязвимости, а просто и ясно.
Представьте, что вы показываете коллеге элегантный кусок кода, который решил сложную проблему. Вы не кричите: «Это величайший алгоритм всех времён! Ты обязан его использовать!». Вы просто говорите: «Смотри, я тут применил такой подход, он хорошо ложится на наши требования по производительности».
Так и с информацией.
- Говорите на человеческом языке: вместо «это когнитивное искажение, такое как катастрофизация» скажите «иногда наш мозг, как баг в логике, начинает бесконечно выполнять цикл worst-case scenario».
- Будьте кратки: дайте небольшой, реиспользуемый модуль информации, который можно «протестировать», а не монолитную code base.
- Сохраняйте нейтральность: не «это ужасная практика, ведущая к техдолгу», а «исследования показывают, что это может влиять на maintainability кода в долгосрочной перспективе».
Ваша цель — не вызвать red alert или произвести wow-effect, а просто сделать commit — чистый факт, без эмоционального legacy code.
Шаг третий (главный). СПРОСИТЬ — запускаем процесс интеграции
Это самый важный шаг, который чаще всего пропускают. После того как вы что-то предоставили, не спрашивайте «Понял?». Это вопрос code review с позиции силы. Спросите иначе: «Как ты это видишь?», «Насколько это применимо к твоей текущей задаче?», «Что из этого кажется тебе самым полезным?».
В этот момент происходит чудо. Информация перестаёт быть вашим форком и становится его собственным repository. Он начинает её дебагить, рефакторить, находить в ней свои собственные use-cases. Возможно, он скажет: «Ну, это всё, конечно, логично, но в моём legacy project это не применить...». Не спорьте! Это его runtime environment. Ответьте: «Да, ты прав, каждая система уникальна. А что в твоём проекте является самым сильным триггером для рефакторинга?».
Вы переносите фокус с общих best practices на его личную codebase. Из лектора вы превращаетесь в pair programmer, который помогает человеку услышать самого себя.
Вывод
Когда мы перестаём быть «носителями абсолютной истины» и становимся «проводниками в мире смыслов» другого человека, всё меняется. Мы перестаём force-push-ить свои решения и начинаем сотрудничать через pull request. Мы заливаем патч и с замиранием сердца ждём, когда же система перезагрузится и выдаст первый, такой долгожданный, стабильный и осмысленный результат.
Это и есть искусство мотивационного консультирования: не чинить человека, а помочь ему найти ресурсы для самостоятельного апгрейда.