Избыток информации при принятии решений

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

Обычный очевидный ответ на этот вопрос — чем больше информации, тем лучше. Мы пытаемся собрать все, что только можно перед принятием решения, будь то старт нового проекта или выбор фреймворка или библиотеки для проекта или решение о принятии на работу.

Последовательность

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

Люди любят быть последовательными. Очень любят. С последовательностью ассоциированы такие положительно окрашенные вещи, как честность, постоянство, надежность. А с непоследовательностью ассоциированы такие отрицательные штуки, как непостоянство, неуверенность, отсутствие собственного мнения.

Групповая поляризация

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

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

Давление прошлого

Представьте, что вы кидаете монетку пять раз перед аудиторией и случается маловероятное, все пять раз выпадает «орел». Вы просите предсказать, каким будет следующий результат. Как вы думаете, как поделятся мнения аудитории? На что поставите вы сами? Результаты экспериментов показывают, что большая часть людей будет предполагать, что следующей будет «решка». Удивительно? Как бы да, ведь монетка не имеет памяти и каждый раз орел и решка равновероятны. Но память имеют люди. И эта память часто не позволяет здраво оценить вероятность события.

Еще раз про собеседования

В дополнение к посту «Собеседование на работу».

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

Собеседование на работу

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

В нашей компании кроме технического отзыва принято еще давать свое мнение о том, как человек себя держит и общается. Хотим ли мы его видеть в нашем коллективе и т. п. Что можно сказать о этой оценке. Возможно ли что-то понять о человеке за 1-2 часа стандартного собеседования?

Огрупленное мышление

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

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