題:
使用TL; DR專業嗎?
bhilgert
2018-06-22 00:52:18 UTC
view on stackexchange narkive permalink

最近,我的任務是為中層管理人員和技術IT人員編寫一封電子郵件。我需要從技術上解釋事件發生的原因,並向管理層提供關鍵點,以便他們可以根據所提供的信息採取行動。在花了很多時間寫電子郵件之後,我意識到大多數經理可能不會閱讀文字牆和我所寫的幾個要點。由於我沒有選擇將電子郵件分為兩部分(即,一個技術部分和概述),因此我在標題中包括了一個“ TL:DR”部分,標題為“ TL; DR-概述”,其中對技術信息進行了解釋。

一些團隊成員指出,使用短語“ TL; DR”可能被認為是不專業的。當對此感到壓力時,他們都無法確切指出他們為什麼這麼認為,但表示我將來可能不應該使用該短語。經過進一步思考,它可能歸結為年齡差異。我認為“ TL; DR”一詞在任何意義上都沒有負面含義。但是與老一輩一起工作,我可以看到其中有些想法可能會被“這封電子郵件太長,我沒看完所有郵件”的想法所反駁,儘管可能確實如此。

在工作場所(書面和口頭)使用“ TL; DR”是否專業?如果是這樣,為什麼?

評論不作進一步討論;此對話已[移至聊天](https://chat.stackexchange.com/rooms/79233/discussion-on-question-by-bhilgert-is-using-tldr-unprofessional)。
當某人發布大量無法閱讀或需要大量努力的文本時,它們就會從Internet論壇中衍生出來的“ TL:DR”。如果您的電子郵件太長而無法讓人閱讀,則需要一個簡單的電子郵件。甚至可能包括“ BLUF”類型的電子郵件,其中會概述內容,然後進行深入介紹。
TL; DR是非正式的。當需要正式語言時,這是不專業的。有時會成為非正式的IS專業人士。
十二 答案:
Chris G
2018-06-22 01:20:20 UTC
view on stackexchange narkive permalink

我會說TL; DR是不專業的。 TL; DR代表“太長;未讀”。

如果您寫的電子郵件中包含“太長;未讀”部分,那將是不專業的。您已經想出了合適的詞並將其添加到“ TL; DR”中。只需使用“概述”即可。

是的,主體部分使用“摘要”或“概述”,然後使用“詳細信息”或“技術細節”。
一切都說這種摘要在某些地方也稱為“管理摘要”
bharal
2018-06-22 02:01:48 UTC
view on stackexchange narkive permalink

是的,TL; DR是不專業的-意味著您認為某人(經理)不會閱讀您的電子郵件。

這暗示您認為經理本身並不專業。因為他們沒有技術素養,也不致力於理解這個問題。

您對TL; DR的使用表明了另一個潛在的問題-這部分是電子郵件的開頭還是結尾? TL; DR表示結尾處了-這不是摘要的來源。摘要應該在開頭。

您還注意到“由於我沒有選擇將電子郵件分為兩部分”,大概是“兩封獨立的電子郵件”嗎?我從未聽說過有人對電子郵件的結構有如此具體的指導。

對於您而言,將電子郵件分為兩部分會更有意義。其中一個標題為“問題摘要”,其中概述了問題。然後,請注意在“詳細摘要”電子郵件中找到了更多詳細信息,您在其中放置了更詳細的電子郵件。

鑑於您顯然已被指示不這樣做,最簡單的操作步驟是:

  1. 開頭請注意,這是一封長電子郵件。第一部分將概述問題,第二部分將介紹更詳細的技術細節。

  2. 總結問題

  3. 進入更詳細的技術細節。

  4. ol>

    寫信給您的上級經理/人時,請始終抓住機會將自己介紹為經理。這意味著一定程度的形式性,準確性和智能性。

    無論在專業環境中與初級,同級或高級人員交談,都不再使用TL; DR。

    請注意-您對它的使用遠沒有那麼糟糕就像您用TL; DR回復一封長電子郵件一樣。請永遠不要這樣做。

您反對TL; DR的主要論點是,它暗示人們不會閱讀電子郵件,但不是TL; DR基本上只是摘要(您建議使用*代替*,它表示相同的意思)?帶有“ TL; DR”的摘要與沒有摘要的摘要有何不同?為何暗示人們不會閱讀電子郵件有什麼不好呢?我當然不希望閱讀冗長的電子郵件,談論與我無關的事情,而且我絕對不介意有人暗示太多。
@Dukeling摘要並不意味著您不會閱讀。摘要只是一個精簡版本。總結非常適合提供上下文,然後讀者可以將上下文應用於深入的細節。它也是語,並且在談話時-如所指出的-應該表現出自己是經理,而不是特立獨行的人。小牛之所以使用語,是因為“他們太好了”以致無法恭維。
如果它是一個長文檔,描述了為什麼某事(可能很嚴重),為什麼您沒有以Word文檔的形式編寫報告-電子郵件不是長格式的媒介。
@Dukeling如果可以對電子郵件進行匯總,那麼為什麼要發送長格式而不是摘要格式?如果接收方需要更多信息,您可以在他們要求時將其發送給他們。
@Cronax這似乎是一個討論論壇的問題,或者是答案的開始。
答案的另一個好角度是解釋首字母縮寫* TL; DR *的含義:*太長;沒看過*。這種措辭對我來說似乎天生就不專業。據我所知,它起源於非正式環境,例如討論論壇,這是造成這種情況的另一個原因。
Jay
2018-06-22 01:18:25 UTC
view on stackexchange narkive permalink

這實際上取決於誰編寫TL; DR。如果您正在編寫建設性電子郵件,並且希望提供TL; DR作為摘要,那是非常專業的方法,但是我只是將其標記為“摘要”而不是“ TL; DR”。

但是,如果您的一位同事給您寫了一封長電子郵件,而您用TL; DR答复,那肯定是不專業的,因為這意味著您不必花時間閱讀某人對特定問題的想法。有些人對此會很不滿意。就個人而言,如果我覺得需要與TL; DR進行回复,我會安排面對面的交流,因為通常他們可以以書面方式傳達他們的提議,而這種提議要比我通過書面文本獲得的提議要快得多。

jmoreno
2018-06-22 05:22:42 UTC
view on stackexchange narkive permalink

簡短版本:是的,TL:DR不專業。

長期版本:TL:DR的不專業,不是因為老迷們不了解它,而是因為他們會-他們會理解您以為自己寫了一堆文本,希望他們能在乏味和難以理解之間找到一個地方。您希望他們與之抗爭,最終放棄它,直到完成它。

而不是侮辱,而是要體貼-清楚,準確地預先提出要領,以便他們能夠對用量做出明智的判斷。他們需要閱讀的詳細信息以及何時閱讀。

** TL; DR ** TL; DR不專業。:)
mhoran_psprep
2018-06-22 01:01:58 UTC
view on stackexchange narkive permalink

BLUF:我發現將BLUF放在消息,電子郵件或報告的頂部,然後進行快速提要是可以接受的方法。


我發現BLUF用於最底線有效。它在頂部放置一個段落,以便您可以快速找到摘要和結論。所有細節都可以閱讀整個文檔,不需要所有細節的人可以快速獲得基礎知識。

我不確定這是否能回答問題...好軼事
啊。可惜。在編輯之前,我喜歡這個答案,但是將縮寫放在消息的頂部可能不是一個好主意。
ItWasLikeThatWhenIGotHere
2018-06-22 12:59:17 UTC
view on stackexchange narkive permalink

[已經有很多很好的答案,但是我認為這是另一個角度。]

就其本身而言,並不一定非專業-甚至那些不喜歡該短語的人也可能傾向於將其歸於天真。而不是不專業,可能會有一些公司或部門不被重視甚至不被讚賞。

但是現在您的一些同事已經表明他們不欣賞它,對於繼續為此辯護-尤其是如果您要把人們對它的不喜歡歸結為可能被視為年齡歧視的因素。

您已經有了“概述”一詞,它可以單獨使用,那麼為什麼要添加“ TL; DR”呢?如果您認為您的同事願意,他們的反應表明這是錯誤的,現在您知道您不在一個好事的地方工作。

考慮到您的同事是專業的方法。

meriton
2018-06-22 03:28:31 UTC
view on stackexchange narkive permalink

摘要

“ TL; DR”可能令人反感,因為它暗示

  • 經理不願意為您閱讀電子郵件(
    • 這可能是電子郵件的長度(可能是或不是)。

    此短語是因此有可能在行為或動機上錯誤地描述接受者,從而造成不必要的冒犯。犯下不必要的罪行並不專業。

    詳細信息

    例如,大多數經理都非常願意閱讀數十甚至數百頁的報告,如果內容與他們有關。要說簡單的長度會阻止他們留下懶惰,這幾乎是唯一可能的動機。

    此外,經理很有可能實際上會閱讀您的電子郵件,但受益於摘要來詳細說明是的,人們已經意識到TL; DR是一個常見的成語,並且大多數人會將它的使用歸因於年輕的天真,而將其稱為“摘要”或什至“執行摘要”則會強調您考慮並關心他們的需求。

    您是願意與瑣碎工作的人一起工作,還是與預期並關心您的需求的人一起工作?

+1代表“執行摘要”,由機構廣泛使用,為決策者撰寫冗長的報告,決策者沒有時間或專門知識來詳細閱讀。管理人員可能沒有時間閱讀100頁的報告,這使4頁的執行摘要非常有用。
user44108
2018-06-22 13:09:15 UTC
view on stackexchange narkive permalink

正確處理並寫文檔,然後將其附加到電子郵件中。

如果創建的電子郵件需要使用標題,並迫使人們滾動閱讀“文本牆” “,這表明要成為一封電子郵件可能太久了。

相反,請編寫帶有標題的文檔,並對其進行格式化,以使所有目標受眾都易於閱讀。首先以通俗易懂的語言概述問題,然後再針對特定目的使用小標題。

使用隨附的電子郵件摘要內容,並讓讀者決定是否要閱讀文檔。

創建文檔可以增強此處的專業水平,表明您對此處的問題足夠關注,可以正確地對其進行文檔編制。

如果您鍵入TL; DR,請立即停止;這表明有一種更專業的方式來編寫您要編寫的內容。

user1666620
2018-06-22 00:58:00 UTC
view on stackexchange narkive permalink

我從未在工作電子郵件中使用過“ TLDR”。但是,在必鬚髮送較長電子郵件的情況下,通常我會嘗試思考我能想到的最具描述性的主題標題,並提供TLDR作為第一段,以學術用語作為摘要。 。這樣,某人就會知道他們是否應該對閱讀電子郵件的其餘部分足夠感興趣。

Pieter B
2018-06-22 16:24:35 UTC
view on stackexchange narkive permalink

您必須在這裡考慮TL:DR的歷史。

人們會在網上進行討論,有人會鍵入一個論點,而另一部分只會回答4個字母:TL:DR基本上來說:我對您的觀點不感興趣,而我將忽略您的論點。作為對策,

作為對策,人們開始在其參數中使用TL:DR,並提供摘要以嘗試縮短TL:DR用戶。

在專業環境中,假設您的讀者是“ TL-DR”讀者是不專業的。

Kilisi
2018-06-22 03:51:26 UTC
view on stackexchange narkive permalink

使用任何類型的未定義縮寫都是不專業的。

評論不作進一步討論;此對話已[移至聊天](https://chat.stackexchange.com/rooms/79297/discussion-on-answer-by-kilisi-is-using-tldr-unprofessional)。
Neil_UK
2018-06-22 15:55:10 UTC
view on stackexchange narkive permalink

如果我要給老闆寫一封技術性電子郵件,那麼一旦發現自己超出了3個段落,我就停下來,將這些“詳細信息”作為標題,然後在“行政摘要”的頂部添加一個新段落。

假裝他們的時間很寶貴,並稱他們為高管來撫摸他們,從來沒有給我帶來麻煩。

這更像是切線註釋,請參閱[answer]
這接近隱式回答問題。您介意對所提問題做出明確回答嗎?這篇文章包含有用的建議,但是除了回答實際問題(而不是代替回答)之外,還應該發布它。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...