Как сообщить, что вы всё уронили: шаблон действий в ситуации, когда всё пошло не по плану
Время на прочтение
7 мин
Количество просмотров 6.6K
Когда всё падает — это нормально. Особенно в IT. Даже Марку Цукербергу периодически приходится извиняться, когда сбой в работе соцсетей приводит к миллиардным потерям. Надеемся, что у вас таких потерь не будет, поэтому поговорили с разработчиками, тимлидами и менеджерами. Спросили, что и как нужно делать, когда всё плохо, чтобы не навредить карьере.
Почему вообще сообщать об ошибках сложно
Рабочий процесс не идеален, ошибки случаются по разным причинам, мы не всегда в этом виноваты, а даже если и виноваты, то и это тоже естественно. Но когда ошибка случается, коммуникация с коллегами затрудняется.
Так работают наши психологические механизмы. У каждого из нас есть набор представлений о себе, и в этот набор по умолчанию входит установка «я прав». Момент, когда нужно рассказать о неполадках в работе, разрушает эту установку и нам становится неприятно и неловко.
Исследования показывают, что непризнание вины может повысить самооценку.
Хотя исследования психологии правонарушений говорят, что признание в ошибках делают люди, которые готовы изменить поведение. Когда случаются неприятности, мы тратим время на выбор тактики и стратегии поведения, и это может привести к худшим последствиям: сроки исправления затянутся, коллеги обидятся.
Поэтому мы собрали мнения и истории, которые помогут построить свой алгоритм действий в сложных ситуациях, не отвлекаясь на сомнения и выбор линии поведения.
Чем быстрее, тем быстрее
Кевин Риггл, специалист по информационной безопасности и консультант, рекомендует сразу определить, в какой из чатов вы сообщите о проблеме. Причём критерием выбора должна быть скорость: люди, которым важно знать о проблеме, должны максимально быстро отреагировать на сообщение. Но оповещение не должно затрагивать ту часть команды, которую не коснутся перебои в работе.
Это может быть рабочий чат в мессенджере, соцсетях или сообщение на электронную почту, а скорее всего — всё вместе. Главное — оповестить всех членов команды, кого может затронуть инцидент. В Atlassian также рекомендуют использовать специальную Status page или виджеты и пуши, чтобы сообщать об инцидентах клиентам. В крупных компаниях, как правило, такие механизмы уже отработаны, но не факт, что все знают и помнят, как ими пользоваться.
Назовите проблему сразу же
Сбои в работе — тот случай, когда можно пропустить даже приветствие. Если вы пишете в мессенджер, начните сообщение с заголовка. Если чат большой и активный, привлекайте внимание к сообщению — выделите текст жирным начертанием, поставьте эмодзи. Если вы решили извещать команду по электронной почте, опишите суть в теме письма. Например, «производственный сбой в базе данных». Не нужны общие фразы и оценки, такие как «у нас неприятности», «пишу, чтобы сообщить об ошибке» и так далее. Сразу переходите к делу.
Мне совершенно всё равно, как будет сказано, хоть матом. Главное, чтобы сразу же сказали, что и где упало и что с этим делали. Когда случилась проблема, обычно уже не до процедур. Часто начинают паниковать. Но важно уметь спокойно разбираться и чинить, пока тебя дёргают со всех сторон — это отдельный скилл. Он приходит с опытом.
Кира 2Pizza, ведущий разработчик
Антонина Лебединская, бизнес-тренер, эксперт по менеджменту и личной эффективности и преподаватель Нетологии, предлагает использовать самые простые и короткие формулировки. Чем более далека от технической части аудитория, которая получит письмо, тем проще нужно писать. В детали погружаться не нужно вовсе. Если же в деле есть важные детали, лучше дать ссылку на документ или дашборд, где с ними можно ознакомиться. Ничего объяснять для начала тоже не надо: может быть, вы и сами ещё не понимаете, в чём проблема. Тем более не надо оправданий о том, что «оно само». Вообще ничего не нужно, кроме факта.
Добрый день, коллеги.
Сегодня стала недоступна функция Х.
Проявить эмпатию, если это уместно
Этот пункт зависит от того, кому вы сообщаете об ошибке. Как правило, конечным пользователям и клиентам принято сообщать, что вы сожалеете, что поставили их в неловкую ситуацию.
Приносим извинения за этот инцидент.
Мы понимаем, что эта функция крайне важна для вашей работы в системе.
Эта формулировка нейтральная и подходит для широкой аудитории: разных клиентов, руководителей, бизнес-отделов, бухгалтерии.
Конечно, это нужно далеко не всегда. Допустим, у вас неформальные отношения в команде и вы пишете в соседний отдел, где принято общаться на сленге и в целом царит суровая атмосфера. Формальный подход вызовет недоумение, зато можно сказать: «Понимаю, как мы все влипли, будем выбираться».
Рассказать, как и когда все исправите
Даже если вы пока не знаете, как и что сделаете, хотя бы сообщите, что уже работаете над вопросом. Ну а если вы пишете руководству, можете указать подробности в теле письма или в сообщении в чате.
Михаил Корнеев, тимлид, автор YouTube-канала «Хитрый питон»
На мой взгляд, важно уведомлять команду оперативно, но при этом сообщить достаточно подробную информацию о том, что произошло, какие могут быть последствия и что делается для исправления. Недавно мы нашли проблему в безопасности, довольно заметную. Конечно, сразу об этом сообщили. Я удалил конкретику из письма, а то, что осталось, можно использовать как шаблон:
Макс, привет!
У нас случился security-провал, ставлю тебя в известность. У нас xxx, и из-за этого yyy (описание ситуации и вероятных последствий).
Что делаем, чтобы исправить:
-
Я запросил у Васи информацию, которая нам поможет информировать NNN.
-
Завёл тикет, в рамках которого поправим ZZZ.
-
Договорился с Петей, что теперь в чек листе будет отдельная задача на проверку xxx.
Лучше всего рассказать, когда вы сможете восстановить нормальную работу, хотя бы приблизительно. Ваши коллеги тоже планируют день, и им нужно знать, как долго какие-то функции будут недоступны. Иногда вместо описания шагов вам потребуется запросить обратную связь или ресурсы. Пишите об этом сразу же, в одном сообщении с обозначением проблемы. Список ресурсов или действий, которые вам нужны, укажите тоже сразу.
Специалисты работают над исправлением ситуации.
Мы рассчитываем вернуть функцию до конца дня. Если вы заметили ошибку в своей работе, пришлите описание или скриншот мне. Если хотите помочь, принесите кофе на второй этаж.
Опция для продвинутых — рассказать, что случится, если вы НЕ почините то, что сломалось. Может понадобится, когда требуются дополнительные ресурсы и вы просите их у руководства.
Назначить ответственного
Елена Степанова, разработчик и product owner из Nokia, считает, что нужно назначить человека, который будет координировать весь процесс, пока проблема не решится. Это должен быть сотрудник, который достаточно компетентен, чтобы разобраться с технической проблемой. К тому же, с хорошоими коммуникационными навыками. Если у вас в команде есть проджект-менеджер — то вам повезло, эту ответственность можете смело делегировать ему.
Елена Степанова, разработчик и product owner из Nokia
Внутри команды у нас сообщения предельно прямолинейные и простые: сломали вот это, коллега N занимается анализом, выглядит не очень сложно, починим в течение суток. Главное — указать:
— какие компоненты задействованы и на что влияет поломка
— кто отвечает за решение проблемы
— какой примерный срок починки
Все понимают, что ошибиться может любой, и надо прийти помочь коллеге разобраться, если проблема уже знакома.
Ответственного и его контакт можно и нужно указывать всем, кого коснулась ошибка. Именно этот человек должен собирать обратную связь: репорты о новых багах, отчёты о старых. Кто-то должен аккумулировать всю информацию в одном месте, работать копилкой идей и решений, чтобы координировать информационные потоки. Для этого можно выделить даже отдельный канал в мессенджере.
Контакт ответственного нужно дать всем заинтересованным лицам. Возмущение сотрудников тоже придётся принимать на себя ответственному — негативные реакции были, есть и будут, но на них, как правило, некогда отвлекаться.
Не искать виноватых
Каждый сбой — это повод проверить, что не так в рабочем процессе. Но нужно чувствовать разницу: искать причину ошибки, а не кого-то, на кого свалить неудачу. Когда инцидент уже произошёл, велик риск начать поиск виноватых, погрязнуть во взаимных обвинениях и конфликте, считает Product Adviser Александр Дученчук. Но это то, чего делать как раз не нужно. Проблему вы решите, а отношения испортятся.
Александр Дученчук, Product Adviser
Наша команда подхватила стартап, которые вышел с инвестраунда, у них были мобильное приложение и сайт. Оба костыльно написанные, с двумя разными базами, которые также костыльно синхронизировали. Нам поставили задачу переписать оба продукта, начиная с API. Идея была в том, чтобы сделать общий бэкенд для сайта и приложения. Мы посчитали, назвали сроки и начали пилить.
Приходит срок релиза API, бэкенд готов, всё круто. Но! Сайт-то висит старый, со старым бэком, и там сотни тысяч юзеров, и никто не подумал, что мы не сможем релизить продукты с разными и рассинхронизипованными базами. А сроки-то названы, под них подвязан инвестраунд следующий. Перед нами два варианта: либо мы строим синхронизацию между старой и новой базой на время, пока делаем сайт, либо ничего не релизим и уходим в разработку сайта. Приходим к инвесторам, объясняем честно ситуацию, признаёмся, что не спланировали полностью миграцию, предлагаем оба варианта решения.
Закончилось всё не фатально, продукт полностью релизнули и мигрировали на новые базы, но пришлось посидеть какое-то время без выплат, потому что с отложенным релизом отложился и раунд инвестиций.
Мораль сей басни такова: планируйте до конца весь флоу, проговаривайте честно свои ошибки, давайте сразу варианты решений, и если уже ошиблись, то несите ответственность за ошибки и принимайте их спокойно, не ссорясь с заказчиком. Главный тезис — сначала проверяешь, можно ли решить проблему и за какое время. Идёшь и честно объясняешь ситуацию. Никого не винишь, это тоже очень важно, даже если где-то были со стороны заказчика недосказанности.
Правда, бывают случаи, когда причина ошибки всё-таки в конкретном человеке, допустим, злостном нарушителе техники безопасности. Если есть такие истории — рассказывайте в комментариях.
Сообщить, когда всё наладится
Когда все восстановите, обязательно напишите ещё одно письмо — оно будет короче и приятнее. Пишите в те же чаты и тем же адресатам на почту, даже если на первое сообщение никто из них не отреагировал. Схема та же: заголовок с важным фактом, коротко — раскрыть суть.
Функция х снова работает
Добрый день
Работа приложения восстановлена в полном объёме
Если заметите сбои — пишите ххх
Пример большого и подробного письма
В стрессовых ситуациях, а ошибки — это стресс, лучше всего работают понятные алгоритмы и наработанные решения. Мы нашли пример письма с сообщением об инциденте от консультанта Кевина Риггла, которое можно использовать для работы.
Тема: Производственный сбой в базе данных
Кластер первичной базы данных перестал отвечать на запросы в 0:02 UTC — 17:02 по тихоокеанскому времени. Через тридцать секунд производство переключилось на вторичную базу данных и предупредило об инциденте.
Сайт по-прежнему функционирует, но, если из-за сбоя отключится вторичный кластер базы данных, сайт выйдет из строя.
Я куратор инцидента. Координация через канал отработки отказа # 2021-03-15-production-failover в Slack.
Представитель по связям с клиентами: Джейла М.
Специалисты в данной области: Алисия С., Дэйв Д.
В письме обозначено, когда произошёл инцидент, в чём суть проблемы, какие у неё последствия, кто ей занимается и в каком чате команда может обсудить решение. Это самые важные детали, которые позволят в любой момент вернуться к письму и увидеть, что произошло и кто за что отвечает, пока инцидент не исчерпан.
Любая система допускает ошибки. Это может быть как человеческий фактор, так и ошибка самой системы. В обоих случаях, нужно правильно эти ошибки отображать, так как они являются очень важным элементом пользовательского опыта.
Вот 3 жизненно важных части любого хорошего сообщения об ошибке:
- Четкое текстовое сообщение
- Правильное размещение
- Хороший визуальный дизайн
Четкое текстовое сообщение
1. Сообщение об ошибке должно быть понятным
Сообщение об ошибке должно четко говорить о том, какая именно ошибка произошла, почему она произошла, и что с этим делать. Думайте об этом сообщении, как об общении с пользователем — оно должно звучать так, будто оно написано для человека, а не для машины. Убедитесь, что ваше сообщение вежливо, понятно, дружественно, и не содержит жаргона.
2. Сообщение об ошибке должно быть полезным
Не достаточно просто написать, что что-то пошло не так. Покажите пользователю, как он может исправить проблему.
Например, Microsoft описывает проблему, и прямо в сообщении об ошибке предоставляет вариант ее решения.
3. Сообщение об ошибке должно подходить под определенную ситуацию
Очень часто, веб-сайты используют одно сообщение об ошибке для всех схожих состояний. Оставили пустым поле ввода электронного адреса — «Введите правильный электронный адрес», пропустили символ «@» — «Введите правильный электронный адрес». MailChimp решает эту проблему иначе — они используют 3 разных сообщения об ошибке для каждого состояния процесса подтверждения электронной почты. Сначала проверяется, заполнено ли поле ввода. Затем проверяется введены ли символы «@», и «.».
4. Сообщение об ошибке должно быть вежливым
Не вините пользователей в том, что они что-то не так сделали, даже если это так. Будьте вежливы, дайте им почувствовать себя комфортно.
5. Используйте юмор, если он уместен
Но будьте осторожны. Сообщение об ошибке, в первую очередь, должно быть информативным и полезным. И уже затем, можете улучшить пользовательский опыт, добавив немного юмора, но только если он уместен.
Правильное размещение
Хорошее сообщение об ошибке — это такое сообщение, которое вы увидите. Размещайте его рядом с элементами интерфейса, с которыми ошибка непосредственно связана.
Правильный визуальный дизайн
Сообщение об ошибке должно быть заметным. Используйте контрастный текст и фоновые цвета, чтобы пользователь мог легко его рассмотреть и прочесть.
Обычно, используется красный цвет. В некоторых случаях желтый или оранжевый (некоторые ресурсы утверждают, что красный цвет нервирует пользователей). Как бы то ни было, убедитесь, что ваш текст разборчив, и хорошо контрастирует с фоном. Не забудьте внедрить в сообщение связанную с ним иконку — это улучшит доступность сообщения для людей с нарушенным восприятием цветов.
Заключение
Сообщения об ошибках — это отличный способ улучшить пользовательский опыт. Чтобы ваше сообщение стало действительно идеальным, уделите внимание всем аспектам — языку, размещению, и визуальному дизайну.
Предыдущая статья
F-паттерн: как пользователи просматривают контент
Следующая статья
Метрики, за которыми должен следить любой SEO аналитик
One of other department managers has sent me mail with invalid information in the report. How do I communicate politely error in report?
asked Aug 4, 2016 at 9:30
3
Email back asking for clarification on what you believe to be erroneous is the best way. It gives them time to change it or explain it, without any embarrassment.
answered Aug 4, 2016 at 9:38
Kilisi♦Kilisi
210k117 gold badges457 silver badges756 bronze badges
2
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
|
Универсального решения нет. Как лучше это сделать зависит от степени доверия между вами, уровня деликатности вопроса и принятой в вашем обществе этики поведения. Также имеет значение характер вашего знакомого, насколько он воспринимает критику и что происходило с его самооценкой до этой ситуации. Общий совет — постараться избежать такой формы подачи, когда это может намекать на вашу личную заинтересованность, провокацию соперничества и т.п. автор вопроса выбрал этот ответ лучшим
Васильевна3 3 года назад В вопросе утверждается некое правило: если человеку указать на ошибку, то у него понизится самооценка. Но автор предполагает, что есть вежливый способ (один?!) сделать это без влияния на самооценку другого. При такой постановке вопроса мы попадаем в ловушку телепатии, приписывая другому одну реакцию. Невозможно точно знать, как отреагирует человек, которому указали на ошибку. Один смутится, другой станет спорить (и даже может оказаться правым), третий скажет: Бери и сам делай. Вежливость пригодится в любых ситуациях, и в личных отношениях, и на работе. Как здесь уже написали, при указании (сообщении) ошибки не затрагивать личность (какой ты неумеха, тебе ничего нельзя доверить…). И помнить о цели указания ошибки — делается общее дело для общего блага, поэтому ошибки надо находить и исправлять. Создавая атмосферу, в которой исправление ошибки будет поднимать самооценку всех участников — кто совершил ошибку, кто обнаружил и указал на неё и кто исправил. Внимание не на понижение самооценки, а на её повышение. А если у кого-то и понизится, это будет ему на пользу, для самовоспитания, для принятия своего несовершенства и как прививка от гордыни. Нормально совершать ошибки. «Не ошибается тот, кто ничего не делает». Поэтому будем терпеливо и вежливо относиться к ошибкам, чужим и своим.
ХартБит 3 года назад Абсолютно любые слова об ошибках, не содержащие оценочных суждений о личности человека, являются вежливыми. Можно добавить несколько вводных слов, подчеркивающих то, что вы понимаете субъективность своего мнения и признаете право другого человека не принять его. Но это совсем не обязательно. «Вы ошибаетесь в АБВ» «Мое мнение, вы ошибаетесь АБВ» «Осмелюсь/вынужден/нахожу нужным заметить, вы допускаете ошибку в АБВ» «Простите, но вы насквозь неправы» Более деликатно будет сказать, вообще никак не упоминая личность собеседника. «Я считаю, что АБВ — это ошибка» Если самооценка человека страдает просто от факта сообщения об ошибке, то это его личная проблема. Это не забота окружающих людей. Но, увы, слова — это просто слова. Учитывать только их — мало. Важны и многие другие вещи:
К тому же, хотелось бы обратить внимание на интересный момент в вопросе. Указать на ошибку. В этом слове уже заложено некое снисхождение. Указывает — начальство. Собеседнику, если он не ваш непосредственный подчиненный, будет неприятно, и он будет прав. Лучше избегать закладки подобных вещей в свою речь, это провокация. А вот сообщать об ошибке — это уже совсем другое. selana 3 года назад Если ошибку подчинённого заметил начальник, то, конечно, он вызовет сотрудника и укажет ему на ошибку. Считаю, что должен он это сделать спокойно и дружеским тоном. Ни в коем случае не допускать грубость и крик. При этом сотрудник должен понимать недопустимость своего просчёта . Далее начальник должен разобраться почему была допущена ошибка и как быстро можно её исправить. И. что главное, не следует в дальнейшем вспоминать об этой ошибке и при каждом удобном случае говорить об этом подчинённому и другим сотрудникам. И, конечно, не нужно наказывать сотрудника, лишая его премии или даже понижая его в должности. А если сотрудник учтёт в последующей деятельности замечание начальника и исправится, то отношение между начальником и подчинённым останутся исключительно деловыми и на прежнем уровне. При этом самооценка сотрудника, допустившего ошибку, не будет понижена. Белочка 2 2 года назад Во-первых при разговоре старайтесь не переходить на личности, это не к чему, не говорите «ты поступил как дурак, ты поступил как подлый человек», во-вторых балансируйте позитивом, вспомните что ранее человек сделал хорошее и подчеркивайте что он не обидел вас, а растроил. К примеру « Ты вчера не пришел к больной маме, я не ожидал такого, ведь ты раньше так не поступал, я знаю тебя давно, ты хороший человек. Что у тебя творится, что случилось? Я от тебя точно такого не ожидал» Знаете ответ? |
Правила написания сообщений об ошибках
Народная мудрость гласит, что хорошие сообщения об ошибках должны быть вежливыми, точными и конструктивными. С приходом Web к этим требованиям добавились еще несколько: делайте так, чтобы сообщение об ошибке было четко видно; в случае ошибки пользователь не должен тратить много времени на ее исправление; обучайте пользователей по ходу дела.
Правила создания эффективных сообщений об ошибках не меняются вот уже 20 лет. Хорошее сообщение об ошибке должно:
- Явно указывать, что что-то не так. Самое плохое сообщение об ошибке это то, которое не было создано. Если пользователи делают ошибку и не получают никакого отклика от системы, это самое худшее для них. Например, приложение работы с электронной почтой имеет несколько ситуаций, где указание о произошедшей ошибке было бы явно полезным. Скажем, вы отправили почтовое сообщение, которое было благополучно проглочено системой, но так и не достигло адресата. Еще пример? Вы сообщаете в письме, что прилагаете к нему файл, но просто забыли сделать это. Вот тут-то и нашлась бы работа для этой глупой скрепки из MS Office: «Похоже, вы хотели прикрепить файл к вашему сообщению, но не сделали этого. Хотите сделать это?».
- Быть написано на человеческом языке, а не с использованием таинственных кодов и сокращений типа » произошла ошибка типа 2″.
- Быть вежливым и не обвинять пользователей в том, что они такие глупые или сделали что-то не так, как например в сообщении «запрещенная команда».
- Точно описывать источник проблемы, а не просто выдавать общие фразы типа » синтаксическая ошибка».
- Давать конструктивный совет о том, как исправить проблему. Например, вместо того, чтобы сообщать о том, что товара » нет в наличии», ваше сообщение об ошибке должно либо сообщать, когда товар будет в наличии, или предлагать пользователям настроить отсылку им сообщения-уведомления, когда товар появится в наличии.
Самая распространенная ошибка в Web — 404 — нарушает большинство из этих правил. Я рекомендую вам написать свое собственное сообщение об ошибке 404 вместо того, чтобы полагаться на скупую серверную фразу «page not found».
Новые правила
Сложность работы с веб-страницами привела к появлению еще одного правила, которое не требовалось в старые времена. В интерфейсе DOS пользователи набирали команду и сообщение об ошибке появлялось в следующей строке на экране. В современных графических оболочках когда пользователь выбирает ошибочную команду, сообщение об ошибке выводится в большом диалоговом окне в центре экрана, и оно не исчезает до тех пор, пока пользователь не примет его. Однако, в Web сообщения об ошибках часто спрятаны в тексте страницы, из-за чего мы выводим следующее правило: сообщение об ошибке должно быть:
- Видимым и очень заметным, как относительно самого сообщения, так и того места, где пользователь должен исправить ошибку.
Я часто замечал, как пользователи совершают ошибку в веб-форме, подают форму и получают на экране опять ту же самую форму без какого-либо указания на то, что с ней не так. Часто в верху страницы появляется небольшое сообщение об ошибке, но так как пользователи смотрят на странице в первую очередь на то, с чем они работают (то есть, на поля формы), они как правило не замечают этого сообщения.
Точно так же неверно будет обозначать сообщение об ошибке только красным цветом. Это нарушение одного из старейших и простейших правил создания технологий, доступных пользователям, у которых проблемы со здоровьем: никогда не используйте в интерфейсе только цвет для обозначения состояния системы; всегда дополняйте его еще какими-нибудь сигналами, которые могут увидеть люди с проблемами в восприятии цвета.
Вот еще несколько правил, которые позволят смягчить неприятную ситуацию, в которую попадает пользователь при ошибке:
- Сохраняйте как можно больше от работы, сделанной пользователем. Позволяете пользователям исправить ошибку в своем действии вместо того, чтобы предлагать ему все начать сначала. Например, выводя ему результаты поиска, показывайте там же поле поиска и в нем выводите те ключевые слова, которые пользователь искал, чтобы он их мог исправить и улучшить результат. Если поиск не дал никаких результатов, дайте пользователю возможность одним щелчком мыши расширить область поиска.
- Сократите работу по исправлению ошибки. Если возможно, постарайтесь, чтобы система догадалась о правильном действии и предложила пользователю выбрать это правильное действие из небольшого списка вариантов. Например вместо того, чтобы просто написать «название города не соответствует его почтовому индексу», дайте пользователю возможность щелкнуть на кнопке и выбрать в списке город, соответствующий его почтовому индексу.
Обучение пользователей
И наконец, вы наверное уже знаетеПервый Закон Нильсена о компьютерной документации: люди ее не читают. Этот закон действует еще сильнее для веб-сайтов, где пользователи действительно избегают читать то, что не существенно для их задачи. Щелкнуть по ссылке «Помощь»? Да ни за что.
Пользователи читают документацию к системе только тогда, когда у них возникает проблема (это Второй закон). Они особенно внимательно ее читают, когда хотят исправить ошибочное действие. В этом случае вы можете использовать сообщения об ошибках в качестве обучающего материала, и подавать в них эти знания малыми порциями. Естественно, сообщения об ошибках должны быть краткими и по делу, как впрочем весь контент веб-сайта. Однако, сообщения об ошибках все-таки могут дать людям крупицы информации о том, как работает система, и подсказать, как с нею лучше работать. И в завершении этой темы, Web вводит еще одно правило:
- Гипертекстовые ссылки можно использовать для того, чтобы связать краткое сообщение об ошибке с дополнительным материалом или объяснением проблемы. (Только, смотрите, не перестарайтесь).