Письменное замечание лишено интонации, поэтому даже нейтральный текст читатель часто воспринимает как претензию или личный выпад. Главная задача при указании на ошибку – перевести фокус с поиска виноватых на решение проблемы. Правильно составленное письмо или сообщение в рабочем мессенджере помогает быстро исправить недочет, сохранить рабочий настрой и не тратить время на эмоциональные оправдания.
| Что разберем | Что это даст |
| Базовый алгоритм сообщения об ошибке | Сможете писать так, чтобы текст не звучал как обвинение |
| Различия в подходе к коллегам и подрядчикам | Подберете правильный тон для разных рабочих дистанций |
| Стоп-слова и пассивная агрессия в тексте | Уберете из писем фразы, которые провоцируют конфликты |
Базовый алгоритм: как строить сообщение
Любое конструктивное замечание строится по схеме: Контекст + Факт + Предложение. Этот каркас исключает эмоции и сразу переводит диалог в рабочее русло.
- Контекст. Укажите, о какой задаче, документе или проекте идет речь. Читатель не должен догадываться, где именно проблема.
- Факт. Назовите ошибку без оценки личности. Описывайте то, что видите, а не то, что думаете о квалификации исполнителя.
- Предложение или вопрос. Скажите, что нужно сделать сейчас, или спросите, как исполнитель планирует это исправить.
Пример сборки:
“Привет! Смотрю презентацию для завтрашней встречи (контекст). На пятом слайде указана выручка за прошлый год, а не за текущий (факт). Поправь цифры до вечера, пожалуйста, чтобы я успел переслать файл клиенту (предложение)“.
Развилки и сценарии применения
Формулировки меняются в зависимости от того, кому вы пишете и как часто повторяется проблема.
Сценарий 1: Ошибка коллеги равного грейда
Если вы работаете в одной команде, используйте принцип “мы против проблемы”. Не становитесь в позицию начальника. Оптимальный формат – прямое указание на неточность и готовность помочь, если это необходимо.
Как действовать: Пишите в личные сообщения, а не в общий чат. Используйте формулировки, которые оставляют право на случайную опечатку.
Рабочий вариант: “Олег, привет. В таблице с расчетами по логистике съехала формула в столбце С. Проверь, пожалуйста, чтобы у нас не ушли кривые данные в финальный отчет”.
Сценарий 2: Ошибка подрядчика или исполнителя
Отношения с подрядчиком регулируются договором и техническим заданием. Здесь не нужна излишняя мягкость, но недопустимо и хамство. Опирайтесь на факты, ТЗ и первоначальные договоренности.
Как действовать: Укажите на расхождение результата с задачей. Обозначьте сроки исправления.
Рабочий вариант: “Ирина, добрый день. Посмотрел тексты для рассылки. В третьем абзаце указана скидка 15%, хотя по брифу мы даем 10%. Внесите правки сегодня до 15:00, чтобы мы успели настроить отправку”.
Сценарий 3: Ошибка руководителя
Указывать на ошибку начальнику нужно максимально безоценочно, оставляя ему пространство для принятия решения. Ваша задача – подсветить риск.
Как действовать: Задайте уточняющий вопрос или сошлитесь на внешние ограничения.
Рабочий вариант: “Иван, в согласованном бюджете на квартал не учтены расходы на лицензии для нового ПО. Мы оставляем это за рамками или нужно добавить отдельной строкой?”
Сценарий 4: Систематическая ошибка
Если человек ошибается в одном и том же месте несколько раз, разовые исправления не помогут. Нужно менять процесс или выяснять причину.
Как действовать: Сместите фокус с самой ошибки на алгоритм работы.
Рабочий вариант: “Марина, я замечаю, что мы третий раз за месяц путаем реквизиты в закрывающих документах. Давай созвонимся на 10 минут и решим, как автоматизировать этот шаг, чтобы больше не тратить время на переделки”.
Частые ошибки и точки провала
Ошибка 1: Использование пассивной агрессии
Фразы “я же говорил”, “как нетрудно заметить”, “очевидно, что” и “вы, наверное, забыли” считываются как высокомерие. Они заставляют человека защищаться, а не исправлять недочет.
Как избежать: Удаляйте из текста любые вводные слова, которые оценивают умственные способности или память собеседника.
Ошибка 2: Фокус на человеке, а не на объекте
Формулировка “ты сделал ошибку в коде” звучит как обвинение. Формулировка “в коде ошибка” констатирует факт.
Как избежать: Используйте безличные конструкции по отношению к предмету. Ломается не человек, ломается процесс или результат.
Ошибка 3: Публичное замечание (копии писем и общие чаты)
Если вы ставите руководителя в копию письма (CC) при первом же указании на ошибку, это воспринимается как донос и эскалация конфликта. Писать об ошибках в общий чат отдела – значит публично унижать коллегу.
Как избежать: Первое замечание всегда делайте лично (в приватном чате или письме один на один). Подключайте руководство только если человек игнорирует исправления или отказывается работать.
Ошибка 4: “Сэндвич” обратной связи в коротких сообщениях
Метод “похвалить – поругать – похвалить” хорошо работает на больших ревью, но в рабочих мессенджерах выглядит фальшиво. Если вы пишете “Ты отличный дизайнер, но баннер никуда не годится, продолжай в том же духе”, человек увидит только манипуляцию.
Как избежать: В ежедневной переписке переходите сразу к делу. Конструктивность и вежливость заменяют искусственную похвалу.
Ограничения и исключения
Правила деликатного общения отменяются или сильно сокращаются в следующих случаях:
- Критическая авария. Если “упал” сервер, клиент теряет деньги прямо сейчас или есть угроза безопасности, нет времени на смягчающие формулировки. Нужны короткие директивные команды: “В релизе критический баг. Откатываем систему на вчерашнюю версию. Срочно”.
- Саботаж. Если подрядчик или коллега намеренно игнорирует правила, срывает сроки после предупреждений и отказывается вносить правки по ТЗ, деликатность только вредит. В этом случае письмо об ошибке становится юридическим или административным инструментом фиксации нарушений.
Таблица замен: от претензии к конструктиву
Используйте эти шаблоны, чтобы быстро перестроить конфликтный текст в рабочий.
| Как писать НЕ надо (провоцирует конфликт) | Как писать надо (решает задачу) |
| Вы опять забыли прикрепить исходники к задаче. | В карточке задачи нет ссылки на исходники. Добавьте, пожалуйста. |
| Я же просил сделать кнопку красной, почему она синяя? | По макету кнопка должна быть красной. Перекрасьте, и можно отдавать в релиз. |
| Тут куча ошибок, переделывай. | Текст не проходит по уникальности, и есть опечатки во втором блоке. Внес правки в режим комментариев, посмотри. |
| Чем вы слушали на созвоне? Мы договаривались о другом. | Кажется, мы по-разному зафиксировали итоги встречи. В моем понимании мы договорились о [суть]. Давай сверимся. |
