2013年1月29日

專案管理人應該知道的97件事:來自專家的集體智慧

(到博客來購買本書)

身為專案經理,我們應該引導使用者對軟體開發人員表達意見,要盡早而且要經常表達。[3]

當我們試著預估實作功能的時間,請別只考慮編寫程式碼所需的時間。請加上用於強化、修正、改善程式碼所需的時間。寫出品質良好的程式碼與測試,都需要時間。這看起來是種短期的損失;卻是長期的收穫。[5]

請問問自己:是要求速度呢?還是要具有一定水準的進展過程呢?[5]


----------
專案失敗並非美式企業的特有現象。根據一家日本的資訊科技雜誌龍頭在數年前的調查,如果從品質、成本與交貨標準來衡量,日本企業所負責的專案中,有超過75%都被視為失敗。

在日本,就像在大多數其他國家,有著相同的各項標準無法達成的首要因素:糟糕的需求定義。最常處於緊急狀況的企業,也是事業分析能力最差的企業。觀察目標指定為科技性專案-例如軟體開發時,專案的成功則委婉被歸類為「不太可能的事」。這個結果顯示了尋找、辨識與定義軟體專案之需求的困難度有多高。

既然這是件很困難的事,許多專案的擁有者-例如客戶、專案資助方、公司的高級管理階層-就期待由專案經理自行定義與調整軟體的需求。擁有者不會提供太多指引或是對於需求的清楚定義。因為是軟體專案,他們或許不瞭解軟體開發事怎麼回事,就假設自己不需定義出期望中的成品。

軟體專案經理人通常並未具備足夠的權力或時間,可以自行尋找、選擇專案的需求,並排定需求的優先順序-尤其是專案涉及到多個利益團體,而各個團體對於軟體成品的預期有相互矛盾的時候。[8]
----------


在定義需求的階段,若沒有認真、專門地思考專案即將建造的事物,則專案成功的可能性實在岌岌可危。請記得,專案擁有者需要傳達出他們希望的軟體達成效果,而不是程式設計師想產生何種成果便採用何種成果。[9]

請說服專案擁有者,他們有著從頭到尾都參與專案過程的必要性。可靠的需求規劃,能在商業案例、專案目標與專案成果間建立清晰的連繫。否則專案無法產生預期中的滿意成果。[9]

一個失敗的軟體專案,傷害最深的人就是專案擁有者,因為他們必須負擔用於建立專案的金錢,還要期待能用這個軟體賺回投資下去的心血。[9]

當然,我們可能是用「多功能」委婉掩飾「太複雜」這件事。沒有人一開始就以製作過度複雜的產品為目標。複雜是意外下的產物。[10]

軟體通常用於解決複雜的問題。但問題是我們把多少原有的複雜度轉嫁到終端用戶身上?我們的軟體是否放大了複雜度?優秀的軟體通常能吸收複雜度,為使用者承受問題的衝擊,而不是把衝擊轉嫁到使用者身上。[11]

身為軟體專案經理人,你是複雜吸收器或複雜放大器?最好的經理人能吸收來自各方面-程式設計師、終端用戶、管理階層的複雜度,而不會加以放大。而終端用戶產生似乎自相矛盾的需求時,經理人的工作就是協助釐清需求,而不是盲目地交給開發人員。而在開發人員引用晦澀艱深的技術理由,表示無法達成某項需求時,經理人的工作就是翻譯(吸收)複雜度,並提供終端用戶足夠的資訊,以協助它們選擇另一條路。[11]

簡單明瞭不會偶然產生,這需要我們的積極耕耘。當我們漫不經心時,就會冒出複雜的狀況。[11]

我發現自己不再位員工的成長做投資。我們不再尋找新鮮的天賦。我們變為尋找極為特定、經過調訓的「技能」。現在,我都跟別人說,如果他們看到某個老闆雇用完全符合某些技能的人,這位老闆實際傳達的訊息是:「我們不打算在你身上投資。」[15]


----------
對於任何尋求建立一個強大團隊的人,我都建議各位雇用天份,而不是雇用技能。我會為自己的機動開發團隊雇用具有哪些天份的技師呢?我覺得幼稚園兒童的技能值得參考:

* 他們能否與其他人和平相處?
* 他們是否遵守規則?
* 他們對於新事物是否流露出興奮之情?
* 他們是否喜愛學習?[15]
----------


----------
保持需求簡單。產業分析師常把自己想到的某種特定方案,與基於產業需要的實際客戶需求混為一談。雖然真正的需求很可能非常簡單,但在產業分析師與程式設計師或開發人員間,可能有某種代溝,畢竟隔行如隔山,兩邊都無法瞭解對方在做什麼。

產業分析師應該使用簡單的樹狀圖表明需求。根需求(root)是整體專案的簡易目標。表示子需求的細枝則應該分組,以構成表示父需求的較粗分支。這個過程在圖表上重覆出現,直到每個需求都以清晰明朗。軟體的心智圖(mind-mapping)工具也可用於紀錄透過樹狀圖表達的需求。只要釐清任一個分支的需求,開發即可開始。[16]
----------


我學到了架構不良、編寫不良的需求有多危險,而且還可能成為反咬自己一口的工具。要養成總是書面記錄假設的習慣,還要堅持與終端客戶檢視並簽定需求,而不是與中間人交涉。[21]

幸好,敏捷專案管理的習慣已可緩和這類問題。基於認識到開發人員與真實客戶面對面的重要性,我們逐漸形成集體發想使用者故事(User Stories)的做法,並根據功能帶給客戶的商業價值來安排優先順序,而不是依照需求清單上的順序。一到兩週的週期流程,表示我們收到反饋的時間較早、頻率較高,而澄清客戶期待的機會也跟著提高。[21]

在雇用程式設計技能時,我們都希望技能愈多愈好。但是該如何定義「多」?雖然候選人具有極佳的知識,但可能還沒發展出有效運用知識的技巧。若是面對高要求的現實專案,一名剛畢業或剛受完訓練的開發人員,或需耗費十二萬分精力才能應用課堂所學到的理論知識。當緊張的期限壓縮了探索解決方案的時間,來自客戶與其他利害關係人的密集壓力如陰雲罩頂時,我們需要的是經驗,更勝過半生不熟的知識。[24]

沒有留言: