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日

[讀書樂]愛.無所畏

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

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

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