Как разрешать конфликты в командной работе?

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

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

Я хотел бы, чтобы ответы на эти вопросы были вашим руководством при принятии решения о том, что делать. Если ошибка человека № 2 — это то, что можно исправить позже, возможно, пусть человек № 2 учится на ней. Однако, если это действительно плохая идея, тогда придерживайтесь своего мнения и продолжайте искать способы сообщить решение человеку № 2.

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

Вариант 3: Человек 1 и Человек 2 обсуждают проблему/задачу/тему и возможные решения/способы, а также предысторию. Они вместе выбирают лучший способ сделать что-то. Качество продукта лучше, и они действительно работали в команде.

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

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

Установите для себя крайний срок, когда вы вернетесь к проблеме — скажем, месяц — и проверьте, находятся ли они на правильном пути или нет.

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

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

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

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

Если ваша команда демонстрирует такие вещи, вы еще не команда.

Да, здесь я согласен с Дэвидом Эспиной. Хороший менеджер решит эту проблему, тщательно манипулируя встречей, то есть задавая вопросы обоим (не допрашивая) в обычном порядке, играя в дурака, если необходимо, чтобы они объяснили так, как вы, как (предположительно) менее технический менеджер, можете понять, это отличный способ для них объяснить друг другу достоинства того, о чем они думают. Я проработал более 20 лет в качестве разработчика, я довольно опытен, и меня может раздражать, когда кто-то приходит на том же уровне и не понимает того же технического уровня - такова человеческая природа. Объяснять кому-то, кто должен знать/понимать, — это одно, а объяснять начальнику, который не настолько техничен, — совсем другое дело. У свежих умов часто есть что предложить, иногда то, что звучит великолепно, в долгосрочной перспективе просто не работает (мы все это видели!), и человек с длинными зубами может понять это до того, как потратит деньги на открытие на полпути. Это, безусловно, самая важная часть работы продакт-менеджера: контролировать свою команду, поддерживать производительность, но при этом сохранять баланс с моральным духом и, в конечном счете, принимать решающее решение, когда мяч на его/ее стороне. В худшем случае, прислушайтесь к этому третьему уху, еще одному технарю (надеюсь, того, которого они оба уважают) и позвольте им представить свои дела. Что касается того, чтобы позволить им потерпеть неудачу в качестве учебного опыта, я бы не стал. Неудачи обязательно будут - как и опыт - я не хочу, чтобы остальная часть команды страдала из-за тренировки одного человека - и это вдвойне касается моих пользователей и моего руководства. ), и человек с длинными зубами может понять это до того, как потратит деньги на открытие на полпути. Это, безусловно, самая важная часть работы продакт-менеджера: контролировать свою команду, поддерживать производительность, но при этом сохранять баланс с моральным духом и, в конечном счете, принимать решающее решение, когда мяч на его/ее стороне. В худшем случае, прислушайтесь к этому третьему уху, еще одному технарю (надеюсь, того, которого они оба уважают) и позвольте им представить свои дела. Что касается того, чтобы позволить им потерпеть неудачу в качестве учебного опыта, я бы не стал. Неудачи обязательно будут - как и опыт - я не хочу, чтобы остальная часть команды страдала из-за тренировки одного человека - и это вдвойне касается моих пользователей и моего руководства. ), и человек с длинными зубами может понять это до того, как потратит деньги на открытие на полпути. Это, безусловно, самая важная часть работы продакт-менеджера: контролировать свою команду, поддерживать производительность, но при этом сохранять баланс с моральным духом и, в конечном счете, принимать решающее решение, когда мяч на его/ее стороне. В худшем случае, прислушайтесь к этому третьему уху, еще одному технарю (надеюсь, того, которого они оба уважают) и позвольте им представить свои дела. Что касается того, чтобы позволить им потерпеть неудачу в качестве учебного опыта, я бы не стал. Неудачи обязательно будут - как и опыт - я не хочу, чтобы остальная часть команды страдала из-за тренировки одного человека - и это вдвойне касается моих пользователей и моего руководства. но сбалансированный с моральным духом и, в конечном счете, принимающий решающее решение, когда мяч на его/ее стороне. В худшем случае, прислушайтесь к этому третьему уху, еще одному технарю (надеюсь, того, которого они оба уважают) и позвольте им представить свои дела. Что касается того, чтобы позволить им потерпеть неудачу в качестве учебного опыта, я бы не стал. Неудачи обязательно будут - как и опыт - я не хочу, чтобы остальная часть команды страдала из-за тренировки одного человека - и это вдвойне касается моих пользователей и моего руководства. но сбалансированный с моральным духом и, в конечном счете, принимающий решающее решение, когда мяч на его/ее стороне. В худшем случае, прислушайтесь к этому третьему уху, еще одному технарю (надеюсь, того, которого они оба уважают) и позвольте им представить свои дела. Что касается того, чтобы позволить им потерпеть неудачу в качестве учебного опыта, я бы не стал. Неудачи обязательно будут - как и опыт - я не хочу, чтобы остальная часть команды страдала из-за тренировки одного человека - и это вдвойне касается моих пользователей и моего руководства.

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

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