軟體專案的Scrum的一次sprint之後，照例的檢討會議(retrospective)中，張經理收集了成員的意見，經過投票整理與排序，發現"不夠專注在重點上"是成員們最希望改善的地方。於是，張經理發表他的見解：「看起來大家可能是覺得瑣碎的事情太多，沒辦法專注於工作，這次新的sprint開始，大家試著把心思專注在重要的事情上」，接下來，張經理開始順道交代其他事情：「呃，上次要給法務部門的3rd party版權清單，老馮你準備一下；明天我們要定個下午茶，小陳你有空的時候幫個忙...」。....於是乎，最希望改善的地方就從未改善過。
Pareto Principle，又稱為80/20法則，指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們，在其他領域也觀察到重複類似情形，因此被簡約成此法則。
80/20法則中的數字，有時候，會和實際領域不同而有所改變。例如，絕大部份的軟體，其90%的執行期間，執行的是其中10%的程式碼(參見這裡)。
在軟體專案管理中，能掌握80/20法則，等於是掌握80%的成功。
以程式撰寫為例：最重要的10%程式碼，關係到軟體運作的90%時間，掌握最重要的10%的效率與品質，就掌握系統的本身。當然，80%的bug來自於20%的程式碼。（參考這裡）
以測試為例：1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug)，就可以有效縮小測試。
以人員管理為例：在有一定人數的情況下，30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時，80%的問題來自20%的模組撰寫者。
因此，掌握並改善20%重點，是任何專案的成功關鍵因素。
不過，這件事情知易行難。以反面來看，作為專案管理人，如果整個專案過程的每天都忙得焦頭爛額，隨時都有不同的人來進行不同的會議，螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點，而你雖然很努力的想要完成任務，但並沒有朝向正確的努力方向。更慘的是，假如你認為這種忙碌可以顯示自己在組織的價值與貢獻，這種想法做為專案的領導者只會害死大家。
每個專案都是獨一無二，因此每個專案的重點20%都有所不同。然而，掌握關鍵的「20%」倒是有三個共同切入點。
1. 目的 - 真正目的
軟體專案的真正目的各有不同：有些是新產品開發，有些是既有產品增加新功能，有些是客製化專案。大部份的情況下，其目的通常不是「技術目標」，而是「達成效果」。
例如，網路商店需要開發mobile app，其目的鐵定不是為了要有一個Android APP或是iOS APP，而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何，技術目標：也就是有Android/iOS APP，與達成效果通常有相關，但專案管理者必須清楚兩者的不同：
達成效果是勢在必行不可或缺，但技術目標永遠都有其他選項。
網路商店不見得需要有APP才能讓使用者在智慧型手機上購物，可以使用符合智慧型手機規格的網站(所謂的響應式設計)，讓使用者利用手機瀏覽器進行購物，也可以透過簡訊或者撥打電話的方式購物，開發APP只是其中一個選項而已。
掌握真正目標之後，列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能，而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%，才不會「先」耗費力氣在無謂的事情上，「最後」才做真正重要的事情。
2. 時間 - 不倒退的沈默成本
時間是不會倒退的（參考這裡）。軟體專案裡的時間成本一旦投入，都屬於不會退還的沈默成本。也因為時間無法退回，一旦投入就是投入。因此，必須要確定「先」運用時間在重要的事情上。
80/20法則的重點在於：計劃先運用「未來的時間」，在有效果的事情上以先達到80%的產出。
舉例來說，一個程式設計師，在早上抵達辦公室，打開電腦的第一件事情，應該試圖確認「今天什麼事情對我最重要」，而一個開發團隊，每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此，典型的scrum都會在一早展開standup meeting(快速會議)，以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。
這也是一個聽起來簡單，執行起來並不容易的概念。有很多情況，團隊成員並未「徹底」實踐快速會議時的精神。
例如：某甲陳述：今天會開始開發模組A，預計今天會完成，而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統，因此實際上會議結束，其實他花了一早上在簽入程式碼，並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情，而是他對於「未來即將使用的時間」沒有腳踏實地的認知。
80/20法則運用在專案的時間管理上，最重要的精神在於「腳踏實地」，並且「確實展現事實」-- 缺乏這兩者，會讓80/20法則淪為壓榨程式設計師的幫兇。
3. 激勵因素與保健因素
激勵保健理論(參考這裡)，將影響人工作時心裡的滿意度因素分為兩類：激勵因素與保健因素。簡單的說，保健因素是「沒有會死，但是有也不會很高興的因素」，激勵因素是指「沒有的話不會怎樣，但有的話會很高興」。
激勵與保健理論，乃是在軟體專案管理中，80/20法則運用的最容易忽略的一環。特別是在兩個面向上：(a)軟體團隊經營
(b) 技術決策
(a)軟體團隊經營：
保健因素(薪水，電腦設備，工作環境)：無論加碼到什麼程度，對程式設計師的績效成長極端有限，然而一旦失去基本下限 - 例如減薪，則其他的激勵方式會突然失效。軟體專案負責人，應該在一開始，就先確保：保健因素是成員可以接受的。爾後專案執行過程，不要特別關注它即可。激勵因素(個人成長，價值觀，成就感)：激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者，應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同，因此了解團隊成員個別的「真正需求」，才是需要花時間的地方。
舉例來說，有些團隊成員可能會抱怨沒有雙螢幕，雙螢幕對於撰寫程式的確很重要，專案經理想辦法弄給他雙螢幕之後，千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素，是必要取得，但不是重點。專案領導者在團隊經營上，應該花20%的時間快速搞定保健因素，而後，花80%的時間確保激勵因素的存在。
缺乏激勵因素的團隊成員，並不代表一定會離職，也不一定代表任務不能完成。一個能力很強的人，可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員，反而成為一個潛在的問題，他隨時有可能因為任何短暫膚淺的因素而離開，更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題，而是團隊領導者，沒有辦法找到並維持適合的激勵因素。
(b)技術決策：
既然是軟體開發專案，必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。
以功能而言，如果有A功能與B功能在短時間之內，只能選擇完成一個。則技術決策應該從幾個方向考量：
方向一：中大型軟體專案一定有20%的重要功能，會滿足80%的使用者需求。哪一個功能屬於這類。
方向二：如果A與B都滿足方向一，則考慮哪一個功能會直接滿足「專案目的」。
方向三：如果A與B都滿足方向一與二，則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能)，哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的，是屬於維護且保守的專案，還是開創性的新專案。開創性的專案自然優先考慮激勵功能；而維護型或保守的專案，當然要先考慮保健功能。
80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言：有很多15年以上專案管理經驗的所謂專案經理，他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過，這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理，為了團隊好，或許應該考慮轉換適合的工作跑道。
沒有留言:
張貼留言