系統測試就像健康檢查

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

之前曾有過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：ＯＯＯ是比較強嗎？）

［PL的Project Management］天啊！Schedule！

＜天啊！Schedule！＞，這應該是大家做project最傷腦筋的吧！

當你還是RD時，你討厭老闆、PL、PM來壓你schedule，覺得這麼不合理的schedule怎麼他們不自己來做做看；可是當你是PL時，老闆還是一樣壓你schedule，老闆不合理的要求可能還在，只不過你想把壓力扛在你身上，給member多一點合理的空間，還是把壓力by pass如member呢？亦或是給member的壓力比老闆給你的更大，這樣才能確保你可以在老闆面前輕鬆自在？

你想過schedule的意義嗎？對你的意義、對PL的意義、對project的意義？
是壓榨、欺騙、假象、抗爭的過程？還是承諾、尊重、誠實、信任、互助的基礎呢？是想真實地反應狀況，還是想要漂漂亮亮地粉飾太平？緊一點，亦或鬆一點又會怎麼樣呢？做不到就真的表示你不行、不夠強？會不會換人來做了呢？

老闆要的應該是一個真實的、可執行的、優化過的、可預期的、可靠性高的schedule，可是這樣的要求做起來一點都不簡單，因為它考驗著你的態度和挑戰你壓力的極限。當然，還能讓你看看別人的反應，對真實的人性有一點點的領悟。

［PL的Project Management］PL與PM

PL一般是RD出身，本身已經具備專業上的背景，甚至已是專家等級的程度，有能力解決project遇到的技術問題。而PM不一定是RD背景，可能是企管背景，技術上需要依賴PL，但是有能力和方法去管理project大大小小事情的進度，管控協調資源，分析整理資料並適時地highlight。

PL和PM是project最主要的二個角色，好的搭配，project會事半功倍；配合不好，project也會亂成一團。好或不好，關鍵在彼此的分工，是達到了互補正向的效果，還是重覆又衝突的狀況。

PL必須在一開始就和PM有清楚明白的分工，彼此專注在彼此的專長上面，有需要時能夠互相cover，還有誰主誰副、決策如何進行、還有如何向上報告project狀況也必須先達成共識，避免過程中的衝突。主副關係可能會依公司文化有潛規則，我曾待過完全以PL為主導的公司，PM角色是被弱化的（不管PM能力強弱），這裡談的主副關係，最好丟掉所謂的公司文化，真想為project好，那就在彼此尊重的前提上，PL和PM二個人談好，建立默契就行了。