布魯斯的雜記空間

  有效率的非同步工作模式 Author: Bruce Data: 2023-02-22 目前許多文書產品都 已經有線上協作功能了，再來就是我們要懂得如何好好的利用這些功能： Google Doc / Microsoft Word 明確的記錄狀態，並留下 標記與提問討論紀錄 。   在使用 Word 作為非同步工作工具後，同事們便可以在文件上將不清楚 / 需要簡單討論的部分直接在文件上註解並留下紀錄，其優點有： 1.       不需要固定的時間段如每周會議才能針對內容討論得到結論 ，大家在自己方便的時間跟其他人註解後便能推動進度。 2.       新加入的同事或請假的同事 只需透過閱讀文件內容便能夠跟上進度 ，不需要再讓主事者花時間口頭講解目前狀況。 文件的內容可以是 新功能的設計 或者是 測試實驗的紀錄 ，同事們可以針對設計的部分註解提問討論，也可以針對測試實驗的結果提問討論。 文件的提問討論後也可以讓原始文件獲得修正，變成更明確易懂。 Google Tasks (in Chat) / Microsoft Planner 瞭解其他夥伴的負擔，簡易快速的追蹤與傳遞工作。 Tasks/Planner 可以用來快速簡易紀錄一個工作事件，會需要與其他同事交互的工作便能用此輪流指派對象，讓大家知道目前狀況如何並通知下一位關係人。 在記錄與指派了足夠多的工作之後大家便能容易看出誰的負擔過重，管理職也能夠注意到並調派人力資源來幫忙。 使用  Tasks/ Planner 也能夠在低打擾的狀態下瞭解同事是否完成了他的部分，也能夠低打擾的接受到其他同事指派來的工作。   Google Chat / Teams 其實  Chat/Teams 反而是強制同步工作模式：因為它會一次發送通知給群組裡的所有人。

  Author: Bruce Date: 2023-02-13 本標題致敬『 你就是不寫測試才會沒時間 』。   當 1 個人想要傳達給 7 個人的內容，花 1 個小時開會才能傳達完的話：整體便花費了 8 個小時的時間；如果這個人可以花 0.5 個小時把想傳達的東西先整理好寫好，剩下的人如果每個人能用 3 分鐘 (0.05 個小時 ) 看完文件：那麼總共只會花費 0.5 + 0.05*7 = 0.85 個小時，已經相當於接近 10 倍的效率。   另外在文件已經寫好的狀況下，如果要分享給其他當時無法參加會議的人，或其他新進人員：都能夠減少重複溝通所消耗的時間。   用比較差的效率重算上面的時間：花 2 個小時寫文件， 0.5 個小時閱讀 2 + 0.5*7 = 5.5 ，即使是這樣也比 8 個人一起花 1 個小時開會還要有效率，更不用提有時候會議還會拖到 2 個小時長。 這是一張 Google Calendar 把每個人的時薪算進來的概念圖，一個會議就會花掉 603.25 美元。大家的時間累積起來是很有價值的。

  Author: Bruce Date: 2023-02-13 本標題致敬『 你就是不寫測試才會沒時間 』。   寫 Unit test 可以幫助及早發現程式問題。   假定在系統中已經有存在既有的 Unit test ：當一份修改過的程式碼上傳時，在其中的 bug 經過 0.5s 的 Unit test 執行檢查被發現，撰寫此段程式碼的 R&D 花 15 分鐘 (0.25 hours) 修改正確， bug 週期結束。     有 Unit test 耗時 0.25 hours   假定在系統中沒有存在 Unit test ：當一份修改過的程式碼上傳時，在其中的 bug 經過 2 hours 的 Build 階段， 1 hour QA 建立環境後發現和回報問題，撰寫此段程式碼的 R&D 也花 1 hour 重現和理解問題，再花 15 分鐘 (0.25 hours) 修改正確，再經過一次 2 hours 的 Build 階段， 1 hour QA 建立環境後發現和驗證問題正常， bug 週期結束。     沒有 Unit test 耗時 7.25 hours   效率已經差了 29 倍。     用比較寬鬆的時間重算一次： bug 經過 0.5s 的 Unit test 執行檢查被發現，撰寫此段程式碼的 R&D 花 1 hour 修改正確， bug 週期結束。     有 Unit test 耗時 1 hour   假定在系統中沒有存在 Unit test ：當一份修改過的程式碼上傳時，在其中的 bug 經過 1 hour 的 Build 階段， 0.5 hours QA 建...