Как мне поступить с медленным и не назначенным коллегой по команде? [закрыто]

Я работал над новым проектом. Проект работает следующим образом: конечный пользователь может получить доступ к веб-приложению, используя ссылку, и он может добавить несколько систем в свою сеть и управлять деталями этой конкретной системы. Моя часть включает в себя интерфейс и веб-сервер, который сделан на Python. Мой Python фактически общается с другим проектом, который полностью сделан на C & C ++. Проект c / c ++ является основным приложением, которое выполняет всю функциональность. Мой питон отправляет запрос пользователя и отображает ответ от него пользователю.

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

Приложение c / c ++ находится под управлением другого коллеги, который имеет опыт работы более 5 лет и может делать вещи намного быстрее, чем я, но он никогда не делает этого. Может быть, он не любит это делать. Его приложение часто падает, когда мой питон общается с ним или возвращает неправильные значения. Это полно ошибок. Так как от этого зависит мое приложение, мне сложно его создать. Вместо того, чтобы исправлять ошибки, он просит меня замедлить работу. Он просит меня сказать менеджеру, что моей работе нужно много времени. Он просит меня обмануть менеджера и даже заставляет меня работать медленно, как он.

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

Я ничего не могу сказать менеджеру по этому поводу, поскольку, если менеджер спросит его, почему, он может подумать, что я пожаловался на него менеджеру. И он продолжает лежать на собрании. И поскольку он исправляет ошибку медленно, это даже замедляет мою работу. Теперь я подумал о том, чтобы поработать над интерфейсной частью моего приложения и доработать его, чтобы за это время он смог сделать свой проект стабильным. Теперь он просит меня сказать менеджеру, что моя часть внешнего интерфейса требует много работы, и мне может понадобиться все больше и больше времени, просто чтобы он мог перетащить проект вниз. И печально то, что наш настоящий менеджер уехал в США, поэтому у нас есть временный менеджер, и этот парень мало что знает о проекте, поэтому c, c ++ его просто дурачит.

Кто-нибудь может подсказать мне, как я справляюсь с этим? Я хотел закончить проект в ближайшее время. Как я могу заставить его работать, даже поддерживая с ним хорошие отношения?

Ответы на комментарии:

Если он действительно намеренно вводит в заблуждение компанию, вам следует сообщить об этом руководству.

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

В вашей компании нет какой-либо системы отслеживания ошибок?

Здесь нет действующей системы отслеживания ошибок. Компания пытается завершить проект как можно скорее и передает его в отдел контроля качества. А затем исправляет ошибки, обнаруженные QA.

Вот почему компании должны предоставлять сотрудникам акции / опционы или какую-то собственность. Таким образом, вы можете буквально сказать парню: «Вы стоите мне денежного роста ... разве вы не хотите зарабатывать деньги тоже?».

У компании есть опционы на акции, которые они дали мне по 2500 акций, в основном он тоже получил бы еще.

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

Я даже делал это, сначала его приложение не обрабатывало несколько запросов одновременно, он использовал очередь для обработки запросов, которые я ему отправил. Я даже предложил ему некоторые свои идеи по этому поводу. Он сказал, что у него уже были эти идеи, и они будут реализованы. Он объяснил это следующим образом: «На все требуется определенное время, и это проект, для завершения которого может потребоваться два года, и нас просят завершить его через два месяца». Из-за этой ошибки у меня были трудности с написанием кода в течение первых нескольких недель. Но теперь он исправил это. Но он использует одну очередь для пользовательских запросов, и это теперь замедляет работу приложения, поскольку оно обрабатывает один запрос за раз.

Что QA делает все это время? Почему они не сообщают / не подтверждают статус проекта (ов)?

Менеджер - это человек, который решает, когда давать QA. На данный момент он еще не передан в QA. Он сказал, что мы должны дать это к концу этого месяца.

Ты в плохой ситуации, я бы не хотел быть на твоем месте. Вряд ли вы могли бы разобраться, не вступая в конфликт с коллегой.

Вот что я бы сделал:

• Не становись его партнером в преступлении. Откажитесь врать о статусе вашего проекта или его проекта.

• Внедрите (в свободное время, если необходимо) отчеты об ошибках в свое приложение, чтобы все ошибки отправлялись по электронной почте вашим коллегам и вашему менеджеру. Если ошибка вызвана его приложением, сделайте это видимым в электронном письме (укажите [XYZ APP BUG] в теме письма или что-то в этом роде).

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

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

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

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

Я собираюсь добавить немного противоречивый взгляд: вы говорите, что работаете столько часов, сколько можете бодрствовать. Так что, может быть, он не особенно несправедливо говорит: «Ты заставляешь меня выглядеть плохо, и я на самом деле работаю столько часов, сколько захочу». Может быть, он был там и сделал это, и, возможно, он сгорел. Я обещаю вам, что вы будете, если вы будете продолжать в том же духе.

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

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

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

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

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

В следующий раз, когда вы будете на собрании, и он скажет, что весь его код в порядке, скажите: «О, хорошо, то, что я рассказал вам около часа назад, когда он звонит в XYZ с датой, которая не является рабочим днем, исправлено сейчас? " Произойдет одно из трех:

• Он будет лгать и говорить, что такой проблемы нет, вы скажете: «Это так! Мы обсуждали это! Я написал вам по электронной почте!» и все это привлечет внимание менеджера
• Он скажет вам, что на самом деле это не ошибка в его коде, это ошибка в вашем коде, потому что вы должны проходить только рабочие дни, и вы скоро узнаете, о чем он думал, но не говорил
• Он скажет: «Нет, тот, о котором вы только что сказали мне, я буду иметь дело сегодня, но все остальное хорошо». Если он так говорит, просто поблагодарите его.

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

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

Защитите себя любым способом, используя отслеживание ошибок, электронную почту и т. Д., Но НЕ делайте вид, что это ваша задержка, а не его. Никогда не давайте боссу поддельный отчет о состоянии, он вернется, чтобы укусить вас. Скажите боссу правду о проблемах, которые у вас есть (и покажите доказательства), когда его код не работает.

Этот человек, который просит вас расслабиться, чтобы он не выглядел плохо, - змея (ну, это оскорбление сообщества змей (тонкое упоминание о Светлячке), извините всех настоящих змей там). Он сделает все что угодно, чтобы бросить тебя под автобус вместо него. Не верь ему.

В первую очередь:

Поскольку он мой коллега, я ничего не мог сказать менеджеру.

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

Сообщите свои статусы честно. Если ваша работа задерживается ошибками на стороне другого разработчика, запишите, что вы нашли ошибки в C / C ++ и сообщили о них (пожалуйста, скажите, что вы используете какую-то форму документации, которая оставляет след за бумагой).

А пока продолжайте, завершите свою работу и сообщите своему боссу, когда вы закончите. Если ваш менеджер хочет знать, почему остальная часть проекта еще не запущена, вы можете отослать его к другому разработчику и, возможно, упомянуть, что он, вероятно, очень сложный / большой / требует много тестирования / другой разработчик очень занят / и т.д.. Если вы знакомы с C / C ++, вы можете предложить помощь по основной логике приложения, чтобы и с этим справиться. Да, вы будете выполнять работу другого парня, но из этого становится ясно, что вы работаете усердно и продуктивно, а другой - нет, не говоря уже о том, чтобы сделать вас еще более ценным для своего босса. Это может даже оказать некоторое давление на другого разработчика, чтобы ускорить процесс и сделать это быстрее.

Есть ряд проблем на работе. Быть в курсе, что:

1. Вы делаете предположения о мотивации других людей
2. Вы раскрашиваете факты мнениями.
3. Аутсайдеры (кто-либо еще) не знают историю и не знают о ваших разочарованиях с вашим коллегой.
4. Вы можете выглядеть по-детски, если вам кажется, что вы играете в игру "Гоча". Ваш коллега, вероятно, может сыграть лучше - ведь у него все еще есть работа, не так ли?

Поэтому при представлении статуса вашего проекта:

1. Не упоминай другого человека.
2. При сообщении об ошибках или проблемах с кодом - не разработчик. Скажите «Вызов метода FooBar () возвращает 1, когда он должен возвращать 2». Тогда любая проблема не является личной атакой, вы просто говорите о коде, а не о людях.
3. придерживайтесь фактов, для которых у вас есть доказательства.
4. Если ваш коллега становится оборонительным или враждебным, задавайте вопросы. «Я не понимаю, почему вы думаете, что я должен делать _ »
5. Не обращайте внимания на социальные пренебрежения или намеки. Притворись, что ты не получил личную атаку.
6. Выспитесь ночью перед любым статусным собранием, так что вы умственно ловки.
7. Документ, документ, документ.
8. Не стесняйтесь попросить этого парня помочь вам с интересной проблемой, он может обратиться к вам, если он почувствует, что вы уважаете его. Это касается налаживания отношений. (обратите внимание, что это не всасывание - это что-то еще)
9. Будьте готовы уйти, если нужно, чтобы вы не были ни в нужде, ни в эмоциональной ловушке. Это поможет держать голову на собраниях.

«Я человек, который любит работать. Я провожу большую часть времени в офисе и иду домой только тогда, когда чувствую сонливость».

Это вредно для здоровья и не может ожидаться от коллег, если только вы не получите компенсацию за то, что можете взять годы отпуска для неизбежного выгорания. (Что-то вроде> 10% владения в компании или выше 200 тыс. Долл. В год). Сохранение опыта, чтобы добраться до точки, где он может развиваться очень быстро, требует времени. Часть вашего времени должна быть посвящена развитию опыта.

«Проект c / c ++ - это главное приложение, которое выполняет всю функциональность. Мой питон отправляет ему запрос пользователя и отображает ответ от него пользователю. ... Может быть, ему это не нравится».

Python - более гибкий язык, чем C / C ++. Его приложение, кажется, содержит всю функциональность; ваше приложение просто пользовательский интерфейс. Скорее всего, они не равны по сложности. Возможно, он не производит код быстро; но качественное кодирование намного лучше, чем количественное кодирование. У вас вполне могут быть нереалистичные ожидания относительно того, как быстро он сможет писать в часы, которые он желает / ожидал отработать (обычно ~ 40 часов в неделю; помните, что если он был там годами, он, вероятно, накопил другие задачи, такие как управление другими или помощь в поддержании старшего возраста). проекты, которые занимают значительную часть рабочей недели).

Не ври ему; но опять же не критикуйте его тоже. Поговорите о том, как велика его система. Конечно, ему нужно больше работать, пока он не закончится. Дайте своему менеджеру точное обновление статуса без именования / назначения вины. Напишите смоделированную версию его системы, которая соответствует тому же стандарту, которому должна соответствовать его система. Убедитесь, что ваша система отлично работает с вашей макетированной системой с помощью автоматизированного набора тестов. Тогда ваша система может быть завершена (например, она идеально синхронизируется с макетом), даже если живая система все еще глючит.

Затем вы можете написать автоматический набор тестов для его системы, который будет вызываться извне, что соответствует согласованным стандартам. Например, проверьте, чем Foo (1,2,3) возвращает ответ «Бар 4 5 6». Это может помочь ему выявить ошибки и ускорить его разработку (и не нужно возиться с его кодом). Как только эти вещи будут выполнены, вы сможете перейти к другому проекту / задаче (например, помочь ему с частями C / C ++).

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

В этой ситуации необходимо учитывать несколько моментов.

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

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

Так что, если плохо противоречить своему коллеге перед менеджером, и также плохо не противоречить ему, тогда что вы делаете?

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

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

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

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

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

Мне кажется, что здесь неадекватное управление проектами. Вы должны: а) отслеживать ошибки, которые влияют на вас, и б) следить за обсуждениями в письменном виде.

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

Ничего плохого в том, чтобы защищать коллегу, но чтобы кто-то ожидал, что вы будете лгать своему боссу на ежедневной основе, он должен уйти. Я не мог уважать его как личность и не хотел бы, чтобы этот человек был случайным знакомым. Он хочет быть врагом, принеси это.

Как вы можете спорить о задержках на уровне приложений из-за внешнего интерфейса? Вот почему вы делаете это, чтобы они могли быть отдельными. Что дальше, у него еще больше задержек, потому что кто-то хочет создать мобильную версию?

Выполни свою работу. Документируйте любые проблемы, которые у вас возникли с ошибкой в ​​его приложении. А потом иди домой! Мне все равно, сонный ли ты или нет. Найдите друзей, которые стоит иметь.

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

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

Я бы посоветовал вам сразу перейти к управлению. Однако в прошлом у меня были проблемы из-за того, что я был слишком «честен» (в некоторой не связанной с этим ситуации), поэтому я не уверен, что вы должны принять мой совет. Кроме того, как отмечали многие, возможно, ваше восприятие ситуации не так точно, как вы думаете.

Трудно и неразумно оценить относительные усилия и сложность другого проекта, если вы не знакомы с базой кода. Вы говорите, что его код подвержен ошибкам, но он может быть в отличной форме со всеми остальными проблемами на очень высоком уровне абстракции ... Проблема в том, что это единственный код, который нужен вашему интерфейсу!

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

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

С политической точки зрения, говоря об этом, вы можете утверждать, что он не совсем прав, и в то же время давать ему возможность играть глупо и не быть защищенным.

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

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

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

Ответ Пэт был великолепен. Я согласен на 100%. Не ходи тайком на встречу с боссом. Или возьмите это с вашим коллегой между 4 глазами или сделайте это со всеми 3 из вас. Но предложение Пата сосредоточиться на проблемах с кодом, а не на людях, - правильный путь.

Кстати, 40 часов в неделю достаточно чувак. Вы должны держать свою мотивацию высокой!

Попросите кого-нибудь еще, чтобы помочь вам обоим в интеграционном тестировании. Человек должен быть в состоянии сказать, где возникает проблема. Как отметил Темптар, я удивляюсь, почему нет даже отличного материала для отслеживания проблем! Так как слежения нет, это похоже на то, что каждый раз, когда другой парень говорит, что сейчас все в порядке! так не получится!

Это ваш модуль, если вам нужно это сделать, вам нужно поднять красный флаг, что вызывает задержку на вашей стороне. Опыт работы в MERE Years не имеет ничего общего, это просто знание и на этом должен настаивать ваш менеджер. Как я уже сказал, здесь чувствуется плохое управление проектом.

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

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