Пост Мортемы Без Упреков и Культура Справедливости

В продолжение предыдущего поста:

Перевод статьи Джона Оллспоу "Blamelless PostMortems and a Just Culture"

На прошлой неделе Оуэн Томас написал лестную статью на Buiseness Insider о том, как мы в Etsy работаем с ошибками. Я думаю, что могу немного уточнить, как мы в действительности это делаем, и почему.

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

Сбои просто случаются. Если вы работаете со сложными системами, то этот вывод предопределен. Но что насчет сбоев, которые случаются из-за действий (или, в некоторых случаях, отсутствия действий) отдельных людей? Что вы делаете с теми небрежными людьми, которые устроили весёленький денек для всех?

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

Это традиционный взгляд на "человеческие ошибки", сосредоточенный на особенностях вовлеченных в происшествие людей. Это то, что Сидни Деккер называет "Теорией Испорченного Яблока" - избавьтесь от испорченных яблок, и вы избавитесь от человеческих ошибок. Выглядит просто, не так ли?

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


Пост-Мортем Без Упреков

Что значит проводить Пост-Мортемы Без Упреков?
Значит ли это, что все могут делать ошибки и им это сойдет с рук? Нет.

Ну, может быть. Это зависит от того, что для вас значит "сойдет с рук". Позвольте мне объяснить.

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

Процесс Пост-Мортемов "без упреков" означает, что инженеры, чьи действия способствовали появлению катастрофы, могут детально описать:

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

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

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

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

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

Цикл "назови-упрекни-пристыди" выглядит примерно так:

1. Инженер что-то делает, и в результате становится соучастником сбоя или инцидента
2. Инженера наказывают, пристыжают, всячески упрекают, или отправляют на переобучение
3. Уменьшается доверие между инженерами "у сохи" ("острый конец") и менеджментом ("тупой конец"), занятым поиском козлов отпущения
4. Инженеры начинают замалчивать детали касательно действий/обстановки/наблюдений, что приводит к работе в стиле "Прикрой Свою Заницу" (из-за страха перед наказаниями)
5. Из-за молчания, упомянутого в предыдущем пункте, менеджеры получают меньше информации о том, как идет повседневная работа, а инженеры хуже информированы на счет спящих или скрытых обстоятельств, которые могут стать причиной катастрофы
6. Шансы ошибиться растут, скрытые обстоятельства невозможно определить из-за п.5
7. Переходим к п.1

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

Основной принцип здесь - это сказанное Эриком Холлнагелем:

Мы должны понимать, что катастрофа произошла не потому, что кто-то играл и проиграл.  

Катастрофы случаются потому, что кто-то верил что:  

...то, что только что случилось невозможно 

...или то, что только что случилось, никак не может быть связано с тем, что они делают 

...или что вероятная выгода от сделанного стоит любых потенциальных рисков

Второй Уровень Понимания

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

Исходя из "За Человеческой Ошибкой" получается следующая разница между пониманием человеческой ошибки "первого уровня" и "второго уровня":

Первый Уровень Понимания	Второй Уровень Понимания
Человеческая ошибка стала причиной сбоя	Человеческая ошибка - это следствие системных уязвимостей в самой организации
Сказать, что  именно люди должны были сделать - это подходящий способ описать произошедший сбой	Рассказы о том, что люди должны были сделать, не объясняют, почему то, что они сделали, казалось для них разумным
Если мы скажем, что в следующий раз  надо быть более аккуратными, мы решим проблему раз и навсегда	Только постоянный поиск уязвимостей поможет организации улучшить безопасность

Позволяя Инженерам Владеть Своими Историями

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

Так что, технически, инженерам не совсем "сойдет с рук" содеянное, если применять процесс Пост-Мортемов Без Упреков. Им еще как придется постараться, чтобы помочь Etsy в результате стать более безопасным и надежным. И вот смотрите: большая часть инженеров, которых я знаю, считают, что упрощать работу другим людям это отличное занятие.

Так что же мы делаем чтобы "Культура Справедливости" работала в Etsy?

• Мы поощряем познание через Пост-Мортемы "без упреков" по результатам перебоев в работе и катастроф
• Наша цель - понять как инцидент мог случиться, чтобы в будущем встретить его во всеоружии
• Мы ищем Второй Уровень Понимания, копаемся в деталях, смотрим с разных точек зрения на сбой, и мы не наказываем людей за то, что они делают ошибки
• Вместо того чтобы наказывать инженеров, мы даем им необходимые полномочия по улучшению безопасности, позволяя им детально описать свой вклад в происшествие
• Мы даем возможность, и даже поощряем людей, сделавших ошибку, становиться экспертами в обучении остальной организации по части того, как не допустить подобного в будущем
• Мы допускаем, что всегда есть ситуации, в которых люди принимают решение о том, что делать, а что нет, на свой страх и риск, и что адекватная оценка этих решений возможна лишь после их принятия
• Мы допускаем, что ошибка ретроспекции будет и дальше мешать нам правильно оценивать произошедшие события, но мы усердно работаем на тем, чтобы избавиться от нее
• Мы так же допускаем, что избежать фундаментальной ошибки атрибуции атрибуции трудно, поэтому мы стараемся сосредоточиться на окружении и обстоятельствах вовлеченных людей при исследовании инцидентов
• Мы стараемся убедиться, что "тупой конец" организации понимает, как работа на "остром конце" происходит на самом деле (в противоположность их представлению о процессах из описания процедур и диаграмм Ганта)
• "Острому концу" полагается информировать организацию о том, где проходит граница между корректным и некорректным поведением. Это не та вещь, которую "тупой конец" способен проделать самостоятельно

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

С одной стороны, мы можем решить, что единственной причиной может быть только некомпетентность, и орать на инженеров "будьте внимательнее!" или "будьте аккуратнее!".

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

Вот почему мы в Etsy практикуем Пост-Мортемы Без Упреков, и по той же причине мы стараемся создать у себя Культуру Справедливости.

_______________________________________________________________

Примечания переводчика:

1. "Тупой/острый конец" это отсылка к модели причин несчастных случаев (модель "швейцарского сыра" это одна из них, да) Ричарда Кука и Дэвида Вудса. Я позже постараюсь о ней написать.

Спасибы rovena antary за то что обычный русский язык победил мой собственный русский язык

Проблемы тестирования это результаты тестирования

Перевод вот этой статьи Майкла Болтона (от 9 Сентября 2011 года)

Часто во время курса "Быстрое Тестирование ПО", я провожу упражнение, в ходе которого прошу людей записать те вещи, которые, по их мнению, замедляют тестирование и делают его сложней. Эти списки отлично ложатся на шаблон, который я снова и снова слышу от тестировщиков (вы можете посмотреть пример такого шаблона в этой беседе на Stack Exchange). Обычные пункты в этих списках выглядят так:

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

В добавок к этому:

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

Ах да, вот еще:

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

Как мы можем принять во внимание все эти наблюдения?

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

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

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

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

• Осознают ли люди риски (особенно риски вроде Черных Лебедей), которые обычно несет с собой усложнение?
• Если люди осознают эти риски, обращают ли они на них достаточно внимания? Паникуют ли они из-за этого? Или они игнорируют их, в надежде пролететь мимо кладбища? Или...
• Люди реагируют спокойно и прагматично? Знают ли они об этой сложности, пытаются ли с ней что-то сделать? Если они не могут сделать продукт или процесс, который данный продукт моделирует, менее сложным, пытаются ли они делать какие-нибудь шаги в сторону большего понимания продукта и упрощению его обработки?
• Может быть программисты создают и модифицируют код настолько быстро, что они не успевают понять, что в действительности происходит?
• Если кто-то чувствует что нужно больше тестировщиков, то что скрывается за этим ощущением? (я уже пытался ответить на этот вопрос несколько лет назад)

Как мы можем получить ответы на эти вопросы? Один из способов - присмотреться к результатам и мета-результатам тестов.

• Догадывается ли кто-нибудь, что тестирование очень сложное, и занимает много времени? Кто? Что является причиной таких догадок? Какие предположения лежат под ними?
• Правда ли исследование и описание багов перегружает тестировщика настолько, что ему трудно поддерживать хорошее покрытие тестами продукта? (я писал об этой проблеме тут)
• Показывает ли тестирование сложившиеся шаблоны ошибок в продукте?
• Постоянно ли программистов удивляют эти ошибки и шаблоны?
• Приводят ли небольшие изменения кода к непропорционально большим и труднообнаруживаемым проблемам?
• Хорошо ли программисты понимают все взаимозависимости? Нужны ли эти взаимозависимости или от них можно избавиться?
• Принимают ли программисты какие-нибудь шаги для того чтобы сократить или предотвратить проблемы с интерфейсами или взаимодействиями?
• Если автоматические проверки трудно разрабатывать и поддерживать, говорит ли это что-то о навыках тестировщика, о качестве интерфейсов для автоматизации или об области проверок? Или это говорит о чем-то другом?
• Являются ли нестабильные сборки преградой на пути более детального и глубокого тестирования? Или мы можем считать, что нестабильные сборки это признак того, что проблем настолько много и они настолько серьезные, что даже поверхностное тестирование легко демонстрирует их?
• Когда мы наконец получаем "стабильную" сборку после серии нестабильных, насколько она стабильна в действительности?

Возможно, ответив на эти вопросы мы сможем поднять еще больше вопросов.

• Какие риски могут возникнуть из-за этих проблем на пути продукта к успеху? Долгосрочные это риски или краткосрочные?
• Если тестирование постоянно демонстрирует шаблонные ошибки и постоянно присутствующий риск, то что команда работающая над продуктом предпринимает по этому поводу?
• Должны ли программисты просто поставлять код? Или они должны поставлять код, который обязан делать то, что он должен делать (и не делать того, чего не должен делать) по мере их знаний?  Предпочитают ли программисты последний вариант?
• Давит ли кто-нибудь на программистов, заставляя взять на себя дополнительные обязательства, или управиться в сроки, которые в реальности не достижимы?
• Могут ли программисты и тестировщики избавиться от давления и лишних обязательств в случае когда они ставят под угрозу продукт или проект?
• Прислушивается ли менеджмент к жалобам команды разработки? Насколько они в курсе проблем которые пытаются донести до них программисты и тестировщики? Когда команда разработки указывает на наличие риска, делает ли менеджмент что-нибудь по этому поводу?
• Работает ли команда в устойчивом темпе, или мы должны ожидать, что продукт и проект сокрушат сложности, взаимозависимости, хрупкости, проблемы, которые скрываются за пределами возможностей команды разработки и тестирования?
• Действительно ли команда Agile в тех терминах, что обозначены в Agile Manifesto? Или эта "гибкость" всего лишь культ карго, маскирующийся за артефактами и внешними атрибутами другой методологии?

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

Нужно ли вам больше Тестеров? Упражнение в рамках контекстного подхода.

Перевод вот этой вот статьи Майкла Болтона (от 29 Апреля 2007-го года)

Эта дискуссия о лучших практиках в отрасли началась недавно на comp.software.testing:

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

Мой (слегка отредактированный для этого блога) ответ был...

• Если вы собираетесь найти все баги, то 100 тестеров на программиста будет куда лучше чем полтора. Ваши клиенты могут счесть это впечатляющим (если они захотят за это платить), но ваш финансовый директор взбесится. И все еще не будет никакой гарантии, что вы найдете все баги.
• Если вы хотите сэкономить, то 0 тестировщиков будет куда лучше, чем полтора на программиста. Это даже может сработать, но будет ли вы уверенны в том, что все важные вопросы о вашем продукте были заданы, а ответы на них были получены?
• Если уж вы собрались действительно сэкономить, то 0 тестеров на 0 программистов будет самым лучшим решением.

Мы еще не говорили о квалификации тестировщиков и программистов, вовлеченных в процесс. Мы ничего не сказали об области бизнеса и сопутствующих рисках. Мы еще не говорили о том, считаете ли вы тест менеджеров и админов тестерами, или можно ли считать ваших программистов тестировщиками, когда они тестируют. (Мы так же не поговорили о ситуации, возникающей, когда вы принимаете эти "1,5 тестера на программиста" как "лучшую практику" для команды из трех программистов буквально - какую половину от пятого тестировщика вы бы хотели сохранить? Подсказка: выбирайте ту, что с головой).

С моей точки зрения, на этот вопрос невозможно ответить, не обладая большей информацией о контексте - опыт работы в компании, с командой разработчиков, в технических или бизнес-областях? бюджет? график? размещение программистов и тестировщиков? цель тестирования? Другая точка зрения: вне зависимости от ответов на вопросы, озвученные выше, "лучшая практика" - бессмысленный маркетинговый термин, как правило означающий "что-то, что наша большая и дорогая консалтинговая компания продвигает потому, что это сработало для нас (или мы слышали, что для кого-то работает) ноль или более раз". "Лучшие практики в индустрии" еще хуже. Какой индустрии? Если вы разрабатываете биллинговое веб-приложение для медицинской компании вы в "веб"-индустрии, в индустрии "програмного обеспечения", в индустрии "медицинских услуг" или в "финансовой" индустрии? Я писал уже о "лучших практиках" для журнала Better Software; вы можете найти статью тут (http://www.developsense.com/articles/Comparitively%20Speaking.pdf).

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

Один из ответов в той дискуссии был таким:

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

Это выгладит вполне разумным. Тем не менее, есть одна вещь которую проделывают последователи контекстного подхода для того, чтобы точить свое ментальное оружие. Мы берем утверждения вроде этого, и применяем к ним Правило (Как Минимум) Трех
 (которое пришло из работ Джерри Вейнберга). "Если вы не смогли придумать по меньшей мере трех альтернатив, то вы, вероятно, не достаточно подумали". Когда мы хотим умеренно потренироваться, мы ищем от (Как Минимум) Трех до (Как Минимум) Десяти.

Итак, выше мы видим один из возможных подходов для уменьшения уровня дефектов в релизе. Можем ли мы придумать по меньшей мере еще девять?

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

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

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

Количество "пропущенных дефектов" это просто число. Ни одно число не скажет вам того что вам действительно нужно. Числа могут провоцировать вопросы, но мир очень сложное место. Если вы не придумали как минимум трех (или десяти, или семнадцати) возможных вариантов, то могут найтись важные варианты которые вы пропустили.