Меня завораживает психология разработчиков программного обеспечения.

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

С этим не по пути…

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

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

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

Избегайте вопроса

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

  • Для каких платформ предназначено программное обеспечение?
  • Что я уже хорошо знаю, чтобы не узнавать ничего нового? (Может быть, Java?)
  • Что мой менеджер предпочел бы, чтобы я использовал? (Возможно, Java…)
  • Что наиболее востребовано в объявлениях о вакансиях? Может ли это быть предлогом, чтобы узнать что-то, что улучшит мое резюме? (Swift! Это должно быть приложение для iOS!)
  • Что, по мнению крутых разработчиков из Hacker News, мне следует использовать? (Эрланг!)
  • Что бы больше всего впечатлило моих коллег? (Хаскелл!)

Борьба!

Другой подход — это подход «обсудить это». Это дебаты, в которых каждый высказывает свое мнение о правильном выборе, а затем следует риторика. Дебаты обычно заканчиваются, когда либо (1) кто-то с хорошими риторическими навыками звучит более убедительно, чем все остальные, либо (2) все, кроме одного человека, устают спорить об этом, и последний человек, желающий продолжать спор, принимает решение. Что, если самый убедительный человек находится вне офиса в отпуске, когда принимается решение… может ли другой выбор победить, потому что следующий по убедительности человек, который не в отпуске, успешно проповедует другое мнение?

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

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