Кейс контекст

Дизайнер выпускает макеты, которые отличаются от согласованного ТЗ.

На уточнение он отвечает, что «так будет лучше» и начинает активно убеждать команду, что его решение правильнее исходного запроса.

Команда недовольна нарушением договорённостей, а дизайнер считает, что действует в интересах продукта. Возникает конфликт.

Вариант решения

Сначала я бы задал бы дизайнеру уточняющие вопросы

• «Расскажи, пожалуйста, какие предпосылки, данные и идеи лежат в основе твоего решения?»
• Уточнил бы вводные по задаче: цели, ограничения, аудиторию и т.д.
• Зафиксировал бы аргументы дизайнера, чтобы иметь чёткое понимание его позиции.

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

⇒тестим

• организовал бы исследование на клиентской аудитории (A/B-тест или прототипирование) для объективной проверки спорных решений.
• Собрал бы обратную связь, чтобы понять, насколько выбранное решение отвечает потребностям клиентов.

⇒ обсуждаем

• провел бы аргументированное обсуждение внутри команды: можно привлечь как дизайнеров, так и продактов, чтобы проверить логику предложенного решения.
• если у коллег есть опыт или “синк” по аналогичным кейсам, спросите их мнение – это поможет выявить слабые места и сильные стороны аргументации.

⇒ если ничего из этого не помогло найти консенсус = эскалируем

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

Таким образом, решение сводится к:

• Сбору и документированию аргументации.
• Коллективному обсуждению и тестированию спорных моментов.
• Эскалации проблемы при отсутствии конструктивного диалога.
• Финальному вмешательству тимлида для принятия окончательного решения.