我第一次帶一支橫跨台北、柏林、舊金山的五人遠距團隊時，做錯的第一件事，是把辦公室那套原封不動搬上線：每天早上開站立會、Slack 訊息期待十分鐘內回、用「大頭貼有沒有亮綠燈」判斷誰在工作。三週後柏林的設計師寫信問我，能不能不要在他當地凌晨兩點 tag 他。那封信讓我明白，遠距團隊管理真正要重新設計的不是工具，而是「什麼算完成、什麼算在工作、什麼事值得打斷別人」這三件事的規則。這篇是我後來把制度重寫一遍的完整做法，包含台灣雇主躲不掉的工時記錄義務。
📌 本文重點
- 台灣雇主讓員工遠距工作，依勞動部「勞工在事業場所外工作時間指導原則」（106 年 11 月 30 日修正）仍須逐日記載勞工正常工作時間，並在交付加班時記載起始時間、由勞工回報終止時間；出勤紀錄依勞動基準法第 30 條第 5 項須保存 5 年、同條第 6 項須逐日記載至分鐘為止。
- 《勞動事件法》第 38 條明文規定「出勤紀錄內記載之勞工出勤時間，推定勞工於該時間內經雇主同意而執行職務」，這代表遠距團隊若用打卡軟體記錄「上線時間」，那份紀錄在訴訟中會反過來變成加班費的推定基礎。
- 把「線上狀態」當績效指標在統計上站不住腳：微軟 2022 年 9 月 22 日發布的 Work Trend Index 調查 11 國 20,006 名知識工作者，87% 的員工認為自己有生產力，但只有 12% 的領導者對團隊生產力有充分信心——落差來自可見度，不是產出。
- Nature 2024 年刊登的隨機對照試驗（Bloom, Han & Liang，中國一家科技公司的 1,612 名大學學歷員工、每週在家 2 天）顯示混合遠距讓離職率下降約三分之一，而績效評等與兩年內的升遷率沒有出現差異，代表「遠距會拉低績效」缺乏實驗證據支持——但這是「混合」而非「全遠距」的證據。
- 員工監控軟體在台灣不是「裝了就合法」：個人資料保護法（114 年 11 月 11 日最新修正）第 5 條要求不得逾越特定目的之必要範圍，第 19 條在「與當事人有契約或類似契約之關係」這個蒐集事由上還加了「且已採取適當之安全措施」，第 29 條規定非公務機關違法致生損害須負賠償責任（能證明無故意或過失者除外），而司法院釋字第 603 號（94 年 9 月 28 日）已把「資訊隱私權」定位為憲法保障的基本權。
- 跨時區團隊的重疊工時要用「保護時段」設計而非「盡量湊」：台北與德國時差 7 或 6 小時、與美東 13 或 12 小時，且歐美日光節約時間每年會讓重疊帶位移一小時兩次（美國為 3 月第二個週日至 11 月第一個週日）。
遠距團隊先崩掉的不是效率，是「完成」的定義
大部分人以為遠距團隊的第一個問題是「大家會不會偷懶」。實際帶過就知道，第一個爆掉的通常是交付：同一份東西 A 以為在等 B 確認、B 以為 A 還在改，兩邊各等三天，誰都沒偷懶，進度就是不動。遠距把「隱性同步」拿掉了——辦公室裡一個轉頭、一句「這樣可以喔」就結案的事，在遠距沒有寫下來就等於沒發生。
我後來把失效模式歸成三類，因為每一類的解法完全不同，混在一起處理只會做白工。
| 失效模式 | 表面症狀 | 真正的缺口 | 該修的地方 |
|---|---|---|---|
| 交接斷點 | 任務停在半路，沒人推進 | 沒有明確的「當前負責人」與「下一步是誰」 | 每張任務卡強制填 DRI 與下一動作 |
| 脈絡遺失 | 同一個決策每兩週被重新討論一次 | 結論只存在於某次會議或某條訊息 | 決策一律寫進文件，訊息只放連結 |
| 回應焦慮 | 大家整天掛在聊天室不敢離線 | 沒有約定回覆時效，所有訊息看起來都像急件 | 分級的回覆 SLA 與「不必即時回」的明文授權 |
這三類裡最被低估的是第三類。GitLab 把全公司的做法寫成公開手冊，其中溝通章節直接寫明：團隊成員不被期待隨時在線，也沒有在計畫工作時間之外回訊息的義務。把「不必秒回」寫成白紙黑字的制度，比任何一次「你們放心、下班不用理我」的口頭安慰都有效，因為前者是可以被引用的規則，後者只是老闆當下的心情。
還有一個更根本的：遠距團隊裡「完成」必須有可驗收的形式。不是「我做好了」，而是「連結在這、驗收條件是這三條、我已自檢過」。這件事在接案端也一樣，我在需求確認防呆流程那篇寫過同樣的機制：把驗收條件前置，比事後吵架便宜十倍。
非同步溝通的三條規則：什麼寫成文件、什麼才開會、回覆時效怎麼約定
非同步（async）不是「大家慢慢回」，而是「送出訊息時不預期立即回覆」（”you send a message without expecting an immediate response”）——Doist 在他們的非同步指南裡就是這樣定義的。這個定義的重點在送出方：你要在按下送出之前，就把對方回覆所需的全部脈絡準備好，否則你只是把等待成本轉嫁給別人。
規則一：什麼事該寫成文件
判準只有一條——這個資訊未來三個月內，會不會有第二個人需要查？會，就寫文件；不會，才丟訊息。GitLab 的做法是 handbook-first：所有流程與決策先進手冊，聊天室只負責通知與貼連結，他們的公開手冊如果印出來超過兩千頁。
我在自己的小團隊落地時，把它縮成四類必寫文件，因為五人團隊不需要兩千頁：
- 決策紀錄：做了什麼決定、當時考慮過哪些選項、為什麼淘汰、由誰拍板、什麼條件下要重新檢討。少了最後一項，同一個議題半年後一定被翻出來重吵。
- 流程 SOP：任何做過兩次以上的事。第二次做的時候順手寫，不要等第三次。
- 專案交接包：現況、卡在哪、下一動作、相關連結、風險。這份是為「明天你被車撞到」寫的。
- 對外承諾：跟客戶說過的期限、範圍、例外條款。這一類我一律要求貼原文截圖或原信連結，不接受轉述。
GitLab 手冊裡有一條我實測後覺得最值得抄：當你問問題、而答案不在文件裡時，得到答案的人要立刻把它補進文件，補文件的動作本身就是對回答者的道謝。這條規則把「文件會過期」這個永恆問題，變成每次提問都會順帶修補一次。
反過來也有不該寫進公開文件的東西。GitLab 把「團隊成員資料（個人績效、到職日、離退）」「違反或可能違反政策與當地法規之情事」「客戶或合作夥伴資訊」「重大未公開資訊」列為敏感主題，走保密層級與內部管道而不是公開手冊；連行事曆上的「一對一績效或考評會議」與「組織調整會議」也建議設為私人，並把「負面回饋一對一給」列為原則。至於這幾類事情該不該一律改走同步管道，手冊並沒有這樣規定，那是我自己的做法——理由是文字沒有當場澄清的機會，被誤讀的代價太高。這不是保密癖，是把風險放在對的容器裡。
規則二：什麼事才值得開會
我用一句話當閘門：如果這件事在文字裡來回三輪還沒收斂，或是它牽涉情緒與信任，就開會；否則不開。GitLab 手冊蒐集了團隊成員自己的判準，反覆出現的模式是：緊急事件、線上故障、需要即時對話才能除錯、創意發想與腦力激盪、以及「非同步已經失敗」的時候，才切回同步。
GitLab 手冊自己也把話說在前面：非同步不是目的本身（”Working asynchronously is not a goal unto itself”），它很強大但不是絕對，尤其不該以犧牲價值觀為代價，重點是在可行時把討論往非同步推，好空出真正需要的同步時刻。以下這個反面觀察不是手冊寫的、是我自己帶團隊踩出來的：如果什麼都非同步，你會得到一個很能擴張、但做不出決定的組織——討論串分叉、脈絡漂移、沒人知道誰決定了什麼。這跟「什麼都開會」一樣糟，只是糟得比較安靜。
我實際使用的會議分級如下，重點是每一種會都要有「不開會的替代方案」，否則它會自動變成每週固定行程。
| 會議類型 | 該開的條件 | 時長上限 | 不開會的替代做法 |
|---|---|---|---|
| 每日進度 | 幾乎永遠不需要 | — | 每人每天在專案工具寫三行：昨天完成、今天要做、卡在哪 |
| 專案啟動 | 新專案、目標尚未取得共識 | 60 分鐘 | 無（這種會值得開，但會前要先發文件） |
| 設計／方案評審 | 文字來回超過三輪未收斂 | 45 分鐘 | 錄一段 5 分鐘螢幕錄影＋文件註解 |
| 一對一 | 固定，雙週一次以上 | 30 分鐘 | 不可替代，這是遠距唯一能接住情緒的通道 |
| 事故處理 | 正在燒的線上問題 | 不設限 | 無，但結束後 24 小時內要寫事後檢討文件 |
會議還有一條硬規定：沒有寫下結論的會，視同沒開過。GitLab 的手冊把「確保線下對話的結論被寫下來」列為溝通原則之一，我在自己團隊的做法更粗暴——誰召集誰負責在散會後 30 分鐘內把結論貼回原本的任務卡，貼不出來就代表這場會沒有結論，那要重開還是取消，由召集人自己面對。
規則三：回覆時效怎麼約定
這是最容易被跳過、卻最直接影響信任的一條。沒有明文 SLA 時，每個人會用自己的標準揣測別人：有人覺得兩小時沒回是失禮，有人覺得隔天回很正常，於是誤會就開始累積。
我用的是三級制，寫進團隊手冊第一頁：
| 等級 | 使用管道 | 承諾回覆時效 | 可用時機 | 誤用的代價 |
|---|---|---|---|---|
| P0 立即 | 電話／簡訊 | 15 分鐘內 | 正式環境故障、客戶端已受影響 | 一年用不到三次；濫用一次就失效 |
| P1 當班內 | 聊天室 @ 個人 | 對方當地工作時間內 4 小時 | 對方是唯一 blocker，你已無法推進 | 對方下班就是下班，不追、不補 tag |
| P2 非同步 | 任務卡留言／文件註解 | 24 小時內（週末順延） | 絕大多數工作 | 沒有代價，這是預設值 |
搭配三條配套，缺一條這個表就會失效。第一，P1 只能 @ 個人不能 @ 群組，因為 @群組等於沒有人負責。第二，回覆時要給出時間點，不要只回「收到」「我等等看」——GitLab 手冊直接指出這種回覆沒有幫助，正確做法是給一個期限、或乾脆花兩分鐘做完讓對方腦袋清空。第三，不要用群組私訊（group direct message）討論工作——GitLab 手冊直接寫「Do not use group direct messages」，理由是群組私訊很難維護、追蹤與回覆，而且有一個關鍵限制：你無法把人加進那段對話，這會妨礙協作與透明；正確做法是改用私人頻道。另外值得一提的是，GitLab 只保留 90 天的 Slack 紀錄而且是刻意為之——目的就是讓聊天室無法被當成專案管理工具，逼大家把該留的東西寫進手冊。
工具選擇本身反而是最不重要的部分。如果你還在決定用哪一套任務系統，我另外寫過專案管理工具比較 2026，把 Trello、Asana、ClickUp、Notion 適合的團隊規模拆開比較；文件系統的選擇則可以參考2026 AI 筆記工具比較。但工具換得再好，沒有回覆 SLA 的團隊還是會過勞。
跨時區重疊工時怎麼設計：保護時段而不是盡量湊
跨時區最常見的錯誤，是把重疊工時當成「大家盡量配合」的善意，而不是一個被明確設計、寫進契約、且會被保護的時段。沒有寫下來的重疊時間，最後一定由職級最低、時區最不利的那個人吸收。
先看數字。台灣採用 UTC+8 且沒有日光節約制度，所以台北端的時間是固定的，變動的永遠是對方。以下是常見協作地的時差區間：
| 對方所在地 | 標準時間偏移 | 與台北時差 | 可用的重疊帶（台北時間） | 備註 |
|---|---|---|---|---|
| 新加坡、馬來西亞、香港 | UTC+8 | 0 小時 | 幾乎完全重疊 | 不需特別設計 |
| 日本、韓國 | UTC+9 | 1 小時 | 上午 10:00–下午 5:00 | 對方午休較早 |
| 越南、泰國、印尼（西部） | UTC+7 | 1 小時 | 上午 10:00–下午 6:00 | 幾乎無痛 |
| 澳洲東岸 | UTC+10／夏令 UTC+11 | 2 或 3 小時 | 上午 8:00–下午 3:00 | 南半球夏令時在我們的冬天 |
| 印度 | UTC+5:30 | 2.5 小時 | 下午 1:00–晚上 8:00 | 無日光節約 |
| 德國、法國、荷蘭 | UTC+1／夏令 UTC+2 | 7 或 6 小時 | 下午 4:00–晚上 7:00 | 夏令期間重疊帶往前移一小時 |
| 英國 | UTC+0／夏令 UTC+1 | 8 或 7 小時 | 下午 5:00–晚上 8:00 | 同上 |
| 美國東岸 | UTC−5／夏令 UTC−4 | 13 或 12 小時 | 台北早上 9:00–11:00＝對方前一晚 20:00–22:00（冬令）／21:00–23:00（夏令） | 幾乎無健康重疊帶 |
| 美國西岸 | UTC−8／夏令 UTC−7 | 16 或 15 小時 | 台北早上 9:00–11:00＝對方前一日 17:00–19:00（冬令）／18:00–20:00（夏令） | 反而比東岸好排 |
這張表有一個管理者常忽略的陷阱：歐美的日光節約時間會讓你精心設計的重疊帶一年位移兩次，而且兩邊位移的日期不同一天。美國依 2005 年能源政策法，日光節約自 3 月第二個星期日凌晨 2 時開始、11 月第一個星期日凌晨 2 時結束；歐盟依 Directive 2000/84/EC，夏令時間則是 3 月最後一個星期日與 10 月最後一個星期日的格林威治時間凌晨 1 時起訖。也就是說 3 月中到 3 月底、10 月底到 11 月初這兩段期間，你的台北團隊跟美國、歐洲的時差會分別是不同的數字。
我的做法是：行事曆上的固定會議一律用對方當地時間釘住，並在每年三月與十月各排一次「時區校正」提醒，把所有跨時區的循環會議重新確認一次。這聽起來很瑣碎，但我看過整個團隊有兩週在錯誤的時間上線，只因為沒人記得歐洲已經換季。
三種重疊工時模型，挑一種、不要混用
模型一：核心帶（Core Hours）。約定每天固定 2–4 小時所有人必須可即時聯絡，其餘時間自主。適合時差在 3 小時以內的團隊。優點是簡單，缺點是台灣對歐美完全套不上——你不可能要求柏林同事每天凌晨三點上線。
模型二：交接接力（Follow-the-Sun）。不強求同時在線，而是設計「交棒點」：台北下班前把任務交接包寫完並轉移負責人，歐洲上班時接手，再交給美洲。這個模型的成敗完全押在交接包的品質上，因為沒有人可以立刻問你問題。我的規定是交接包必須包含「我卡在哪」與「如果你也卡住，可以做的替代任務是什麼」。
模型三：錨點會議（Anchor Meeting）。每週只保留一到兩個所有人到齊的時段，且這個時段必須輪流承擔不便——這個月台北晚上八點，下個月換成柏林早上八點。輪流承擔痛苦是這個模型唯一的道德基礎，一旦固定由某個時區長期犧牲，人就會走。
如果你是接案身分而非受僱，跨時區的界線設定更需要寫進報價與合約，我在跨時區協作實戰指南裡拆得更細，包括會議費怎麼算進報價、以及非同步交付的驗收節奏。
台灣雇主躲不掉的部分：遠距的工時記錄與加班認定
這一節是台灣讀者最需要、國外大站不可能寫的部分。很多台灣公司以為「讓員工在家工作＝不用管工時」，實際上恰好相反：只要僱傭關係存在、勞工仍在雇主指揮監督下提供勞務，勞動基準法的工時義務一條都沒有免除，只是記錄方式改變。
勞動部的指導原則怎麼說
勞動部訂有「勞工在事業場所外工作時間指導原則」（104 年 5 月 6 日勞動條三字第 1040130706 號函訂定，106 年 11 月 30 日修正），專門處理不在雇主場所內工作的工時認定。其中與遠距團隊直接相關的重點包括：
- 書面約定義務：勞資雙方應就正常工作的開始與終止時間、延長工時（加班）的認定、休息與輪班等事項以書面勞動契約約定，並訂入工作規則。
- 工作時間的定義：指勞工在雇主指揮監督下提供勞務、或受指示等待提供勞務的時間。休息時間則指勞工得脫離雇主指揮監督、自由利用的時間。
- 逐日記載：雇主應逐日記載勞工的正常工作時間。需要加班時，雇主應記載交付工作的起始時間，勞工完成後以雙方約定的方式回報終止時間，由雇主據以記載。
- 正常工時結束後的指示：若雇主在正常工作時間結束後，以通訊軟體或其他方式指示工作，勞工可自行記錄並檢附對話或交付紀錄，雇主應予補登。
- 記載工具不限打卡鐘：指導原則明列可用網路回報、手機打卡、通訊軟體紀錄、客戶簽單等多元方式輔助記載。
- 免回報的例外：工作性質特殊者，勞雇雙方得預先約定在一定時數內免回報、也不需事前同意。
指導原則還特別把「電傳勞動」列為一種類型，定義為在雇主指揮監督下、藉由電腦資訊科技或電子通信設備履行勞動契約者——這幾乎就是今天所有遠距工作者的法律描述。對這一類，指導原則建議由勞工自我記載（例如工作日誌），經電子設備記錄後電傳雇主，延長工時則採事前申請或事前約定的方式處理。
三條會咬人的法條
光看指導原則還不夠，因為指導原則本身不是罰則來源。真正會讓公司付出代價的是下面這三條：
| 法條 | 內容重點 | 對遠距團隊的實際意義 |
|---|---|---|
| 勞動基準法第 30 條第 5、6 項 | 第 5 項：「雇主應置備勞工出勤紀錄，並保存五年。」第 6 項：「前項出勤紀錄，應逐日記載勞工出勤情形至分鐘為止。勞工向雇主申請其出勤紀錄副本或影本時，雇主不得拒絕。」 | 遠距不是不用記，是要記到「分」，而且要留 5 年、員工隨時可以調閱 |
| 勞動基準法第 32 條 | 延長工時須經工會或勞資會議同意；「延長之工作時間連同正常工作時間，一日不得超過十二小時」；延長工時 1 個月不得超過 46 小時，另經工會或勞資會議同意得達 54 小時，但每 3 個月不得超過 138 小時。僱用 30 人以上依但書延長者，應報當地主管機關備查 | 注意 12 小時是「正常工時＋加班」的合計上限，不是加班本身可以到 12 小時；遠距讓加班變得無形，但上限並沒有變寬，「反正在家，多做一下」照樣會撞到 138 小時的季上限 |
| 勞動事件法第 38 條 | 「出勤紀錄內記載之勞工出勤時間，推定勞工於該時間內經雇主同意而執行職務」 | 舉證責任翻轉：只要出勤紀錄上有那段時間，就推定是雇主同意的工作時間，要由雇主提出反證推翻 |
第三條是我認為所有台灣遠距主管都該先讀懂的一條。它的實際效果是：你裝的那套「自動記錄上線時間」的軟體，很可能不是在監督員工，而是在替員工累積加班費的證據。如果系統把員工晚上十點打開筆電回一封信也記成「出勤」，而公司又沒有配套的加班申請與核准紀錄，這段時間在爭訟時就會落在推定範圍內，由公司負責舉證推翻。
換句話說，遠距工時制度要成立，必須同時具備兩件事：一是明確的正常工作起訖時間書面約定，二是可以清楚區分「加班」與「自主使用系統」的申請與核准流程。只做前者，加班就變成無底洞；只做後者，你連基本的出勤紀錄義務都沒盡到。
地方政府的行政指導：台北市的版本
臺北市政府勞動局另訂有「臺北市事業單位實施居家工作勞動條件保障指導原則」，於 2023 年 3 月 1 日實施，性質是行政指導而非強制法令，目的在減少居家工作的勞資爭議。它值得看的原因是，它把幾件勞基法沒有明講、但實務上一定會吵的事寫出來了。這份指導原則全文共 14 點（勞動局 112 年 1 月 17 日核定），以下幾點直接對應遠距主管的日常決策：
- 第七點（設備與費用）：雇主「得提供或補助」居家工作者必需之軟硬體設備（電腦、螢幕、鍵盤、VPN 系統、印表機等）、設施（符合人體工學之桌椅等），以及處理業務所生之必要支出費用（網路費、電費等）。注意用字是「得」，不是「應」。
- 第八、九點（工時記載）：雇主應「事先與勞工約定正常工作起訖時間及休息時間，並依約履行」；應置備出勤紀錄並逐日記載正常工作時間至分鐘為止，出勤紀錄「得以電腦資訊或電子通信設備記載」，並須與勞工約定回報方式（電子郵件工作日誌、APP 打卡、通訊軟體、差勤系統等）。
- 第十點（加班）：正常工作時間結束後若因工作需要或接獲雇主要求延長工時，雇主應記載交付工作的起始時間，勞工完成後回報持續工作時間與成果並留存紀錄，雇主應記載終止時間，「並給付加班費」——指導原則把補登與付錢寫在同一句，不是只要求登記。
- 第十一、十二點（離線權）：雇主應尊重勞工休假或非約定工作時間的合理「離線權」。這裡最容易被誤讀：指導原則並沒有全面禁止下班傳訊息，而是要求「如仍有傳送相關電子郵件或數位訊息通知之情形時，應伴隨提醒受訊者『毋須立即回復(或處理)』之提醒文字」；若有緊急突發事務須勞工立即處理，應依勞動基準法第 32 條第 4 項或第 40 條辦理通報核備程序，並與勞工約定處理時間之合理限度、事後補行休息或休假；且不得因勞工在休息或休假期間未回覆郵件電話，就對其勞動條件、職務或晉升為處罰或不利對待；還要對勞工與管理階層施行離線權教育訓練。
- 第十三點（申訴）：雇主應建立內部申訴管道、調查機制及懲處辦法，處理居家工作與離線權爭議。
把第十一、十二點連起來讀，實務上的合規動作其實是四件事而不是一件：約定離線權的方式與期間、非工時訊息附註「毋須立即回復」、緊急事務走勞基法的通報核備、以及不得因未回覆而不利對待。只做到「盡量不要下班傳訊息」，其他三件都沒做，並不算符合這份指導原則。
臺北市勞動局的專區同時提供事業單位自主檢核用的評分表與問答集。那份「事業單位實施居家工作自主檢核評分表」共 25 個項目，官方在表尾寫明：勾選已完成達 15 項以上為「及格」，14 項以下為「不及格」、「有較高衍生爭議風險」。「離線權」在台灣目前沒有專法，但它已經出現在地方政府的行政指導與自主檢核表裡（該表第 7 大類 7-1 至 7-5 全都在問離線權），這代表主管機關在處理爭議時的傾向。對遠距主管來說，最務實的讀法是：下班後傳訊息這件事，正在從「文化問題」變成「制度風險」。
還有一個常被忘記的：職業安全衛生
勞動部職業安全衛生署訂有「居家工作職業安全衛生參考指引」，供事業單位與居家工作者參考，用於強化居家工作的危害辨識與風險評估。這份指引的版本日期常被寫錯，值得先講清楚：它是 110 年 6 月 23 日以勞職衛 1 字第 1101032036 號函訂定、111 年 6 月 1 日以勞職衛 1 字第 1111031706 號函修訂，職安署網站上那個「112-05-04」是公告張貼日，不是指引的發布日。指引原是因應 COVID-19 疫情期間的居家工作而訂，但內容並不限於防疫：它要求雇主會同居家工作者辨識工作環境與職務可能的安全衛生危害，明列應評估「長時間工作、異常工作負荷、疏離人群、工作與生活無法取得平衡」等對身心健康的影響，並建議提供符合人體工學的桌椅與顯示器配置、規劃定期休息（例如每半小時站立伸展）、以及支持同事間的非正式交流以降低孤立風險。臺北市那份指導原則第五點也直接指向這份指引，要求雇主在「安全衛生工作守則」中訂定與居家工作有關的內容。員工在家工作期間發生的傷害是否構成職業災害，並不因為地點在家裡就自動排除，這也是為什麼書面約定裡最好把工作場所、工作時段與工作內容寫清楚——它同時是工時的界線，也是職災認定的界線。至於長期在家工作對身體的實際傷害，我另外整理過遠距工作者的久坐健康自救指南，主管在編列設備預算時可以拿來當清單。
遠距績效怎麼衡量：線上狀態是最糟的指標
先講結論：「線上狀態」測的是員工對監視的服從度，不是產出。綠燈可以用滑鼠晃動器製造，鍵盤敲擊數可以用重複輸入衝高，而這些行為恰恰是你最不希望聰明員工把時間花上去的地方。
微軟在 2022 年 9 月 22 日發布的 Work Trend Index 報告替這個落差提供了數字。該調查由 Edelman Data & Intelligence 於 2022 年 7 月 7 日至 8 月 2 日在 11 個國家訪問 20,006 名全職或自僱知識工作者，結果是：87% 的員工回報自己在工作中具有生產力，但只有 12% 的領導者對團隊的生產力有充分信心；85% 的領導者表示轉向混合工作讓他們難以確信員工是否真的有生產力。微軟把這個現象命名為「生產力偏執（productivity paranoia）」，並在報告裡把它定義為：領導者擔心生產力流失是因為員工沒在工作，即使工時、會議數與其他活動指標其實都增加了。
值得注意的是，這份調查測到的是「信心落差」，不是「產出落差」——它沒有證明員工真的比較不努力，只證明管理者看不見。把看不見誤讀成沒做事，是遠距管理最昂貴的認知錯誤。
那產出到底有沒有掉？目前品質最高的證據來自 Nature 在 2024 年刊登的一篇隨機對照試驗（Bloom, Han & Liang，Nature 630 卷 8018 期，第 920–925 頁，DOI 10.1038/s41586-024-07500-2）。研究把中國一家科技公司的 1,612 名員工隨機分派為「每週五天進辦公室」與「每週三天進辦公室、兩天在家」兩組，追蹤六個月介入期與其後的表現：混合組的工作滿意度提升、離職率下降約三分之一，且這個下降在非管理職、女性與通勤時間長的員工身上具統計顯著性；等值性檢定（null equivalence tests）顯示混合工作並未影響後續兩年的績效評等，兩年內的升遷率「整體與各主要子群體皆未見差異」，工程師寫出的程式碼行數同樣沒有受影響。另一個常被忽略的發現是：實驗中的 395 名主管，對「混合工作對生產力的影響」的看法從實驗前平均認為 −2.6%，實驗後翻轉為 +1.0%。
這篇研究的限制要說清楚：它測的是「每週兩天在家」的混合模式，不是全遠距，也不是跨時區團隊；樣本來自中國單一一家科技公司的大學學歷知識工作者（含電腦工程師），不是所有產業、所有職級。所以正確的結論是「混合遠距沒有付出績效代價」，而不是「全遠距一定沒問題」——把它當成全遠距的萬用背書，就是誤用證據。
可以拿來替代的四類指標
| 常見的壞指標 | 它實際測到的東西 | 建議替代指標 | 怎麼取得 |
|---|---|---|---|
| 線上時數／綠燈時間 | 員工願意讓你看見的程度 | 週期內完成的交付項目數與規模 | 任務系統的完成紀錄 |
| 訊息回覆速度 | 員工被打斷的頻率 | 依 SLA 分級的達成率（P1 四小時內回覆比例） | 抽樣檢視，不必自動化 |
| 鍵盤／滑鼠活動 | 噪音，以及員工的反制創意 | 交付品質：返工次數、上線後缺陷數 | 驗收紀錄與事故紀錄 |
| 會議出席率 | 行事曆填滿的程度 | 決策週期：議題提出到拍板的天數 | 決策文件的建立與結案時間戳 |
設計指標時有一條我踩過坑才學會的原則：任何你打算拿來評分的數字，員工都會學會操作它，所以在採用之前先問「如果有人想作弊，最省力的作弊法是什麼」。如果答案是「多開幾張小任務卡」，那「完成任務數」就不能單獨使用，必須搭配規模或影響力的加權；如果答案是「把驗收標準寫鬆一點」，那驗收條件就不能由執行者自己訂。
另外，遠距團隊的績效面談必須比實體更頻繁、而不是更少。實體辦公室裡，主管一週有幾十次微小的觀察機會來校正印象；遠距沒有這些，所以如果你半年才談一次，你的評價其實建立在極少的樣本上。我的節奏是雙週一對一 30 分鐘、每季一次正式回顧，一對一絕不取消——寧可縮短成 15 分鐘。
監控軟體的法律與信任成本
市面上的員工監控軟體功能包山包海：定時截圖、鍵盤活動、瀏覽紀錄、應用程式使用時間、甚至攝影機定時拍照。導入前必須先想清楚兩件事：法律上能不能做、以及做了之後你會失去什麼。
台灣法律的三道關卡
第一道是憲法層次的資訊隱私權。司法院釋字第 603 號（民國 94 年 9 月 28 日公布）明確指出，隱私權保障人民決定是否揭露其個人資料、以及在何種範圍內、於何時、以何種方式、向何人揭露的決定權，並保障人民對其個人資料之使用有知悉與控制權、以及資料記載錯誤的更正權。員工並不因為簽了勞動契約，就整片放棄這些權利。
第二道是個人資料保護法。第 5 條要求個人資料的蒐集、處理或利用應尊重當事人權益、依誠實及信用方法為之，且不得逾越特定目的之必要範圍；第 19 條規定非公務機關蒐集個資須有特定目的且符合法定情形之一，而依 114 年 11 月 11 日修正後的條文，「與當事人有契約或類似契約之關係」這個常被公司拿來當依據的事由，還多了一個並列條件——「且已採取適當之安全措施」，換句話說，光是「他跟我們有僱傭契約」已經不足以撐起蒐集正當性；第 20 條則限制利用必須在特定目的必要範圍內。關鍵字是「必要範圍」——這是一個比例原則的檢驗，不是一句「員工同意了」就可以概括通過。
第三道是責任條款。個資法第 29 條規定，非公務機關違反本法致個人資料遭不法蒐集、處理、利用而損害當事人權利者，應負損害賠償責任，但能證明其無故意或過失者不在此限。也就是說舉證責任偏向企業，公司必須證明自己沒有故意過失，而不是由員工證明公司有錯。
一個實務判準：從「必要性」倒推功能清單
與其問「這個功能合不合法」，不如反過來問「這個功能是為了達成哪一個具體、可說明的營運目的，而且有沒有侵害更小的替代手段」。我把常見功能依這個邏輯排成風險梯度：
| 監控手段 | 侵害程度 | 是否存在侵害更小的替代 | 我的建議 |
|---|---|---|---|
| 由員工自行填寫的工時／工作日誌 | 低 | 本身就是最小手段 | 首選，且符合勞動部指導原則對電傳勞動的建議 |
| 公司配發設備的資產盤點與資安更新狀態 | 低 | 難以替代，且屬資訊安全必要 | 可行，但範圍應限於設備狀態、不含內容 |
| 公司系統的登入／存取日誌 | 中 | 可縮短保存期限、限制查閱權限 | 可行，需明確告知目的、保存期限與查閱權限 |
| 應用程式使用時間統計 | 中高 | 可改為「交付成果」衡量 | 多數情境沒有必要性，不建議 |
| 定時截圖、鍵盤側錄、瀏覽全紀錄 | 高 | 幾乎都有替代 | 不建議；必要性難以說明，且會蒐集到大量無關個資 |
| 攝影機定時拍攝、常時開啟鏡頭 | 極高 | 有 | 不建議；居家場景必然蒐集到家人與住宅內部影像 |
最後兩列在居家工作情境還有一個獨有的問題：員工的家不是公司的場所，截圖與鏡頭必然會蒐集到與工作無關、甚至屬於第三人（家人、同住者）的個人資料，那些人跟公司之間沒有任何契約關係，公司對他們的蒐集缺乏合法基礎。這是很多主管在評估時完全沒想到的一層。
信任成本比法律成本更貴
《哈佛商業評論》在 2022 年 6 月 27 日刊出 Chase Thiel、Julena M. Bonner、John Bush、David Welsh 與 Niharika Garud 五位研究者的文章，標題直接指出監控員工反而使他們更可能違反規則。文中提到疫情期間「how to monitor employees working from home」這類網路搜尋增加了 1,705%（也就是暴增超過十七倍）。他們在兩項研究中發現，被監控的員工明顯更容易違規，包括在測驗中作弊、竊取設備、刻意放慢工作速度；而背後的機制是：監控讓員工在潛意識裡對自己的行為感到較少責任，最終更可能做出他們自己原本會認為不道德的事。要不要遵守規則於是從「我是什麼樣的人」滑向「反正責任不在我」——這一句是我的轉述，原文的用詞是責任感被削弱。
我自己觀察到的版本更平淡但更普遍：裝了監控之後，表現最好的人會先離職。因為他們是最不需要被監控、也最有機會換工作的人，而監控傳遞的訊息是「公司預設你會偷懶」。你花錢買了一個系統，把最不需要它的人趕走，留下最需要它的人——這個交易在任何一張試算表上都不划算。
如果團隊裡有真實的信任問題（例如已經發現有人重複謊報進度），正確做法是針對個案處理，而不是對全員施加集體監控。集體監控的隱含訊息是主管不敢處理個案，這件事全隊都看得出來。至於個人層級的裝置與帳號安全，我在手機 APP 個資外洩怎麼防裡整理過權限自檢的做法，那是員工自保的部分，跟公司該不該監控是兩個問題。
新人遠距 onboarding 的前 30 天
遠距 onboarding 失敗的樣子很好認：新人第三週還在問「我到底該找誰」，或是連續兩週產出為零卻沒人發現。實體辦公室有大量偶然的補救機會——隔壁桌看到你發呆會問一句——遠距把這些全部拿掉了，所以流程必須主動製造這些接觸點。
GitLab 的公開做法值得參考：他們預期遠距 onboarding 至少需要兩週完整時間，第三週才做團隊專屬的訓練，並且明說不期待任何人第一天就上手。所有 onboarding 步驟被寫成標準化的任務清單，讓新人自主推進、盡可能非同步完成，同時每位新人會配一位 onboarding buddy 當作友善的求助窗口。他們把 onboarding 拆成三個面向：組織的（流程與制度在哪裡查）、技術的（工具怎麼用、如何取得早期小勝利）、社交的（怎麼認識人）。
我把這個框架壓縮成一張 30 天表，適合 5 到 20 人的小團隊：
| 期間 | 目標 | 新人的可驗收產出 | 主管必做的事 |
|---|---|---|---|
| 第 1–3 天 | 能自己找到答案 | 讀完團隊手冊，並提出至少 5 個「手冊沒寫清楚」的問題 | 當天回覆全部問題，並把答案補進手冊 |
| 第 1 週 | 完成第一個真實但低風險的交付 | 一個小任務走完全流程：接單、做、送審、上線 | 指派 buddy；第 3 天與第 5 天各一次 15 分鐘一對一 |
| 第 2 週 | 理解「好」的標準 | 對照三份既有的優良交付物，寫出自己的觀察 | 親自示範一次完整驗收，把默契變成明文 |
| 第 3 週 | 接手正式責任 | 成為至少一張中型任務的負責人 | 刻意放手；只在對方求助或超過約定期限時介入 |
| 第 4 週 | 雙向校正 | 提出三件「這個流程可以改」的具體建議 | 正式回饋面談；同時問新人 onboarding 哪裡不順並修流程 |
幾個我實際踩過的坑，寫出來給你省時間。第一，設備一定要在到職日前送達並確認可以開機——遠距最常見的第一天災難是筆電還在物流。第二，第一週不要塞滿會議，新人在陌生的非同步環境裡最需要的是安靜讀文件的時間。第三，「早期小勝利」要刻意設計：第一週就讓對方完成一個真的會上線的小東西，這對遠距新人的心理錨定效果遠超過任何歡迎會。
第四個坑最隱形：新人不敢說 onboarding 有問題。GitLab 手冊也點出這件事——當 onboarding 出狀況時，新人往往不覺得可以提出來。解法是主管主動、定期地問，而且要問具體問題（「這週有沒有哪一刻你卡住超過 30 分鐘卻不知道找誰？」），不要問「還好嗎」。
如果你是在招募端而不是管理端，遠距職缺的篩選邏輯跟實體很不一樣，我另外寫過遠距工作面試怎麼準備，裡面的必考題其實反過來也是主管該問的題目。
看不到就焦慮：管理者的心理與信任建立
先承認一件事：新手遠距主管的焦慮是真的，而且不是人格缺陷。你的績效由團隊產出決定，但你失去了絕大部分即時訊號，這在心理上等同於被蒙眼開車。問題不在於你會焦慮，而在於你把焦慮轉譯成什麼行為——轉成監控與催問，就會毀掉團隊；轉成把資訊流設計得更透明，就會救回團隊。
我用三個問題自檢，每次想要「看一下大家在幹嘛」的時候先問自己：
- 我現在缺的是哪一個具體資訊？如果答不出來，那就不是資訊需求，是情緒需求，該處理的是我自己。
- 這個資訊有沒有非侵入的取得方式？多數時候答案是「去看任務板」而不是「去問人」。
- 如果我什麼都不做，最壞會發生什麼？如果最壞情況是「延遲兩天」，那就值得等；如果是「客戶違約」，那就直接開會，不要用暗示的。
信任在遠距團隊的建立方式跟實體不同：實體靠相處時間累積，遠距靠可預測性累積。一個每次都準時交付、卡住會提前說的人，即使你從沒見過他本人，你也會信任他；一個天天在線但交付永遠要催的人，你天天看得到也不會信任他。所以管理者要做的是讓「可預測性」變得容易被看見——這正是前面那些 SLA、交接包、決策文件真正的功能：它們是信任的基礎建設。
反過來，主管自己的可預測性同樣是團隊焦慮的來源。如果你的回覆時間從十分鐘到三天不等、決策標準每次不同、答應的事偶爾忘記，團隊就會學會不依賴你，於是他們開始自己猜、開始不報壞消息，你的資訊會愈來愈少，焦慮再升一級。這是我看過最常見的遠距管理惡性循環，而起點通常是主管而不是員工。
還有一件常被跳過的事：遠距員工的孤立感是實際存在的職場風險，不是矯情。Buffer 與 Nomad List、Remote OK 合作的 2023 年 State of Remote Work 調查（2022 年 10 月 10 日至 11 月 28 日，3,000 名遠距工作者）顯示，受訪者最大的困難依序是「待在家裡太久、沒有理由外出」21%、孤獨感 15%、跨時區協作 14%、維持動力困難 11%、無法完全脫離工作 11%。注意前兩名加起來 36%，都跟社交隔離有關，而跨時區這種「制度問題」只排第三。
這代表遠距主管的工作有一大塊是設計非工作性的接觸機會——不是強制的線上團康，而是低壓力、可自選參加的形式。我用過有效的兩種：一是每週一次 20 分鐘、不談工作的自由咖啡時間（隨到隨走）；二是專門的閒聊頻道，主管自己要先在裡面貼廢話，否則沒人敢貼。相關的個人層面自救，我整理在遠距孤獨感怎麼辦與在家工作第三個月開始失控兩篇，主管可以直接轉給團隊。
Doist 在他們的非同步指南裡引用了《哈佛商業評論》「Collaborative Overload」的觀察：過去二十年間員工花在協作上的時間增加了約 50%，部分工作者甚至有高達 80% 的工作日在與同事溝通。如果你的遠距團隊感覺比實體更累，多半不是因為遠距，而是因為你們把辦公室的同步習慣原封不動搬到線上，卻少了通勤時間當緩衝。
什麼樣的工作本質上不適合全遠距
這節是這篇文章裡我最想寫、但坊間遠距內容最愛迴避的部分。全遠距不是普世解，硬推不適合的工作型態，代價會由員工的健康與客戶的體驗一起支付。
我用四個判準來評估一項工作能不能全遠距。四項都通過才推全遠距，過三項適合混合，過兩項以下不要勉強。
| 判準 | 通過的樣子 | 不通過的樣子 | 不通過的典型工作 |
|---|---|---|---|
| 產出可獨立驗收 | 成果本身能被檢視，不需要看過程 | 品質只能從現場行為判斷 | 實體服務、看護、教學現場 |
| 知識可文字化 | 核心技能能寫成文件與範例 | 大量依賴手感、臨場判斷與默會知識 | 手工技術、實驗操作、現場維修 |
| 對外互動可異步 | 客戶接受非即時回覆 | 需要即時在場處理突發狀況 | 櫃檯、急件處理、現場活動執行 |
| 資安可控 | 資料可在受管設備上安全處理 | 受法規或契約限制不得離開特定場所 | 涉及高度機敏資料、受監理的作業 |
除了工作性質，還有兩種情境即使工作本身適合遠距，我也會建議先不要全遠距。
第一種是「團隊本身還沒有共同標準」。一個剛組成、對「什麼叫做好」還沒有共識的團隊，全遠距會讓標準永遠對不齊，因為對齊標準最有效的方式是一起做過幾次、當場修正。我的建議是新團隊前三個月採混合，等到有了三五份可以當範本的交付物，再放開。
第二種是「主管本身還沒有把制度寫下來」。如果你的團隊手冊還是空的、決策沒有紀錄、驗收標準在你腦袋裡，那全遠距只是把你的管理債務放大。這種情況下先別談遠距，先花兩週把制度寫出來——寫不出來，代表本來就沒有制度，只是辦公室的物理鄰近度幫你掩蓋了。
另外有一類職務值得特別提醒：需要大量帶人、教人的資深職位。這類工作的價值有很大一部分來自於「被觀察」與「隨手示範」，全遠距會讓資淺成員的成長速度明顯變慢。可行的折衷是把示範刻意產品化——錄影、寫成教學、做成範例庫，但這需要額外投入時間，而多數公司不會給。如果不打算給這個時間，就不要期待全遠距的師徒傳承能自然發生。
最後是基礎設施這件現實的事：全遠距團隊的每個人都是自己的 IT 部門。網路斷線在辦公室是公司的問題，在家就是員工的問題，而客戶不會因為你家跳電就延後驗收。這部分的備援設計我寫在遠距工作斷網備援方案，主管在制定遠距政策時應該把它列成公司補助項目而不是員工自理。
常見問題
Q：員工在家工作，公司還需要記錄出勤嗎？
A：需要。依勞動基準法第 30 條第 5、6 項，雇主應置備勞工出勤紀錄並保存 5 年，且應逐日記載至分鐘為止，勞工申請副本時雇主不得拒絕。勞動部「勞工在事業場所外工作時間指導原則」進一步說明，場所外工作的勞工，雇主仍應逐日記載其正常工作時間；記錄方式不限打卡鐘，可用網路回報、手機打卡、通訊軟體紀錄等輔助，並建議電傳勞動者以工作日誌自我記載後電傳雇主。實務上請與勞資雙方以書面約定正常工作起訖時間並訂入工作規則，個案認定仍以主管機關與法院見解為準。
Q：主管在員工下班後傳工作訊息，違法嗎？
A：台灣目前沒有「離線權」專法，所以下班傳訊息本身通常不會直接構成違法，但它可能產生工時效果。依勞動部指導原則，若雇主在正常工作時間結束後以通訊方式指示工作，勞工可自行記錄並檢附對話紀錄，由雇主補登為工作時間；而《勞動事件法》第 38 條規定出勤紀錄內記載的出勤時間，推定為經雇主同意執行職務。另外，臺北市政府勞動局 2023 年 3 月 1 日實施的居家工作指導原則（行政指導性質）第十一、十二點已明白要求雇主尊重勞工在非約定工作時間的合理離線權；它不是全面禁止下班傳訊息，而是要求若仍需傳送，應附上「毋須立即回復（或處理）」的提醒文字，緊急突發事務須依勞動基準法第 32 條第 4 項或第 40 條辦理通報核備並事後補休，且不得因勞工未即時回覆而在勞動條件、職務或晉升上作不利對待。
Q：公司可以裝監控軟體看員工的螢幕嗎？
A：不能只憑「員工簽了同意書」就認為沒問題。個人資料保護法第 5 條要求蒐集、處理、利用個資不得逾越特定目的之必要範圍，第 19、20 條分別限制蒐集與利用的合法事由，第 29 條則規定非公務機關違法致生損害須負賠償責任，且能證明無故意或過失者才免責。司法院釋字第 603 號亦確立資訊隱私權為憲法保障的基本權。實務上應逐項檢視每個監控功能的必要性與是否存在侵害更小的替代手段；定時截圖與鏡頭拍攝在居家場景還會蒐集到同住家人的個資，法律基礎更薄弱。建議導入前諮詢律師。
Q：跨時區團隊，重疊工時要留多久才夠？
A：以我實際帶團隊的經驗，時差在 3 小時以內建議每天保留 2–3 小時核心帶；時差超過 6 小時就不要追求每日重疊，改用「每週一到兩個錨點會議＋交接接力」的模式，並且讓不便的時段在不同時區之間輪流承擔。要注意台灣採 UTC+8 且無日光節約，但美國（3 月第二個週日至 11 月第一個週日）與歐盟（3 月最後一個週日至 10 月最後一個週日）的夏令時間會讓時差每年變動兩次，固定會議請以對方當地時間釘住，並在每年三月、十月各校正一次。
Q：遠距員工在家受傷，算職業災害嗎？
A：不會因為地點在家裡就自動排除，實際認定取決於傷害是否發生在執行職務的過程中、與工作之間有無因果關係。勞動部職業安全衛生署訂有「居家工作職業安全衛生參考指引」（110 年 6 月 23 日訂定、111 年 6 月 1 日修訂），供事業單位強化居家工作的危害辨識與風險評估。實務上建議在書面約定中明確載明工作場所、工作時段與工作內容，這同時是工時的界線，也是職災認定時的重要依據。個案認定請洽勞工保險局或勞動主管機關。
Q：怎麼判斷團隊該不該全遠距？
A：用四個判準檢查：產出能否獨立驗收、核心知識能否文字化、對外互動能否非同步、資安是否可控。四項全過才適合全遠距，過三項適合混合，兩項以下不建議。另外有兩種情況即使工作性質適合也該先緩：一是團隊剛組成、對「好」的標準還沒有共識，二是公司的流程與驗收標準還沒有寫下來。Nature 2024 年的隨機對照試驗支持的是「每週兩天在家」的混合模式不影響績效與升遷，把它當成全遠距的背書屬於誤用。
延伸閱讀
資料來源
- 勞動部勞動法令查詢系統，〈勞工在事業場所外工作時間指導原則〉（104 年 5 月 6 日勞動條三字第 1040130706 號函訂定，106 年 11 月 30 日修正）：https://laws.mol.gov.tw/FLAW/FLAWDAT0202.aspx?id=FL076813
- 全國法規資料庫，〈勞動基準法〉第 30 條：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=N0030001&flno=30
- 全國法規資料庫，〈勞動基準法〉第 32 條：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=N0030001&flno=32
- 全國法規資料庫，〈勞動事件法〉第 38 條：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=B0010064&flno=38
- 全國法規資料庫，〈個人資料保護法〉全文（第 5、19、20、29 條；本法最新修正日期 114 年 11 月 11 日）：https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=I0050021
- 司法院憲法法庭，〈釋字第 603 號解釋〉（民國 94 年 9 月 28 日）：https://cons.judicial.gov.tw/jcc/zh-tw/jep03/show?expno=603
- 勞動部職業安全衛生署，〈居家工作職業安全衛生參考指引〉（110 年 6 月 23 日勞職衛 1 字第 1101032036 號函訂定、111 年 6 月 1 日勞職衛 1 字第 1111031706 號函修訂；職安署網站公告日 112 年 5 月 4 日）：https://www.osha.gov.tw/48110/48713/48735/148082/post
- 臺北市政府勞動局，〈臺北市事業單位實施居家工作勞動條件保障指導原則〉PDF 全文（112 年 1 月 17 日核定、112 年 3 月 1 日實施，全文 14 點）：https://www-ws.gov.taipei/001/Upload/307/relfile/11869/128732/9652a39d-ff29-4282-9435-86a7a9b51b4b.pdf
- 臺北市政府勞動局，〈事業單位實施居家工作自主檢核評分表〉PDF（共 25 項，15 項以上為及格）：https://www-ws.gov.taipei/001/Upload/307/relfile/11869/128732/e539316a-a274-4cce-8d1c-2d637cbeb158.pdf
- 臺北市政府勞動局，〈居家工作勞動權益保障專區〉：https://bola.gov.taipei/cp.aspx?n=ECD43AA057E9D8B2
- 理律法律事務所，余天琦、施穎弘、李其航，〈臺北市政府勞動局公布實施「臺北市事業單位實施居家工作勞動條件保障指導原則」〉（2023 年 4 月 28 日）：https://www.leeandli.com/TW/NewslettersDetail/7070.htm
- 臺北市建築師公會轉知公告，〈臺北市政府勞動局訂定「臺北市事業單位居家工作勞動條件保障指導原則」及「自主檢核評分表」〉（2023 年 3 月 7 日）：https://www.arch.org.tw/News/news_more?id=f950f77679674404abf5f56d32f1a9d6
- Bloom, N., Han, R. & Liang, J., “Hybrid working from home improves retention without damaging performance,” Nature 630(8018): 920–925, 2024（DOI 10.1038/s41586-024-07500-2）：https://pubmed.ncbi.nlm.nih.gov/38867040/
- Microsoft WorkLab, Work Trend Index 2022: Hybrid Work Is Just Work. Are We Doing It Wrong?（2022 年 9 月 22 日；Edelman Data & Intelligence 於 2022/7/7–8/2 訪問 11 國 20,006 名知識工作者）：https://www.microsoft.com/en-us/worklab/work-trend-index/hybrid-work-is-just-work
- Buffer, State of Remote Work 2023（與 Nomad List、Remote OK 合作，2022/10/10–11/28，3,000 名遠距工作者）：https://buffer.com/state-of-remote-work/2023
- GitLab Handbook, “GitLab Communication”：https://handbook.gitlab.com/handbook/communication/
- GitLab Handbook, “Asynchronous communication for remote work”：https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/
- GitLab Handbook, “The importance of a handbook-first approach to communication”：https://handbook.gitlab.com/handbook/company/culture/all-remote/handbook-first/
- GitLab Handbook, “The complete guide to remote onboarding for new-hires”：https://handbook.gitlab.com/handbook/company/culture/all-remote/onboarding/
- Doist（Twist），”Asynchronous Communication: The Real Reason Remote Workers Are More Productive”（原 doist.com/blog 網址已 308 導向此最終網址）：https://async.twist.com/asynchronous-communication/
- Thiel, C., Bonner, J. M., Bush, J., Welsh, D. & Garud, N., “Monitoring Employees Makes Them More Likely to Break Rules,” Harvard Business Review, 2022 年 6 月 27 日：https://hbr.org/2022/06/monitoring-employees-makes-them-more-likely-to-break-rules
- NIST, “Daylight Saving Time (DST)”（美國依 Energy Policy Act of 2005，3 月第二個週日至 11 月第一個週日）：https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst
- EUR-Lex, Directive 2000/84/EC on summer-time arrangements（3 月最後一個週日至 10 月最後一個週日，GMT 01:00）：https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32000L0084
