30天的專案時間,已經過去1/3了,
在我們早早就規劃妥當的情況下,進度一定相當喜人吧?
並沒有……
到底是哪出了問題呢?
這時候我們必須回去查看我們的計畫。
理論上,按照我們的甘特圖,不論需求、文件,
甚至是原本10月才要加入的CI/CD也都提前部署好了。
我們基本上沒有太多的延宕,
但工程進度呢?
給了三十天讓工程進行,但現在的進度到底算是正常還是delay,卻一點概念都沒有。
看起來,我們缺少了一種驗證的標準,一種讓我們可以盡早看出是我們能打敗大魔王,還是被反殺的標準。
因此,我們要定下更明顯的指標--里程碑。
顧名思義,一般是用來記錄達成某成就的時機。但他也可以被用在專案管理上面。
設立完成某個段階或成就的時間點,做為一個單純的時間戳記,你不用特別做什麼去驗證他,而是在專案執行的過程中,確認有完成該項成就。
我們已經確立了需求、分配了工作項目(雖然只有我一人)、規劃了時程及甘特圖也試著用蜘蛛法將需求細分成每一個小環循能完成的任務,我們剩下的迷茫只有自己是否真的能達成,以及如果有環節出錯了我要怎麼知道並即時補救。
里程碑能讓我們知道這些,並加強挑戰的動力。
就好像在挑戰魔王時,我知道成功在時間內打掉魔王1/3血後,通關的機率會很高,那一定能讓我更有動力完成剩下的任務。就算沒在時間內完成,也至少知道,我完成了這部份的成就,我不是什麼都沒有做到,更不是沒有希望通關。
里程碑不是任務化分,他應是代表某個重要的時刻。例如:
即時檢視該工程,是在評估時出了問題,還是有什麼錯誤導致無法完成。
若是有問題,是否能盡可能的修正他,在到達下一個里程碑之前?
9/16 專案啟動(來做一個遊戲吧) (OK)
9/17 確立需求(成就!我要成就!) (OK)
9/18 規畫期程(來吧!甘。特。圖)(OK)
9/19 工程啟動(Flutter+Flame) (OK)
9/20 UI/UX及遊戲畫面規畫
9/21 細化任務及敏捷開發 (OK)
9/27 平台及CI/CD導入完成 (OK)
9/30 登入及使用者資料
10/4 遊戲玩法試作
10/7 成就系統啟動
10/10初版發布
10/14上架各平台
10/16 完成專案