Как проверить экспертный совет на прочность: четыре вида доказательств

Эксперт говорит: «Так делать нельзя». Звучит уверенно. Иногда за этой фразой стоят двадцать лет практики. Иногда — один неудачный случай, который человек носит с собой как закон природы.

Читателю трудно отличить одно от другого. Автору ещё труднее: собственная уверенность ощущается как доказательство.

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

Слабый совет начинается с оценки: «клиенты не любят длинные предложения». Сильный — с наблюдаемого поведения: «после страницы с расчётом до формы заявки доходят 42% посетителей, после версии без расчёта — 19%».

Наблюдение можно увидеть, посчитать или воспроизвести. Оно отвечает на вопросы:

• кто действовал;
• в какой ситуации;
• что произошло до решения;
• что произошло после;
• как часто это повторялось.

Если этих деталей нет, полезно честно назвать фразу гипотезой, а не правилом.

Корреляция ещё не объясняет причину. Продажи могли вырасти после нового скрипта, но в ту же неделю компания снизила цену и запустила рекламу.

Механизм — это цепочка между действием и результатом. Например: менеджер задаёт вопрос о критериях выбора → клиент называет скрытое ограничение → предложение становится точнее → уменьшается число согласований.

Хороший механизм позволяет найти место поломки. Если клиент не назвал ограничение, дальнейший эффект ждать рано.

Профессиональная репутация не рушится от признания исключений. Наоборот, именно ограничения отличают метод от лозунга.

К совету стоит добавить хотя бы один контрпример:

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

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

Самая строгая проверка совета — сделать прогноз до применения.

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

Прогноз должен содержать:

• срок;
• наблюдаемый признак;
• допустимый диапазон результата;
• условие остановки.

Без этого любой исход можно задним числом объявить успехом.

Перед публикацией или передачей рекомендации заполните пять строк:

1. Совет: какое действие предлагается.
2. Наблюдение: на каких фактах он основан.
3. Механизм: почему действие должно привести к результату.
4. Граница: кому и при каких условиях оно не подходит.
5. Прогноз: что изменится и когда это проверять.

Если пустует одна строка, материал ещё можно использовать — но с правильной маркировкой. Нет наблюдений — это гипотеза. Нет механизма — найденная связь. Нет границ — черновик правила. Нет прогноза — мнение, которое пока нельзя проверить.

Совет: «Отвечайте на претензию в течение двух часов».

Наблюдение: в обращениях, где первый человеческий ответ приходил в тот же рабочий день, клиенты реже отправляли повторные сообщения.

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

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

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

Так совет перестаёт быть фразой авторитетного человека. Он становится инструментом, который другой человек может применить, проверить и при необходимости отвергнуть.