［PL的Project Management］什麼！版本出不來！

每到出版本build load的日子，PL/PM總是緊張兮兮，實在是因為常常狀況會很多，要不是RD來不及解不完bug，就是build load會fail，也可能版本出來了，但是一開機就當機，想罵人還不知道要罵誰，得先想辦法找出兇手才行。

其實build load時不只是PL/PM緊張，RD的壓力也很大，因為build load時間就是deadline，RD要在deadline前解完bug上code。Build load的時間一般都會安排在大半夜，因為這樣一大早VT就可以拿到新的版本好展開一整天的工作，所以常見一堆RD加班到大半夜趕著在build load前上code，也造成build load前一二個小時會有大量上code的情形。如果build load時間到了，卻還沒來得及解完bug上code，那project delay的大帽子很可能就會扣到自己頭上，頭髮又不知道要掉幾根白幾根了。前公司會每天用mail highlight bug和bug owner，build load前更是會列出MUST Fix的bug。RD通常還可以忍受每天被highlight，但是最怕的就是好不容易解完手上明天凌晨要build load的MUST Fix bug，正在開心地吃晚上便當時收到mail，發現自己突然又多了幾筆MUST Fix的bug，掙扎著是要當做沒看到，還是咬著牙吞口水認了。若在星期五，那跟女朋友的約會又要泡湯了。

［讀書樂］權謀至尊司馬懿

＜權謀至尊司馬懿＞這是本值得推薦的書，我自己是看了再看，作者對每個章節歷史事件的描述總可以讓你陷入思考，對比自己的過去經驗，彷彿歷史又重演了一遍。

有興趣了解歷史的，作者對事件的看法分析，會讓你有不同角度的視野。例如曹丕上位後發動的東征，歷史是孫權獲勝了，但是作者的看法是曹丕也嬴了，因為曹丕藉著戰爭解決內部問題掌握住權力，這才是曹丕最需要的。不同的角度切入來看，檯面上的、檯面下的，誰負誰勝出很值得玩味。

權謀是這本書的重點，權謀是為了達到目的，也是體現了人思想行為的方式。目的＋思想＝＞權謀＝＞行為，歷史事件可以看得出行為，從行為可以了解使用的謀略，但是思想需要對個人有足夠的了解才行，像諸葛亮之於周瑜、司馬懿之於孟達，然而目的在明裡的和暗裡的都是耐人尋味的。歷史就在拼拼湊湊中還原，但是現下的處境卻是要認真觀察，邏輯思考才能知道如何應對。知己知彼其實也真不是件容易的事。

看書時跟職場經驗連結也是很自然發生的事情，當時的我選Ａ是必然的，那現在呢？思想不一樣了，或是目的不一樣了，Ａ選項已經不是唯一或最好的選擇了。反省檢討，才能再成長吧。

不論你想了解歷史，看懂權謀，還是自我成長，這本書都是值得一看的。

［PL的Project Management］續談Review

延續上一篇［PL的Project Management］Review是你的武器，再從其他角度來談談review這件事。

１、是浪費還是節省？
　　Review是需要人和時間的，reviewer至少一位，是否需要多個reviewer，可以視重要程度調整，像project前期的requirement phase和design phase、key feature、跨team合作複雜度高的，就值得多投入幾個reviewer。
　　Requirement phase要的是明確的需求，沒有模糊空間，而design phase要有清楚易懂的設計，並且確實可行，還要讓介面明白與其他人溝通合作沒有問題。過去開發平台時，在requirement phase和design phase我自己小team內的人都是reviewer，5~6個reviewer也許多了，但對於平台的基礎建設我們願意這樣做，而且其實佔用reviewer的時間並不多，owner 3~5天的工作量，reviewer花1~2個小時offline review加上1個小時review meeting就可以review完了，約多花了20%左右的人天成本做review。而投入的20%成本找出來的問題，可以期待節省未來5倍以上的debug時間(上一篇我多花了5人天review，至少節省了23人天的debug)。
　　在project schedule上，一般PL/PM如果沒有review的觀念，看到RD在working item上列OOO review和XXX review等等，會很緊張，因為他看不到review所節省下來的debug時間，只看到的schedule多了20%。而通常project schedule從requirement、design到implementation是較可以精確估算的，所以PL/PM甚至老闆會誤以為project在implementation結束就可以等著準備量產了，所以會非常計較那多出來的20%，認為project因此delay了20%的時間，而忘了verification的測試階段才是真的見公婆的時間（如果公司內部的VT權力不夠大，那就只好遞延到客戶的測試才算公婆了）。有個真實的案例，該project的人天成本分布比例是(requirement+design+implementation phase) : verification phase = 1 : 3，而且在bug數比是內部project : 客戶project = 5 : 4 (以前project平均是5 : 1)。數據其實也容易取得，大部份公司對bug都是有控管記錄的，用點心檢視一下就知道了，project phase的時間點也有清楚的milestone，加上每個phase投入的人力就可以計算出人天成本了。我們先不管project management方面的問題，很明顯地該project就是忽略下圖藍色曲線代表的成本觀念，在前期requirement phase和design phase投入的成本cost是最最最便宜的，所以不在這時間多撿便宜多抓bug，那才真的是叫浪費。

［PL的Project Management］Review是你的武器

Project management有一個威力強大的武器－－Review。

依project的life cycle，一般RD都會經歷requirement review、design review、code review、bug review，也會有schedule review、risk review、document review等等不同的review。Review的時間點可能是daily review、weekly review或是依事件發生點來review。而review的參與者至少有owner和reviewer，常常也會有其他相關人員或專家參與。然後review會有記錄，會有actions。

Review是一個同步大家的認知並達成共識的過程，也是一種認證和背書的行為，目的是為了藉由不同人角度儘早發現問題，降低做錯而重做的程度和次數。當然review是要付出代價的，先不論owner準備review要花的功夫，光review這個動作就會佔用owner和reviewer的時間。Review的代價是顯而易見的，大家都看得到，也感受地到，但是review的成果卻是隱性的，除非有人把成果量化並且做出比較，不然review的成果很容易被忽略。

［PL的Project Management］關於人月，你要了解的

PL要懂得將project量化，例如code size量化、bug數量化、開發人月的量化等等，量化的目的是讓你對project有較整體性的概念，進而可以較準確的預估project所需要投入的成本(如人力、時間)和產生的結果(如可完成的功能數量、schedule的milestone時間點)。儘管量化的結果不一定準確，但是不可否認地量化愈精細，所考量的因素愈多，則數據的參考價值愈高。所以PL懂得量化project時，就會對project的掌握度愈高。

［讀書樂］愛．無所畏

我喜歡看歷史小說，總會想像自己是故事主角時，會是什麼樣的反應，如果身處當時的事件中，我可能會是什麼樣的角色，又是否可能改變歷史的發展？但是歷史總是歷史，你回不了過去，不能親睹諸葛亮舌戰群儒，也無法身歷其境去感受赤壁火燒連環船的震撼場面 ，讀完歷史總是會有這樣小小地遺憾。

＜愛．無所畏＞不是在說三國的故事，只是在說一群在台東的大人小孩的故事，雖然孩子的書屋是現在進行式，可是這本書卻讓我有讀歷史的感覺，書中每個人都有故事，充滿人生的曲折，每一個篇章都像幻燈片一樣，短短的幾頁中濃縮播放了故事主角的人生重要轉折，仍然不禁會想，如果是我，又會怎樣？跟歷史不一樣的是，我沒有感覺到遺憾，因為他們還沒有結束。有幸見證了這樣的事情在發生，也有幸可以付出一點心力，更有幸可以握住陳爸的手，那雙粗獷、厚實、有力的手仍記憶在我的腦海裡。

他們不是歷史，正在發生，也持續在寫他們的故事。

［PL的Project Management］想知道Project在什麼狀態？前期問RD，後期問測試！

想知道project在什麼狀態？可以簡單的依SW process phases把project分成二個部份，
1. 前期問RD
　Requirement、Design、Implementation的主角都是RD，PL想要掌握project的schedule進度，了解project的風險，知道哪些地方是弱點，不能只看RD的report，不能只看project file的進度完成度，這些是表面的。實際的和表面的存在多少落差，要問RD才能知道。
　Report有時候是不真實的，因為不少RD都不喜歡寫report，認為浪費時間，或不知道怎麼寫，或有些就只是為了應付，不想PL/PM來煩他，可能有多報少或少報多的情形。

［PL的Project Management］Lead and Learn

Project總是讓你學到東西，不管你是新手還是老手。

對於事情，或許你有自己解決的方法，但是因為你是PL，你可能會聽到其他三種不同的解決方法，你要學習分辨出哪一種最適合（不一定是最好）。
對於人，或許你懂得排解自己的情緒問題，但是因為你是PL，困難低落時你要激勵別人，達成目標時你要鼓舞團隊士氣。人的情緒是複雜的，有時完全沒有規則可言，但是你接觸的人愈多，你經驗值就會愈高。

［PL的Project Management］一旦失焦，很容易失火

Project要有焦點，焦點是集中火力投入資源的地方。
焦點對了，project就可以個個擊破，愈來愈順手。
焦點錯了，project就陷入瞎忙困境，愈來愈沒力。
而PL是應該指出焦點的人，指錯了或不指，都是問題。

什麼才是焦點對的位置呢？

＊、焦點放在Project的目的和特性
　　PL最重要的目標就是達成project的目的，了解project的特性才能正確定位project的焦點。
　　例如對平台型的project來說，穩定性和通用性是最基本的要求。平台當然也是希望功能愈豐富愈好，有時候因為客戶的要求把個別客戶的特殊功能加入平台。在Requirement phase時很容易就不小心把一堆不同客戶的功能加進來，這時如果PL沒有考慮好這些功能之間是否具有高度通用性，有沒有衝突互斥的情況，誤以為平台的功能多就是好，失去了平台型project最基本的焦點－穩定、通用，可想見RD要花多少時間和代價才能處理好衝突互斥的問題達到穩定的要求，而且未來客戶開project時，也可能搞不清楚那些功能如何使用。
　　反過來客戶project追求的是獨特性和時效性，沒有特殊差異化的賣點，就沒有市場的亮點。即使技術仍不成熟，穩定性只有80分，為了Time to Market，也是可能要先推出的，如果PL是抱著做平台的心態，凡事都追求一百分，要求完美，很可能就失去了Time to Market的契機。
　　另外其實不管是平台或客戶project，schedule永遠都是老闆會給的壓力，如果PL以schedule為藉口而對平台型的project便宜行事，求快而不求穩，那是不可取的，因為所有不穩定的後果只是延後到客戶的project才爆發，那時的代價會比原本的schedule delay還嚴重很多的。

＊、焦點在解開未知的黑盒子
　　＜未知＞是project最大的風險，PL不需要擔心問題太多，因為至少那些問題已經曝露出來，問題的解決只是時間的問題。PL的焦點要放在解開所有＜未知＞的黑盒子，想辦法把問題都攤在陽光下。

［PL的Project Management］Bug review可不可以不要這樣？

如果說有一種meeting常常讓人覺得浪費時間，卻又不得不參加，我想除了大拜拜的會議之外，應該有不少人會投bug review一票吧。

RD=>Function leader=>PL/PM=>Boss，RD是處於review環節中的最下層，也是實際上解決問題的人。Function leader是最接近RD的專家，不管是在專業上或人力資源上，Function leader是最有可能提供RD直接幫助的人。PL/PM雖然位置又高一些，基本上在專業上能提供的意見有限(除了一些PL本身的專家之外)，但是卻是有能力整合不同團隊，解決資源衝突或短缺的人。Boss關心的是整體的project進展，schedule的狀況，project team的狀態是否異常，對客戶的影響等，必要時對project外在的人力、資源和時間可以提供協助或決定。

了解每個角色可以做的事和專長做的事，對一些bug review時的奇怪狀況，就比較知道問題出在哪了。
Ａ、一個bug，RD要被review好幾次。
　　Function leader review一次問你能不能解，怎麼解，有什麼樣的solution選擇，需不需要某某某來幫忙，什麼時候可以完成。然後PM再來追一次，你的schedule，要你update status，積極一點的PM除了追蹤之外，還會重覆問一次Function leader會問的問題，雖然PM忘了他提供不了實質上的幫助，只是為了要詳細的追蹤和整理報告。然後PL再問一次，也許會多問一些是否需要其他team的人來幫忙之類的問題，但大部份的問題也是在重覆Function leader和PM的問題。
　　不能怪RD覺得很煩，因為一個bug這麼多人在問，又不能不回答，假設每個人問一個bug要花5分鐘，就已經花了15分鐘，更何況身上不是只有掛了一個bug。難怪RD必須要加班才有多一點的時間花在解bug上，這真的是很令人討厭。

　　有效率的review，先減少對RD無謂的重覆review吧！
　　PL必須意識到自己是無法也沒有時間去review project的每一個bug的，善用Function leader，他才是對靠近RD的人。只有在處理很嚴重的bug或已經卡住的bug時，真的有必要深入了解時再接觸的RD吧，不然PL只要跟function leader review就好了。要相信detail的bug review，function leader絕對是可以做得比你更好的。

［PL的Project Management］要關注bug在質與量的變化

Project的管理在進入Implementation phase(SW process)之後，不管是做Unit Test、Integration Test或System Test，大部份的時間都圍繞著bug打轉。
RD會注意的是自己身上掛的bug，重心自然在思考如何解決bug，然而PL要注意的是所有RD的bug，除了特殊的、嚴重的issue需要PL下decision而深入個案之外，PL應該多花時間關注整體bug在質與量的變化。

有幾個bug的趨勢比較明顯的，例如：
1、Bug發現的數量應該是收斂的　
　　理論上project是要往穩定的方向前進，每個階段或每個版本都應該比之前的完整和穩定，自然RD和VT發現bug的數量是會愈來愈少。
　　反過來如果沒有收斂的趨勢，或反而發散，那很可能出現類似分批健康檢查這樣的操作上的問題，或是沒有照SW process的步驟而引發不可控制的連鎖反應。PL如果放著不管，不即時改正錯誤的做法，那project將陷入無窮的測試迴圈。

［PL的Project Management］RD的schedule不應該是你給的，也不應該是給你的

如果RD給的schedule完全符合PL的原始的要求，PL應該有所警惕：

Ａ、RD是真的遊刃有餘，那有多少多餘的能量可以去幫助其他人？

Ｂ、RD是打腫臉充胖子，想以一天工作二十小時來滿足schedule，雖然勇氣可佳，但PL是必須找資源來幫忙的。

Ｃ、RD並不是明確的計畫，只是應付而已。這類RD的心態是有問題的，做好review的工作是可以把螺絲栓緊一點。

如果一群RD給的schedule完全符合PL的原始的要求，PL應該驚覺project已經危險。

如果PL清楚知道project team成員都是跑百米的好手，跑13秒以內是輕鬆的事，那就沒問題。

但是如果能力高低差異大，功能分工的難易差異也大，就像一場馬拉松跑下來，大家都在同一時間到達終點，可能嗎？

［PL的Project Management］不懂專業沒關係，但要懂人

Project Leader不懂專業沒關係，但要懂人。
這句話並不是說專業不重要，而是現在分工太細，想成為單一領域的專家往往已經要花個三五年的時間，而一個project又需要集各個團隊的力量才能完成，如果要一個PL什麼專業都懂，那是不是要學習個幾十年後再來呢？所以PL本來就不可能什麼都懂，除了原本自己本身的專業之外，其他領域的知識只是皮毛而已，很難比得過在該領域打滾多年的人。

既然如此，那PL要專的就不是業，而是人。
如果你想成為一位PL，＜與人相關的事＞才是你應該學習的專業。

［ PL的Project Management］氣血不通是會生病的

當身體氣血不通的時候，輕微地會造成麻木，嚴重一點的就會疼痛生病，如果還置之不理，可能會有截肢或生命的危險。當Project的working flow和message flow出現扭曲或斷層時，就像身體的氣血不通一樣，是危險的訊號！

常常feature或bug需要跨不同的team處理，一般同team的溝通或協調是容易的，但是一旦跨team，就會變得複雜。例如feature的開發就常發生＜A說他在等B的東西，B說他在等A的東西＞，如果又少了一個強力的人介入協調，這樣的dead lock迴圈就會一直拖到最後關頭才爆炸。又像有些複雜的bug不是一個function的人可以處理，第一個接手的人可能只能澄清不是他的模塊造成的bug，但是卻也不知道是哪邊出了問題，該由誰來接手？或是剛好遇到一個資淺的RD，可能連是不是他的問題都要花很久的時間，而bug就這樣block在他的手上。

說清楚不容易，講明白也很難

最近一位朋友為了工作上的事很生氣，起因是因為一早到公司就發現桌上多了二台機器，看起來是希望朋友幫他測試，只是桌上就只有二台機器，沒有任何字條或留言，查看email，也沒有任何通知或關於這二台機器的mail。雖然覺得莫名其妙，手上測試工作也排得滿滿的，但直覺告訴他不能不管這二台機器，所以就還是發了一個mail給可能相關的人，問問看是誰放在他的桌上，然後需要做什麼事。果然有工程師回信說那是他放的，需要測試，很急，還問朋友什麼時候可以給他測試結果。然後在幾個來回的mail中，雙方的老闆都被loop進來了，沒有交集之外，還搞得一肚子火。

朋友感嘆：＜為什麼工作上的專業不難，反而是跟人溝通就這麼難啊！？＞

其實專業不難嗎？當然也不是不難，隔行隔山，只是專業上的門檻對有心學習或學習能力強的人是容易跨越的。更何況如果本來就是本身專業領域的範圍，即使是新的事物，也很快就能上手。

溝通很難嗎？真的很難，只要面對的是＜人＞，從來都不是容易的事。
朋友生氣的原因，其實也就只在意二點：
１、不受尊重
　　工程師不尊重測試單位似乎是一般公司普遍的現象。但是如果連基本做人做事的道理都沒有，那就真的太過份了。像那位工程師需要人家幫忙測試，事先不僅是不按照測試申請流程走，甚至連句話或一封mail通知都沒有，事後還認為幫他測試機器是應該的，劈頭就要如測試的結果。無怪乎朋友的同事會說：＜請董事長來說，就幫你測。＞

系統測試就像健康檢查

很多人都有做健康檢查的經驗，一次健康檢查會包含身高、體重、肝指數、膽固醇、胸部Ｘ光等等基本項目，可能有時你還會額外再多檢查腸胃鏡之類的項目。不過不管有多少檢驗項目，都是一次做完的。

之前曾有過project在搶快，不管有些功能還沒做完，就硬要進VT的系統測試，還要求先給一版已經完成的功能先測試，過一陣子等其他功能完成了再給一版測試，如果有功能比較慢可能還會有第三版。老闆只看到project進入測試階段，卻不知道只是表面功夫。開始測試時沒什麼問題，然後等後來版本進測試時才發現原本測試過沒問題的case又有問題了，就這樣來來回回搞得測試時間都跟開發時間差不多了,還是沒辦法有效收斂。

［ PL的Project Management］知道就做得到？

接續上一篇［ PL的Project Management］順序很重要，Requirement=>Design=>Implementation
後面的問題，為什麼這麼簡單又直覺的邏輯和做事步驟，真的在project執行時卻很難做到呢？

先來看看幾個對話：
＜１＞
RD：VT測試發現的這個問題是因為之前interface沒有考慮好相容性的問題，現在要嘛把interface改得更完整，只是接口二邊的模塊也都要動到，schedule一定會受影響，不然就還是用舊的，新的功能就先disable，等以後接口改好了再enable。
PL：這不是給我找難題嗎？怎麼都測試一半了才發現這個問題，設計和實作時怎麼都沒發現功能有問題？而且這個功能是客戶指定要的，怎麼可以disable呢！要改，schedule會delay；不改，又要想辦法說服客戶project沒有這個功能。天啊～～

＜２＞
PL：這個功能一定要現在project後期加進來嗎？為了這個不重要的功能影響project進度，很不值得。
Sales/Boss：很多客戶都要，不在這次平台版本加進來，就要等下一次，那些客戶都等不及了，很可能會轉單到對手那邊去。
PL：這次版本release的主要目的就是給大客戶的，但是大客戶並不要這個功能，是不是可以先找人開發這個功能，但是等這個版本release後，再把功能整合進來以patch的方式release？這樣既不影響現在project的進行，也可以很快讓其他客戶有這個功能。

［ PL的Project Management］順序很重要，Requirement=>Design=>Implementation

SW process的第一個phase並不是implementation phase，而是requirement phase，也就是說如果project一開始就朦著頭就開始實作階段，那是錯的，也是假的，因為連要做什麼都不知道，又怎麼可能開始做呢，先搞清楚requirement是什麼才是最重要且第一個要做的事。

有的PL為了搶快，或是為了讓老闆看得見產出，即使在做什麼都不明確的情況下，project就投入人力開始implement，這是錯的，也是假的。為什麼是錯的？簡單的邏輯－清楚要做什麼(What to do) ==> 才思考應該怎麼做(How to do) ==> 然後才是開始實作(Do it)，對應的SW process順序就是Requirement phase ==> Design phase ==> Implementation phase。客戶明明要的是要＜重型機車＞，結果你自己很高興地做了一個＜很重的機車＞，然後才發現做錯了，你能要求客戶把需求改成＜很重的機車＞嗎？所以順序不對，就不合理，就是錯的。那為什麼是假的呢？因為現在實作完成的東西，會因為requirement不對、design不合而需要修改，甚至重來，看起來已經完成100%的工作都可能要再歸零重做，也就是現在完成的工作可能都是白工，所以是假的。

Requirement phase (What to do) ==> Design phase (How to do) ==> Implementation phase (Do it)，簡單的邏輯，淺顯易懂，不過＜知易行難＞，看過很多project直接就要開始進入implementation，忽略requirement、跳過design，妄想要一邊實作一邊釐清需求，一邊實作一邊修改設計，這樣的做法或許對很小很小的task有用(因為重工的代價很小)，但對於project來說，那會是讓事變多好幾倍、功減一大半的行為。

原來真的enjoy就不會覺得累

＝＝＝＝
心理學家契克生米哈利（Mihaly Csikszentmihalyi)稱呼一種不花力氣的注意力狀態叫＜心流＞(flow)，體驗過心流的人描述這種感覺是＜一個完全不花力氣的專注狀態，你深陷其中，完全忘記時間、自己或手邊的問題。＞
＝＝＝＝

我想這就是一種enjoy，一種樂在其中的狀態，即使長時間的專注，也不會覺得累。

工作上曾經有幾次也像這樣進入心流的經驗，感覺真的很棒！
而且當還有人跟你一起有同樣的感覺時，那更是棒極了！

［成長系列］當下與未來

看到一篇小文章，很不錯，跟大家分享一下，
＝＝＝＝＝

[連桂慧管理小品]轉折的智慧

「轉折的智慧」，需要有些正向的思考，與對未知的期待。

當下的挫折與逆境，皆可在轉折處得到不同的體會。

眼前的擔憂與不安，也因柳暗花明而得到疏解。

不要害怕轉折，那是對一成不變的生活最好的禮物。（圖文：連桂慧）

＝＝＝＝＝

轉折可以期待，只要你可以多一點等待。

態度，才能幫你度過當下的黑暗，而智慧的增長，就是你度過之後的果實。

你好，如果對文章有想法或意見，那就留個言吧！

Hi 朋友,

到目前為止，我在部落格上發表了88篇文章，瀏覽次數超過6千次，不過文章的回應卻只有4個，簡單做個統計：
　
每篇文章的回應率只有4/88*100%=4.545%
每次瀏覽的回應率只有4/6000*100%=0.067%

也許會來看文章的朋友都偏工程師，是比較沈默的一群，不過我還是想讓這個部落格可以活絡一點，我其實也比較希望可以跟大家有些互動，因為很多文章在發表時不一定能說的完整，或立場偏激，甚至有些想法不一定是正確或真的有用，也可能隨著時間的變化，原來的觀點也會改變的，不是嗎？

像［成長系列］和［PL系列］，如果你剛好是我想傳達的主要對象，那有沒有打動到你的隻言片語呢？是不是也想說些什麼回應呢？如果是，那就別再沈默了，請在文章的後面留個言，說說你的想法，讓我們做個交流吧。

如果你是我的朋友，按個＜讚＞是不錯啦，不過你知道我更喜歡你的留言的。
如果你我還不認識，歡迎光臨，交流一下，很快就是朋友了！　^_^

Steve

［ PL的Project Management］Schedule之規劃、應變與透明化

這篇還是來談談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 Management］你不能不知道，schedule的競爭意義

上一篇談面對schedule的基本態度，但是除了那些之外，你必須了解和認知你的schedule到底有什麼競爭力！


＜一＞
客戶：人家Ａ公司三個星期就可以做一個project了，怎麼你們就需要三個月呢？投入的人力還比較多？
PL：m.......m.......，我們比較便宜，＠＠。

＜二＞
Boss：人家對手都已經有OOOO了，你現在才在做XXXX，到底要怎麼樣才能趕上人家？
PL：m.......m.......，努力中～～＠＠。

＜三＞
Sales：對手已經推出新的產品出來了，我們現在做的東西已經沒有競爭力了。
PL：m.......m.......，那需要更改哪些requirements市場才會接受呢？還是我們要加強哪些功能當賣點呢？Project端會需要重新評估看看。

＜四＞
路人甲：聽說類似的project，ＯＯＯ只花了一個月就做好了，而你要花二個月？！
PL：m.......m.......，投入的人力、資源不一樣，時間當然不一樣啊～　（OS：ＯＯＯ是比較強嗎？）