Latest / 創意每天聽 / 事業怕失傳？開發者自製「死人開關」，保證資產交接！

Transcript

事業怕失傳？開發者自製「死人開關」，保證資產交接！ · 創意每天聽

• 0:00
  今天我們要聊一個有點出乎意料的創新案例。想像一下，你是個獨立的接案設計師或個人工作室老闆，你的事業全靠你一個人。如果有一天，你突然失蹤或發生意外，你的客戶、你的事業該怎麼辦？
• 0:22
  對，這就是很多自雇者或小型企業主的痛點，但大家常常選擇不面對。因為聽起來太麻煩、太悲觀了，誰會想主動去想這些啊？
• 0:36
  沒錯。所以這個案例特別的地方就在這裡。有個獨力開發者，Peter Bishop，他做了一個叫做「Death Plan Switch」的工具。它是一個「死人開關」，但特別的是，它是「自託管」的。
• 1:00
  等等，「自託管」的「死人開關」？這聽起來就跟一般想法很不一樣。我們一般想到的「死人開關」服務，應該都是雲端託管，有專人維護才對吧？自託管感覺風險更高啊，伺服器掛了怎麼辦？
• 1:22
  其實這就是它的創新點。Peter 他之前有過一次教訓。2012 年他住院，那時事業就因為他無法處理而中斷，客戶資料也沒辦法即時交接出去。所以他決定要為自己的事業做好萬全準備。
• 1:44
  喔，原來有這樣一個背景故事，那就能理解他為什麼會這麼做了。但他一個人的工作室，要怎麼做到這麼複雜的事？「死人開關」不就是當你失聯，系統自動發出通知嗎？
• 2:03
  它的做法其實很明確。這套系統每週會發一封「確認信」給你，你要點擊裡面的按鈕表示你還好。如果 24 小時沒回應，它會發提醒。
• 2:18
  然後呢？如果一直沒回應，就直接通知客戶嗎？這樣會不會太快了，搞不好只是我剛好在度假，或網路掛了之類的。
• 2:31
  當然不會這麼快。如果 48 小時你都沒回應，72 小時後，系統會先聯絡你指定的「緊急聯絡人」，也就是你的家人或親友，詢問他們你是否平安。
• 2:49
  喔，這點很聰明耶！先問過家人，可以避免因為小狀況就引起大恐慌。這樣也比較人性化。那如果家人也說聯絡不上呢？
• 3:02
  如果緊急聯絡人也確認你確實失聯，那麼在 144 小時，也就是大約六天後，它才會把預先寫好的訊息，發送給你指定的其他聯絡人，例如你的備援開發者或律師。
• 3:21
  這樣一來，從你最後一次點擊確認按鈕，到真正通知到客戶，最長會是 13 天。這個時間差感覺還算合理，既能確保消息不會太早洩漏，也能讓重要資訊在必要時被傳遞。
• 3:41
  而且，它的設計很強調安全性。它不是一個資料庫，不會儲存任何敏感文件或密碼。它只是發送訊息，訊息內容會引導接收者去哪裡找到這些資料，例如加密文件放在哪、密碼由誰保管。
• 4:01
  這點很關鍵！它不是一個「保險箱」，只是一個「通知系統」。這樣一來，即使系統被駭，資料也因為不儲存在上面而不會外洩。這也解釋了為什麼可以做到自託管，因為沒有敏感資料需要高度防護。
• 4:24
  沒錯，這也降低了成本和維護的複雜度。他用的是 PHP 8.1 以上的環境，不需要資料庫，架設起來也很快，就像他原文說的，幾分鐘就能完成。
• 4:41
  如果我是個經營小店的創業者，或者是一名獨立接案的工作者，我可以從中學到什麼？畢竟我不會去開發一個這樣的系統。
• 4:55
  學到的不是要開發一套 Death Plan Switch，而是去思考自己事業的「失蹤計畫」。即使是個人事業，也應該有個類似的緊急應變機制。你的重要客戶資料、帳號密碼、網站資訊，有沒有整理成一份加密文件？誰會知道這份文件的密碼？
• 5:23
  嗯，這點我是信了。我身邊很多朋友開工作室，真的從來沒想過這個問題。他們可能覺得，反正我沒事，就不會發生。但人生很難說。
• 5:38
  這點其實不容易做到，因為牽涉到信任。Peter 的做法是，他把加密文件的密碼交給備援開發者，文件的第二份備份交給律師。這是一個多重保險的機制。
• 5:56
  那對於一般上班族來說呢？這個概念能帶入工作或生活嗎？我們又沒有客戶資料要傳承。
• 6:07
  我覺得可以換個角度思考。在職場上，我們每個人都有一些獨特的知識或技能，只有自己會做。如果有一天你突然不在了，你的同事或主管能立刻接手你的工作嗎？這其實就是另一種形式的「知識傳承死人開關」。
• 6:30
  你的意思是，至少要把自己手上最關鍵的工作流程、帳號密碼，或是重要聯繫人清單，備份一份給信任的同事或主管？這聽起來也像是一種「降低個人工作風險」的思維。
• 6:49
  對，這就是那個概念的延伸。甚至在個人生活上，你的銀行帳號、保險資訊、數位資產，你希望在緊急狀況下誰能知道？這個案例好像也提醒了我們，規劃未來的「不確定性」，其實也是一種負責任的態度。