Спорить не обсуждают!

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

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

Экспериментируйте, не спорьте!

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

Ошибочные аргументы: мы все слышали их раньше

Что отличает бессмысленную ссору от продуктивного обсуждения? Основная характеристика первого состоит в том, что люди используют в основном неверные мнения, чтобы убедить другую сторону. Аргументы могут быть ошибочными по разным причинам, в том числе по следующим:

  • «Общеизвестное» решение: аргументы этого типа основаны на идее, что кто-то протестировал какие-то идеи и где-то опубликовал результаты тестов. Однако результаты могут быть неактуальными сейчас или в другой среде. Подумайте обо всех тестах, доказывающих, что JavaScript на стороне сервера не имеет смысла (и что по этому поводу думают создатели Node.js).
  • Выборочная проверка: этот тип рассуждений, также известный как «это не работает для меня», является популярным подходом для признания аргумента недействительным. Что с этим не так? Во многих случаях оценка, основанная на одном примере, никоим образом не является действительной: это может быть чистая (плохая) удача, что данный «неработающий» случай был выбран из большого набора успешных.
  • Предвзятое мнение: обычно оно основано на предыдущем опыте, приводящем к склонности за или против определенных результатов. У некоторых есть предубеждения в отношении определенных текстовых редакторов, вкладок или пробелов или определенных IDE.

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

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

«Тест, проводимый для того, чтобы что-то узнать или выяснить, работает ли что-то или правда».

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

Как спланировать эксперимент

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

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

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

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

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

Эксперименты ≠ A / B-тестирование

Проведение экспериментов как основы для принятия технических решений слишком часто сводится к A / B-тестированию. A / B-тестирование - это методика выбора одного варианта из двух возможных решений. Вы должны выбрать две группы пользователей и проанализировать их реакцию на вариант A или B. Объем экспериментов шире, чем A / B-тестирование: вы можете, например, сравнить скорость двух разных реализаций данного алгоритма. В этом эксперименте не участвует ни один пользователь, поэтому это не A / B-тестирование.

Как получить данные для экспериментов

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

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

Лучшим источником данных для большинства экспериментов являются производственные данные.

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

Потребность в экспериментальных площадках

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

Многие компании, такие как Microsoft, Google, Uber, Airbnb, Pinterest и Netflix, уже имеют экспериментальные платформы и пишут об этих платформах в своих технических блогах. Другие компании предлагают платформу для экспериментов в качестве продукта: Google Optimize, Adobe Target, ax.dev (от Facebook) или Optimizely.

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

Вы проводите эксперименты на производстве или горячо сторонник жарких споров в повседневной работе? Я хотел бы услышать о вашем опыте ссор в команде и экспериментов на производстве. Не стесняйтесь делиться своими неудачами в принятии решений и хвастаться своими успехами в комментариях!