大綱

5/06/2016

80/20法則之軟體專案的三個運用重點




軟體專案的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年沒有什麼不同。如果你是這樣的專案經理,為了團隊好,或許應該考慮轉換適合的工作跑道。












沒有留言:

張貼留言