DMA01
非同步溝通

非同步溝通

胡立

這篇純粹談一下自己對溝通的看法,講的比較多是針對工作上的討論或是其他要事的討論。

這其實不是一篇技術文,但就是因為不是技術文所以開頭才要來解釋一下什麼是同步。懶得看的話可以直接下拉看第二段。

在程式的領域中有一個名詞叫做「同步」,講到這個你可能會想到「同步進行」,例如說「這個調查我們同步進行」,你做你的我做我的,兩邊同時進行。但同步進行的「同步」翻成英文比較像是 parallel 的概念,也就是平行。

而程式領域中的同步是另外一個意思,比較像是你打開筆記軟體或是信箱時候出現的「同步處理中…」的同步,例如說我在電腦版打開 LINE,可能會出現「訊息同步中」,表示程式正在把手機上的訊息同步到我的電腦,這裡的「同步」就不是平行的意思了,而是「讓兩邊一致」,翻成英文是 synchronous。

程式領域中的同步指的就是 synchronous 而不是 parallel。那既然同步是要讓兩邊一致,就必定會有一個等待的過程,比較快的要等比較慢的追上來,兩者才會同步。

因此在程式領域中,同步指的就是「做一件事情時要等它結束,才做下一件事」。以讀檔案為例好了,程式碼可能會長成下面這樣:

let content = read_file('note.txt') // 讀取檔案
print content // 印出

第一行指示電腦去讀取一個檔案,等到讀取完畢之後會把內容指定給叫做 content 的變數,第二行則是把它,也就是把檔案內容印出。

如果程式是同步執行的,那在第一行執行完畢時就代表檔案已經讀取完了,才會繼續執行第二行。若是檔案很大要讀取十秒鐘,那第一行就會卡在那邊十秒,十秒後才繼續執行下一行。

同步的相反就叫做非同步(asynchronous,同步前面加個 a),代表程式碼在執行某些操作的時候是不等的。

以同樣的程式碼為例:

let content = read_file('note.txt') // 讀取檔案
print content // 印出

在執行第一行時,程式只負責「叫系統去讀檔案」,然後等檔案讀取完的時候再跟他說。因此就算讀檔要十秒,也不需要在這邊等待十秒,而是可以立即執行第二行,但在執行第二行時的 content 就不會是檔案內容了,因為這時候檔案根本沒讀取完。

那非同步怎麼回傳結果呢?就沒辦法用上面這樣的形式了,而是要換一種方式,換成那個閃閃發亮的紅色圓盤。

在百貨公司地下街點餐時如果你點完要一直在那邊等,沒辦法去其他地方,這就叫做同步。如果點餐之後店員給了你一個呼叫器,你可以先去別的地方,等到餐點好了的時候會透過呼叫器通知你,這就叫做非同步。

因此非同步的程式碼會像這樣:

function done(content) {
  print content // 印出
}read_file('note.txt', done) // 讀取檔案,讀取完時呼叫 done()

讀檔的函式現在沒有回傳值了,而是需要傳入一個 function,等到讀檔完成時再去呼叫你提供的函式。

化為點餐的範例就是這樣:

function 呼叫器() {
  // 呼叫器響了,來拿餐囉
}點餐('排骨飯', 呼叫器) // 點餐,做好的時候呼叫呼叫器

所以在非同步的模式之下那些耗時的操作不會阻礙你做下一件事,你不會被卡在那邊。在瀏覽器上面跑的程式就必須要是非同步的,因為你想想,如果是同步的話,那你去 server 拿個資料花十秒,你畫面就停住十秒不動了,因此這操作必須是非同步的。

但這篇其實沒有想談程式,而是要來談溝通。

 

先來談談寫信

像是寫信就是一件很非同步的事情,我寫完信之後寄給你,我不用每天都守在家裡等郵差送信來,而是可以去做其他事,等郵差主動上門就好。所以訊息之間是有時間差的,差距多寡取決於距離跟回信的快慢。

寫 Email 也是,你通常寫出去之後不會預期立刻有個回應,而是會等個一兩天或甚至更久,也因為如此,在寫信時會盡可能思考多一點狀況,可能就可以少一次來回,減少溝通成本。

舉例來說,如果寫 Email 沒有思考的話,約時間就會是這樣:

> 我後天八點有空,你呢?

我沒有欸,那你禮拜三九點有空嗎?

> 沒有,那你星期四十點有空嗎?

有,那就這樣吧

> 好!

經過了五封信件,兩造達成共識約好時間。但有些人預期到信件是需要時間的,可能就會先這樣寫:

> 我這周有空的時間是:
> 後天 八點以後
> 週四 八點以後
> 週五 八點以後
> 再看看你要約什麼時候

就星期四十點吧

> 好!

只要三次的來回就搞定了,因為有把「如果對方後天八點沒空怎麼辦」這個狀況給考慮進去。

 

懷念的即時通

早期的即時通訊其實是很同步的溝通模式,通常不太會留言給離線的人,而是看對方上線才會敲他。如果敲了沒有反應,還會送對方一個「叮咚!有人在家嗎~」或是一個嗆聲娃娃。

確認對方有在線上之後才開始聊天,有事情會說暫離,要下線會說我要下線了,像我有個學妹每次密他她都剛好有事說要先閃了,真的很忙。

會這樣是因為當年網路沒有現今這麼方便,可能每天(或間隔更久)都只有固定一段時間可以在電腦前上網,所以才需要這樣的溝通模式,利用兩個人都在線上的時候趕快把事情給搞定。

但現在的即時通訊不一樣了。

 

現代的即時通訊

現在網路已經是隨身必備的東西,因此大家在零碎時間時可能都會滑一下手機或是看個訊息。這已經不是那種「上線就會連續上線一段時間,下線就會下線好一陣子」的年代了。

在這種零碎的時間之下,同步溝通就顯得沒什麼意義。

在嗎?

請大家在發送這句話之前,先花個三秒想一下:「我想講的事情真的需要對方同時在線上嗎?」,如果需要的話,麻煩把句子寫完整:「在嗎?我有事情想要在你有空的時候直接跟你說」;如果不需要的話,麻煩擺脫同步的溝通模式,改採非同步,直接把你要講的事情說清楚。

你真正要講的事,其實就只是原本對方回「在」以後你要說的事,如果你不需要對方同時在線上,「在嗎」就是毫無意義而且會讓訊息多一次來回的句子。

你該做的是把想講的直接寫出來:

嗨!最近想約你敘舊吃個晚餐,你下禮拜方便嗎?

這樣等對方有空回訊息的時候就會來回你訊息,這也不是什麼對方一定要同時在線上才能講的事。

問我程式問題的時候也是一樣,不需要用「在嗎?」來當作開場白,甚至連開場白都不需要有,你就是把問題直接丟過來就對了,等我有空的時候自然就會回,而你問完之後就可以去做其他事情了,對於這些不需要同時在線上的事,非同步溝通才是比較有效率的解法。

如果對方回一回訊息突然不見,若是沒有在討論什麼真的很重要的事,你也不必多想,畢竟回訊息的時間本來就可能是零碎時間,例如說中午吃飯的空檔,或是搭公車的時候滑手機回一下,回完就把手機收起來了。在這樣一個使用網路時時間零碎的時代,這都是很正常的事情。

我自己幾乎沒在看已讀跟未讀,一來是因為很多人會看,所以有各種 App 或是方法可以看到訊息但不標已讀,二來是已讀不回也不代表什麼,像是我對於有些訊息就會想先點開,但要思考個一兩天看看怎麼回,已讀不回可能只是暫時的沒回,並不是真的就不回。

如果過了一兩週還真的沒回,那可能才是不想回或是漏掉了,可以等那個時候再做後續的處理。總之我想說的是,已讀後暫時沒有回覆是正常的,讀了訊息不代表對方馬上就要回你。

所以除非事態緊急,不然看對方已讀還是未讀其實是沒什麼意義的,大概只會有負面的影響而已吧,影響了你自己的心情。

 

非同步溝通的好處

每個人都可以自由且彈性地利用時間。當我想討論某件事情時我不用跟對方喬一個時間,我就先把自己想到的全都寫下來寄給對方,再等對方回覆就好。我就可以去做其他事情了,對方也可以去做其他事。

但有時候同步其實還是必須的,因為非同步就是善用零碎時間,把時間切成一小塊一小塊的,把事情搞定所需要的「整體時間」可能較短,但是時程可能會拉長,如果想在短時間內直接搞定,那約個同步的 meeting 當場解決可能會是更好的做法。

所以說其實同步非同步各有優劣啦,依照不同的情境選擇不同種溝通方式才是上策。但我想強調的是,很多事情真的不用等到對方上線才傳訊息,就像你寄信也不會管對方是不是在電腦前一樣。

 

這篇純粹談一下自己對溝通的看法,主要是覺得收到那種「在嗎?」的訊息就跟收到「在嗎?」的信件差不多瞎,想問什麼問題就直接問,我如果沒辦法回我就會說沒辦法回,不用等我在的時候才把想問的東西傳給我,我就算在也不會馬上回覆。

上面講的比較多是針對工作上的討論或是其他要事的討論,跟朋友的瞎聊當然另當別論,那種想怎麼傳都可以,硬是要把一則訊息分成好幾封也都可以,輕鬆自在就好。

但如果是要討論一些正事,可以在發送訊息時多想個幾秒,想想如何減少訊息的來回,想想非同步的精神,或許就能增進一些效率。

 

 

原文出處:非同步溝通

胡立
胡立
Huli

重度拖延症患者,興趣是光想不做,有很多想做的事,卻一件都沒有執行。

無聊的時候喜歡寫文章,發現自己好像有把事情講得比其他人清楚的能力。

相信分享與交流可以讓世界更美好。

Medium 文章列表請參考:https://aszx87410.github.io/blog/medium

[筆記] Facebook 資深產品經理聊聊產品與創新
今天下午在 Clubhouse 上聽了一場收穫良多的演講,講者和主持人 Ian,Albert,和 Han-Shen 都是在設計和產品管理上經驗豐富又願意分享的前輩,之前有機會在灣區和紐約向他們請益的時候就覺得收穫滿滿,這場 Clubhouse session 仍舊相當 insightful。此篇文章便是這場演講的筆記。
Project delivery
Step 1:Go to market plan, Step 2:User onboarding flow, Step 3:Deployment plan
談UX設計師網站改版三招:利害關係人訪談/數據分析/Prototype
本篇文章是工作心得,著重專案流程上遇到的情境問題。以下我會介紹這三種 UX 工具如何陪我度過網站改版案的驚濤駭浪: 1. 利害關係人訪談 2. 數據分析 3. Prototype