В этой статье поговорим о том, как противостоять нездоровому уровню конформизма в команде и помогать ей своевременно принимать взвешенные решения.

В 1950-х психолог Соломон Аш провёл обманчиво простой эксперимент; один из его прогонов можно посмотреть на YouTube. В каждой сессии участвовала группа людей, все они были частью эксперимента, но только один человек был настоящим испытуемым. Остальные были подставными участниками, которым поручили давать заведомо неправильные ответы. Задача заключалась в том, чтобы сопоставить одну линию, нарисованную чернилами на табло, с другой линией той же длины. Когда подставные участники единогласно называли неверный вариант, более трети настоящих испытуемых подстраивались и выбирали тот же неправильный ответ — несмотря на то, что правильный был очевиден.

Дело было не в незнании. Это было проявление конформизма без рефлексии: когда «плывешь по течению вместе со всеми», не задумываясь о возможных негативных последствиях.

Какое это имеет отношение к разработке ПО? Большее, чем нам хотелось бы думать.

Как вы думаете, сколько дефектов возникает из-за неосознаваемого конформизма?

Сколько раз вы видели, как в разработку проталкивают едва тестируемую фичу — не потому, что она готова, а потому что все остальные согласно кивнули? Или, может быть, вы наблюдали, как продуктовая и инженерная команды с гордостью выкатывают фичу, в полезность которой, по-честному, никто в глубине души не верил?

Я сам был одним из таких разработчиков. Однажды я руководил полным редизайном приложения — не потому, что он решал какую-то проблему, не потому, что мы руководствовались обратной связью от клиентов или результатами исследования, а потому что «продакт-менеджеру показалось, что пора». Мы выкатили новую версию. А через месяц откатили всё назад, когда упали ключевые пользовательские метрики. Мы не учли потребности пользовательской базы — многие сидели на старых мобильных устройствах. Новая версия, набитая анимациями и параллакс-эффектами, работала у них мучительно медленно. Короче говоря: до начала разработки никто не поставил редизайн под сомнение.

Сейчас я понимаю, что проблема была не в недостатке навыков или усилий. Причиной был неосознаваемый конформизм.

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

Конформизм у людей — это фича, а не баг… большую часть времени

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

К сожалению, эта склонность закрепляется задолго до того, как мы выходим на работу. Эдвард де Боно, автор термина «латеральное мышление», неоднократно критиковал традиционное образование за поощрение того, что он называл «вертикальным мышлением»: решения заранее заданных задач в жёстких рамках. Стандартизированная образовательная система вознаграждает послушание, а не любопытство. К моменту выпуска большинство разработчиков уже научились оптимизировать внутри границ, а не ставить эти границы под вопрос.

Дональд Шён в книге «Рефлексивный практик» также отмечает, что профессионалы склонны по умолчанию переходить в режим «решения проблемы», вместо того чтобы задумываться о том, как именно проблема сформулирована. В софтверных командах эта привычка только усиливается. Разработчиков нанимают, чтобы они делали, а не сомневались. Их оценивают по способности строить, а не по способности оспаривать поставленные задачи и сами формулировки проблем. Более того, сами мыслительные процессы, необходимые для эффективного проектирования и написания кода, подталкивают разработчика смотреть на ситуацию через узкую оптику.

Организационные структуры часто закрепляют бездумное подчинение

Конформизм без рефлексии «вшит» и в большинство организационных структур. Разработчики обычно работают внутри иерархий, а иерархии подразумевают выполнение задач без рефлексии. Даже в agile-организациях нередко можно увидеть KPI и OKR, нацеленные на «делать больше», менеджеров, которые следят за burn-down chart, и индивидуальные планы развития (ИПР), которые составляют для разработчиков, чтобы постоянно подталкивать их выпускать всё больше фич. Всё это делает акцент на результате, а не на осмыслении, и невольно транслирует, что ставить работу под вопрос — не часть обязанностей.

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

Тестировщики ПО могут стать тем самым необходимым голосом несогласия

И вот здесь роль тестировщиков может оказаться по-настоящему сильной.

Ни конформизм, ни несогласие — не черты характера. Это ситуационные реакции. Большинство людей подстраиваются или молчат, пока не увидят, что кто-то другой бросает вызов группе. Социолог Марк Грановеттер описывал это через идею «порога конформизма»: у каждого есть точка, в которой он готов выразить несогласие, и зависит она от того, скольких несогласных он видит вокруг до того, как решится сам. Кто-то выскажется сразу. Но большинству нужно увидеть, что ещё несколько человек поставили норму под сомнение, — только тогда они почувствуют себя в безопасности и присоединятся.

Вот почему так важно, от кого ожидают, кому разрешают и кого поддерживают, когда речь идёт о раннем оспаривании допущений.

В то время как на разработчиков часто действует тонкое давление «не выбиваться из общего ряда», от тестировщиков структурно ожидают — и социально им это позволено — сомневаться, проверять и оспаривать. Социолог Филип Селзник писал, что когда роли институционализируются, они несут нормативные ожидания: не только в том, что ты делаешь, но и в том, как ты себя ведёшь. В случае тестировщиков такое ожидание — находить изъяны.

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

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

Как решить, когда говорить, когда молчать а когда искать середину

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

Каждому тестировщику приходится решать, что он может делать, что он хочет делать и позволяет ли это текущая среда. Но когда такое пространство есть — или его можно создать, — одним из самых практичных и эффективных шагов становится подход shift-left, или сдвиг влево. Отстаивать shift-left зачастую проще, чем отстаивать само несогласие. Это можно подать в прикладных терминах снижения рисков — таких, которые менеджеры обычно понимают интуитивно. Например, раннее вовлечение легко обосновать, если упомянуть кривую Боэма «стоимость изменений» и подкрепить её собранными данными о затраченном времени и задержках, которые возникают, когда задачи возвращаются из тестирования обратно в разработку. Это знакомые «болезни роста», и shift-left предлагает знакомое решение — просто в нём, заодно, несогласие встраивается ровно туда, где оно наиболее ценно.

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

Shift-left тестирование усиливает способность команд справляться со сложностью

При успешном внедрении shift-left подхода тестирование становится чем-то гораздо большим, чем просто изменением процесса.

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

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

В завершение

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

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

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

• 21 января 20:00. «Data-driven против AI-driven: как принимать решения, когда данных мало или они недостоверны». Записаться

• 27 января 20:00. «Зависимость нефункциональных требований и качества продукта». Записаться

• 2 февраля 20:00. «Как тимлиду создавать процессы, которые работают и без него». Записаться

А для тех, кто заинтересован в профессиональном развитии в качестве тестировщика, рекомендуем обратить внимание на курсы: QA Engineer. Basic (тестирование с нуля) и QA Automation Engineer (автоматизация тестирования на Java).