「IT 鐵人賽」就像小型個人專案一樣，這篇想分享「鐵人賽」和實際「專案管理」相似之處。

專案要能準時交付，最重要的是「團隊合作」和「溝通」，如果專案團隊的利害關係人，角色錯亂的話很容易讓專案運行不順利，而「鐵人賽」要合作的對象是「自己」，溝通的對象也是「自己」，以跨部門溝通、協調來的簡單多了，對吧？！因為專案管理最複雜的就是「人」?

有句話是這麼說的，「人生最大的課題是自己」，以實現自我挑戰為目標的話，「鐵人賽專案」該如何運行呢？

1. 確認動機、目標、範圍

這三要素其實個別討論會寫很多，筆者在這邊大概的說明：

動機

從哪裡跌倒就從哪裡爬起來，希望下次面試國外工作，在進行 online pair coding interview 遇到要我從既有元件寫 Spec，要能寫的出來，在國外寫 UT 是基本的能力 ?

目標

• 沒有底線交稿壓力下，完成鐵人賽
• 志在參加，不在得獎，用心學習、分享每天的收穫

範圍

從自己不擅長的項目開始「單元測試」，對於這個領域：

• 要能啟專案的單元測試
• 瞭解 UT 運行方式
• 各種 Spec 撰寫方法
• 撰寫 Spec 的技巧
• 如何應用在實際專案

跟自己確認好「需求方向」和「需求範圍」後，專案的輪廓也大致出現，「如果提需求的人不知道自己要什麼？」別人也很理解目的是什麼，所以需求擬定後，接下來是安排行事曆

2. 安排行程、預計完成日

鐵人賽活動是連續 30 天 PO 技術文章，9/1 ~ 9/15 可以任選一天作為開賽日，T+30 就是完賽日。

結合目標「沒有底線交稿壓力下，完成鐵人賽」，也就是需要「囤稿」才有辦法，在沒有時限壓力下交稿。而「囤稿」需要事先規劃要寫的內容，所以筆者約莫在開賽前兩週，開始準備目錄大綱、素材，然後在9/1 ~ 9/12 的過程中累積 10 篇，在 13 號 開始發文，同時，繼續學習這次的題目，過沒幾天就卡關，需要 饅頭大師 (mentor) 協助，這中間花了兩三天。

這壓力真的不容小看，還好有囤稿，才有時間消化看不懂的地方，當然也是可以把看不懂的地方在當天 PO 紀錄出來，這就取決於個人，沒有對錯喔！

時間線來看

• 8/18 ~ 9/1 準備素材
• 9/1 ~ 9/12 開始撰寫 10篇
• 9/14 開始 PO 文
• 9/15 接續其餘 20 篇的學習紀錄
• 預計 9/13 完賽

從專案管理來看，我們「無法預期遇到的風險」計畫趕不上變化，假設專案團隊從 9 月開始跑專案，預計 12 月底上線、交付，共有16周，以時程推估：

• 2.5 周 需求確認
• 1.5 周 系統規劃
• 6 周 系統開發
• 2.5 周 測試
• 2.5 周 準備上線
  上述共 15 周，預留 1 周緩衝處理非預期狀況。

但是如果這中間有成員想請「陪產假」、「育嬰假」、「病假」等等，都是身為 PM 無法提前知道的，即使提早知道，又該從哪找到即戰力？

我們無法控制「風險」，但可以「降低風險傷害」，所以「預留緩衝」能夠降低無法完成專案的風險。當然也是會有專案失敗的情況，這邊就不另討論。

3. 資源取得、過濾

「專案完成」不是一個人的功勞，是個角色協作執行的「成果」，平常廣結善緣?! 在有需要的時候會有意想不到的幫助。

大型組織的產物，通常會需要跨部門協助，一個「行動網銀應用程式」需要增加新功能，除了開發團隊，還有 BU 團隊、設計團隊，各部門都有自己的行事曆，要能安插新需求，是必要協調整合。

「鐵人賽」有個人組、團體組，前者需要自己的人脈，或是找到對的網路資源；後者有其他成員可以幫忙解惑。在準備「鐵人賽」(專案)前，需要先調研可用的資源，以便順利的運行專案。

筆者在開賽前，和自己的 饅頭大師 討論過可行的題目，剛好這次的題目 饅頭大師 也碰過，所以在學習的過程中有人問，是莫大的幸福 ?

感謝的話就留到明天在說吧！以上三個是筆者認為，鐵人賽之於專案管理幾個精華，希望對日後想參賽的人有一點方向。