這篇還是來談談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的角度來看，都是需求，都一樣要考慮要不要做的問題。
PL必要清楚知道project必須滿足哪些需求，確定明白所有需求的重要性、優先序和相依性，掌握這些才能掌握project的範圍和輪廓，對人力的配置和時間的控制才能有初步的規劃。
＜應變schedule＞
Project進行時，總是會有意外發生，處理意外的應變能力對PL來說是很重要。PL必須有project隨時會有變化的心裡準備。常常客戶改了一個需求或是對手出了新的東西，project就必須跟著改變。而PL很重要的工作就是要＜把改變控制在合理（可控制）的範圍內＞。怎麼說呢？例如project要新增一個功能，也許就需要捨棄某些功能才能維持原來project的人力和schedule，PL必須懂得如何在各個需求之間做取捨。又例如已進測試階段還要強加入一個功能，如何在新功能開發和已完成功能的測試之間取得平衡點，PL必須懂得人力和schedule如何重新調整。
面對變化，不管是主動還是被動的，PL一定會有動作，只是這個動作是＜謀定而後動＞的結果，還是＜先不管其他，先搞定這個再說＞的結果，最後project的成敗，差別是很大的。
如果PL對上面談的規劃schedule很清楚，謀定也可以是快速的、胸有成竹的。
其實project所要應變的應該是來自外部不可抗拒的變化，而不是內部為了彌補計劃不周而造成的變化。過去看過有project沒有做好前期的規劃就直接進入實作階段，看似project進展很快，其實只是假象，因為經常發現不是少做了Ａ功能就是Ｂ功能沒辦法跟Ｃ介面配合，或是因為Ｄ所以要改Ｅ，然後過一段時間Ｅ又因為Ｆ改了什麼而要再改一次。這樣東修西補的就像挖來挖去的馬路一樣，看似工作很忙，其實很多都是規劃思考不周多做了很多白工罷了。嚴格來說，修補馬路不能算是一種應變，只是反應出規劃的不足罷了。
PL要避免這樣的白工浪費，最有效的方式還是做好規劃的工作，寧願把精力放在面對外部的突發狀況，也不要為了不停地修補馬路而疲於奔命。
＜資訊透明化＞
有時候需求改變，客戶知道、老闆知道、PL知道，就是RD不知道，或是RD只是被告知要改變什麼而不知道為什麼要改變。當基層RD被要求已經做好或做一半的東西要再修改或放棄，卻不知道為什麼時，那是一種不被尊重的感覺，會影響後面工作的效率和品質，甚至對PL產生不信任感。
資訊適當的透明，傳遞到最下層執行的人，是有助於project的進行的。Project schedule也應該是在project team公開的，而不是只有PL、PM和老闆知道。Schedule公開可以讓各個team知道彼此的進度，誰進度落後、哪邊進度超前都是公開的。PL在要求進度落後的人時，不需要說太多，落後的人自然感受到可能成為拖油瓶的壓力。PL在要求進度超前的人去幫忙落後的人時，不用太多口舌就能做好協調的工作。
我遇過有些更積極的team leader，自己就先做好負責區塊的平衡工作，對人力做有效的重配置。甚至有想表現或能力強的RD做完自己工作後，自動去幫ＸＸＸ忙。因為資訊公開，讓下面有了自動優化的可能。
看過一些PL把schedule和資訊的掌握當做是自己權力的象徵，只是不願公開的結果是所有事都落在PL自己身上，PL反而變成project的瓶頸。Team member不是不願意幫你，而是不知道哪裡出問題，如何幫你，千萬不要為了掌握權力而讓自己成為孤家寡人啊。
Project schedule當然還有很多執行面的問題，只是以我個人的經驗，如果PL懂得規劃schedule、知道應變schedule，並且會讓資訊透明化，那project schedule就在控制之中了。
沒有留言:
張貼留言