絕不犧牲品質 (軟體主管的31堂課)

無論是大型軟體公司，還是小新創公司，軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證，遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者，孫子兵法有云：兵聞拙速，未睹巧之久也。似乎都在說速度比任何事重要。

然而，做完軟體主管，唯一不能做的事情，就是犧牲品質，現在犧牲品質，下一個犧牲的就是自己和開發團隊，接下來就是公司本身。

兵聞拙速，未睹巧之久：指的是快速決定一個方向，並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條（或者只能期待對方更差）

為什麼不能犧牲品質？

(1)如果PM/Sales/BD說可以不再太在乎品質？我需要在乎品質嗎？

當然要在乎品質，事實上，負責任的人會是決定的人。當軟體出現問題的時候，難道PM會負責改code上patch？最終負責的人就是會真正感受到痛苦，並且付出代價的人。軟體品質有問題，會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價，當然就不能決定品質。

(2) 這次改動範圍大，但是有環境上的時間限制deadline-driven的開發，難道我能說品質不好就不上線嗎？例如耶誕夜12/24要上線，無論如何耶誕節都會來，已經做得差不多了難道就不上線嗎？

品質是可以有範圍定義，畢竟不能可能期待大型系統完全沒有bug。但是，即便是有環境上時間限制，如果品質真得無法達到要求，上線只會讓事情變得更糟糕。最近的例子是7 pay，而我們其實可以輕而易舉地找到很多過去的例子。

那麼，為什麼還是會被「逼」上線？許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短，大家工作這麼拼，每天都加班，品質要是有問題應該「高層能理解」！ 這絕對是錯誤的認真，品質有問題的話，「高層」只會知道你們做得不好，更糟的是，你自己已經知道做得不好，連自己的良心也都過不去，而使用者拿到品質差的軟體，當然只是浪費他的時間，這會是個lose-lose-lose三輸的決定。相反的，直接說品質不好無法上線，高層也是知道你們做得不好，但起碼你不會對不起自己的良心，最起碼不是雙輸決定。

(3) 真的沒有時間怎麼辦？

時間資源，品質，規模範圍：這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話，會自動犧牲品質。然而，其實品質是可以控制，但絕對不能犧牲，因為一旦犧牲，整個軟體不能做出本來該做的事情，有再多功能，用再快時間上市都沒有意義。
因此，其實最應該考慮的是規模範圍，簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up（精實創業）的精神。

Scrum的缺點 (軟體主管的31堂課)

當手上有榔頭，看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而，Scrum是個在agile development範疇內的方法論，它是個很好的參考軟體開發流程的工具，而這工具有其「特性」，無所謂好與壞，當然就無所謂優點與缺點。

然而，這些特性不可否認，需要對該工具有一定的認知，特別是一些「預設要知道的事情」，以免誤用。舉例來說，當你使用榔頭的時候，大概會知道它是用來釘釘子，而不是拿來釘螺絲。此外，你也會大概猜到，右手拿榔頭左手扶著釘子時，要記得不要敲到自己的手指。

以下Scrum缺點（特性），也是常見的陷阱僅供參考。

(1) 團隊成員對Scrum的了解必須一致，工作能力最好也要差不多。

Scrum的運作中，高度依賴成員的自主性。Scrum Master雖然很重要，但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質，還是靠所有成員的能力。

換言之，如果有人技術能力特別糟糕，或者技術能力雖好，但對於Scrum的運用與瞭解和大家都不一樣，那麼有可能會有意想不到的長時間磨合期。

(2) Scrum並不會真正加快速度，只是讓速度透明，讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上，Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明，同時也讓團隊進行的速度變透明，讓大家更容易專注於正確的事情上。

整體來說，Scrum會減少各種不必要的浪費，讓整個專案效率提升，但就個別事情的速度而言，Scrum並不會提升。換言之，軟體工程師仍然需要有自己的方式來提升個人效率。

(3) Scrum並不會解決工作內容的相依性 

傳統的專案管理方法論，常常會提供類似甘特圖的工具。然而，Scrum方法論專注於某件任務(story)的完成，而隱含著希望每個任務的相依性，會在團隊成員的「成熟考慮」下被處理完成。

換言之，有相依性的工作就是有相依性的工作，軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失，也並不表示當有個寫得很獨立的story產出時，就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具，都應該有自己的處理相依性的方式。

節省招募時間 - 電話面試的技巧 (軟體主管的31堂課)

在軟體「人才」的招募上，通常會花上比預期還要多時間，人才難尋是軟體產業其中最困難的問題。自招募流程上，各種審慎的過程當然不能省略，例如技術評估，面談等等。然而，整個過程可以透過各種方式，提前篩選適任或者不適任的人。其中，電話面試在台灣是最被忽視的一項。大概也是因為台灣交通十分方便，特別是大台北地區，面試者一般都不會因為「太遠」而放棄，但交通因素並不是電話面試最大的好處，電話面試最大的好處是可以低成本有效地去除偏誤，有效增加後續篩檢的正確率，並節省時間。

---

案例：在某次研討會中，軟體研發團隊主管K說，我從來不做電話面試，因為我想要看到應徵者的臉孔跟肢體反應，這樣我比較容易判斷個性。

---

電話面試有幾個好處：
(1) 去除偏誤：尤其是對外表的偏誤。已經有太多研究證實，沒有人能夠避免對外表的偏見，只是多或者少而已。也因此許多研究指出，履歷表不放照片才是最好的方法。當然也有人持反對意見，不過整體來說，雖然遲早會見到本人，但電話面試的確可以去除主管對外表的偏誤。案例中的主管K試圖去判斷個性，但容易流於自我偏誤。

(2) 節省彼此時間：一般面談起碼也要花2個小時，而電話面試至少可以先過濾掉10~15%的明顯不適合的應徵者。許多資深的軟體職位起碼要收20個履歷表才能找到1個人。換言之，電話面試，在表面上起碼可以少讓2個人來辦公室，但其實背後意義不僅於此，操作得當可以讓另外18個人對你的組織更有興趣更能在面試中努力表現，而非因為獵人頭介紹隨便來試看看。

(3) 其他：其實還有很多好處，例如再度驗證履歷表的真實性等等。

電話面試的技巧：

一：結構性問答而非開放性討論

電話面試必須要「固定詢問有意義的結構性問題」，而不是開放性討論。透過結構性問題收集了解事實。

結構性問題例如：
* 你為何想要離開現在的公司
* 是從什麼管道知道我們有在找軟體開發人才
* 你最近一次跟主管起衝突的時候，當時你做了什麼
* 最近三個月，你學了什麼新的資訊技術是跟工作無關的
* 你最近一次code review是什麼時候

這些問題回答不要評論好壞，只是記錄最為後續判斷。

不要問開放性的問題，除非你要找的是很會唬爛的人，開放性的問題通常都是假設性的問題，例如：

* 如果你跟老闆吵架了你會怎麼做
* 要是你加入一個有大流量的公司，你要怎麼做分散式系統設計

二：基本的事實查核

事實查核比想像中重要，倒不是因為履歷表造假的問題，而是在看履歷表的時候可能會有自已的假設，這些假設可能會有認知偏誤。

簡單的事實查核問題
* 請問你想要離開現在公司的原因
* 請問你當初加入這個公司的原因
* 在2013/3~2014/10年這段期間，你履歷表中似乎沒有在任何地方就業，請問是什麼原因呢
* 您在2012年某公司A的離職原因是什麼

進階的事實查核
* 在履歷表中，您有描述溝通是你的強項，請舉一個最近一次你解決非常困難溝通狀況的例子好嗎？
* 您剛才說在某公司A的離職原因是公司內部高層政治鬥爭很嚴重，可以舉一個政治鬥爭的然後影響到你的工作的實例嗎？

三：回答面試者對公司以及團隊所有問題

優秀的人才鐵定會想要再加入一個團隊時，了解一些事情。讓面試者詢問問題，不對問題做衍生性的回答，也不做假設，只是誠懇地回答問題。並且在最後再詢問「請問你還有任何想要了解的問題嗎？任何問題都可以現在詢問」

當面試者問了廣泛性的問題，請必定要他縮小範圍。否則，廣泛地回答對他也沒有好處。舉例來說：常遇到面試者問「呃 ...我很重視軟體工程文化，請問一下貴公司的文化是怎樣」這種問題太過空洞，可以直接告訴面試者「我們也很重視工程文化，但你的問題太過籠統廣泛，這樣我也會回答的籠統廣泛對你也不好，可否你縮小問題範圍，或者問實際的某件事情，透過實際上事情你就可以判對我們的文化對你來說好還是不好」。如果是容易溝通優秀的人才，很快能了解，因而他們就會問類似這樣的問題：「喔 我了解，那我想問，請問你會進行code review嗎」這樣彼此就可以針對事實討論。

更重要是這樣的事實討論，可以讓他了解優秀主管通常是實事求是，而主管也可以了解他能不能馬上抓到重點。



藉由這三個項目，一個好的主管可以初步篩檢適合或者不適合的人。另外一個值得一提的是：電話面試中間盡可能不要提早判斷面試者適不適合，盡可能是電話之後才根據筆記來判斷是否要邀請來面試。

自我感覺良好的能力不足: 預防與解決之道

在軟體開發團隊的招募中，技術能力當然是不可或缺的一環。候選者如何自己評斷技術能力，也許和如何評估候選者的技術能力一樣重要！

換言之，謙虛的人比自我感覺良好的人，可能實質上的能力更好。這在「達克效應」中說明得十分清楚。

達克效應簡單的說：是指能力不足的人通常會高估自己的能力 無法正確判斷自己能力的不足。不過經過提高能力之後，是可以認知到過去能力不足的事實。
這個理論雖然廣為人知，但真正去證實的人很少，因為大家總是覺得很合理，

該論文研究分為四例，無論是哪個例子，結果都類似下圖(註1)

本圖取自論文：Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments

該圖是取自研究案例二，研究者讓所有受測者考一個邏輯考試，這邏輯考試取自於美國的法律學校入學考(LSAT)，主要看一個人的邏輯思考是否完整，有興趣可以參看這個網站。

當然考試不是重點，考完試之後，將結果分成四組人，最差的就是bottom，最好的是Top。所以在上圖中，很明顯bottom組的結果當然是在最下方。但有趣的是在於，最爛的一組，在預測自己的成績與能力，卻是和實際上差距很大！次佳組(3rd)其實實際成績和自我預測最接近。而成績最好的那組，反而感覺非常「謙虛」！？是唯一反而預測自己考得不好，同時也自覺的不好的一組。但實際上考的成績卻是最好的。

研究有四個案例，考試的範圍跟內容各有不同但結果很一致。

這篇論文，雖然很直觀，但寫得有點幽默，所以竟然還得了搞笑諾貝爾獎，細想其實很有啟發性。尤其在組織中，員工的自我感覺良好是績效評估產生問題的最大因素之一，那麼在組織中有什麼樣的解決方式呢？

預防的方式：招募時的預防

尤其是軟體開發團隊，招募一個謙虛的人，比招募一個很有自信的人更容易找到真正有能力的人。倒不是說有自信是不對的，但自信心往往容易落入低能力的範圍（請參見上圖)。

要判斷自信與能力最簡單的方式有兩種：一者，就是根據過去實際的產出內容來衡量，例如詢問他過去工作中，實際上做了什麼事情，導致於貢獻的產生，而不是只問了貢獻的結果。其二，設定簡單的測試環境，例如直接在白板上討論演算法問題。

解決的方式：衡量產出而非能力

絕大部分的企業組織都知道，衡量員工的績效乃是基於產出，並非能力。當然，能力好的人自然有機會有更高的產出。

在軟體開發團隊中，衡量產出極其困難。每個團隊幾乎都因人而異。有幾個方式倒是可以適用於大部分的狀況 
(1) 員工自評，並且加上3位以上的同僚互評。
(2) code review
(3) quality

由於最近比較忙，關於產出的衡量有機會再寫。:)



------
註一:本圖擷取自該論文本身：https://pdfs.semanticscholar.org/e320/9ca64cbed9a441e55568797cbd3683cf7f8c.pdf

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的31堂課)

1999年美國的籃球夢幻隊1992 dream team 是所有籌組團隊的人遙不可及的夢想。他們除了籃球技術精湛，經驗豐富之外，更重要的團隊都有拿到奧運金牌的唯一目標，此一目標會讓他們自我激勵，根本不需要額外的刺激。這樣的團隊組成似乎可遇而不可求，在軟體開發的世界幾乎鮮少看到例子。

無論如何，建立能高度自我激勵的團隊，是主管最重要的工作之一。如果你是團隊主管，你必須認識到這是你最重要的任務。

自我激勵會造成工程師的職涯成長，而看得到自己的職涯成長，是能驅動效率的最好的因素(註1)。

軟體開發工作，通常是需要高度的心智活動以及集中的創造力。要造就高強度心智活動，幾乎很難單純由「薪水」或者「物質獎勵」來滿足工程師。加薪獎勵與升遷固然非常重要，但它能維持的效果頂多3-6週，之後所有的工程師都會認為這樣的加薪獎勵與升遷是「理所當然」，並且很快地將獎勵拋諸腦後。這不是說工程師都不懂惜福，而是研發工作本來就很大部分的來源會來自成就的滿足感，而成就的滿足感幾乎是加薪升遷無法長期提供的(參考 1)(註2)。非營利事業有可能天生就存在這樣的激勵因素，例如，慈善組織試圖拯救世界的所有窮困兒童，研究組織試圖大幅延長人類生命到200年...然而這些組織一般都有極為獨特的目標以及具有個人魅力的領導者。

一般的營利組織以及軟體開發團隊如何建立一個能自我激勵的團隊呢？

有三個方向：(1)選對人 (2)找交集 (3)自我導航

(1) 選對人

在選用人才時，就先確定此候選人是正面思考，能自我激勵，自我成長。因為要維護一個人的正確態度，比要矯正一個人錯誤態度來得容易太多。

換言之，選擇已經能夠自我激勵，並且確定此候選人在他過去工作經驗中，已經有自我激勵的事實。

不要選擇個人技術能力很好，但卻在自我激勵上面有非常負面的紀錄。因為，要培養技術能力並不難，但要改變人類的思考模式實在難上加難。現存的coach教練式領導，不過也就只是希望透過引導，造成行為上的調整(參考富比世, 英文版？)，要引導到行為心態的調整，教練(coach)幾乎必須要和學員長期合作才有辦法做到。

選擇的重點在於透過過去的實質發生的紀錄，而不是透過詢問未來的問題。這個做法在選人時非常重要，選擇能高度自我激勵的人才，此人必須在過去工作時，已經展現高度自我激勵的情況。例如，你可以詢問面試者：「請問你最近工作上遇到最艱難的狀況，或者壓力最大的狀況，當時你是怎麼處理的」。這個問題重點在於"最艱難"以及"當時怎麼處理"。有時候面試者可能說沒遇過太艱難的情況，那麼也可以詢問"普通難"或者"壓力普通大"的情況。一個工作超過3年以上的人，當然可能運氣超級好，從來沒遇過艱難狀況，然而絕大部分的人，都可以說出幾個艱難狀態。這時候，不需要太早評斷，也不用加入討論，而是要徹底瞭解，在這個狀態下，面試者通常會表達過去的事情和想法，暫且將其想法放在一邊，妥善記錄事實。最後再由事實來判斷。

舉例以下的對話為例：

主管：「請問你過去遇到工作壓力最大的時候，當時是怎麼處理的？」

面試者：「之前在HXC工作時常常加班到很晚，要趕專案當然覺得壓力很大。怎麼處理喔？就想說當練功啊，學到東西我就要離開了」

主管：「當時你如何判斷已經學到東西然後可以離開了」

面試者：「呃？...就那時候我負責的app都推出去了」

此例的事實是。面試者因環境工作時程長壓力大，處理的方式是轉換心態-當練功，並且設定好離開環境的方式。請記得在此並不判斷好壞，而僅是記錄而已。然而，設定好離開環境的方式並不是以學到東西為主，而是做完東西。光是這樣可能還不足盼對此人是能積極自我學習還是消極無法激勵，需要更多挖掘過去的行為的討論才會確定。

(2) 找交集

我們不可能知道別人腦袋在想什麼，每個人都有所謂 left-hand-column，即便已經選擇最能高度自我激勵，自我成長的人才進入團隊，而且他們也都是非常坦誠並努力工作的人。但我們要知道每個人都有不能說，不想說，或者不適合說的事情。 
有些領導者會試圖找出這些事情，但其實有沒有找到不重要，重要的是「重視left-hand-column的存在」。

一個好的領導者，會找出交集。確保雖然人人有不同想法，但整合個人，團隊以及組織的交集，大家可以獲得三贏狀態(win-win-win)往同一個大目標前進！

當然，一個能力好而且能自我激勵的成員，可以自己找到此交集。不過身為領導者或主管，應該要時時注意：每人對這個交集其實都不太一樣。但好的團隊的每個人，應該都有部分交集。

最底線是：一定要避免三輸的局面。聽起好像很荒謬，但軟體開發的世界偶爾常聽到雙輸或者三輸的狀況。不必要的長期加班，幾乎都會造成雙輸或者三輸。長期加班必然會造成人才的耗損，幾乎也不能避免地造成團隊無法緊密成長，所以起碼就是雙輸，最後也常常造成組織本身無法長期經營，那就變成三輸了。

要建立能自我激勵的團隊，找到每個人不同的交集點。如果真找不到，則很有可能該人才並不適合這個組織，如果一半以上的團隊成員你都找不到目標的交集點，或許你本人並不適合當領導者。

交集點的例子很多，某些有資深能力好的工程師，除了團隊環境之外，或許可兼顧家庭是職涯的重要考量。因此，彈性的工作時間，和受到控制的可在家工作，就會是這類資深工程師(註3)的「left-hand-column」而這可能是最容易取得交集的地方。做法很簡單，就是讓資深工程師自行定義產出和目標，

(3) 自我導航

自我導航(Autopilot)是指團隊成員知道自己為什麼要做，知道該做什麼，知道怎麼做，知道什麼時候做。而更有甚者，他知道自己什麼還不會，所以需要特別努力學什麼。

一個能自我導航的工程師鐵定是資深的工程師，他會自我衡量自己在團隊中的「交集」也會自己「選擇」適合成長的環境。換言之，根本不需要煩惱這樣的成員。

對與已經是自動導航的工程師，僅僅只需要「教練式引導」(coaching) 。領導者或主管，應該必須對coaching有一定程度的了解，如果還不了解，現在就是學習的好時候。

在此最底線是千萬不要micromanagement -  也就是枝微末節都要管。大部分的資訊工作都是高度腦力工作，枝微末節都要管意味兩種可能
(1) 團隊成員根本無力勝任這樣高度腦力工作，而你組出這樣的團隊表示你也不適合作為建構團隊的人
(2) 團隊成員可以勝任高度腦力工作，但你身為管理者想要插手，表示你並不了解高度腦力工作的統御管理方式，所以你大概也不適合作為建構團隊的人。

要怎麼樣知道領導者管理者是不是「微觀管理」？只要看他實際做的事情就知道，當時「實際要做的事情」超出「本身的意義」就是這類型。

舉例來說，上班有規範時間，並非微觀管理，沒有規範在大部分得時候反而浪費大家的時間。然而，毫無彈性的硬性規定人必須出現在辦公室的時間，其實就超過規定上班時間的意義。對軟體開發團隊來說，上班時間規範是為了讓團隊容易一起面對面討論，互相砥礪解決問題。例如組織定義9:30~18:30是工作時間，然而，因個人因素不在範圍之內，例如想要8:30~17:30只要該成員能確保他的scrum團隊夥伴都知道他和大家時間略有不同即可，成熟的團隊的紀律來自「自我認知和團隊合作」，並不需要管理枝微末節。同樣的，「規定現在要加班」也是某種程度的管理枝微末節，順便強調一下加班其實是解決問題最爛的方式，尤其是被規定加班。

抱歉 沒有什麼神奇的快速方式！

組織理論其實並沒有捷徑，也沒有什麼神奇的快速絕招。然而只要方向正確，忍耐個幾個月都會看到成效，但是簡單的路總是難行。當然，特定快速的環境 - 例如非常新的新創產業，還不確定能否獲利 - 似乎不值得這樣長期投資？也有不少人主張時間不等人？然而，對大部分的資訊產業來說，大部分的情況是跑馬拉松而非短跑。

技能與績效的考量:

在這裡省略一件很重要的事情！
我們並沒有討論技術能力和工作績效，但其實在軟體開發團隊中個人技術能力與個人工作績效是非常非常重要的！沒有好的能力與產出，要怎麼激勵自己恐怕都沒太大用處。然而，績效和能力應該比較容易在面試與履歷表中檢核出。因此才不在這裡討論。

---

註1:  要使團隊有高效率，自我激勵是最好的方式 。然而其他方式也存在，例如鞭子與蘿蔔。
註2:  但是如果薪水實在太少，不能滿足基本需求，就不在此討論範圍之內。
註3: 不過要特別注意，資深和年紀沒有絕對關係。必須要是做事態度資深，而非年紀資深。