關於「軟體開發」與「專案流程」－ 丟掉習慣
成功的團隊做了什麼其他團隊沒做的事？他們經常質疑自己的習慣，並試著排除浪費的習慣。他們毫不留情地隨著重組軟體一併重組工作程序。
為什麼各個團隊現在不應用這項原則呢？為什麼經過一段時間後，最終成品的價值變得愈來愈少，而工作程序和副產品卻變得愈來愈多？為什麼程式碼的行數總是在擴張，而軟體中好用的功能卻變得愈來愈少？
以下關鍵指出軟體開發流程出現「毀損」的事項：
● 軟體因程式碼行數與無用的功能而虛胖
● 團隊所開發的軟體大小一直增加
● 程序變得愈來愈有硬性規定且固定不變
● 團隊經歷到「死在細節上」的會議
● 書面記錄與支援素材的數量以指數增加
● 用戶測試團隊一直找出新臭蟲
團隊領導人偏好增加更多程序、更多檢查、更多審核，認為一套漸增的嚴格程序將能解決問題。但根據我的經驗，程序從來不是真正的問題。加入更多程序只會讓團隊更難察覺真正問題的根源。
為什麼大多數團隊都害怕拋棄一些對團隊沒有幫助的習慣呢？為什麼團隊一開始就要設定所能想到的一切習慣，而不是及時新增習慣呢？
這可能因為團隊最初並未融會貫通使用此程序，而造成的症候群。或者表示有人並非全面理解軟體開發程序，遂把嚴苛無謀的理論方法強行套用在團隊身上。無論是哪一種狀況，專案變得如同一座紙牌塔，隨時都準備散落成一堆堆無用的程式碼片段。在瞭解專案擴張卻未增加價值的真實原因前，試圖改變任何事情將是無用的。
依個人而言，我覺得一位優秀的專案經理人，應該能良好掌握團隊運作方式。他們應該能保持一點距離，以評估加在團隊上的每個程序，將對生產實用軟體的能力造成何種影響。
有識的專案經理人應該仔細篩選團隊可能要求執行的所有行動，只留下對於促成當前的特定專案很重要的行動。一旦清掃了來自團隊過去、不合時宜的習慣，團隊的生產力與處理能力，應該能在短期間內獲得提昇。
關於程序，「言簡意賅」是個非常重要的哲學。
關於「軟體開發」與「管理專案、人際與團隊」－ 精巧的程式碼很難維護
開發人員常被要求創造奇蹟。他們必須找到能讓現在的專案程式碼與過去的老古董軟體（包含多個修補程式）共同運作的方式。根據各人的技能與創意，或許能建造出很多行精巧的程式碼，最終達成任務。但是根據這些精巧程式碼的長度與複雜度，可能只會創造未來的維護問題。或許還有更好的解決辦法。
如果你是軟體開發的新手經理人，別害怕讓開發人員探索新的語言與開發工作。賦予開發人員做研究的自由，因為這是發現創新道路、改善編程習慣與結果的方式。他們或許能為古董介面問題設計出更快速的軟體解決方案，需要測試與維護的程式碼行數也變得比較少。這對專案絕對是種優勢。
有些創新的程式語言可用較少行又穩固的程式碼，達成與現行語言相同的功能。其中價值在於較簡單的程式結構較容易測試、可以自我定義、儲存時佔用的空間較少、也較容易維護。
在組織內部，當然有人會對增加新的語言與平台產生疑慮。有人會擔心，新的程式碼是否真能在開發下解決現有軟體的問題，或加以升級呢？是否能與古董資料庫上一直使用的老軟體、公司內的使用者介面、公司做了投資的第三方軟體相互接合？團隊或部門中，是否有其他開發人員可以使用這種語言或這種平台來建立軟體？語言的作者是否提供了適當的產品支援？是否有及時更新與改善？
就算不太熟悉程式設計，也別阻撓程式設計師擁抱新語言。如果新語言的家譜可以蜿蜒上溯到 C 或 Java（或任何常用的工作完成方式），把新語言融合到現有習慣中大概會是相對無痛的體驗。
不過，請務必記錄在程式碼中的任何新習慣。否則程式相關的 code base 與文件可能有所分歧，結果造成瞭解系統的最佳方式就是自行研究程式碼。這種狀況被稱為軟體零件與系統 metadata 的「耦合損耗」（loss of coupling）。當文件不適合用於維護系統時，就該替換文件了。
鼓勵專案團隊裡的開發人員發揮創新能力，但不要聰明過頭反而造成過度複雜。任何一位程式設計師都可以試著聰明地強化工作成果的安全性，但專案經理人全都不會從中獲益。
太聰明的程式碼，最終都會難以維護。進而導致維護失敗，然後是耗資甚巨的軟體系統重建工程。
60/60法則
我們經常假裝「軟體的開發」是軟體生命週期中最重要的部分。關於開發，有著大量的方法論，各種書籍、雜誌與部落格專門討論。然而，開發，卻不是金錢所在之處。
軟體系統的生命週期中，總共有 60% 花在維護，相對較少的 40% 才是用在開發。當然，這只是個平均數。實際上，根據系統類型及部署環境的不同，維護成本可能從 40% 到 80% 不等。在維護時，平均 60%花在使用者引發的強化活動（需求變更）、23% 用於遷移活動、17%用於修補臭蟲。
軟體週期的 60% 用於維護，再加上 60% 的維護活動是與強化有關，形成所謂的 60/60 法則（60/60 Rule）──少數能在軟體維護中獲推薦為法則（law）的概念。
遷移活動包括把系統移到新的硬體或軟體環境。遷移，當然是需求變更的一種。把這個元素加到我們的估計後，即可發現一項有趣的事實：超過 80% 的維護活動都與某種類型的需求變更有關。
修改程式碼的能力，自然包含了理解程式碼的能力。在維護期間，理解即將進行的變更，即為主要活動；大約 30% 的維護時間花在「理解」某個現有的軟體產品。關於理解（understanding）的發展，適用於所有的維護形式，包括：需求變更、遷移活動，以及修補臭蟲。
理解，是我們在維護其他人寫的程式碼時、或維護很久以前寫的作品而記不得其中細節時，必須付出的成本。在維護期間開發大多數任務時，「理解程式碼」佔用了創新設計工作所找到的位置。
60/60 法則應該促使我們重新思考軟體開發，以及維護行動的重點。著重開發活動的傾向，不一定能產生最重大的收獲。Boehm 在 1980 年代早期所做的初步主張中，認為適當的軟體工程紀律最多可以減少 75%缺陷，這或許是真的（雖然我很懷疑），也成為開發方法相關理論的大部分基礎；但是，這又如何？
好的開發方式或許能減少臭蟲（維護行動中的 17%），但完全不能照顧到遷移、強化產品的時間或成本。想降低維護的成本，我們必須處理關於理解程式碼、為新需求調整程式碼、或許還要加上遷移程式碼到新環境等各種成本。
60/60 Rule 隱含了我們應該致力於建立可維護系統。我們的軟體必須為了改變而設計，如此系統在面對新需求時才有彈性。設計這類系統將是軟體工程學的下一個重大課題。
我們至少知道一部分答案。軟體組件之間的結合程度需要變得少一點，要更像全球資訊網的組件所結合的方式──盡可能到最後一刻再用有彈性的方式組合起來。
關於「網站開發」與「專案管理」－ 尺寸很重要
專案的尺寸、交付貨物的尺寸，還有核對清單的尺寸──專案中的一切都取決於尺寸大小。尺寸大小改變了遊戲進行的規則。
專案愈大（包括尺寸與複雜度），則專案經理人拆解專案為可管理模組，並把模組交貨的責任分攤到合適人選身上的工作就愈發重要。如此可確保專案成員、包括專案經理人，都能看到「專案整體」，而不會在偵察專案的健康數據時迷失在細節中。
分散式專案的尺寸通常大於其他專案類型；因此，專案經理人用以管理尺寸的策略，將實際影響到專案的底線。「大」，給人各式各樣的印象；可能表示 8 個人工作 12 個月的專案（如果是小型開發商），也可能是數百人規模的年度維護契約（如果是客戶的重要 IT 伙伴）。
關於如何劃分專案的正確尺寸，然後確保每個人都瞭解手中的一小塊拼圖如何構成（或毀壞）專案整體，我有幾項建議：
● 盡可能把專案分解成許多各自獨立，但可管理的 workstream（工作分組）。
● 確定每個 workstream 至少有一個負責交付成品的關鍵聯絡窗口。
● 如果情況允許，試著讓關鍵成員在 workstream 中擔任略有重疊的角色，使得不同團隊能共享「專案整體」的狀況。
● 分別追蹤每個 workstream 的進度（可使用任何工具），並定期聯繫出其中的規律，以感受整體專案的脈動。
● 分別記錄並分享每個 workstream 的風險、問題、假設與依存性。
● 組織定期的團隊會議，以分享各個 workstream 的狀態。
● 發表整體專案路程圖，涵蓋來自各個不同 workstream 的上市計畫。
● 積極使用線上工具分享使用者的需求、里程碑的更新、臭蟲報告、回報時間軸，以及風險。
例如說，你接受了為某網站建立三種版本的委託（北美版、亞太版、中東版）。你決定最好建立三個 workstream，各有自己的交貨聯絡人。因為三個網站其實是同一個網站，只是版本不同（遂需要中度客製化），有一些關鍵資源會在三個 workstream 間流動。如此一來，他們就可以確保網站整體的完備，並可建議重複運用實作時的細節。
另外的運用範例或許是有多個協作廠商的單一專案。理想狀況將是把各個協作單位（或可依關聯性）區分成不同的 workstream。如此各單位即可同步工作，或許能縮短交貨時間。每天請召集各個團隊開會，以協調交付貨物的整體素質。
別用試算表處理人際問題
你曾用試算表列出活動，以解釋自己在專案中的工作嗎？許多有經驗的專案經理人都試著把試算表當成管理與監控專案時的銀子彈。
Tom 是位資訊科技開發工程師，任職於一家大公司的線上部門。他所需服務的利害關係人團體超過四個。因為他不太擅長安排交付產品給不同利害關係人時的優先度，幾乎每週都會惹惱客戶，或讓對方失望。因為有太多委託要完成，而手邊的資源又太少，他總是身處不同團體間的衝突中心。
Tom 與他的團隊都是有天分的 IT 工程師，但是缺乏時間、以及管理利害關係人期望的必須技術，造成線上部門每個成員的困擾。解決方案？找一位經過訓練的軟體專案經理人，為 Tom 與他的團隊列出每週、每月或每季的交付標的，並安排優先度。
有了 PM，與各方利害關係人討論並安排交付標的優先度，變得較為容易。然後，評估所有內部客戶的優先度。如此一來，不只利害關係人能正確設定自己的期望，Tom 與他的團隊也能拿到時常更新的任務列表。他們可以專注於開發週行程表上最重要的項目，涵蓋所有專案。
讓這個計畫有效率的秘密，在於不是只用試算表列出各專案的交付標的。不僅如此，PM 透過讓利害關係人也加入排列優先度、決定最為重要或最有價值或最能產生利潤的特色與功能的過程，而且是根據 Tom能控制的資源（時間、金錢、人力）來決定，從而設定利害關係人的期待值。然後，根據線上部門其他小組的需求，各個團體都能從反饋得知本週可期待的工作量。為 Tom 的團隊規劃工作時，溝通是其中最有效率的成分，尤其是必須建立許多專案的優先度時。
或許 Tom 與他的團隊曾與利害關係人團體有過不好的專案經驗。有了這種方法後，這個被列為「黑名單」的團隊，即可持續完成工作，等待時間或更為積極的介入幫助癒合來自過往互動的裂痕。
歸根究底，軟體專案管理就是管理人際關係、以及「人」所牽涉到的程序。團隊間與競爭的組織團體間的人際衝突相當普遍。在理想、目標、價值觀、信念與需要上的差異，是重要的團隊強項，而不是弱點。然而，這些差異難免導致個人衝突，以及團隊間關於工作流優先度的衝突。
大多數衝突都是生產力與效率的大敵，解決衝突的方式若令眾人滿意，其實可以強化人際關係、促進有創意的變更，並改良成果。所有的衝突解決對策，都來自主動積極的溝通、聆聽、熱誠的瞭解，以及一些有效的協調，或許再加上一點仲裁。我們需要技巧成熟的軟體專案經理人──因為只用試算表無法解決人際的問題。
關於「管理專案」與「自我管理」－ 專案管理就是問題管理
在最好的狀況中，軟體專案的管理是種既有挑戰性又複雜的努力嘗試。不過，我經常看到 PM 對角色的期待錯誤，而使事態更為困難。
簡單來說，專案管理就是問題管理。若非如此，根本不需要專案經理人──要求執行後，所有零件（資源、技術、需求、時間表……）都會自動校正，工作將順利完成而不需要任何管理。
事實上，專案經理的角色之所以存在，就是因為現實並非如此美好。
資源可能分配過度、技術可能有所矛盾、需求可能不清不楚、時間表可能不切實際。
我所遇過的 PM 中，經常有人把這些問題視為外部力量造成的不方便、煩人的事情，或是「疑難雜症」，干擾到他們的工作。如果他人先做了某件事、如果他人先想到了某些狀況、如果他人還有更多時間……這一切不需要的複雜狀況都會消失，而「我」終於可以專心於專案管理的任務。
想當然爾，他們有很多時間覺得沮喪、緊張與憤怒。
安撫一切不需要的顛簸不平與複雜障礙就是專案管理的職責。我們的角色是做出更好的計畫、思考時更加清醒，而且比專案資助方與努力實現專案的人更具有良好的大局觀。
我們在這裡，是因為專案的執行原本就是一場混亂，而我們所具備的技能與性格，可確保不可避免的困難能夠正面擊碎、或迂迴規避、或「大事化小、小事化無」。
事態還可以更複雜，這些不只應用到管理專案的機制上。有時候，人也需要大事化小、小事化無。
專案中最有挑戰的部分，不見得一定是技術或時間，也可能是共同為專案努力的各方人士；可能是指派給專案的人力資源，也可能是某位資深的監管委員。
當然，如何處理在專案中可能遇到的各式各樣人際問題，這已超出了本篇該討論的範圍。至少，在這個領域中經常有管理問題的需要；而我們的專案管理職責範疇裡，管理問題與瞭解工作單位結構或維持準確的專案計畫是一樣重要的。
如果我們不把這些狀況視為完成工作時的障礙，而是更恰當地視為職務的核心，工作將更為順利、平穩，也更為安寧。當然這是相對於負面心態而言。（摘錄整理自本書）
專案管理人應該知道的97件事
──來自專家的集體智慧
Barbee Davis／編
莊惠淳／譯
歐萊禮出版
碁峰資訊發行
售價：400元
《作者簡介》Barbee Davis
MA、PHR、PMP，為PMI的《Community Post》撰寫半月刊載的專欄。她擁有一間Davis Consulting公司，提供訓練與開發工作室及諮詢服務。
熱門新聞
2024-04-15
2024-04-15
2024-04-15
2024-04-15
2024-04-15
2024-04-15
2024-04-15