Релиз выпустили по требованиям, которые команда собрала и согласовала с заказчиком. Уже во время реализации отдельные части бизнес-логики начали плохо складываться друг с другом. Разработчик это заметил, но решил, что так и задумано. Аналитик тоже не остановил работу, так как предположил, что вопрос можно решить на уровне реализации.
После релиза выяснилось, что необычной логики там не было заложено, а просто в требованиях остался пробел. Команде пришлось срочно искать временное решение, исправлять последствия и возвращаться к заказчику с вопросами, которые следовало прояснить раньше.
На разборе я подробно расспрашивал участников: когда появились сомнения, кто что видел и почему никто не вынес вопрос на общее обсуждение. Никто не пытался сознательно скрыть проблему или показать более красивый статус. Проблема в тот момент еще не воспринималась как проблема.
«Я решил, что так и задумано».
Первый вывод из ситуации, который приходит в голову, что аналитик и разработчик должны были уточнить требования. С этим трудно спорить. Но если закончить разбор возникшей проблемы фразой «надо было спросить», то мы ничего не поймем о том, как она возникла.
Что стало очевидным только после релиза
После инцидента всё выглядит гораздо яснее. Уже известно, какой сценарий не учтен, где проявилась ошибка и что придется переделывать. В момент первого сомнения такой ясности нет. Есть несколько требований, которые плохо соединяются, и ощущение, что недостающую часть, возможно, понимает кто-то другой.
Ранний сигнал редко похож на потенциально что-то плохое. Чаще он может выглядеть примерно так: «Я пока не понимаю, как эти два условия работают вместе» или «Кажется, здесь есть предположение, которое мы не проверяли». Сотруднику еще нужно решить, стоит ли останавливать работу или он просто не до конца разобрался.
Ли Лу, Конни Юань и Поппи Маклеод объединили результаты 65 исследований групповых решений. В экспериментах разные участники располагали разными фрагментами информации, а правильный вывод зависел от того, смогут ли они собрать их вместе. Однако группы чаще обсуждали сведения, уже известные всем, чем уникальные наблюдения отдельных участников.
В нашей ситуации таким уникальным наблюдением было сомнение разработчика. Аналитик не видел противоречие так же ясно, а руководитель получал только общий статус. Пока разработчик не вынес своё наблюдение на обсуждение, остальные участники не могли сложить полную картину.
Информация была в команде, но не стала информацией команды.
Для меня проблема появилась после релиза. Для команды она началась появляться раньше, но еще не выглядела проблемой.
Дело было не в страхе перед руководителем
Самое привычное объяснение информационной блокады - сотрудники боятся реакции руководителя. Такое действительно бывает. Но к этому случаю оно не подходит. У нас не было запрета задавать вопросы, привычки наказывать за сомнения или требования приходить только с готовым решением.
Фрэнсис Милликен, Элизабет Моррисон и Патриша Хьюлин беседовали с 40 сотрудниками о рабочих вопросах, которые те не поднимали руководителям. В ответах встречались страх негативной оценки, риск испортить отношения, сомнение в пользе разговора и неуверенность в собственной позиции. Исследование было небольшим, но хорошо показало, что за одинаковым молчанием могут стоять разные причины.
В нашем случае каждый нашел объяснение, при котором можно было продолжать работу. Разработчик предположил, что странность заложена в процессе. Аналитик - что вопрос решится при реализации. Эти версии не были абсурдными. Ошибка возникла в том, что их не проверили друг об друга.
К этому могло добавиться обычное нежелание приносить неприятные новости. Сидни Розен и Абрахам Тессер в экспериментах обнаружили, что люди менее охотно передают информацию, которая может расстроить получателя. В рабочей ситуации такой разговор затрагивает еще и профессиональную оценку: вопрос разработчика мог означать, что требования собраны не полностью, он сам их неверно понял или уже выполненную работу придется переделывать.
Поэтому сомнение сначала получает удобное объяснение. Потом человек ждет дополнительных фактов. Затем надеется, что вопрос прояснится по ходу работы. Когда уверенности наконец становится достаточно, новость уже запаздывает.
Два предположения поддержали друг друга
Здесь важен не только выбор каждого специалиста по отдельности. Важно, как отсутствие вопроса с одной стороны стало подтверждением для другой.
Разработчик мог рассуждать так: требования подготовил аналитик, значит, бизнес-логика проверена. Аналитик видел, что разработка продолжается, и мог считать это признаком технической реализуемости. Ни один из них не говорил второму: «я проверил этот фрагмент».
Каждый отвечает за свою часть работы и предполагает, что соседнюю часть проверил специалист, который ближе к ней. Без такого разделения команда вообще не сможет работать. Но иногда предположение о чужой проверке постепенно заменяет саму проверку.
После того релиза нам было полезнее не повторять «будьте внимательнее», а точнее определить момент, когда сомнение уже нельзя оставлять внутри одной роли. Если требование удается реализовать только после догадки о бизнес-смысле, эту догадку нужно вынести на обсуждение. Даже когда пока непонятно, ошибка это или особенность процесса.
Что зависит от реакции руководителя
Позднее сообщение не всегда вызвано поведением руководителя. В той ситуации я не вижу оснований объяснять случившееся страхом перед реакцией. Но руководитель всё равно влияет на то, когда команда принесет следующий слабый сигнал.
Джеймс Детерт и Итан Бёррис изучили 3 149 сотрудников и 223 руководителя одной ресторанной сети. Люди чаще высказывались там, где руководитель на практике показывал готовность рассматривать предложения и вопросы. Одним из объяснений была психологическая безопасность: сотрудники учитывали, чем для них может закончиться такой разговор.
Метаанализ М. Лэнса Фрейзера и его коллег объединил 136 независимых выборок - более 22 тысяч человек и почти 5 тысяч групп. Психологическая безопасность была связана с обменом информацией, обсуждением рабочих вопросов и обучающим поведением. Для руководителя здесь важен не комфорт сам по себе, а возможность услышать сомнение до того, как оно превратится в подтверждённую проблему. Сотрудник должен иметь право сказать: «Я пока не уверен, но здесь что-то не сходится».
Это не обязывает руководителя соглашаться с оценкой и не снимает ответственности за ошибку. Но если за сам факт раннего сообщения человек получает жёсткий разбор, в следующий раз он подождёт более убедительных доказательств.
На практике многое решает то, что происходит в первые минуты после сообщения. Сначала стоит понять возможное влияние и определить следующий шаг. Подробный разбор причин можно провести позже. Когда первый слабый сигнал сразу превращается в поиск виноватого, в следующий раз сотрудник постарается прийти уже с доказательствами и готовым объяснением.
В той истории я подробно расспрашивал команду уже после того, как проблема проявилась. Это было необходимо. Но если бы разработчик пришел раньше только с фразой «логика пока не сходится», ему не следовало бы сначала доказывать, что требования точно ошибочны. Достаточно было показать, на каком предположении держится дальнейшая работа.
Ингрид Нембхард и Эми Эдмондсон исследовали 1 440 специалистов в 23 медицинских отделениях. В командах с заметными статусными различиями сотрудники активнее участвовали в улучшениях там, где руководители явно приглашали их задавать вопросы и вносить предложения. Работа проходила в медицине, где цена ошибки и профессиональная иерархия особенно заметны. Но должность и в разработке влияет на то, насколько рискованным сотруднику кажется вопрос руководителю.
Не каждое сомнение должно идти наверх
При этом пересылать руководителю каждое сомнение тоже не выход. Он быстро превращается в диспетчера, а специалисты постепенно перестают принимать решения сами. Полезная фильтрация информации нужна любой команде.
Я бы смотрел не на степень уверенности сотрудника, а на возможную цену ожидания. Вопрос стоит вынести на обсуждение, когда он может изменить срок или обязательства перед заказчиком, затрагивает данные и деньги, требует решения другой роли или делает позднее исправление заметно дороже.
Фраза «не приносите проблему без решения» пытается защитить руководителя от необработанного потока и развивать самостоятельность. Но у нее есть побочный эффект: человек может ждать готового решения именно тогда, когда ему не хватает чужого контекста.
Точнее сказать так: существенный риск сообщай сразу; если время позволяет, приложи факты, варианты и свою рекомендацию.
Раннее сообщение может быть коротким:
«Два требования не складываются в единый сценарий. Возможно, это особенность процесса, но тогда нам не хватает одного правила. Если продолжим по текущему предположению, после релиза может потребоваться переделка. Нужен короткий разговор с аналитиком и уточнение у заказчика».
Готового решения пока нет, но уже понятно, что именно требует проверки.
Сообщил вовремя - не значит оказался прав
Из этой истории не следует, что любой ранний сигнал автоматически отражает проблему. Риск можно переоценить. Эскалацией можно прикрыть нежелание разбираться. Иногда человек действительно обязан был задать вопрос раньше и несет ответственность за то, что этого не сделал.
В нашем случае ответственность аналитика и разработчика никуда не исчезает. Один видел противоречие при реализации, другой отвечал за целостность требований. Возможность задавать вопросы была. Поэтому разбор должен касаться не только процесса, но и качества профессиональных решений.
При этом раннее сообщение и оценку действий лучше не смешивать в первые минуты. Когда команда срочно ищет временное решение, длинное выяснение вины мешает собирать факты. После стабилизации уже можно восстановить момент первого сомнения, проверить решения участников и договориться, что изменить в работе.
Почему статус "Всё ОК" ничего не гарантирует
На встрече вопрос «есть ли проблемы?» мог не изменить эту историю. Разработчик еще не считал увиденное проблемой. Аналитик не получал отдельного сигнала, который требовал бы реакции. Оба могли честно ответить, что работа идет.
Статус становится положительным не обязательно потому, что кто-то хочет его приукрасить. Каждый участник сообщает уже обработанную версию происходящего. Сомнение, которое кажется недостаточно важным, остается за кадром. Руководитель получает не ложь, а результат нескольких сокращений.
Поэтому время от времени полезнее спрашивать не о проблемах, а о том, что пока не подтверждено. Например: «Какое требование мы сейчас интерпретируем, а не знаем точно?» или «Что может оказаться устроено не так, как мы предполагаем?»
Достаточно одного вопроса. Если превратить встречу в обязательный поиск рисков по длинному списку, люди быстро научатся давать формальные ответы и на него.
Полностью убрать неопределенность не получится. Но сомнение уже нельзя оставлять внутри одной роли, если от него зависит общий результат.
Что проверить на встрече
После этой ситуации команда стала чаще выносить на обсуждение потенциальные проблемы и непонятные места. На первый взгляд, так и должно было быть раньше. Формально возможность задать вопрос существовала. Не хватало более точного понимания, какой вопрос уже нельзя оставлять внутри своей роли.
Чтобы проверить это на практике, не обязательно менять весь процесс. На несколько недель достаточно скорректировать один регулярный статус.
Иногда вместо общего «есть ли проблемы?» задавать другой вопрос:
«На каком неподтвержденном предположении сейчас держится наше решение?»
А при первом слабом сигнале начинать не с виноватого, а с возможного влияния, следующего шага и времени нового статуса. К разбору действий участников можно вернуться после того, как команда ограничит последствия.
Через несколько недель стоит посмотреть, стали ли существенные риски появляться раньше и не вырос ли бесполезный шум от потока информации. Если руководителю начали пересылать каждое сомнение, границы эскалации нужно уточнить. Если новости по-прежнему приходят только вместе с инцидентом, одного вопроса на статусе оказалось недостаточно.
В той ситуации никто не держал готовую плохую новость в столе. Один специалист решил, что требования были странные, другой - что вопрос решится при реализации. «Так и задумано» иногда означает, что человек понял замысел. А иногда - что предположение, на котором держится следующий этап, никто не проверил.