這篇還是來談談schedule，因為對PL來說，project就是圍繞在schedule上打轉的，而好的PL對schedule是懂得規劃、知道應變，並且會讓資訊透明化的。
＜規劃schedule＞
規劃的目的在於找出project的範圍和輪廓，定義重要的milestone。
要怎麼樣做好規劃呢？當然要先了解要規劃什麼！簡單的說就是＜需求Requirement＞。
先收集需求，再分析需求，然後定出需求的重要性和優先順序。
需求的來源很多，可以簡單分成二大類：
Ａ、客戶、Market
這是基本、重要、直接，也是最貼近市場的。不過客戶需求的來源管道很多，可以從Sales、FAE、Market、甚至是老闆，而且當客戶很多時，往往需求也會有重覆、相似或衝突等差異性問題，還有對不同客戶的重要性和輕重緩急也會不一樣的。更不用說客戶經常只說＜一句話＞的需求，不清不楚搞不懂客戶到底要什麼。
因為客戶需求的來源是多管道的，接口的對象也多元，所以最好將客戶的需求能有最後整理匯總的地方，簡單的說就是要有＜需求管理＞的機制，將發散的客戶需求收斂成清楚明白的需求。因為集中管理，所以可以對需求做對比、整合、做重要性和優先序的排序，然後就能清楚將人力投入在哪些CP值高的需求上面。
Ｂ、內部需求
內部的需求來自RD、老闆、公司策略等，例如平台開發、新功能開發、新技術導入、新產品線等等。內部需求的重點主要二個方向－－優化和產品競爭力。
優化是針對既有的做改善，期待可以節省人力（維護人力、FAE支援人力等）、時間（RD開發時間、build SW時間、Release時間等）、空間（code size、memory size、package size等）、獨佔資源的使用(CPU、memory、bandwidth等)，以提升效率和降低成本為優化的目的。
優化當然也是可以提升產品競爭力，不過這裡的產品競爭力主要是指新的技術、新的功能、新的架構、新的平台等，可以讓市場驚豔、讓對手驚嚇的新東西。
不管是優化還是產品競爭力，常常需要投入的人力和時間都很可觀，一旦投入的資源太多時就會排擠到客戶的需求，進而影響現有project或可預期量產的project，所以該不該做，做多少，什麼時候做，是需要審慎評估，同時也在考驗決策者的智慧。
另外當然也可以把內部需求和客戶需求一起集中管理，以project的角度來看，都是需求，都一樣要考慮要不要做的問題。
.png)
