Общение с тимлидом: рабочие правила построения диалога
Правильное общение с тимлидом способствует продуктивному рабочему процессу и гарантирует получение плюшек, интересных задач и опыта.
Представим, что вам была поставлена задача реализовать новый API endpoint в существующем проекте. Простая цель: вернуть список почтовых адресов текущего пользователя.
Вы начали работу: зарегистрировали новый endpoint, ассоциировали его с контроллером и создали пояснительный комментарий. Но позже вас осенило, что запрос некорректный. Вы захотели проявить себя, показать все свои достоинства и подключили весь свой креатив, чтобы найти уникальное решение поставленной задачи.
Это очень плохо! Это неправильно, т. к. вы не обсудили решение с тимлидом. По его мнению, он дал вам простую задачу, а вы потратили в три раза больше времени, чем ожидалось. И неважно, что была создана прекрасная архитектура. Вы подорвали доверие вашего руководителя.
Даже лучшие инженеры, создающие элегантные решения, проходят через общение с тимлидом.
Во время собрания сфокусируйтесь на том, что вы делаете не так
Пришло время для доклада. Что вы скажете своей команде и руководителю?
"Вчера вопрос сдвинулся с мертвой точки. Я столкнулся с некоторыми проблемами при тестировании, и теперь стараюсь их исправить. Надеюсь, что сегодня все заработает".
Это было описание текущего состояния проекта, которое абсолютно бесполезно. Описание состояния – это повествование, на которое нет никакой реакции, кроме "ОК, хорошо звучит". Зачем на это тратить время?
Основная цель докладов – побуждать членов команды к выводу из ступора друг друга. Традиционными тремя вопросами являются:
- Что ты вчера закончил?
- Что ты сегодня закончишь?
- Что у тебя не получается?
Люди часто сосредотачиваются на первых двух и полностью опускают последнее. Но это самое важное!
"Что у тебя не получается" часто интерпретируют так: "Что полностью мешает тебе работать?". Предпочтительнее задавать вопрос: "В чем сложность?". Сложность может заключаться в следующих примерах:
- “Я не знаю, как написать тест для этого”.
- “Я не могу представить, что вернется от мобильного приложения”.
- “Мне нужно отрефакторить код, чтобы он заработал”.
Никакая из этих причин полностью не остановит вас в работе, но займет значительную часть рабочего времени. Это те причины, которые хочет услышать ваш технический руководитель. Это его лучшая возможность помочь вам ускорить работу и придумать решение самых сложных проблем.
Важное примечание: вы всегда должны нести ответственность за свой проект и за трудности, с которыми столкнулись. У вас не должно быть привычки использовать какую-либо отговорку, если ваша работа не выполнена.
Многие специалисты произносят впечатляющие речи: "Посмотрите, что я вчера сделал! Как же я хорош!". Остерегайтесь этого соблазна Лучше сосредоточьтесь на том, как вы можете ускорить работу.
Проактивное общение в течение дня
Когда вы работаете руководителем команды, у вас может появиться паранойя, что команда полностью застряла, а вы этого не знаете. Вы приходите в офис и видите, что все на своих местах, но чем они заняты? Все ли у них получается? Двигаются ли они в правильном направлении?
Конечно, тимлид должен иметь доверительные отношения со своей командой. Он не может позволить паранойе постоянно контролировать свое поведение. Вы должны несколько раз в день интересоваться рабочим процессом ваших подчиненных.
Проактивное общение – это разговор, инициированный вами. Собрания, брифинги и доклады не входят в список такого общения.
Примеры того, как можно начать подобный разговор:
- Сообщение в Slack.
- Комментарий к выполняемой задаче.
- Начать разговор при личной встрече.
Проактивное общение иногда принимает форму обращения за помощью. "Я не могу импортировать данный модуль и не знаю, что случилось. Ты можешь помочь?". Это возможность конвертировать общение с тимлидом в потраченное с пользой время.
Другая форма проактивного общения – создание контрольной точки. Например: "Я работал над функционалом и обнаружил, что … Дай мне знать, если захочешь это обсудить". Это отличный способ выявить потенциальные архитектурные разногласия. Перестаньте ждать обзора кода или следующего собрания, прежде чем заговорить.
Проактивное общение кажется простым, но на практике все стараются не "доставать" других подобным общением. Попробуйте добавить задачу в to-do list, чтобы тренировать проактивное общение.
В ходе технических обсуждений повторяйте и обобщайте
Важно, что вы и ваш руководитель достигли понимания, и вы сами можете этому способствовать.
Во время брифинга технический руководитель дает вам новый проект. Он имеет некоторые первоначальные мысли о том, как это может быть реализовано, и делится ими. Через некоторое время вы перестаете понимать, о чем идет речь, и прерываете общение с тимлидом недоумевающим "Че?". Это неправильно. Всегда уточняйте, что вы поняли, а что нет, вместо того, чтобы сказать: "Я потерялся".
Ваш руководитель хочет знать, что беседа прошла не зря, и вы поняли и услышали то, что он хотел до вас донести. Многие люди просто кивают или улыбаются. Вместо этого повторите и резюмируйте услышанное.
Пример:
"Правильно ли я понял? Я должен вычислить это на стороне сервера, чтобы сократить время ожидания, и отдать это клиенту во время загрузки страницы?"
Это в значительной степени доказывает, что вы услышали и поняли. Такой подход заставляет лучше слушать собеседника.
Когда начнете испытывать новую манеру общения, мозг будет сопротивляться неизведанному. Не останавливайтесь, если с первого раза не получится. Подумайте о том, насколько важно конструктивное общение с тимлидом, его отношение к вам, как к специалисту, и подача себя с лучшей стороны.
Руководители проектов хотят работать с теми инженерами, которые могут брать на себя ответственность. Это может быть сложно сделать на техническом уровне, если вы не знакомы с той системой, с которой работаете. Но вы можете взять на себя ответственность за то, как вы общаетесь в коллективе. Подумайте о том, как вы можете поменять свое общение с тимлидом, какие модели общения вы можете применить, и вы обязательно найдете для себя подходящую.