Как управлять конфликтами в проектной команде: переход от противостояния к решению проблем
Когда в проектной команде возникают споры о том, что возможно выполнить, вернитесь к действующим договоренностям, прежде чем требовать от кого-либо компромисса. Определите обещанный результат, срок, доступных исполнителей и факты, стоящие за спорной оценкой. Затем отделите вопрос, требующий проверки, от выбора, требующего авторизованного решения. Призыв «работать дружнее» не создаст недостающих ресурсов.\n\nЭтот подход эффективен, когда разногласия затрагивают реальные обязательства по проекту. Он направлен на работу, которую необходимо изменить, а не на личности участников. Итогом может стать пересмотр объема работ, изменение последовательности задач или четкий отказ от необоснованного изменения; это вовсе не обязательно должна быть золотая середина между двумя первоначальными требованиями.
Сопоставьте спорное изменение с существующими обязательствами
Представьте небольшую команду, готовящую демонстрацию для внутреннего воркшопа. Согласованная демонстрация включает три функции. Теперь кто-то просит добавить четвертую, а специалист, который ее готовит, говорит, что тогда не останется времени на обязательное ревью. Это наглядный пример. Прежде чем обсуждать отношение к работе, определите текущий объем задач и согласованную дату воркшопа. Проверьте, была ли новая функция обещана ранее или это действительно новый запрос.
Зафиксируйте разницу простыми словами: одна дополнительная функция, требуемый для нее объем работы и этап ревью, который может пострадать. Не выдавайте непроверенную оценку за факт. Если два человека опираются на разные версии скоупа (объема работ), определите актуальную версию до согласования решения. Иначе может казаться, что они спорят о трудозатратах, в то время как на самом деле они планируют совершенно разные результаты.
Выясните, какие условия проекта защищает каждая из позиций
Позиция «добавьте это сейчас» может защищать цель воркшопа; позиция «оставьте как есть» может защищать необходимое ревью. Спросите, что именно участники должны увидеть или сделать и какие проверки остаются строго обязательными. Желание сделать демонстрацию более впечатляющей отличается от подтвержденной потребности аудитории. Общее опасение, что процесс займет слишком много времени, отличается от оценки, основанной на конкретных задачах.
Гарвардская программа по переговорам (Harvard PON) разделяет глубинные интересы и заявленные позиции, рекомендуя опираться на объективные критерии. Примените этот принцип к согласованным результатам и фактам самого проекта. Не додумывайте чужие мотивы и не объявляйте общую цель от имени других. Попросите коллег подтвердить, действительно ли ваше описание отражает то условие, которое они стремятся сохранить.
Отделите техническую неопределенность от решений по объему работ
Если спорный вопрос заключается в том, справится ли существующий компонент с дополнительной функцией, договоритесь о точечной проверке: назначьте ответственного, выделите лимит времени и определите измеримый результат. Например, протестируйте только нужный компонент, вместо того чтобы разрабатывать всю предложенную функцию целиком. Заранее определите, какой результат подтвердит целесообразность этого варианта, а какая неопределенность сохранится после проверки.
Если всем уже известно, что дополнительная работа превышает доступное время, дальнейшие технические обсуждения вряд ли что-то решат. Выбор лежит в плоскости объема работ, сроков или ресурсов. Точно так же успешная небольшая проверка не означает автоматического одобрения дополнительных задач. Она лишь предоставляет факты лицу, принимающему решения по проекту.
Такое же разграничение действует и тогда, когда никто не просил о расширении объема. Допустим, два участника команды предлагают разные способы достижения уже согласованного результата. Сравните их предположения относительно исходных данных, условий работы и критериев приемки. Попросите каждого назвать один факт или наблюдение, которое могло бы опровергнуть предпочитаемый ими подход. Детальное сравнение может показать, что в одной из оценок была упущена зависимость или использовались иные условия. Зафиксируйте, что уже проверено, а что остается неизвестным; не выбирайте подход только потому, что его сторонник занимает более высокую должность.
Оцените последствия для проекта в целом
Рассматривайте реально доступные варианты: сохранить исходную демонстрацию, заменить одну согласованную функцию на запрошенную (если владелец продукта согласен) или перенести дополнительную работу на следующий этап. Для каждого варианта определите, как он повлияет на подготовку, проверки, материалы и людей. Казалось бы, незначительное изменение может создать работу для человека, не участвующего во встрече, поэтому спросите его, прежде чем давать обещания от его имени.
Методика анализа компромиссов в проекте (Project Trade-Off Analysis) от Atlassian рассматривает такие переменные, как объем, время, стоимость, качество и риски, определяя, какие из них более гибкие. Она также рекомендует пересматривать приоритеты при появлении новой информации. Вы можете использовать эти вопросы, не проводя воркшоп целиком. Обязательная проверка не становится факультативной только потому, что другую переменную сложно изменить.
Завершите разногласие решением, готовым к исполнению
Используйте существующие полномочия для принятия решений. Представьте текущие обязательства, проверенные факты, нерешенные предположения и последствия возможных вариантов. Если команда не может перенести дату воркшопа или выделить еще одного сотрудника, заявите об этом прямо. Зафиксируйте принятое решение, распределение измененных задач и отмененные инструкции. Убедитесь, что задействованные коллеги могут приступить к работе по новым договоренностям.
В материалах PON о переговорных командах разногласия по задачам отделяются от переходов на личности; при этом сам факт спора не гарантирует, что конфликт всегда идет на пользу проекту. Сосредоточьте обсуждение на конкретном обязательстве. После следующей проверки оцените, позволило ли выбранное решение сохранить требуемый результат и не оказались ли ошибочными исходные предположения. При необходимости вернитесь к пересмотру конкретного решения, не воспринимая прошлый разговор как окончательный приговор чьей-либо надежности.