2013年9月16日

[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,掙扎著是要當做沒看到,還是咬著牙吞口水認了。若在星期五,那跟女朋友的約會又要泡湯了。

2013年9月9日

[讀書樂]權謀至尊司馬懿


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

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

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

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

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

2013年8月30日

[PL的Project Management]續談Review



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

1、是浪費還是節省?
  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,那才真的是叫浪費。

2013年8月28日

[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的成果很容易被忽略。

2013年8月23日

[PL的Project Management]關於人月,你要了解的


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

2013年8月22日

[讀書樂]愛.無所畏

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

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

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

2013年7月3日

[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來煩他,可能有多報少或少報多的情形。

2013年6月28日

[PL的Project Management]Lead and Learn


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

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

2013年5月29日

[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的焦點要放在解開所有<未知>的黑盒子,想辦法把問題都攤在陽光下。

2013年5月20日

[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時的奇怪狀況,就比較知道問題出在哪了。
A、一個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絕對是可以做得比你更好的。


2013年5月17日

[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將陷入無窮的測試迴圈。

2013年5月16日

[PL的Project Management]RD的schedule不應該是你給的,也不應該是給你的



如果RD給的schedule完全符合PL的原始的要求,PL應該有所警惕:
A、RD是真的遊刃有餘,那有多少多餘的能量可以去幫助其他人?
B、RD是打腫臉充胖子,想以一天工作二十小時來滿足schedule,雖然勇氣可佳,但PL是必須找資源來幫忙的。
C、RD並不是明確的計畫,只是應付而已。這類RD的心態是有問題的,做好review的工作是可以把螺絲栓緊一點。

如果一群RD給的schedule完全符合PL的原始的要求,PL應該驚覺project已經危險。
如果PL清楚知道project team成員都是跑百米的好手,跑13秒以內是輕鬆的事,那就沒問題。
但是如果能力高低差異大,功能分工的難易差異也大,就像一場馬拉松跑下來,大家都在同一時間到達終點,可能嗎?

2013年5月7日

[PL的Project Management]不懂專業沒關係,但要懂人



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

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

2013年4月2日

[ 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在他的手上。

2013年3月25日

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



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

朋友感嘆:<為什麼工作上的專業不難,反而是跟人溝通就這麼難啊!?>

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

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

2013年2月25日

系統測試就像健康檢查



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

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

[ PL的Project Management]知道就做得到?

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

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

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

2013年2月4日

[ 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來說,那會是讓事變多好幾倍、功減一大半的行為。

2013年1月23日

原來真的enjoy就不會覺得累

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

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

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

[成長系列]當下與未來



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

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

「轉折的智慧」,需要有些正向的思考,與對未知的期待。
當下的挫折與逆境,皆可在轉折處得到不同的體會。
眼前的擔憂與不安,也因柳暗花明而得到疏解。
不要害怕轉折,那是對一成不變的生活最好的禮物。(圖文:連桂慧)
=====

轉折可以期待,只要你可以多一點等待。
態度,才能幫你度過當下的黑暗,而智慧的增長,就是你度過之後的果實。

2013年1月22日

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

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>。
先收集需求,再分析需求,然後定出需求的重要性和優先順序。
需求的來源很多,可以簡單分成二大類:
A、客戶、Market
  這是基本、重要、直接,也是最貼近市場的。不過客戶需求的來源管道很多,可以從Sales、FAE、Market、甚至是老闆,而且當客戶很多時,往往需求也會有重覆、相似或衝突等差異性問題,還有對不同客戶的重要性和輕重緩急也會不一樣的。更不用說客戶經常只說<一句話>的需求,不清不楚搞不懂客戶到底要什麼。
  因為客戶需求的來源是多管道的,接口的對象也多元,所以最好將客戶的需求能有最後整理匯總的地方,簡單的說就是要有<需求管理>的機制,將發散的客戶需求收斂成清楚明白的需求。因為集中管理,所以可以對需求做對比、整合、做重要性和優先序的排序,然後就能清楚將人力投入在哪些CP值高的需求上面。

B、內部需求
  內部的需求來自RD、老闆、公司策略等,例如平台開發、新功能開發、新技術導入、新產品線等等。內部需求的重點主要二個方向--優化和產品競爭力。
  優化是針對既有的做改善,期待可以節省人力(維護人力、FAE支援人力等)、時間(RD開發時間、build SW時間、Release時間等)、空間(code size、memory size、package size等)、獨佔資源的使用(CPU、memory、bandwidth等),以提升效率和降低成本為優化的目的。
  優化當然也是可以提升產品競爭力,不過這裡的產品競爭力主要是指新的技術、新的功能、新的架構、新的平台等,可以讓市場驚豔、讓對手驚嚇的新東西。
  不管是優化還是產品競爭力,常常需要投入的人力和時間都很可觀,一旦投入的資源太多時就會排擠到客戶的需求,進而影響現有project或可預期量產的project,所以該不該做,做多少,什麼時候做,是需要審慎評估,同時也在考驗決策者的智慧。
  另外當然也可以把內部需求和客戶需求一起集中管理,以project的角度來看,都是需求,都一樣要考慮要不要做的問題。

2013年1月3日

[PL的Project Management]你不能不知道,schedule的競爭意義



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


<一>
客戶:人家A公司三個星期就可以做一個project了,怎麼你們就需要三個月呢?投入的人力還比較多?
PL:m.......m.......,我們比較便宜,@@。

<二>
Boss:人家對手都已經有OOOO了,你現在才在做XXXX,到底要怎麼樣才能趕上人家?
PL:m.......m.......,努力中~~@@。

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

<四>
路人甲:聽說類似的project,OOO只花了一個月就做好了,而你要花二個月?!
PL:m.......m.......,投入的人力、資源不一樣,時間當然不一樣啊~ (OS:OOO是比較強嗎?)