👨‍💻 7 типов «сложных» разработчиков

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

Специалисты по управлению персоналом в ИТ-компаниях по опыту знают, что всех разработчиков и менеджеров можно условно разделить на 7 типов. Перечисляя характеристики этих типов, мы предполагаем, что сотрудники ведут себя так не из вредности, а из лучших побуждений – просто у них такой характер и такие взгляды на работу: остается лишь найти к ним правильный подход.

Консерваторы

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

Почему они это делают

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

Как с ними работать

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

Что еще можно сделать

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

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

Такая презентация покажет, что вы:

• Исследовали все возможные способы решения проблемы.
• У вас есть четкое и надежное обоснование вашего решения.
• Вы понимаете, что делать с возможными проблемами, если они возникнут.

Первопроходцы

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

Почему они это делают

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

Как с ними работать

Принимайте участие в мозговых штурмах: спрашивайте у них, какие риски влекут за собой решения и как они вписываются в существующую систему. Например: «Как это впишется в наш CI/CD-пайплайн? Какие сложности могут возникнуть? Как можно справиться с этими осложнениями?» В процессе такого обсуждения рискованной, на первый взгляд, идеи может оказаться, что это действительно отличное решение проблемы.

Тихие критики

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

Почему они это делают

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

Как с ними работать

• Спрашивайте у них напрямую, в чем дело, если обсуждение осталось без ответа. Например, если тихий критик задал вам вопрос по документации, и вы на него ответили, но при этом чувствуете, что на вопрос можно ответить по-другому – спросите прямо, доволен ли критик ответом.
• Для обсуждения возражений критиков планируйте видео-созвоны один на один. После завершения подготовьте краткое содержание обсуждения, попросите сотрудника ознакомиться с ним и подписать. Этот документ послужит доказательством, если тихушник в будущем начнет высказывать мнения и опасения, от которых воздержался во время обсуждения.
• Устанавливайте крайние сроки для подписания документации. Это гарантирует, что рецензенты рассмотрят документ своевременно, а у вас будет крайний срок подписания, на который можно будет сослаться, если впоследствии они выскажут свои сомнения.
• Разместите чекбоксы для подписей в верхней части первой страницы дизайн-документа – так факт подписания становится явным, а это заставляет критиков обдумать – и озвучить! – все свои опасения.

Самоуверенные и многословные

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

Почему они это делают

• У них много идей по улучшению рабочего процесса, и они просто хотят помочь.
• Им может быть неясен масштаб или цель обсуждения.

Как с ними работать

• Если они уводят совещание в сторону, признайте их точку зрения и возможность ее реализации, но перенаправьте обсуждение обратно к основной теме. Например: «Это отличная мысль. Давайте создадим для этого тикет, чтобы не забыть. А пока продолжим обсуждение нашей темы».
• Создайте раздел «Идеи на будущее» в проектной документации или ревью кода, чтобы предотвратить появление слишком большого количества предложений. Переносите туда все комментарии, не относящиеся к текущему проекту.
• Принимайте предложения, если вдруг они имеют смысл и какую-либо ценность. Это создаст у говорунов впечатление, что вы не всегда автоматически отклоняете их предложения, и разрядит обстановку.

Перфекционисты

Эти зануды придираются ко всему, в первую очередь – к качеству кода. Часто это происходит потому, что у перфекционистов и у вас – разные стандарты качества или разное мнение о том, что важно для компании. Вы, возможно, считаете, что важнее как можно быстрее доставить продукт заказчику, а они – что важнее чистота и элегантность кода.

Почему они это делают

Чтобы поднять планку качества.

Как с ними работать

• Проведите доверительную, уважительную беседу. Начните, например, так: «Предложения, которые вы вносите, определенно повышают планку качества нашей кодовой базы, и я очень ценю это. Но я заметил, что иногда это замедляет темпы нашей работы и лишает нас возможности поэкспериментировать. Я бы хотел узнать ваше мнение о том, как нам лучше работать, чтобы поддерживать эту высокую планку и при этом иметь возможность пробовать нестандартные решения».
• Определите стандарты заранее. Если вы четко определите, что именно должно быть сделано по конкретному тикету, а что выходит за рамки, вам будет проще обосновать, почему какое-то неожиданное перфекционистское дополнение не является важным в данный момент, и не придется сводить обсуждение к конфронтации.
• Четко спрашивайте у перфекционистов, являются ли их комментарии в код-ревью блокирующими. В идеале, разработчики должны помечать все свои комментарии префиксом nit:, позволяя тимлиду решать, двигаться ли дальше или устранить их замечания. Общаться с перфекционистами надо примерно так: «Благодарю за замечание. Поскольку исправление займет время, прошу сообщить, насколько критична эта проблема и можно ли решить ее позже».

Равнодушные

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

Почему они это делают

• Им не нравится работа, которую они выполняют.
• У них есть проблемы, о которых вы не знаете – личные или профессиональные.

Как с ними работать

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

Что еще можно сделать

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

Перегруженные оптимисты

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

Почему они это делают

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

Как с ними работать

• Отнеситесь с пониманием – по крайней мере, в первые пару раз. Если вы требуете невозможного от перегруженного под завязку человека, это навсегда испортит ваши отношения и приведет к тому, что он не захочет помогать вам в будущем, когда нагрузка снизится до нормальной.
• Если проблема сохраняется, уважительно объясните о последствиях срыва дедлайна. По возможности предложите помощь. Разработчику из другого отдела можно сказать, например: «Последние несколько код-ревью, которые мы проводили, закончились тем, что мне пришлось несколько раз перезванивать вам, чтобы получить отзыв. Пожалуйста, сообщите мне сразу, если у вас нет времени и мне нужно попросить другого инженера». Это позволит разработчику либо признать, что у него не остается времени на ваш проект, либо сказать, что он просто забывает вовремя прислать отзывы. Коллеге по команде можно сказать более прямолинейно: «У меня такое ощущение, что у тебя слишком много дел, и это приводит к срыву сроков. Могу ли я как-то помочь?»
• Крайняя мера – обсуждение этого вопроса с руководителем. Как правило, к этому решению стоит прибегать только в том случае, если вы действительно не знаете, как подступиться к разговору.

Подведем итоги

Хотя управление разнородной командой – сложная задача, а стереотипы не всегда точны, понимание мотивов поведения разных типажей может помочь найти правильный подход к «сложным» сотрудникам и построить конструктивные отношения в коллективе. Поделитесь в комментариях своим опытом взаимодействия с разными типами сотрудников – какие методы оказались для вас наиболее эффективными?

Материал написан на основе статьи 7 types of difficult coworkers and how to deal with them