Diversus

Есть старая уловка: инспектор ДПС останавливает вас, говорит, что вы нарушили. Вы уверены, что нет, и начинаете спорить. В ответ он задаёт вопрос: «То есть ты мне не веришь?»
Разговор сразу уходит с уровня фактов на уровень отношений и статуса. И дальше спорить почти невозможно.

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

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

Ловушка 1. «Ты хочешь сказать, я не разбираюсь?»

Ситуация. Подчинённый предлагает более эффективный вариант. Руководитель переводит спор в плоскость «компетентности начальника».

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

Как реагировать? Не спорить о компетенции, а подчеркнуть ценность данных.
Решение: Я уверен, что вы разбираетесь. Просто показываю расчёты и предлагаю сравнить варианты. Решать, конечно, вам.
Подмена: Спор о цифрах превращается в спор о компетентности.

Ловушка 2. «Ты не доверяешь моему слову?»

Ситуация. Руководитель передаёт информацию от партнёра или поставщика. Подчинённый проверяет и находит неточность.

Руководитель: Поставщик сказал, что эта система без проблем установится у нас.
Вы: Я проверил, и технически это не так. Потребуются дополнительные работы.
Руководитель: То есть ты не доверяешь моему слову и словам партнёра?

Как реагировать? Покажите, что проверка — не про доверие, а про снижение рисков.
Решение: Я доверяю вам, поэтому и проверил слова поставщика. Вот, что показала проверка. Теперь можно обсудить риски и цену доработки.
Подмена: Вместо оценки фактов — вопрос личного доверия.

Ловушка 3. «Ты ставишь под сомнение мои приоритеты?»

Ситуация. Руководитель называет задачу «срочной», а подчинённый указывает на последствия для других проектов.

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

Как реагировать? Признайте право начальника на приоритет, но верните его в поле выбора.
Решение: Приоритеты определяете вы. Моя задача — показать последствия. Если делаем А сейчас, то Б задержится на месяц.
Подмена: разговор о ресурсах превращается в разговор о “лояльности” к стратегическим целям.

Чек-лист: как выходить из провокационных ловушек

Что делать ✅

• Спокойно возвращайте разговор в плоскость фактов и цифр.

• Подчёркивайте право руководителя на финальное решение.

• Формулируйте аргументы через заботу о бизнесе: «чтобы снизить риски», «чтобы не потерять сроки».

• Используйте переформулировки. Меняйте «Ты не доверяешь?» на «Я доверяю, поэтому проверил детали».

Чего не делать ❌

• Не спорьте в лоб, не говорите «я прав, а вы не правы».

• Не оправдывайтесь. Фразы вроде «нет-нет, я вам верю, честно» ослабляют позицию.

• Не переводите разговор обратно в эмоции.

• Не теряйте фокус обсуждения. Цель — решение для бизнеса, а не выяснение отношений.

Выводы

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

Гораздо эффективнее — спокойно вернуть диалог к данным и интересам бизнеса. Подчёркивайте, что финальное решение всегда за руководителем. Ваша задача — дать ему фактуру для выбора. В итоге вы не спорите с начальником, а помогаете ему принимать взвешенные решения.

А как вы выходите из подобных ситуаций? Сталкивались с такими ловушками в диалогах?

Давайте обсудим это в комментариях.

Присоединяйтесь в мой TG канал, где я обсуждаю полезные ИТ-кейсы

Я 10 лет руковожу разработкой в своей IT-компании и повидал всякое. Но есть один типаж сотрудников, который обходится бизнесу дороже всего. Я называю его «Игорь».

Работал у меня такой человек лет пять. Его суперспособность быть ни в чём не виноватым. Всегда. Что бы ни случилось, он находил способ доказать, что он тут ни при чём.

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

Доходило до абсурда. В его коде находят баг, а Игорь тут же отвечает: «Так ты же сам сказал так сделать, вот и вылезла ошибка». Орфографическая ошибка на форме? Он начинал юлить и объяснять, что его неправильно поняли. За пять лет я ни разу не услышал от него простого: «Да, это моя ошибка, сейчас исправлю».

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

Почему это проблема, а не просто особенность характера?

Проблема в том, что «Игорь» своим поведением ломает рабочий процесс.

• Как должно быть: Я ставлю бизнес-задачу. Разработчик продумывает реализацию, согласовывает со мной только ключевые, архитектурные моменты и приступает к работе. Я не лезу в то, как расположить кнопки на форме.

• Как было с Игорем: Я ставлю задачу. Дальше мы вместе (!) составляем детальный план вплоть до мелочей, вместе проектируем структуру данных и интерфейс. Любой технический вопрос, даже тот, который целиком в его зоне ответственности, он тащит ко мне на согласование. И речь не о страховке от нечеткого ТЗ. Это был именно системный уход от малейшей ответственности. Микроменеджмент, навязанный снизу. У Игоря возникают вопросы технического плана (за что он отвечает), по реализации (за что он отвечает), более сложные вопросы связи с бизнесом (за что я отвечаю) и со всем ними, без разбору, он бежит ко мне и согласовывает. Да. Часть из этих вопросов - это моя сфера ответственности. Но не ВСЕ же!

И тут возникают два логичных вопроса:

1. Что будет если в согласованном плане (да и в любой задаче) будет ошибка (любая)? Очевидно же, что Игорь подойдет ко мне и скажет, что это я виноват, потому что я там, сказал вот так. Понимаете проблему? При любых вопросах виноват не сотрудник, а руководитель. Даже в тех, где ответственность несет непосредственно разработчик (написание кода).

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

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

Мои выводы, которые стоили мне 5 лет нервов

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

2. «Игорей» выявляет один вопрос на собеседовании. «Расскажите о своей самой серьёзной профессиональной ошибке и как вы её исправили?» Безответственные люди либо «не могут вспомнить» ни одной ошибки, либо рассказывают историю, где виноваты все вокруг: коллеги, обстоятельства, фазы Луны.

3. Увольнять нужно вовремя. Моя главная ошибка - я держал Игоря 5 лет, надеясь, что он изменится. Люди меняются крайне редко. Моя задача как руководителя, не быть психотерапевтом, а собирать эффективную команду. Я затянул с решением, и это стоило компании денег, а мне нервов.

С тех пор я дал себе слово стараться не работать с такими людьми. Мне кажется это касается не только разработки, а вообще любой работы. Есть люди, которые не хотят на работе думать головой в своей же зоне ответственности. Рядом с такими сотрудниками всегда виноваты все вокруг.

Такие дела.

А у вас в практике был свой «Игорь», который мастерски спихивал ответственность на других? Сталкивались?

Понравился разбор? В моём ТГ канале Код ИТ-директора еще больше прагматичных кейсов из практики IT-руководителя. Без воды и "успешного успеха". Присоединяйтесь.

Помните, был такой лайфхак, когда для связи с оператором Сбера просили бота ответить на вопрос «период полураспада радия/плутония» и бот в панике сразу переводил на оператора? Потом это пофиксили, но я этот случай запомнил.

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

Честно говоря, это не только про вендоров. Та же тенденция есть в любой IT-техподдержке — от SaaS-сервисов до внутренних helpdesk, ну и Сбер тоже не исключение. На мой взгляд, причин несколько:

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

• Ставка на «среднего» специалиста, а не эксперта. Задумка хорошая, что средний спец + нейросеть = эксперт, но вот на практике это почти всегда не так.

• Увлечение автоматизацией и «ботизацией» без продуманной логики. Нейросети поумнели, и почему бы их не использовать на полную катушку?

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

• Модель не понимает контекст, если вопрос нестандартный.

• Она «галлюцинирует» там, где не знает ответа.

• Клиент тратит время на проверку, а не на решение.

Я думаю, что ситуация будет усугубляться: всё больше компаний будут пытаться экономить, заменяя первую линию поддержки на чат-бота с LLM. Это общий тренд. И вместо того, чтобы решить проблему за 10 минут с инженером, клиент будет три раза «объяснять заново», прежде чем добьётся связи с человеком.

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

Я думаю вот о чем:

1. LLM как ассистент, а не как фронт. Модель подсказывает оператору варианты решения, а не отвечает напрямую клиенту.

2. Вопросы с высокой ценой ошибки — только через человека. Автоматизация — да, но с триггерами для эскалации.

3. Контекст — главное. Не подсовывать LLM голый вопрос, а давать историю обращений, конфигурацию системы, логи.

4. Метрики качества. Замерять не скорость ответа, а количество обращений, которые закрыты «с первого раза».

Вопрос в том, когда и как компании это будут делать правильно? Потому что гонка «а сэкономим-ка ещё бюджет» легко превратит службу поддержки в чат, от которого клиент убегает к конкурентам.

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

Было бы интересно обсудить с теми, кто из ИТ, как это организовано у Вас с техподдержкой? Да и вообще, кто что думает по этому поводу?

21.03.21 гуляли с женой и дочерью и наткнулись на полянку пролесков. Краснодарский край, г.Кропоткин

Sony A7III + Tamron 28-75