對專案假設的看法

在哈米尼斯的天空看到〈專案管理：Change Management〉，作者提到軟體專案 change management 的重要，而對於專案無法掌控的部分，引用《與熊共舞》這本書所說的可以向上丟給 sponsor 或運用專案假設來限制它。但喲哪桑學長卻認為：

「不要被自己的假設所矇蔽，也不要被其所愚弄。記住，所有的假設在被證實之前，假設既不是對，也不是錯。假設，就只是假設而已」。

我蠻認同學長所說的。沒錯，假設往往是風險的主要來源，在專案風險管理中，最簡單而且最常拿來做風險分析的工具便是敏感性分析，它是用來評估當專案的假設與限制改變時，對專案的影響會受到多大的衝擊。所以不能過度依賴假設，假設是需要被管理的呀！

哈米尼斯的天空的這篇文章的作者還認為專案假設事實上是比較徧向法律層級的一種手段，這與PMI 對假設的定義很不一樣，PMBOK 2000 版中提到：

假設是因應專案規劃而生，其被認為是真的、實際的或確定的事情。假設會影響專案規劃的所有面向，並且是專案逐漸細化的一部分。專案成員常常把識別專案的假設、並將之文件化及驗證它們是否仍然成立當作是專案規劃過程的一部分。

由上面定義我們可以發現，其實專案的假設是無所不在的。而徧向法律層面的手段，看起來比較像專案限制，亦即影響專案成果所適用的約束，一般而言，專案合約書的條款就是一種合約的限制。在專案規模定義過程時，必須列出與描述與專案規模關連的假設及當它不成立時所造成的專案衝擊，也必須列出與描述會限制專案成員意見的與專案規模關聯的限制（PMBOK 3rd）。所以不管是假設與限制都是在規劃過程中的產物，而不是只是為了拿來和客戶對簿公堂的武器。要用它們來防止對方翻案、改變需求，那是非常不切實際的，專案成功是雙方的成功，沒有互信為做基礎，專案再怎樣都不會得到善終的，所以，變更需要管理而非凍結。

至於 change management，做好 change control process，可以參考我之前對軟體專案變更控制的看法，簡單的說，就是一定要先評估對專案的 triple constraint 的衝擊，然後要確認變更是有正面的影響，而且影響變更的因素已發生，最重要的就是好好地管理變更。

資訊系統設計的盲目

近日在電視看到一則新聞，台大研究所考題有一題是「為高鐵設計一個不會重覆訂位的訂票系統」，許多考生都認為這個考題很簡單，甚至有人認為這是所有考題中最簡單的一題。

我看到電視的訪問，大部分的考生都對他們自己的解決方案很有信心，有考生說他設計了一個演算法可以解決這個問題，然而卻沒有看到有人對問題做深入的探討，大概以為問題非常明確－不能重覆訂位，然而造成重覆訂位的因素是很複雜的，這些才是真正的問題所在，如果不了解問題，如何能設計出符合需求及適用的系統呢？沒有問題卻可以有解答，這正是NPS（No-Problem Syndrome）－沒有問題症候群（Gerald M. Weinberg，1986）的心態在作祟，因此，看到這則新聞，讓我不禁搖頭嘆息。

我不知道出題教授要考的是什麼，但以多來資訊系統開發實務的經驗來看，這一題並不簡單。舉例來說，高鐵售票系統專案，並未使用資料庫技術，所以根本不能用資料庫的技術來設計系統，所以用什麼 unique key、lock 或是 database transaction 都對問題解決沒有幫助。在你不了解問題的情況之下所做的設計將會是無效的，也就是說，在提出解決方案之前，別忘了要先找出專案的假設與限制，這是發展複雜系統專案所不可或缺的。

以工程技術（engineering technology）觀點，資料庫可能是最佳解決方案，然而資訊系統卻是社會技術觀點（social technology）下的產物，所以必須考慮專案不同 stakeholder 的期望與興趣，大部分的情況下，你只能尋求最適解，也就是說問對問題才能讓你找到有用的解答呀！

Software inspection 不是只有檢驗而已

看了喲哪桑學長寫的〈誰來檢查code?〉，又看了相同主題的「多人大辯論」，心中感觸頗深，大家的論點都圍繞著用 software inspection 來找出程式的 bug ，但這其實並不是 software inspection 的最大價值，因為 software inspection 不是只有檢驗而已呀！

雖然 software inspection 可以發現程式碼的 defect，但它卻不適合拿來做 QC，為什麼呢？因為用 software inspection 來 QC，其實是在殺雞用牛刀。software inspection 的主要目的是促進 team member 共同成長，不要被 inspection 的字面意義誤導了，切記 software inspection 的過程比結果還要重要。

以 TQM 的觀點來看，品質不是檢驗出來的，而是不設計出有缺陷的系統，然而不管你的設計能力有多強，都不能保證我的設計絕對沒有問題，因此在這種思維下，全員參與是一個好主意，因此讓同僚參與 review 工作產出可讓系統更完善，一來可以用比較客觀的方式來確認設計符合需求及使用者需要，二來也可以讓同僚更清楚我們在做什麼，相互觀摩學習並增進團隊的效能。

所以 software inspection 是一種 QA 的過程而非 QC，亦即它除了重視軟體的產出之外，更重視產能，也就是柯維在《與成功有約》中提到產能必須要與產出平衡。只重視產出而不重視產能，不管開發組織中那個技術最強的人能力有多強，開發過程都會遇到瓶頸，因為所有的產出都要先經過他的 review，他會變成開發系統最大的限制點。

換個角度來看，重視 team member 的產能，review 他們的產出之真正目的在於為了使他們相互觀摩並促進學習成長的良性循環，團隊效能可以不斷提昇及成長，效能提昇了，自然會有更有效率的產出。

Software inspection 並不能取代任何的測試，做 software inspection 之前必須先確認這個程式是可以運作的，已經過測試的，所以不可能藉由 software inspection 靠別人幫你捉 bug。而在 software inspection 會議中，向專案經理、 QA 及 Observer（其他同僚）介紹你的工作產出，而這些與會人員則會 review 你的作品，針對組織或專案各種開發規範及慣例、可讀性、完整性及是否有潛在問題提出看法。review 的時間以不超過 2 個小時為限，而 review 的結果除了成為要求品質改善的表單外，還可以當開發過程中的 lessons learned，誠如我之前在〈軟體開發的團隊綜效〉中所提到的：

記得我在《軟體開發能力的自我組織》中 一文曾提過的：「專案實施 inspection 時，成員的設計能力及 software asset 變得與日俱增，而且在團隊溝通上助益也很大」，就是一種共用件的有效運用，inspection 本身就是一種增進軟體品質的一種共享程序；同時 透過團隊相互觀摩的良性循環，讓有經驗的開發人員分享設計與開發技巧，而達到共享人員的目的；最終的目的其實是要慢慢地形成如 William 所說的軟體資產（software asset）的目標，這不正是共享元件嗎？

開發組織面對規模不經濟，管理能力的改善才是致勝的關鍵，而管理策略採用共用件正是為了去除不必要的複雜度，software inspection 正可以達到這樣的目的。子曰：爾愛其羊，我愛其禮。許多人認為他們沒有時間去做 code review，但它對軟體品質卻有報酬遞增的效果，如果你希望你的開發團隊可以把穩軟體的方向，software inspection 是不可或缺的呀！

Stakeholder 意見太多怎麼辦?

最近我們家那台 Web Server 罷工了，本想關機讓它休息一下，也好讓我們可以有個安靜的睡眠環境，沒想到關了機就開不了機了。不過看了學長所寫的〈Stakeholder 還有誰?〉之後，也想提出我的看法與經驗，於是就在這邊發表第一篇文章。學長提到：

那些不希望專案成功、甚至會扯你後腿的 stakeholder，該如何處置？難道說，大家都這麼走運，遇到的人都希望你的專案成功嗎？

這是一個關鍵問題，也常出現在 PMP 認證考試的考題中，它的標準答案是請 stakeholder 涉入（involve）專案的規劃（planning）。涉入（involvement）是一種心理狀態（a psychological state），而參與（participation）則是具體表現的行動（action）（Daniel Robey　1994）。邀請對方涉入然後讓他參與規劃代表我們重視他的意見，仰賴他的能力，而這正是 team development 過程的目的，讓 stakeholder 貢獻其所長，key stakeholder 的參與可以提昇其滿意度而降低專案風險，可說是最好的做法。

不過，在實務上，要讓 key stakeholder 參與規劃卻要用些技巧，尤其是當牽涉不同的組織時，感受到跨越到不同 boundaries 時，我們會發現因為對專案有不同的期待與目的時，對方可是不太容易會積極參與的，其中最大的問題就是交易成本太高，因為信任必須承受風險，Stakeholder 心中可能會出現以下的聲音：

那是你們應該做的吧，我可不願幫你們背書，到時出問題又說是我的意思！

沒有互信基礎的伙伴關係就會演變成這種結果，而在這種情境下，要解決問題只好運用政治權力去 forcing 了，結果「表面上贏了實際卻輸了（出自電影美夢成真）」，有機會對方還是會不斷扯你的後腿的。

所以，關鍵在於雙方的互信基礎，要贏得對方的信任需要日積月累，但要破壞信任關係卻只在一念之間，所以專案管理技術的硬工夫（外功）並不難，真正難的是衝突解決和溝通能力的軟性議題（內功）呀。行文於此，突然想起吳宗成教授說過的，要練就要練內功的至理名言，所謂天下同歸而殊塗，一致而百慮！

參考

1. Daniel Robey, 1994, "Modeling Interpersonal Processes During System Development: Further Thoughts and Suggestions." Information Systems Research, 5, 4 (1994)