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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Равнодушные

Равнодушные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

admin
14 декабря 2018

ТОП-20 хитрых вопросов по SQL для собеседования

Техническое собеседование может грозить не только общением по теме вакантно...
admin
09 мая 2018

Логические и математические задачи с собеседований

Разомнем мозг! В этой статье собраны логические и математические задачи, ко...