Не приветкайте
Мне кажется, что первое, что раздражает в online общении больше всего — это присланное одиночное «привет».
[13:01] Он: Привет!
Вам приходит уведомление о том, что кто-то написал. Вы переключаетесь в терминал с IM-клиентом и отвечаете:
[13:01] Вы: Привет!
В это время ничего в чате не происходит, так как коллега пишет и формулирует вопрос. Вы же уже отвлеклись. Вы переключитесь снова назад на терминал где проделывали работу, как будто ничего не произошло? Как бы не так! Теперь ваша голова занята возникшим вопросом «что этому коллеге от меня может быть нужно?». Вы вспоминаете какие именно программы и библиотеки вы в последний раз затрагивали, а возможно что-то делали на серверах. Ваша голова забита предугадыванием вопроса который вам могут задать.
[13:04:20] Он: Я сделал вот такую штуку вот так-то. Нормально? [13:04:30] Вы: Да, хорошо.
В итоге, вы потеряли несколько минут абсолютно впустую, плюс из-за раздумий о причинах «привета» вы уже переключили контекст внимания с вашей работы. Но несколько минут ли? Раздражение из-за объективно в пустую потерянного времени и того, что вы тратили силы на предугадывание вопроса, выбивают вас из рабочей колеи по инерции ещё на какое-то время. Говорят, что переключение контекста никогда не длится менее 15мин.
Какой смысл и зачем писать «привет»? Вы ведь всё равно напишете дальнейшее сообщение, так зачем прерывать коллегу преждевременно? Если бы ваш «Привет. Я сделал… Нормально?» был в одном сообщении, то коллеге не нужно гадать какой вопрос ему зададут, он сразу же может потратить свои мозговые силы только на обработку данного вопроса, эти 10сек, без раздражения о потерянных минутах и вынужденном переключении контекста.
Кто-то пишет «Привет. Можно вопрос?». Это точно также отвратительно. Вот какова вероятность того, что ваш коллега вам ответит «Привет. Нет, нельзя»? Скорее всего, не высокая. То есть, почти наверняка вам всё равно придётся писать и задавать ваш вопрос. Так почему бы его не послать сразу же? Если коллега действительно не может ответить, ну что ж, бывает.
Кто-то может посчитать, что без получения утвердительного «да, можно спросить», было бы не вежливо всё же его задавать. Кто-то наверное даже может написать его заранее, чтобы при получении «да, можно» сразу же его отправить для экономии времени. Вот только:
[16:00] Он: Привет. Можно вопрос? а вы не вернулись с совещания [17:00] Вы: Привет. Да, можно. теперь уже он ушёл на обед/совещание/покурить/по нужде [18:00] Он: Вот такой-то вопрос: ... вы же уже ушли домой, конец рабочего дня
В итоге, поперегоняли из пустого в порожнее и вопроса вы так и не получили, хотя могли бы его уже обдумывать и на следующий день утром не тратить на него времени, дав ответ.
Чаты/IM-ы являются асинхронным способом общения! Да, по определению они real-time, но вот только никто не мешает вам переключиться на другой терминал/окно, отойти от рабочего места. Телефонный звонок является синхронным: уж если ваш собеседник поднял трубку, то уж, поверьте, наверняка это прервало его деятельность и он полностью будет вовлечён в разговор с вами с минимальными задержками между вопросом и ответом, так как деваться то уже некуда, всё равно оторвали. Поэтому не надо делать из IM средство синхронного общения, подразумевая, что собеседник безотрывно находится перед экраном чата, сфокусированный только на чтении вашего вопроса.
Отдельной крайностью может стать:
Он: Привет. Вы: Привет. Он: Как дела? Вы: Потихоньку. Он: Можно задать вопрос?
где между каждым вопросом/ответом ощутимые задержки с переключением контекста.
Не спрашивайте «можно спросить?», а просто спросите! Оцените вероятность отказа вашему вопросу (как правило, ничтожная) и сколько времени вы сэкономили бы и себе и коллеге.
Отмечу, что опытные разработчики не совершают подобных ошибок. Об этом много раз сказано: тут, тут, тут, тут, тут, тут.
Спрашивайте грамотно
Отдельной темой является невозможность поставить грамотные вопросы. Речь не про философский «в грамотно поставленном вопросе уже содержится часть ответа», а про следующее:
Он: Привет. У меня не работает программа XXX. Вы: Привет. Почему ты так решил? Он: Она не выводит корректный результат для такой-то задачи. Вы: Почему тебе кажется что он не правильный? Он: Я ввожу вот так, ожидаю вот так. Вы: А какие опции ты передал при запуске XXX? Он: Вот такие. Вы: Ты проверил права доступа на файл с результатами? Он: Да, ls -l: ... [...]
Это безумие по неэффективности использования времени. Если ответы на все поставленные вопросы уже априори имеются, то почему бы их сразу же и не предоставить? «Привет. Я ввожу в XXX, с такими-то аргументами, такие данные и ожидаю получить такой результат. Но его нет. Проверил что с правами всё хорошо, свободное место имеется, …». Вам всё равно придётся писать все эти ответы (!), так же как и подтверждать в техподдержке что вы убедились в наличии электричества и подключении шнура питания к вашему оборудованию. Но общение с техподдержкой это, опять же, синхронный процесс по телефону, в отличии от электронного с вашим коллегой.
Если возникают сетевые проблемы, то что мы всегда скинем админам для выяснения причин? ping, traceroute, netstat, tcpdump, и т.д… Что, вроде бы, всем очевидно. Так почему же не скинуть все проделанные действия и описать ожидания с деталями? Какова вероятность того, что на все ваши приложенные tcpdump-ы, вам ответят «а это мы просто тут сеть шатали, ничего не работало»? Ну потратите вы впустую немного времени на диагностику — вероятность этого не высока. Если же без предупреждения ваши админы часто шатают сети и сервера, то тут уже куда серьёзнее проблема, нежели чем грамотны ли вопросы.
Есть замечательная статья как правильно задавать вопросы (оригинал на английском) от Эрика Реймонда (ESR). Лично я не очень солидарен с предложением первым делом искать ответ на вопрос в Google, так как получив какой-то рецепт, человек даже примерно не будет понимать и задумываться в чём была суть проблемы. Это же касается и Stack Exchange, с которого слепо не задумываясь берут готовые рецепты.
В моём списке приоритетов стояла бы документация программы. Признаю, иногда её не бывает, или же в ней ничего толкового нет, или же она необъятных размеров, или просто паршиво и непонятно написана. Но меня, как программиста, коробит, когда её принципиально не читают, как будто это очередной тривиальный бытовой прибор с единственной «вкл/выкл» кнопкой. Для кого и для чего мы пишем документацию? Может быть, как-раз для того, чтобы нам не задавали вопросов на которые уже даны все ответы? Где уже, бывает, учтены особые и требующие внимания настройки/особенности о которых можно было бы споткнуться?
Мне понравилась рекомендация не говорить «я нашёл ошибку в программе», если только в этом нет абсолютной уверенности (по-хорошему и патча). Если у большинства пользователей проблема возникала, то это было бы наверняка известно. В противном случае, скорее всего, это вы делаете что-то не так. Если вы утверждаете что нашли ошибку, то заявляете что разработчики сделали что-то не так, что им вряд ли понравится. Лично по моему опыту, в преобладающем большинстве случаев не прав пользователь. Несовпадение его ожиданий с тем что делает программа — не означает что она некорректна или с ошибкой.
Описывайте симптомы проблемы, а не ваши предположения. Описывайте конечную цель, а не шаги. Когда мы начинали работать с менее опытными разработчиками, когда была ощутимая пропасть в опыте между коллегами, то всегда приходилось первым делом спрашивать «что именно ты хочешь получить/сделать?». Очень часто начинающий коллега выбирал тернистую дорогу до этой цели. Частенько вообще не нужно предпринимать шаги в которых возникает проблема.
Если проблема/вопрос более не актуальны, то сообщите об этом! Напишите кратко решение. Представьте какие негативные чувства будут у человека, который, прочитав вопрос, поломал свою голову, отписался о возможном решении, а ему говорят «а это уже не нужно, я забил, оказалось опцию забыл». Это равносильно «мне плевать на твоё (ваше, если это вопрос группе) время, даже не вспоминал что тебя спрашивал».
И ещё полезная ссылка на эту тему, на которую стоит отправлять ваших коллег.
Долой снимки экрана
Непознанной остаётся загадка: почему люди отправляют снимок экрана с исходным кодом (или результатом работы командной оболочки) в виде снимка экрана. Неужели существуют текстовые редакторы или эмуляторы терминалов, которые не позволяют скопировать кусок текста из них?
С изображения вы не можете скопировать текст и вставить в свой редактор/whatever для проверки. Вы всё равно попросите или прислать это текстом или просто не будете возиться. Не перенабирать же вручную всё это заново? Речь, конечно же, не идёт про вопросы вёрстки или корявого отображения консольных программ, где, действительно нужны снимки экрана.
Предпочтения людей очень отличаются. Что удобно и приятно может выглядеть для одного человека — может быть трудно воспринимаемым для другого. Шрифты говно, цвета вырвиглазные и всё в таком духе. А ещё у кого-то может быть HiDPI монитор, а у кого-то нет. Зачем усложнять восприятие информации коллеге?
И знаете насколько может раздражать заметная для человека задержка? Я даже когда-то был вынужден отключать показ текущей ветки VCS в приглашении командной строки, так как это могло создать видимую задержку на компьютерах с жёсткими дисками. Пользователям смартфонов это, скорее всего, сложно понять, так как там, насколько я видел из-за плеча, у каждого действия есть задержка, никаких мгновенных реакций у программ. Скачивание и декодирование многомегабайтного JPEG/PNG — это почти наверняка осязаемая задержка даже на современных мощных компьютерах.
Многие совершенно не понимают особенности форматов сжатия изображений и ещё умудрятся отправить это в lossy DCT-based сжатии, типа JPEG, WebP. Видимо, чтобы у вас наверняка «il1» символы, из-за артефактов сжатия, стали неотличимы и вам бы пришлось играть в угадай-ку.
А ещё больше не задумываются об объёмах информации. В одной из почтовых рассылок я недавно видел, как человек отправил фотографию монитора, где полезной информации было на 10 строчек. Фотография занимала несколько мегабайт, из-за чудовищного разрешения. Ему отметили, что только она одна сгенерировала 19 GB исходящего трафика с их почтовых серверов. Если бы он был подключён по 100Mbps каналу связи, то это уйма времени только чтобы разослать жалкие 10 строчек полезной информации.
Каналы связи — это такой же shared resource как водопроводная и электрические сети. Никто вам явно не запрещает открыть все вентили в ванной и пускай вода льётся и льётся. В нашей стране это совсем не дорого стоит. Но представьте, что все в многоэтажном доме так поступят — по сути водопровод в нём станет бесполезным. Так и Интернет магистрали ничем тут не отличаются.
Более того, чтобы не быть голословным, пока я набираю этот текст, я сфотографировал старой цифровой мыльницей свой 27″ монитор, где на экране две половинки с текстом. Изменив размер до 640×480 пикселей, я без проблем могу разглядеть и понять каждый символ на ней. Сжав это в умопомрачительнейший JPEG XL с «-d 2» lossy сжатием, получаю ~60KiB файл, в котором нет никаких артефактов мешающих восприятию. Это я к тому, что даже до 100KiB, при современном формате изображения, можно прекрасно передать на фотографии почти всё что вы захотите.
set spell
Включите же уже наконец проверку орфографии в вашем редакторе! Хотя, как известно, редактора всего два: Emacs или Vim — оба содержат встроенные средства проверки.
Речь не про real-time общение в чате, а скорее про почту, которая уж наверняка набирается в редакторе, и исходный код с документацией программ. Что означают опечатки и плохая орфография? Небрежность, пренебрежительность или лень включать «set spell». Не все люди умеют грамотно писать или даже замечать ошибки — это нормально, это факт. Но в наших компьютерах поэтому и есть инструменты позволяющие хотя бы орфографию исправлять. Одно дело — real-time общение, где важна высокая скорость передачи данных, пускай с ошибками и опечатками. Другое дело — почта или код с документацией, где не бывает спешки из серии «коммить быстрее как есть и валим отсюда!».
Какого это читать (не IM) текст с ошибками? Это как на скорости ехать по дороге, где здоровые колдобины и выбоины — точно так же цепляется глаз за ошибки, резко сбавляя темп чтения. Несколько таких зацепок и вам уже просто физиологически будет неприятно читать материал перед вами. Ибо он написан «на отвали», человеку было лень потратить несколько минут на правку того, что проверка орфографии ему явно бы подсветила. Может быть самому автору и плевать на грамотность, но его код будут читать другие, о чём он не должен забывать. А это небрежно, невнимательно и халтурно сделанная работа — именно такое впечатление она создаст.
И лично у меня речь только про явные опечатки и орфографические ошибки. К несогласованным окончаниям слов (орфографически слова по отдельности корректны, но вместе нет) я не настолько придирчив, ибо по своим текстам знаю, как после многочисленного рефакторинга текста, легко происходит это рассогласование. Плюс проверка орфографии ничем не поможет с запятыми.
Всё то же самое касается и оформления commit message в системах контроля версий. Но про это написано так много статей, что повторяться не буду, лишь снова напомню про орфографию в них.
Помните, что код с документацией пишутся один раз, а читаются, зачастую разными людьми — множество.
Нет вуайеризму
С этим я встречался всего-лишь несколько раз в жизни, но представить такое могут не все: существуют люди, которые продолжают смотреть на тебя, твою клавиатуру, монитор, пока ты набираешь парольную фразу (пароль на худой конец).
Раз уж у нас речь про этикет, сетевой этикет, то подсматривать за набирающим пароли — неприемлемое поведение. Это интимное действие, напрямую касающееся безопасности, приватности. Почти все знакомые коллеги рефлекторно без вопросов и просьб просто отворачиваются, если кто-то набирает пароль, даже общеизвестный.
Изучите же уже ваш MUA
Никто и никогда не смог мне показать хоть каких-то убедительных доводов или примеров, что какое-либо средство коммуникации может сравниться с удобством и мощью электронной почты. Речь про дискуссии и обсуждения, а не оперативные вопросы.
Проблемой непопулярности почтовых решений является только то, что для эффективного использования email необходим адекватный эффективный инструмент. То бишь, хороший пользовательский почтовый агент (mail user agent). Не видя, и не пытавшись использовать онный — толку и удобства от email не будет. За ~20 лет профессиональной деятельности, если я и встречал людей, которые не понимали зачем нужна почта — то они никогда и не вели серьёзных технических дискуссий в электронном виде.
В отличие от массы других средств коммуникаций, которые корпорации нам навязывают, для email есть колоссальный пласт программ на любой вкус и цвет. Меня не ограничивает серверное ПО в возможностях поиска среди писем как мне заблагорассудится. Хочу индексировать всё через Xapian-based систему — делаю. Хочу автоматизировать процессы принятия решений, фильтрации, приоритезации и тасования приходящей корреспонденции Perl скриптами — делаю. Email экосистема (особенно корпоративная) не зависит от прихоти единичных компаний. Email не требует постоянного online подключения, вся корреспонденция может быть под рукой.
Есть отличные рекомендации по сетевому этикету в RFC 1855. Но я выделю только несколько особо критичных.
Указывайте вменяемую адекватную тему письма. Моя почтовая система настроена на то, чтобы вообще не принимать сообщения без тем. Нет никакого смысла общаться с каким бы то ни было человеком, если он не может потратить 10сек на написание вменяемой темы письма. «Привет», «Вопрос», «Нужна помощь» — это такое же дерьмо, как и отсутствие темы.
Ведь достаточно же представить, что тебе написало пять, десять человек с подобной темой. И они ничем друг от друга не отличаются. Бардак, мусор, бесполезная трата времени. Со временем, насколько вижу, опытные люди просто начинают молча помещать подобные письма сразу же в /dev/null без прочтения. Уж написать адекватную тему — это даже быстрее чем включить проверку орфографии в редакторе. И отсутствие этого действия — равносильно полному неуважению к вашему времени.
Каждое письмо имеет уникальный идентификатор (Message-ID). При ответе на письмо, явно добавляется заголовок (In-Reply-To) о том, что это письмо является ответом вот на то, чётко заданное и определённое. Это единственный (если забыть про References заголовок) способ связывания писем между собой в цепочки.
Отсюда следует: если вы хотите начать совершенно новую тему, новое обсуждение, то не нужно этого делать посредством ответа на какое-то предыдущее письмо, так как по умолчанию они будут связаны. Или не забывайте удалять In-Reply-To заголовок после этого. Чем это плохо? Тем, что это письмо ваш MUA покажет как часть какой-нибудь цепочки обсуждения «программы XXX», хотя к ней оно уже не имеет никакого отношения. Какая между ними взаимосвязь? Никакой, скажете вы, даже же темы разные указаны. Однако ваши MUA другого мнения. Кроме того, есть вероятность, что ваше письмо будет проигнорировано. Если коллеги обсуждают какую-то тему про XXX, а она мне совершенно не интересна, то и всё ответвления этой ветки не будут рассматриваться.
Бывает и обратная проблема: человеку лень «прикрепить» сообщение к цепочке обсуждений. Ему лень найти старую цепочку, чтобы сделать reply или выставить In-Reply-To руками. Таким образом, всем получателям придётся самостоятельно вручную в своём MUA проделать операцию привязывания письма к цепочке обсуждений. Либо это сделает один человек один раз, либо это сделают множество множество раз. Выбор, если задумываться о коллегах, очевиден.
Не просите «отправляйте, пожалуйста, ответ на такой-то адрес», а просто выставите «Reply-To»/«Mail-Reply-To» заголовок. Если вам лень потратить несколько секунд на это, то почему получатели и ответчики должны это стерпеть?
Некоторые email решения, типа Gmail, полностью уничтожили возможность вести древоподобные дискуссии, делая обсуждение через email близким к бесполезному. В этих решениях письма группируются на основе изменений в темах писем, игнорируя заголовки. Не стоит использовать вредоносные инструменты.
Следующим бичом в email является избыточное цитирование писем. По умолчанию, при ответе на письмо, оно полностью подставляется в качестве цитаты, дабы мы могли оставить только нужные участки текста на которые даём свои комментарии/ответы/предложения. Ведь только мы, люди, способны сказать что именно мы хотим прокомментировать/обсудить. На кой чёрт оставлять всё остальное, не имеющее отношения к полезной информационной нагрузке письма?
>Привет! > >Завтра такого-то-числа мы пойдём туда-сюда. >Абзац текста > >Собираемся взять то да сё. >Много пояснений и деталей. > >-- >Моя подпись Привет. Я буду в отпуске в эти дни.
Вот какой смысл оставлять в цитате приветствие? Подпись? Абзац текста, детали? Строго говоря, наше ответное письмо и так уже будет содержать «In-Reply-To: Message-ID» сообщения на которое мы отвечаем, поэтому цитата в целом излишня. Но чтобы явно показать контекст ответа, что мы отвечаем на конкретный осознанный участок текста, можно и оставить одну единственно важную и имеющую смысл строку цитаты:
>Завтра такого-то-числа [...] Я буду в отпуске в эти дни.
Многие мне скажут: тебе что, жалко трафика или места на дисках? Я отвечу: ты мне прислал вот такой набор информации, вот такую цитату — она является полезной нагрузкой твоего сообщения. Мне приходится это всё читать, парсить, интерпретировать и разбирать. Чтобы в итоге понять, что почти вся полезная нагрузка — ни на йоту не полезна. Но зачем ты меня заставляешь выполнять эту работу? Скидывать тонну человекочитаемого текста, где ни толики полезной информации, кроме единственной строчки ответа/комментария/предложения и, возможно, контекста к которому она относится.
Размеры заголовков могут занимать не один десяток килобайт — но они ориентированы для обработки машинами. Текст же сообщения — для людей. Так почему вы усиливаете когнитивную нагрузку при обработке такого сообщения? Специально добавляете (оставляете) побольше мусора? Настройте редактор своего MUA чтобы он автоматически вырезал приветствия и подпись, которые в 99.99% случаев не нужны. Это сэкономит время и вам.
Иногда приводят такой аргумент: если мне надо переслать письмо (или целую переписку из нескольких) другому человеку, то я буду вынужден полностью процитировать. Это как-раз классический случай того, что человек делает абсолютно неверные шаги к поставленной цели. Если надо переслать письмо, то так пересылайте! В виде RFC822 attachment, которое полностью сохранит отправляемое письмо (или цепочку) без изменений, без потерь заголовков с Message-ID+In-Reply-To, без потерь криптографических подписей. Но даже если вы вставите пересылаемое сообщение в виде куска текста, то это уже всё же не является цитатой.
И ещё один ужас со времён глюкавых версий Microsoft Outlook:
* Пожалуйста, да. * Должен ли я избегать top-posting в этом списке рассылке? * Потому-что из-за обратной последовательности беседы, читатель остаётся без контекста темы и это заставляет его читать сообщения в неестественном порядке. * Почему top-posting так нервирует? * Это практика размещения ответа на сообщение до самого цитируемого сообщения, вместо размещения его после (обрезанного до только нужных частей) сообщения. * Что такое top-posting?
Выглядит как безумие? Как будто автор этого текста специально извратился и решил ответы в обратном хронологическом порядке показать? Ну чтобы усложнить понимание и восприятие написанного? Так и есть. И именно этим и занимается top-posting, возникший из-за баги в одной популярной некачественной почтовой программе. А небольшой ряд других MUA решил как попугай осуществлять bug-compatibility.
A: Да. Q: Ты уверен? A: Потому что он переворачивает логический поток обсуждения. Q: Почему так не любят top-posting?
Будучи подписанным за 20+ лет на сотни почтовых дискуссионных технических рассылок, почти везде жёстко карают за его использование, ибо оно уничтожает возможность дискутировать, превращая текст в месиво несвязанных между собой ошмётков информации. Через 1-2 предупреждения, большинство просто не будет отвечать на подобные письма, ибо это полнейшее неуважение к людям на том конце MUA. Квалификацию разработчика и его потенциальное умение вести технические дискуссии (не вербально), почти всегда можно оценить по его письмам: есть ли там top-posting, вырезаны ли излишние цитаты, как минимум.
Лично мне, это всё кажется ещё более дико нелогичным, ибо, ещё будучи школьником, я был в сети FidoNet (тогда никакого Интернета), где популярный редактор сообщений GoldED вообще не давал отправлять письма, если размер цитируемого текста превышал что-то около четверти от всего объёма сообщения. В том числе, это была и вынужденная мера, так как иначе бы модемы просто не смогли бы перекачивать объёмы информации между узлами. Зато это позволяло чётко, ясно, лаконично и максимально эффективно вести дискуссии, задавать вопросы, вносить предложения, без массы информационного мусора и бесполезной когнитивной нагрузки.
Я молчу про (не) умение использовать «Mail-Followup-To» заголовок. Молчу про (недопустимость) использование HTML в письмах. И много о чём другом. Ибо проблемы выше — куда серьёзнее.
Заключение
Старайтесь поставить себя на место собеседника и оценить понравится ли ваш метод/протокол взаимодействия и адекватен ли он. Хорошая эффективность электронного общения в ИТ-команде — залог эффективной не простаивающей работы, где, в противном случае, были бы регулярные перерывы и ожидания на живые встречи.
ссылка на оригинал статьи https://habr.com/ru/articles/845172/
Добавить комментарий