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

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

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

или

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

И так далее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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