Как быть с коллегой, который запарывает ваш проект

Мы в TraceAir вместе с коллегой-бэкендером работали над новым программным компонентом. За один спринт необходимо было с нуля написать заглушки для бизнес-логики, а также инфраструктуру доставки кода на продакшн. Коллега был командирован из другой команды для усиления, чтобы мы успели закрыть все эти цели за квартал. Я беспокоился, что ему будет тяжело «въезжать» в незнакомую кодовую базу, поэтому заранее накидал ему примеры кода из других компонентов нашей команды.

Задачи поделили между собой так: коллеге досталась инфраструктура доставки, а мне — бизнес-логика. Также заверил его, что он может всегда обращаться с вопросами ко мне.

Довольно быстро стало понятно, что беспокоился я не зря: бэкендер явно ловил кайф от незнакомых подходов, много рассказывал на стендапах, как ему нравится, а белые пятна в его ментальной карте заполняются новой информацией. Первые несколько дней я очень радовался, что он всё глубже понимает, как у нас всё работает. Однако прошла половина спринта, а задачи не заканчивались: тогда зазвенели тревожные звоночки. Коллега продолжал воодушевлённо рассказывать, какую крутую штуку он за прошлый день прикрутил к раскатке, и как можно сделать ещё лучше. На этом этапе мне пришлось вмешаться и прямо попросить сосредоточиться на задаче. Используя несколько принципов эффективной работы, нам удалось в срок закрыть задачу.

Вот эти принципы:

1. Ведите прямую и откровенную коммуникацию, без грубостей и обвинений. Помните, что вы оба профессионалы, оба неравнодушны.
2. Пишите предметно в таск-трекере, что нужно делать, а главное, что точно не нужно (наша цель на спринт была — написать приличный код и доставить фичу на продакшн, а не полировать код до совершенства). Это поможет исключить разное представление об объёме и составе работ на этапе планирования.
3. Можно писать в задаче не только секцию In Scope, но еще и секцию Out of Scope (особенно это подойдет для джунов, ранних мидлов и незнакомых между собой коллег во время работы).

Как работать в команде программистов?

Одним из самых эффективных способов работы в группе считается работа в паре. Такие мини-команды часто называют «фича-тим»: выделяется маленькая группа, обычно 2-3-4 человека, и они работают слаженно над одной какой-то единой фичей. Перед ними есть цель, они её полностью знают и понимают. В такой команде хорошо налажены коммуникационные связи, люди находятся в плотном контексте своего дела.

Работа в паре очень воодушевляет и зарождает в умах понятие «коллективной ответственности». Если один из участников не успевает в срок выполнить свою часть задач, ему необходимо немедленно оповестить коллег и скорректировать путь всей команды, иначе работа команды будет провалена. Всегда нужно стараться найти общий язык и быть готовым прийти на помощь. У нас, в ИнтернетУроке, в одной из таких пар, frontend-разработчик опережал работу backend. Быстро посовещавшись, ребята приняли решение составить «контракт» и покрыть его «моками», чтобы frontend мог продолжить заниматься интеграцией, а за это время была закончена недостающая часть разработки с другой стороны.

Не бывает такого, чтобы слаженность работы в команде была идеальной, а темп синхронным. Обязательно кто-то во что-то утыкается. При этом нужно стараться, чтобы команда двигалась с одной скоростью, и помнить, что скорость эта всегда измеряется по самому медленному человеку. Бывает, что формируется команда профессионалов — локомотив, который без тормозов несётся вперёд, и далеко не все могут выдерживать такую скорость. Возможно, какой-то участник ещё не готов к подобному темпу, и тогда его необходимо переместить в другую команду, где он покажет наибольшую эффективность и результат.

Как работать в паре, где коллега по проекту срывает сроки или допускает серьёзные ошибки?

Если коллега не тянет, делает много ошибок и допускает баги, скорость всей команды падает. В современных методологиях разработки, таких как Scrum, Agile и т. д. существует встреча «ретроспектива». На ретроспективе встречается команда, которая работает над одним проектом, а если отдел не очень большой, то вся группа разработки. Цель ретроспективы — выяснить, какие проблемы и стопперы были выявлены в ходе работы за этот спринт. На такой встрече необходимо рассказывать о возникших проблемах. Не надо стесняться и думать, что вы «стучите» на своего напарника, это неправильно. Нужно подсветить вопрос, сказать, что в фич-тиме возникла такая проблема, и на стороне конкретного человека случались косяки или задержки по срокам. Основная идея здесь в открытом обсуждении своих проблем, а также в получении коллективной помощи. На встрече обязательно должен находиться руководитель, тимлид, который подхватит вопрос.

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

Если скорость в вашей команде важна, вам необходимо строить пары примерно равные по силам, иначе вы рискуете провалить работу всей команды и демотивировать ваших сотрудников.

Существует практика: если коллега не успевает, вся команда должна кинуться и помогать отстающему. Этот альтруизм не всегда помогает. Команде рано или поздно, и, скорее всего, рано, надоест этим заниматься. Одно дело когда человек чего-то не понимает, обращается к коллегам, и они помогают ему наверстать уровень (если есть ментор, надо обращаться к ментору, чтобы тот подтягивал). А если мы говорим про «прикрывать и тащить на своём горбу», конечно же, это выльется только в негатив и будет отражаться на всей команде.

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

Если со временем становится понятно, что коллега не справляется, то с ним начинаются увещевательные разговоры: «У тебя все ок?», «Может быть, нужно с чем-то помочь?».

В зависимости от ответов, а также того, насколько ценен этот специалист, можно прикинуть, что делать дальше: от продолжения увещеваний до увольнения.

Как работать в команде программистов тимлиду

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

Работа в команде с точки зрения сотрудника

Как сотрудник я порой вижу, что мой коллега не успевает закрывать задачи, от которых зависит и моя работа тоже. В такой ситуации можно поговорить с ним и предложить ему помощь. Или вдвоём обратиться к лиду, но тогда следует обязательно предупредить коллегу, что пойдёте за помощью к руководству.

Причин, по которым коллега срывает сроки или допускает ошибки, может быть очень много. И далеко не всегда они кроются в его непрофессионализме. Для начала стоит проанализировать задачи. Достаточно ли они детализированы, понятны, конкретны? Адекватны ли дедлайны? Вполне возможно, причина неудач разработчика — не в нём, а в деструктивном менеджменте. Лишь после этого следует проверять самого программиста. Если в компании ещё не используют код-ревью, то его стоит внедрить, чтобы помочь коллеге допускать меньше ошибок и расти как специалисту. Или, возможно, стоит поискать нового напарника.

Есть три пути, позволяющие добиться того, чтобы коллега по проекту не срывал сроки и не допускал серьёзных ошибок:

1. Сразу найти правильного напарника — совместимого по софт скиллам, мотивированного и понимающего, почему он хочет работать над этим проектом. В идеале, оба коллеги должны обладать соответствующими хард скиллами. Чтобы тандем удался, один из них должен быть «паровозом», а другой — дотошным педантом.

2. Если партнёра не пришлось выбирать, то при общении с ним нужно:

• Улучшать коммуникацию (понимать, «чем дышит»).
• Выяснить, что он хочет от проекта. При необходимости — разделить с ним зоны ответственности (отдать «кусок», которым ему нравится заниматься).
• Выяснить причину его ошибок или срыва сроков (возможно, из-за проблем дома он не может полноценно уделять время проекту).
• Выяснить, почему он не успел, на примере той или иной задачи (возможно, проблема не в нём, а в постановке или оценке задачи).

3. Если даже после общения не видно улучшений, то расставаться.

Прежде всего, следует не идти на конфликт с коллегой (хотя иногда очень хочется), а выявить причины, которые привели к текущей ситуации. Возможно, ему не хватает знаний, опыта, понимания проекта или поставленных задач.

Я бы назначил ему куратора, который будет помогать в работе. Кроме того, провел бы с ним парное программирование или совместный код-ревью задачи. Причём, что очень важно, не онлайн, а вживую. В случае с пробелами в знаниях нужно провести анализ слабых сторон хард-скиллов сотрудника и составить план индивидуального развития с дедлайнами и отчетами (без них, как показывает практика, результат отсутствует). Если и это не поможет, то остается попрощаться.

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