以終為始

筆者過往曾自修專案管理課程，雖然沒有直接擔當 PM 或其他管理角色，但這些知識一直以來皆成功運用在過往的工作（如規劃個人 sprint 的時程）以及學業上（如完成碩士論文）。

筆者相信，要完成一項挑戰（專案），抱持以終為始的觀念會省事許多。以終為始，即是知道要達成什麼樣的結果，再往前回推並建立長、中、短期的階段性目標，每一個階段性目標又可具體拆分為各個子目標來實踐。亦即，如果設立的目標不夠明確且拆分的不夠仔細，表示沒有想清楚自己到底要什麼，或是太貪心想要在有限的時間內做太多事，挑戰是極有可能半途而廢的。

回到這次的主題，起初筆者對於成果的想像是這樣的：

1. 希望可以在關門前，可能前十分鐘，透過某個平台發出一個推播通知，告訴我可能樓下馬上準備要關門了
2. 希望預測準確率可以超過 7 成，不會有太多失誤沒有預測到或是預測遲到的情形
3. 可以在不斷累積新資料的同時，加強準確率
4. 如果可以，會希望有一個界面，可以快速增加開門聲的記錄

在開始此系列之前，筆者已完成初步的可行性評估

1. 資料量：可能太少，不足以預測。一般來說資料多多益善，太多不會有壞處。此次的資料量應該是足夠的（確切筆數尚未統計，但至少有數十筆）。
2. 期程：若是會花到數個月的時間完成，屆時可能直接換租屋處會比較快。或是實作完畢後，問題已然不復存在（例如該間餐廳歇業）。筆者這次給自己一個月的時間，完成鐵人賽的同時，要能達成上述基本的需求。
3. 技術力：或許以筆者目前的技術能力來說，實作起來會很困難。筆者評估過後，前 10 天的進度算是較不需多做功課，可以趁機多研究後面的工項。而後 20 天的則需較多調查，但仍是有信心可以應付的難度。

試圖將上述構想轉化成專案需求，按照工項先後排列如下：

1. 可行性評估（已完成）
2. 既有資料結構化：詳後述
3. 將資料輸出成較方便利用的形式
   • 可轉存到資料庫（選配）
4. 選定最適合的分析方法，建立預測的模型
   • 待釐清：準確率 7 成的定義
5. 開發 API 來串接此模型，將預測時間往前回推 10 分鐘，發出通知
6. 部署並與指定的平台串接以達到提醒效果
   • 待釐清：何種平台
7. 建立 API 以及界面來快速記錄關門聲（選配）

許多需求仍然處於不明確的狀態，所以筆者將秉持大原則：

1. 執行的過程隨時調整任務內容，適度取捨剩餘的時間以及尚未達成的進度
2. 以最有效率（低成本、高產出）的方式達成一開始的構想

查核點

本專案的查核點，即是依照 Day 01 的安排，透過發文來追蹤。由於筆者僅有自己一人，加上前述大多工作都是 Finish to Start 的形態。讓我們複雜的事情簡單做，不另外設置時程管控表，或許反而是最有效的管控方式。

參考資料

1. Understanding Task Dependencies in Project Management
2. How Much Data is Needed to Train a (Good) Model?

延伸閱讀

1. 技術管理閒聊：以終為始的工作方法
2. SMART原則怎麼應用？超強大目標管理法，助你達成所有目標