Как член команды, как вы выражаете свое несогласие с решением, которое, по вашему мнению, не отвечает интересам компании? Как лидер, как вы позволяете своей команде не соглашаться с решениями на справедливой и продуктивной основе?
Мы собираемся ответить на эти вопросы в Matter. Несмотря на то, что существует ряд полезных структур для принятия НОВЫХ решений (например, общие для Гокюля на площади, Брайана на Coinbase и Бэйна), мы не смогли найти основу для обработки и поддержки разногласий после принятия решений. особенно если вы не участвовали в принятии этого решения . Мы черпали вдохновение из существующих структур для создания структуры разногласий по принятию решений.
С тех пор, как мы начали внедрять эту структуру, я был потрясен результатами. Приняв эту концепцию, наша команда предложила значительно лучшие, более инновационные и менее технически сложные решения. Никто не чувствовал, что они пошли на компромисс или «сдались» по важным вопросам. В этом посте я поделюсь с вами принципами принятия решений.
Вы можете просмотреть наш шаблон структуры разногласий в отношении решений здесь.
Вот пошаговое руководство по использованию разногласий в отношении решений рамки:
Содержание статьи
1. Установите параметры
Определите, следует ли вам использовать основу для несогласия с решением
Если вы не согласны с решением:
Далее если вы не согласны с решением, спросите себя:
Решение замедлит, повредит или разрушит бизнес?
Если ваш ответ положительный, используйте каркас. В противном случае разногласие, скорее всего, не стоит времени и усилий, связанных с использованием структуры.
Если вы принимаете решение о несогласии члена команды:
Во-первых, подтвердите несогласие и перефразируйте мнение человека, не согласного с тем, чтобы удостовериться, что он знает, что его услышали. , Во-вторых, попросите человека ответить на вопрос выше.
Определите разногласие
Краткость является ключевым фактором. Определите разногласие максимум от 1 до 3 предложений.
Определитесь с лицом, принимающим решение.
Может быть только один человек, принимающий решение. Хотя каждый член команды будет заслушан, один человек примет окончательное решение во благо бизнеса. Если у вас стартап, в котором работает менее 15 человек, или в стартапе, подходящем для рынка продуктов, этот человек должен быть генеральным директором. Если вы работаете в более крупной компании, лицо, принимающее решения, должно быть руководителем или руководителем межфункциональной группы. Это может быть руководитель продукта, руководитель отдела разработки или руководитель отдела разработки. Выберите человека, который имеет наибольшее значение для данного решения. Крупным компаниям может потребоваться дополнительный утверждающий (например, генеральный директор, главный продукт / инженер / дизайнер или даже генеральный директор). Однако имейте в виду, что структура оптимально подходит для небольших групп и компаний.
Определение заинтересованных сторон
Перечислите всех людей, которым необходимо получить информацию прежде чем лицо, принимающее решение, может принять свое решение. Этот шаг необходим для того, чтобы все участники посвятили свое время тому, чтобы высказать свое мнение и быть услышанным до принятия окончательного решения.
2. Обсудить варианты
Прежде чем объединять заинтересованные стороны, человек, который поднимает несогласие с решением, должен перечислить 2–3 первоначальных варианта разрешения для обсуждения в команде. Это экономит время: делая это до встречи группы, человек, вызывающий разногласия, продуктивно обрабатывает свои мысли и готовит различные варианты, а также усилия, плюсы и минусы каждого варианта. В качестве необязательного шага заинтересованным сторонам могут быть отправлены различные варианты разрешения до собрания.
Этот шаг соответствует одной из самых важных причин, по которой люди присоединяются к небольшим компаниям: они хотят быть частью процесса, не просто сказал, что делать.
Помните, что все в порядке, если их выбор не является частью окончательного решения, если команда уделяет ему время и внимание. Это означает слушать, чтобы понять или активное слушание. Сравните это с прослушиванием ответов, когда люди слушают, когда они думают о своих собственных идеях (соглашаются они или не соглашаются) и разрабатывают свой ответ.
3. Сбор голосов, принятие решения и документирование обоснования
После того, как все варианты были рассмотрены и обсуждены в группе, лицо, принимающее решение, должно спросить каждого участника: За какой вариант вы голосуете и почему?
В отличие от слепого голосования, это следует делать открыто, в групповой обстановке. Это не только упражнение по эффективному принятию решений, но и повышение прозрачности, честности и откровенности — ключевые навыки для хорошей работы в небольших компаниях.
После того, как лицо, принимающее решения, услышало от каждой заинтересованной стороны, пришло время для этого человека, чтобы принять решение и объяснить обоснование. После того, как решение было заявлено, лицо, принимающее решение, просит вслух поддержать каждого члена команды. Это создает общее мышление и путь для продвижения команды на благо компании. Наконец, лицо, принимающее решение, сообщит о решении и его обосновании всей компании в течение 24 часов. Если ваша компания использует Slack, рассмотрите возможность принятия решения в общем канале вместе с заполненным рабочим листом. Если ваша компания не использует Slack, электронная почта в масштабе всей компании является хорошим вариантом для обмена решением и связанным с ним обоснованием.
В Matter использование этой структуры предоставило гораздо более гармоничный метод для решения разногласий, а также значительно лучшие решения.
Важно, что эта структура не требует от людей компромисса, сдачи или отказа от своих сильных возможностей. Скорее, это основанная на команде структура, которая приводит к групповым решениям.
Вы можете просмотреть наш шаблон структуры разногласия по решению здесь.
Когда следует использовать структуру разногласия по решению?
Не каждое решение требует использования рамок разногласий в отношении решений. Используйте систему разногласий в отношении решений, чтобы справиться с конфликтами, которые могут замедлить, нанести вред или разрушить ваш бизнес. Давайте рассмотрим несколько примеров:
Пример 1: Не подходит для рамок разногласий в отношении решений
Продукту / технике не нравится цвет кнопка. Почему это не подходит для рамок разногласий по поводу решений? Во-первых, это субъективное мнение, которое вряд ли замедлит вашу компанию или нанесет ущерб долгосрочным перспективам. Во-вторых, это можно решить с помощью короткого разговора с разработчиком, который включает быструю обратную связь, своевременное решение и краткое обоснование этого решения.
Пример 2: Подходит для несогласия с решением Framework
В проекте создан новый пользовательский интерфейс с возможностью фильтрации для сортировка списка предметов. Для этой функции сортировки потребовалось меньше суток. Когда инженеры подготовились к работе над этой функцией, они поняли, что это займет две недели работы из-за всех скрытых сложностей. В этом сценарии инженеры могут использовать структуру разногласий в отношении решений, чтобы продуктивно и эффективно встречаться с ключевыми заинтересованными сторонами (проектирование, проектирование и продукт), чтобы решить, как двигаться вперед наилучшим для бизнеса образом.
Почему полезна ли эта структура разногласий при принятии решений?
- Она помогает лидерам создать культуру прозрачности, честности и откровенности, которая является ключевой для людей, которые хотят работать в небольших компаниях.
- Это помогает человеку, который не согласен, делиться своими проблемами кратко, эффективно и продуктивно.
- Это помогает членам команды сопереживать с точкой зрения человека. В приведенном выше случае использования продукт и дизайн могут быть удивлены, узнав, что для создания возможности фильтрации требуется две недели.
- Это помогает человеку, который не согласен, узнать об исследованиях и глубоком размышлении, которые стояли за решением.
- Это помогает получить начальные параметры на столе. Вместо того, чтобы человек, который не согласен с этим, «попытался придумать» и попытаться представить свои проблемы в режиме реального времени, варианты продумываются до того, как они будут переданы в команду для рассмотрения.
- Это помогает команде прийти к общему пониманию сложности разногласий и разрешения. После того, как решение принято, каждый может принять решение, наилучшее для бизнеса.
Выводы:
- Несогласие не является грязным словом 💡
- Лидеры должны работать над созданием культуры, в которой люди могут не соглашаться с решениями, которые могут замедлить, навредить или сломать ваш бизнес 💯
- Практикуйте активное слушание, не слушая, чтобы ответить respond
- Результативные разногласия по принятию решений приведут к гораздо лучшим результатам 🔮
Если то, как мы работаем в Matter, находит отклик у вас, мы с удовольствием пообщаемся! Если вы заинтересованы в присоединении к команде Matter, просмотрите наши возможности карьерного роста здесь.
Спасибо Даниэлле Рубинову, Керему Казанскому и Ленни Рачицкому за то, что они прочитали проекты и предоставили откровенную обратную связь.