這是電腦估的喔

Feb. 05 10:26~12:18

某導入CMMI的公司買了一套估算工時的軟體，號稱可以準確地估算每一件工作所需的時間。在某個場合中Teddy巧遇該公司的員工甲…

Teddy：你們這個軟體估出來的工時真的準嗎？

員工甲：ㄟ，怎麼說哩。其實要使用這套軟體，系統分析的工作都必須要已經做好，假畫面也都要畫好。最後只是透過這套系統填入一些參數，例如畫面有多少欄位、需要操作多少資料庫表格等等的資料。

Teddy：在這個前提之下，軟體算出來的工時準確嗎？

員工甲：對我來講，還算準啦（迷之音：我好強）。例如，軟體估某件工作需要做5小時，我大該都可以在時限內把工作做完，有時甚至可以提前完成。但是對於團隊中比較資淺的工程師，就沒有辦法。

Teddy：那做不完怎麼辦？

員工甲：就只好加班啊，要想辦法在估算工時之內把工作做完，不然時程就會延遲了。

Teddy：這樣感覺有點怪怪的。假設這套軟體估出來的工時是需要很有經驗的資深工程師才可以完成的時間（專案經理內心獨白：這是 電腦選的 軟體的預設值喔），可是實際上團隊中並不是每位成員都是資深工程師。但是專案經理不管這些，只管依據軟體所「估算」出來的工時來押schedule。

員工甲：對啊。

Teddy：可是公司付給資深工程師和資淺工程師的薪水並不相同。資淺工程師拿到針對「資深工程師」所估算的時程，無法在預估時程內完成工作就只能自己留下來加班。但是加班又沒有加班費，所以公司就可以用比較少的成本，來完成專案。

員工甲：但是老闆不會這樣想耶，老闆認為：「我付錢給你（資淺工程師）讓你有學習成長的機會，你應該要感謝我才對」。

***

為什麼估不準

因為軟體專案的變數太多，需求、技術、環境、人員都可能改變，所以估不準是常態，估的準才有鬼。這種說法，相信很多老闆、專案經理都無法接受。先來看下面這張圖，所有工作，都有一個預估完成的工時E，經過開發之後，得到一個實際完成的工時A。在老闆或專案經理的心中，總是期望E=A（預估工時等於實際完成工時）。但是，實際完成工時，至少會受到開發人員與開發流程的影響（先假設在做這件工作的時候需求沒有改變）。而要找到好的人（有能力的人），以及養成團隊持續改善的能力，這些都是需要增加成本的投資。

估不準怎麼辦

為了在最省成本的情況下達到E=A的 幻想 目標，很多公司直接把綁手綁腳的「流程」這一塊砍掉，如此一來便可發揮每個員工的「專業能力」與「應變能力」（傳說中的獨立作業），把一個專案交給一位員工負責，或是讓每個人處理一個很特定領域的工作。

經果一番「最佳化」之後，如果還是E < A 怎麼辦？很簡單，此時再加上「加班」與「降低品質」這兩個法寶，就萬無一失了。

員工：我都一天上班18小時，案子做不完也不能怪我啊。

老闆：大家每天都加班，假日也來加班，已經榨不出汁了。時間到了就「出貨吧」，有問題等客戶反應再說。

***

結論：其實沒有人管你真正的工時需要多久，只管「產品要在計畫中的時程出貨」。

***

友藏內心獨白：反攻大陸的時程表，還是有用滴…Orz。

是不為也，非不能也

Feb. 04 12:58~13:49

Teddy：導入Scrum需要重新安排開發團隊的座位，把辦公室隔間拆掉，讓大家都坐在一起。

鄉民：不可能，公司才不管我們用什麼開發方法，更不會因為軟體部門要導入Scrum就重新安排辦公環境。

Teddy：導入Scrum要組織cross-functional team（跨職能團隊）…

鄉民：不可能，因為我們每個人都個別負責一個以上的案子，不可能把人都集中起來一起開發一個案子。

Teddy：導入Scrum最好不要讓團隊加班成為常態。加班如果是因為某些特殊狀況偶一為之還說得過去，如果變成常態不但無法提升產能，還會降低品質與士氣。

鄉民：不可能，我們主管、老闆一個比一個還晚走。誰敢不加班，不是年度考績很差，就是要準備捲鋪蓋走人。

Teddy：導入Scrum要培養自我管理的團隊，工作由團隊成員自行認領。

鄉民：不可能，我們的員工都很懶，一個口令一個動作都做不好了，怎麼可能搞什麼自我管理。

Teddy：Product Owner要負責Scrum專案的成敗。

Teddy：「不可能」…Teddy幫你說：「我們的產品經理與行銷部門都只會打嘴砲，把email從客戶端轉寄過來，然後再從工程師這邊轉寄給客戶。案子只要出問題，千錯萬錯都是工程師的錯，和他們一點關係也沒有。」

***

還記得早些年輿論在討論「公務人員18趴」改革的問題，有很多反對改革的人都說…

反對者：不可能，這違反了「信賴保護原則」。

最近政府突然宣布，除了早年領取一次退的軍公教人員之外，18趴要逐年調降。Teddy覺得很奇怪，為什麼這次不拿「信賴保護原則」這頂帽子出來擋？當掌權者不想變革的時候，「信賴保護原則」這個理由就可以無限上綱推掉所有改革方案。當掌權者想改變的時候，什麼理由都不是理由。

結論很簡單，很多事情，是不為也，非不能也。為什麼不為？因為還不夠痛。當國家快破產的時候、公司發不出薪水的時候、公司快要被別人惡意併購的時候、產品滯銷庫存堆滿倉庫的時候、加班加到肝壞掉人生變黑白的時候、小孩將隔壁老王誤認為是爸爸的時候，沒有什麼「原則」是不能修改的。

在開口說不可能之前，先想想什麼是「理應如此」的做法，或重讀一下「孟子/梁惠王上」。

曰：「不為者與不能者之形何以異？」

曰：「挾太山以超北海，語人曰，『我不能。』是誠不能也。為長者折枝，語人曰，『我不能。』是不為也，非不能也。故王之不王，非挾太山以超北海之類也；王之不王，是折枝之類也。

***

友藏內心獨白：誰說年薪保障14個月這個規定不能改 。

專案Bug太多要不要導入Scrum？

Feb. 04 10:22~23:26

Teddy有一位朋友對Scrum很有興趣，請Teddy當面跟他介紹，講到一半的時候朋友突然說…

朋友：什麼，deadline到了如果有做不完的需求要把這些需求移到下個版本？！

Teddy：對啊，只要Product Owner隨時都有注意product backlog裡面的需求有依照優先順序排列，而且每次sprint施工所選出來的需求都是優先順序比較高的，這樣子萬一釋出時間到了還有需求沒有做完，剩下來的也是比較不重要的需求。

朋友：可是我們的專案只要需求確定之後，就不能更改耶。

Teddy：啊？！

朋友：因為我們的產品有包含硬體跟軟體，在產品規格（需求）確認之前，行銷、業務、技術人員會先密集討論，但是一旦產品規格確定之後，接下來的開發時程就要依據專案經理拉出來的schedule來執行。規劃的上市時間到了產品就要釋出，而且規格與功能都不能縮水。

Teddy：請問你們的產品規格確認之後，需求會一直改變嗎？

朋友：幾乎不會。

Teddy：那開發過程中，所使用的技術會一直改變嗎？

朋友：也不會耶。

Teddy：那你幹嘛想改用Scrum？

朋友：因為我們的產品bug很多，導入Scrum不是會讓產品品質變好？

***

Teddy在《四種專案複雜度》介紹過一個觀念：「不同類型的專案，需要用不同的開發流程與管理方式」。Teddy這位朋友的專案，比較像是「簡單型專案（Simple）」，也許只要繼續沿用waterfall的專案管理與開發流程應該就可以了。也就是說，朋友真正最痛的問題，是bug太多，專案品質不佳。這個問題的解應該從軟體工程面或是導入實務做法著手，例如：

• Code Review
• 單元測試
• 自動化功能測試
• Pair Programming
• 持續整合
• 提升開發人員的設計能力，讓軟體更容易擴充與測試（請參考《讓軟體變軟的兩個原則》）
• 提供更多的測試設備
• 請參考《600 多個 bugs 要怎麼修？》

當然，專案bug很多非常有可能是「不合理的時程」所造成的結果。傳統「計畫驅動」的專案，在「固定產品功能（所有計畫中的功能，一定要全部做完產品才可上市）」的前提下，時程不准延後，開發成本又不能增加（開發人力有限），那怎麼辦？

除了加班以外，工程師還有另外一項法寶，那就是「降低產品品質」。如果鄉民們一定要堅持自己的專案要採用上圖左方的「計畫驅動」管理方式，又希望產品能夠有不錯的品質。在時程固定的前提之下（上市時間不可延後），只有想辦法找到「高品質的開發人力」，或是提升現有開發人員的能力（也就是增加開發成本）。

如果只是因為bug太多這個原因而希望藉由導入Scrum來解決，但卻不想也不需要改變原本waterfall的專案開發模式，導入Scrum就不是合適的藥方。

***

友藏內心獨白：Scrum不是萬靈丹，無法治百病啊。

2009冬遊日本京都Day5-D逛嵐山商店街與京都塔

Feb. 02 23:35~23:52

離開天龍寺之後到附近的商店街逛一下，買點吃的東西。

 

商店街建築物。

 

時間差不多要準備歸還腳踏車了，有點小迷路，經過平交道。

 

在路上比手畫腳問了指揮交通的警察，還好及時歸還。

 

從嵐山回京都之後，晚上到京都塔欣賞夜景。要先買票。

京都夜景。

 

京都塔內部有強烈的暖氣，雖然外面很冷，但京都塔內卻熱得要死，差點沒在裡面中暑。此地不宜久留，準備離開了。

***

友藏內心獨白：暖氣、烤箱，傻傻分不清楚。

2009冬遊日本京都Day5-C天龍寺

Jan. 31 23:13~23:28

離開大悲閣(千光寺)之後來到了世界文化遺產的天龍寺，有圖有真相XD。

 

其實Teddy已經有點忘了天龍寺內的景物，以下照片請鄉民們自行欣賞。

 

不知道為什麼寺內要掛著「方丈」的匾額?!

 

寺內有一個很漂亮的日式庭園。

 

天龍寺真的有龍耶。

 

建築物。

 

剛好遇到工作人員在清理水池，這個池子已經變成許願池了，清出一堆硬幣。

 

在寺內閒逛。

 

離開天龍寺之後，寺外有一條被高聳竹子所圍成的小路，是遊客拍照的熱門景點。

 

路旁還有幾尊…應該是地藏菩薩，還是小沙彌?

***

友藏內心獨白：清理許願池所掃出來的銅板最後落入誰家哩？

精品 vs. 產品

Jan. 30 16:49~18:14

前一陣子有人提到Lean Startup（精實創業）公司比較適合用Kanban，不適合用Scrum。因為Scrum過於強調「品質」，而很多新創公司連「產品是什麼」都不知道，何必花力氣在「產品品質」上面，過份注重品質反而是一種浪費。

這種看法聽起來也挺有道理的，畢竟新創公司若還處於摸索成長引擎的階段，花費太多精力在所謂的「產品品質」上面，的確有浪費資源的嫌疑。舉個Teddy親身體驗，創立泰迪軟體之後，Teddy因為開課與舉辦活動而經常需要使用網路上某個服務，在此以「X服務」稱之。「X服務」的點子非常有創意，提供的系統功能也算完整，因此一開始就吸引了Teddy選擇這個服務。隨著使用的頻率與時間增長，Teddy陸陸續續發現許多「X服務」系統的bug以及不穩定的之處（Teddy內心獨白：軟體人的悲哀，就是發現別人系統有問題的時候，很想打電話去告訴對方應該要如何修改）。

雖然很想「跳槽」改用其他競爭對手所提供的服務，但由於已經在「X服務」上面建立了許多資料，且跳槽改用其他服務還需要一段磨合的時間，在還沒有出很大的問題之前，Teddy暫時也只能繼續忍受「X服務」有點不穩定的品質以及三不五時免費贈送的bug。這種情況印證了「新創公司的重心，應該放在把產品做對，其次才是 慢慢 做好」。

***

問題是，新創公司所推出的產品或服務不受歡迎，到底是「沒有打中顧客要害（產品方向做錯）」，還是「品質太爛沒人想用（產品方向做對但品質沒有做好）」，有時候並不容易觀察出來。再者，有時候公司會沉迷在成功的喜悅當中，而對於客戶的抱怨抱持著「不然你不要用啊，咬我啊」的心態。長久下來若是競爭對手針對這些弱點加以攻擊並提出更好品質的服務，客戶便很容易會轉台觀賞其他更好看的節目。

***

約一年前Teddy買了生平第一個Apple的產品：Mac Book Air（MBA），在這之前Teddy是很討厭使用Notebook，因為太重。MBA除了重量輕，攜帶方便之外，在很多小細節使用起來覺得很貼心。例如，只要接上投影機，不需要按什麼切換按鈕，畫面直接就會輸出到投影機上面。記得之前使用Windows Notebook的經驗，相信很多人在簡報的時候有：「耶，怎麼電腦畫面打不出來」的經驗。

用了MBA一陣子之後，Teddy的感覺是：「這不是一台notebook，這根本是藝術品啊」。

前一陣子HTC產品銷售下跌，該公司的老闆一直強調類似的話：「HTC是一家非常創新的公司，我們很有創意，沒怕過誰。我們只是行銷做得不好…」。創新很重要，行銷也很重要，但Teddy覺得，對於「品質」與「細節」的重視，是造成「產品」與「精品」的主要差別因素。

對一個專案或是產品而言，「做對」與「做好」應該是同等重要的因素。兩者的比重可以因時、因地、因情而動態調整，但如果長期養成「差不多先生」的習慣，也只能繼續在拚價格、壓低工資這條路不歸路上繼續走下去。

***

友藏內心獨白：被你買到產品的公司怎麼那麼倒楣啊。