Прекращение бесконечных технических дискуссий и принятие решения

27

Я всегда сталкиваюсь с людьми, которые любят целую вечность стучать по самым маленьким «техническим вещам».

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

  • Mac намного лучше, чем Windows
  • Не используйте цикл For Each, используйте цикл While
  • Не покупайте ПК на базе Intel, приобретайте AMD.
  • Мы должны использовать один контейнер IoC поверх другого.

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

Мой вопрос (я получаю!): Как вы, команда разработчиков программного обеспечения, проходите долгие дискуссии, не препятствуя инновациям, чтобы можно было принять решение и приступить к решению реальных бизнес-задач.

Озз
источник
2
Вы говорите "уйти" - это не ответ? Вы говорите о ситуациях, когда вы должны прийти к решению? Или вы говорите о ситуациях, когда нет практического ответа, кроме как уйти?
S.Lott
1
Да, именно это и должно означать мое последнее предложение: «Давай просто выберем что-то уже и приступим к решению бизнес-проблемы».
Оз
Подобные вещи могут происходить во многих областях, поэтому я не думаю, что это здесь по теме.
Дэвид Торнли
Действительно ли вы свинец?
3
Положите цепную пилу на стол. Ты принес свою цепную пилу, не так ли? :)
Vitor Py

Ответы:

25

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

Проблема 2. На самом деле ничего не поставлено на карту, поэтому обсуждение допускается.

Ничего не поставлено на карту? Да. Большинство решений имеют почти нулевое влияние на доллар. Тот факт, что все сводится к «удару на века», означает, что оба варианта фактически идентичны.

Что делать?

  1. Поймите, что ничего не поставлено на карту.

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

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

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

С. Лотт
источник
2
Хороший ответ - две проблемы в общих чертах описывают с самого начала, что приводит к подобным вещам.
Джон Хопкинс
9

Несколько вещей для размышления:

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

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

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

Джон Хопкинс
источник
2
Я не большой поклонник оценки сотрудника на техническом решении, которое они приняли в прошлом. То, что вы можете получить, это то, что никто не хочет брать на себя ответственность, и хотя это может помешать продолжительным и ненужным дискуссиям, это также может остановить любое полезное и разумное обсуждение. Кроме того, вы даете ощущение, что ошибаться считается плохим. По моему опыту в сфере программного обеспечения, люди все время ошибаются, но это не значит, что они не знают, о чем говорят. Просто то, в чем вы были убеждены, на самом деле не удавалось так, как вы думали.
Anne Schuessler
2
@ Энн, я думаю, что есть разница между поиском мнений и двумя / несколькими людьми, которые бьют головой о чем-то, что сдерживает команду. Джон замечательно замечает, что если вы заботитесь о том, чтобы тратить время / деньги на удержание команды в заложниках из-за спора, вы должны нести ответственность
Стив Джексон
2
+1 за то, что заставил людей количественно оценить свои аргументы. Это обычно спешит многих людей в спешке.
Джон Боде
1
@Anne - Это было бы частью оценки, а не автоматически отрицательной вещью. Я, конечно, не стал бы отговаривать людей принимать решения, но вам также нужно, чтобы люди понимали, что решения имеют последствия и что они не могут просто выстрелить из бедра.
Джон Хопкинс
@ Джон и @ Стив Да, думаю, я понял. Я согласен с частью ответственности, я бы просто боялся, что людям может показаться, что они могут получить выговор за принятие ответственности, когда выяснилось, что их первоначальное решение не сработало. Если вы заставляете кого-то брать на себя ответственность за то, к чему он испытывает сильные чувства, вы должны убедиться, что, если он действительно не испортил время, он все равно будет вознагражден за принятие мер. Если это так, то я все на борту.
Anne Schuessler
6

Кухонный таймер

  1. Timebox обсуждение. - Если каждой стороне требуется более 5 минут, чтобы изложить свою позицию, то это слишком сложно. Мы фактически используем кухонные таймеры для этого . Они прекрасно работают и стоят около 5 долларов.
  2. Требуйте, чтобы участники спорили с данными и опытом.
  3. Мы держим варианты на столе. После того, как у каждой стороны есть свое время, мы тратим еще 5 минут на обсуждение последствий каждого подхода. Через 20 минут мы выходим и делаем это (реализуем). Если это не работает, то мы идем с другим подходом.
Джордж Стокер
источник
5

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

Да, выбор Intel v AMD не так прост. Но что лучше для вашей компании? Например, если есть человек, который отвечает за заказ вещей, и ему понадобится целая вечность, чтобы заказать ПК на базе процессора AMD, но на базе Intel можно заказать за минуту, и вам действительно все равно, что это будет - просто закажите Intel на основе, потому что это лучше для компании.

Sharptooth
источник
У нас было это решение для карманного компьютера. Получить один бренд было настолько сложно (мы должны были быть авторизованным торговым посредником, который требовал заполнения форм после заполнения форм), что мы пошли с его конкурентом.
Пьер-Ален Вижан
5

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

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

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

оборота back2dos
источник
3

Стандартизация - это один из подходов

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

«Эй, в конце концов, эти компьютеры были бесполезны, давайте попробуем Mac!»

или

«Я же тебе говорил! Весна намного лучше, чем EJB».

И так далее.

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

Гэри Роу
источник
Стандартизация среды, особенно оборудования и операционных систем, имеет один недостаток, который стоит признать: некоторые проблемы, возникающие в результате взаимодействия вашего приложения и среды, будут замечены только вашими пользователями / клиентами - классическое «это работало на моей машине!». В зависимости от типа приложений, которые вы создаете, может быть предпочтительнее сохранять среду разработки разнородной, чтобы вы могли обнаружить такие ошибки перед отправкой продукта (или, если у вас отдельная среда тестирования, оставить хотя бы ее неоднородной).
Joonas Pulakka
@Joonas Совершенно верно. Я хотел бы взглянуть на стандартизированный процесс сборки (например, Maven), который позволяет любому использовать любую IDE / vim / emacs и т. Д., Но с формальным процессом непрерывной интеграции, чтобы гарантировать, что у вас всегда есть рабочая сборка под управлением исходного кода (или в меньше всего известно, что вы в настоящее время не).
Гари Роу
3

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

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

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

Яцек Прусия
источник
3

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

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

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

user1249
источник
3

Один из подходов - голосование и хорошо работает в небольших командах.

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

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

Аарон Макивер
источник
1

Подобный вопрос может быть:

Как остановить религиозные / пламенные войны на форумах?

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

Если дело в том, чтобы прийти к решению, взвесить все за / против для рассматриваемого домена, установить ограничение по времени и (кивает на Nike) просто сделать это.

DevSolo
источник
Я делаю это, когда люди просто болтают. Обновленный вопрос, чтобы быть более конкретным
ozz
1

В идеале - ИМО - технический лидер или авторитетный человек говорит: «Хорошо, спасибо за ваши очки, мы ...« звук броска костей »... идем с такой-то идеей». и все идут и садятся.

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

Пол Натан
источник
1

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

Роберт Россни
источник
1

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

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

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

crosenblum
источник
1

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

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

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

quant_dev
источник
1

Сначала решите общие проблемы: нам нужен веб-сервер, сервер приложений, БД и т. Д.

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

Во время последующих встреч дайте возможность обсудить «короткий список» потенциальных предложений, например, MySQl, MS SQL Server, Postgres и т. Д.

Позвольте членам команды высказать свое мнение, но попросите, чтобы они подкрепили их фактами. Продукт X отстой! Не сокращает, Продукт Y не масштабируется! Слишком расплывчато И т.п.

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

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

scunliffe
источник
1

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

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

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

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

мин
источник
1

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

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

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

Карл Билефельдт
источник
0

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

Марси
источник