我們遇到了敵人......就是我們自己
 |
- 作者：Barbee Davis
- 譯者：莊惠淳
- 出版社：歐萊禮
- 出版日期：2012年12月06日
|
時刻銘記在心的專案三角函數：專案的三重限制(triple constraint)
時間、成本、範疇，而中心則是品質。
當三角形的任一邊有所變動，勢必影響另一邊。進而改變了專案的品質。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
專案經理的責任
『我們遇到的敵人，就是我們自己』，這句話很適合用來描述初接觸軟體開發流程的專案經理。要知道我們是專案經理人，不是超級英雄。所以對自己要實在，就像坐飛機發生危急事件是，正確的安全步驟是：先載上自己的氧氣罩，再協助老人或小孩戴上。因為如果我們先試著幫別人，可能因為自己缺氧而失敗，然後全部一起死去。
因此當專案經理，失去了自我控制，因而無法照顧團隊，就會像缺氧的團隊，專案也終將失敗。
組成並打造出馬拉松團隊
要建立一個強大的團隊，並不是找出一堆符合「技能」條件的強者；而是要找
出一堆有「天分」的人，包括：是否能和別人和平相處、是否遵守規定、是否對新事物流露出興奮之情、是否喜愛學習等，這樣才能打造出能跑馬拉松的團隊。
另一方是從中找出優秀人才，要知道：「人數永遠不等於人力。」找一個中庸的開發人員，只會拖累進度，並不會改善問題。甚至，造成優秀人才的流失與困擾。特別是軟體開發，軟體開發是門藝術，並不是靠人力生產的產線。
而要維持這樣的團隊，保持專案成員的士氣很重要。如果專案經理學習尊重團隊成員，並願意和成員談心，士氣就會改善。並且還懂得分享專案願景，讓團隊成員知道若達成自己的專案特定目標，將對整體計畫目標的成功有何貢獻。將激發成員的榮譽感，並會想要努力達成任務。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
有效方法
團隊合作依賴兩項關鍵原則：授權與負責
只要領導風格、授權與責任都各就各位，就能互相支援。並保證出現更好的成果。
幫助成員解決效能問題
套用 CRAM：限制(Constraints)、資源 (Resources)、才能 (Aptitude)、動機 (motivation)。依序去找出可能問題 並協助解決。當成員的才能不適合目前角色時，轉換其工作或讓他到其他團隊發揮所長。
引導利害關係人參與專案
每個專案都需要贊助者，不論是好或不佳的贊助者，都是身為專案經理人的我們所要去管理的。及早讓這些贊助者或利害關係人參與專案，可有助於專案不會偏離目標。而要達成這樣的目標，要先讓所有利害關係人必須對於專案運行流程有著共同的理解。所以要讓他們保有足夠的資訊、參與必要的過程，並學習與他們相應的相處之道。
特別是針對最後的使用者，我們在開發時一些軟體開發人員或專案經理覺得很有道理的決定(改變)，卻可能造成實際使用者工作上的混亂。我們應該尊重他們過去的習慣，所以我們應該引導使用者儘早(越早越好)對軟體開發人員(經常)表達意見。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
建立適合專案的流程
專案要與廣大的群眾組合互動，為了效率，所以應該先行規劃專案行政工作。也就是說導入適合的方法論；其中敏捷式專案管理與開發是一個不錯的選項。只是，當專案經理過度於遵循某種理論方法，反將妨礙了他們對專案管理的專業能力。專案管理的流程重點應該是放在效率與保持簡單。別依賴任何單一的管理規則，而是要彈性的運用所有可用的規則。並且繪製一條可變更的道路，來面對未來的挑戰。最後，就是要書面記錄流程(重要部分)，並確實遵守。這樣專案的管理流程才能落實到每一個成員。
 |
| SCRUM |
發展有效率的溝通模式
回顧失敗專案時，大部分的原因都歸因於溝通的失敗。對任何產業中的專案經理人而言，所必須具備的知識就是溝通，並和別人共同合作。
因此，專案會議很重要，除了能促進溝通，更能建立專案成員的對專案的認同感。 但別落入純為開會而開會的陷阱，如果只有老闆或專案經理出席才能開的會，就屬這種，這類會議通常無法讓專案成員獲得價值。簡單的說，就是別讓PM成為所有溝通的樞紐與傳聲筒；而是讓所有利害關係人能一起溝通，這樣才能保持專案前進。
另一方面，光開會寫不了程式。我們經常看到許多可以更有生產力的人被困在會議中，因此要讓開會變得有效率。故要避免讓會議變成例行公事 (試著先公告會議主題，並僅讓相關人參與) 或太深入 (真正的解決建議都不會在會議上出現，請指定適當人員於會後研究)，另外就是太常開會或是超出時間。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
有效方法
每日站立會議：
報告15分鐘、約10人的團隊會議，每人有1~2分鐘機會對團隊報告自己的進度；描述上次報告後所達成事項，與今日預計工作事項
輔助工具：
- ★建立布告欄，更新成員在勤時間，張貼每位成員大頭照，說明執掌與代理人
- ★運用 wiki 或IM 等工具；採用同步溝通或簡短的非同步溝通，可以有效補強面對面溝通的不足
- ★建立資料分享區：DROPBOX 等是不錯的選擇
- ★整合的專案儀表板：公布最新專案狀態、短期議題、長期議題、風險、預算追蹤、里程碑達成狀態……
專案經理的領導力展現，來自於對人際問題的管理
專案經理常身陷於時程表的細節，但缺忽略了真正造成專案失敗的元素：人。專案中的成員或資源不可能自動校正並往前進，一切複雜的事並不會自動消失，甚至夾藏是『懷恨在心的人力資源』、『緊張兮兮的利害關係人』等。這些問題的管理也就是專案經理的存在價值，所以不該將這些狀況是為障礙，而是我們職務的核心。
身為專案經理我們要注意壓力將導致成員行為退縮，且不願積極尋求解決問題的行動。我們要透過與成員的積極對話，並仔細經營工作的環境，來避免壓力的影響。在我們監控與保護非人資源時，也要小心培育跟管理手邊的人性資本。
只是要知道，專案經理無法掌控一切!! 當一個專案經理人顯然想成為控制一切的中心點，參與所有「重大」的決策討論，並由他做出所有決定，表現出他可以掌控一切，但其實事實的結果可能正好相反，儘管專案成員會在口頭上同意，但離開會議後卻不見得會完全反映出我們的意向。更糟的是，這只會造成讓專案成員痛恨，讓成員覺得意見未受到重視，當他們有問題需要解決時，則會試圖從其他方面獲得援助。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
專案經理真正要做的事只有4件
- 經常清掃團隊中不合現狀的習慣 (註：但非增加更多程序。)
- 分享願景，讓大家齊心協力；千萬別視其他人為笨蛋，只想搞垮公司。要知每一個專案成員都想要成功，並為自己的貢獻感到驕傲。
- 傾聽客戶的聲音。但這並不是一昧的用「讓使用者好過一些」的心情來決定解決方案。而是傾聽他們宣洩對日常遭遇的表面症狀的不滿，然後對使用者提出一連串的問題，找出沮喪下的真正根源。確定了正確的目標才是對使用者最好的做法。
- 為你的團隊服務。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
規劃是為了找出成功的道路
計畫的目的並非建立一套文件，而是要讓我們思考專案的問題，找出讓專案成功所需的要件，因為或許專案進行時路程會依實際狀況而有所改變，但目標的變更卻是很少見的。所以可以先為達成目標勾畫出一條合理的道路。
只是何謂合理？根據統計，軟體開發有60/60 法則：也就說，軟體開發週期中，實際上僅 40%是花在開發，而有60%是花在維護。甚至，是花60%在維護，而另外花60%在強化。因此，所以得合理是指據現實以規劃，並再加上維護與風險管控用的緩衝時間，也許是10%...或更多。
而誰是最佳估計人選？請直接邀請負責工作的人來協助。一個良好的方式是使用DELPHI 法，由實際開發者與其他同輩們共同去估計每一項工作，大家分開估，同時亮出答案，然後討論找出合適的對應值。這樣不僅可以互相討論找出合適的作法，而且也會最接近實際開發的時間。
只是，常見的狀況是，專案經理常在專案開始時做了規劃，但卻在專案執行過程中，未曾再審視這份評估報告。其實，正確的作法是定期的進行評估，並持續追蹤狀態、適當調整計畫內容。透過這種持續、積極的反饋，將使我們日漸進步，且更清楚掌握專案。
評估真正獲得的事項
軟體的困難處在於『沒有可以驗證的優良、可驗證的建構方式。』或許可以說，因為可以用來組合的方式太多，反而沒有方法可以預測。
專案的工作狀態完成與否，是由客戶定義而非狀態報告。當專案團隊回報95%工作已完成的事實，和客戶能否使用我們交付的成果，兩者並無真正關聯。
因此要了解自己的整合點，基本方式就是拿出 工作說明書 (SOW) 找出 WANT 和 NEED，並比較出差異。然後回答，我們試著達成甚麼？甚麼可以讓這個專案對客戶、我的公司和我而言都算成功。
然後，擱置不重要也不緊急的工作；減少不重要但緊急的工作。然後，立即處理重要並緊急的工作，但要優先建立處理該類事情的反饋迴圈。但最重要的是，處理重要但不緊急的事。因為這些才是最有價值的事，或許當下沒法看出好處，但隨著時間將會發現這才是專案成敗的關鍵。試著評估、分類這些專案的大小事，並評估完成工作的方式，而是單純針對交付標的，不是去在意成員工作了多久，而是注重其產出成果；這樣才能讓願景、期望與專案進行狀態保持一致。
規律的專案排程與私人生活時間
專案經理人通常會是專案中的唯一一人，沒有備援人選，因此很多專案經理人常會因為責任感而放棄了假期。但一個專案經理真的需要定期的休假，才能從專案的高壓中喘口氣。因此，在專案中試著培養可以填補專案經理角色的人，或是建立自我導向的敏捷團隊。千萬別覺得專案少了你將會停滯不前，就取消渡假計畫。
不僅僅是專案經理自己，也要替專案成員著想，安排規律時間以恢復專注力。另一方面，也可將專案分切成更多小的周期，配合週期來工作；因為我們的身體充滿各種自然週期，生產力自然也一樣。我們把工作分成較小的周期，提供了追蹤進度與讚揚良好開發的機會。還可會為團隊成員提供相互反應與回饋的溝通機會。
最後，最重要的就是，避免打地鼠式的開發。當時間因素非常重要時，我們該如何提升速度?? 『保持一致的適當速度前進』。當我們只是一味求快，卻可能造成未來更大的時間與成本投入。若我們能從頭就用穩健與注重品質的方式投入，最終，你卻會發現「慢」才是快，而「快」卻可能永遠沒有抵達終點。因為品質永遠是結案的唯一選擇。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
企業、組織與環境
真正的成功，伴隨著公司組織的支援而來
當身處不支援或功能不健全的公司組織，則可
- 反覆詢問，直到理解專案的範疇
- 找出利害關係人，在時機允許下邀請他們參與計畫進行
- 讓實際做事的人可以全面參與專案更新與決策
- 做個誠實的專案經理，不要掩飾或簡化問題
而想要保持長期成功的組織，可以試著導入PMO(專案辦公室)。讓專案管理的紀律與風格可以傳承與持續改善。
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
資源的運用與管理
※ ※ ※ ※ ※
人才
專案經理普遍同意，『人』是專案最重要的資源，但最為困難的挑戰是如何適當地讓團隊成員參與到專案中。因為當成員尚有其他重要的日常職責時，將會使他們做出選擇。
只要透過讓專案的目標與公司的目標一致化，讓在專案中成功的成員獲得在公司更多更上層樓的機會，才能使成員願意花更多心思投入。
※ ※ ※ ※ ※
工具
「所需工具尚未發明」症候群害的大部分可以偉大的團隊脫軌翻車。這些團隊成員總認為他們遇到「非常特殊的需求」，需要客製化解決工具。但殊不知，早已有適合的工具被他們棄之如敝屣。所以，他們開發出了真正的「敝屣」。
透過購買現成軟體可以減少花費在開發和實作階段的時間。並可以購買到軟體公司的know-how。但前提是要辨識出真正的需求，且詳實了解要購買的軟體的細節。
資源的運用與管理
糟糕的需求定義永遠是專案失敗的主因之一。所以專案的擁有者(甲方) 更應該從頭到尾的投入。並認真地思考出需求，要知道，專案的失敗，傷害最大的擁有是擁有者。除了投資下去的成本外，更重要的是可能因為重要專案的失敗，導致喪失的競爭能力。
為了有清晰可見、定義良好的規格和接受度準則，要試著讓解決方案更簡單、容易，如用樹狀圖、心智圖來描繪需求，並保持需求的簡單；透過敏捷開發流程，來縮短代溝。
要達到上述結果，就要儘可能將專案分解成許多各自獨立的，但可管理的workstream，並讓其中重要成員略有重疊，以保持資訊的分享。而且再將每個workstream 做出工作分解結構，讓工作內容分解到最小工作包。事前多花一點時間，取得專案成員的理解與同意(包括專案利害關係人)，將是成功的不二法門。
※ ※ ※ ※ ※
重要的文件
專案範疇聲明 (scope statement)
它是專案的藍圖，描述了專案最終成品或服務的特性；定期舉行會議檢視專案範疇聲明，將可以增加專案成功的機會。並讓所有利害關係人的期待與專案的目標一致。
故事(stories)
將需求寫成故事：
- 根據使用者的反應來設定及討論其優先順序。
- 團隊版的專案範圍從故事中建構而成，並建立良好的接受度準則。
- 故事拆解成任務，並由負責完成任務的開發人員予以評估。
狀態報告
要讓報告本身簡單，並協助開發人員愛上寫狀態報告。這樣靠幫成員理解這些報告對其他人的重要性 (註：不是只有對專案經理)，並即時與適當的回應內容，解決成員提出的問題，使成員覺得透過狀態報告有價值。
商業價值永遠是衡量成敗的標準
專案經理對該交付原本承諾的事物：不要多、也不要少。
有經驗的PM知道自己必須從第一天開始就保持堅定立場。並在專案中事先計畫祕密的應急時段與計畫，並將其視為最珍貴的資產，在絕對必要或專案結束才使用它。
另一方面，專案經理也該深知，專案並不單單只是為符合成本、品質、時程和規格而努力。也要注意一項重要的任務，那就是專案要能為組織增加多少價值，這也是決定專案有多成功的唯一準則。
