讓我們回到自己的菜鳥期，如果拿到一個題目:電影訂票系統，你只有一個人，10天的時間，你會怎麼分配時間?

我碰過很多的狀況，新人通常花了8個工作天努力開工，第9天還在努力整合系統調整資料庫，主管提醒隔天要驗收了，然後當天肯定加班或者在家趕工；第10天的Demo Day大家都笑不出來。

這邊笑不出來的，還有兩種情境。第一種情境是新人做完了，但是主管要的細節完全沒有做到；第二種情境是新人著重在某一個特定功能上做得非常精細，所以花了過多時間無法把整體任務完成。當然也有第三種情況，新人是超級新人，把每一個細節做得超乎主管的預期，但....就當這是神話吧。

在這種單人專案上，就是一個考驗個人專案管理技能當中的工作細節拆分的能力，然而這個能力搭配著的，是敏捷開發中與利害關係人，也就是你主管確認規格的執行。

如果是資訊本科的畢業生，原則上應該在大學專題的過程中，就應該有相關的基礎訓練了。不過在公司企業上，還是有一些眉角要注意。接下來專案拆解的思維以後端的視角為主，希望把專案拆解的思維舉例給大家看，也讓大家知道主管的思維是什麼。

首先，電影訂票系統看起來分成兩個部分，一個是電影，一個是訂票。所以理論上應該要有一個後台可以上下架電影的資料(A)，然後會有一個前台可以展現電影的場次(B)；想看電影的人來到這個前台網站，可以挑選想看什麼電影(C)，然後進一步做訂票(D)；訂票完應該還有一個後臺可以看每一場次的銷售狀況與報表(E)。

這樣應該是整個電影訂票系統中最基本最基本的流程，拿著這樣的流程拆解與利害關係人確認，應該是可以在往下討論每一個流程中利害關係人的在意重點。例如部門著重做各樣爬蟲的，就會在電影資料上希望跟著某個影院的資料；如果部門著重做報表的，那在後台看報表部分會有更複雜的邏輯；如果部門著重在金流串接的，那在購票流程中把金流結帳流程應該會有更多的流程細節；如果部門著重在高頻搶票的交易(transction)，那就會在訂票過程的選位交易有要求。

表面上如果捨棄上面每一個細節，只是單純的把購票流程寫完，得到的只是一個沒有靈魂的肉體，主管絕對不會滿意這樣的成果。上面所說的細節，其實每一個細節都不是一個普通新人十天能開發出來的內容。如果拿到這樣的分析，請問單兵如何處置?

拿這樣的分析過程，與主管討論到底要把重點放在哪邊!!!

傻傻地做，不但白費十天做了一個主管看不上眼的東西，也沒有辦法讓自己的工作方向跟主管達成共識，做在點上。

當然也有可能主管派下來的作業，並不需要在意這些深入的細節，就是需要做完這個殼，那麼你也可以非常清楚，這樣的範圍是主管想要的，接著就可以把這個專案拆成A-E五個小專案，然後排定這個專案的所需時間，每天可以按表操課，逐日完成進度。這樣的專案管理透明度也很高，可以讓主管每天了解應有的進度與實際的進度落差。

工作細節拆分並且與利害關係人進行討論是我認為這是整個專案管理的核心流程。在軟體開發的專案中常常會因為事前評估的不仔細，直到專案中期才發現有關鍵技術是缺乏的，導致專案往前走也不是，終止也不是，整體專案就歪掉了.....

而對新人菜鳥期來說，頻繁的在專案任務中不斷地確認專案的範圍與不斷拆解細節，除了可以確保關鍵核心技術是否擁有，也確保雙放對於專案複雜度拉近共識外，最重要的，我認為是去建構自己對於這個產業的流程的理解，這個產業流程的理解最終會影響你對於專案任務拆解是否恰當，形成了一個間驗累積的良性循環。