讀書心得分享－是你選擇了憂鬱

觀察現今的社會現象，自殺與憂慮症讓許多人憂心仲仲，尤其憂鬱症是二十一世紀的文明病。曾經看了一本好書－《是你選擇了憂鬱》，剛好可為憂鬱及不快樂的現代人提供一帖良藥，在此與大家分享。接觸這本書的機緣，是由從事學校輔導工作多年，內人的介紹。她在工作上經常運用現實治療理論來助人，有時會與我分享現實治療的觀念。現實治療是在選擇理論架構下的實際應用工具，於是她推蔫我看這本書。其實現實治療不僅是專業的諮商理論與技巧，同時也適合一般人使用。面對關係的緊張與衝突，我們總是認為「如果對方能夠改變就好了」。但是本書告訴我們，問題往往就出在這裡；當我們習慣以我們認為對的事情要對方照著做，這種以 操控方式強迫別人做他不願意做的事情對雙方的關係的增進沒有幫助，反而會造成雙方關係的緊張，彼此的距離反而會愈拉愈遠，最後你就會感到無比地憤怒及憂鬱。除非你了解到你所能控制的只有自己，並放棄操控對方的意圖，你們的關係才有可能獲得改善。

對於關係的改善，這本書指引我們一些方向。 作者用簡單的觀念並舉出一些實際的例子來說明，在看完本書以後，深深覺得選擇理論有效而且實用。這個理論架構可以創造一個不批判他人、不控制他人的世界，透過選擇理論我們會了解到操控別人是不智的行為，外在控制只會造成關係的疏離而對問題的解決於事無補。我們能控制的只有自己，懂得尊重他人的選擇，我們將會擁有屬於自己的美麗世界！

屬於我們的美麗世界，存在於每個人心中的完美世界的圖像，也就是所謂的優質世界。每個人的優質世界不一定會相同，但這優質世界中會有我們想要在一起的人、想要擁有和經驗的事情及信仰觀念與遵循模式；所以當我們和特定的人在一起擁有、使用或經驗某些特定的事情，把 這些特定的信仰付諸行動，比其他人在一起或作其他事感覺要好多了。但如果放入優質世界的人想要操控我們，要我們去做我們不想做的事，我們就會與他慢慢疏 離，就會造成關係的緊張與衝突；最後我們會選擇把對方的圖像從優質世界中移開，通常下這樣的決定是痛苦的，但那也代表彼此關係已經很難挽回了。

我們須掌握住「你的行為會造成雙方距離疏遠或拉近？」的原則，才能與身邊的人維持親密的關係。我們唯一能控制的只有自己的行為，關鍵就在於我們到底願意為增 進彼此關係做什麼樣的努力？過去我們習慣一味地問自己的感覺、指責對方的不是，但卻忘了面對真實的現在，雙方要有共識：關係的改善是現在最重要的事情，然 後共同面對問題想出解決之道。問題可以解決並是不在於別人該做什麼，而是在各自雙方願意互相妥協做出讓步。當雙方都了解到「你唯一可以控制的只有自己 時」，兩個人就處在「解決圈圈」中了，也就是葛拉塞博士對各種關係的改善所提出的實務方法。

憂鬱，我們都知道是因為我們的生活出了問題，當問題造成壓力使我們無法承受時，我們就會感到無比憂鬱。但葛拉塞博士告訴我們，憂鬱是可以選擇的！你的憂鬱的源頭來自於關係的不滿足；如果你與周遭的人 際關係無法得到滿足，身心系統的創造力便會介入，讓你感到生理或心理上的不舒服，於是我們選擇以憂鬱或疾病的方式逃避面對問題或藉此壓抑我們心中的憤怒； 但如果我們關係課題可以獲得妥善解決後，困擾我們的身心疾病就會迎刃而解，這本書舉了夫妻、親子、學校及工作職場中的許多實例，淺顯易懂，非常值得我們多 加學習及參考運用，如果能夠熟練選擇理論的觀念和技巧，適時地予以推廣，相信可以讓我們的世界充滿了愛、自由與樂趣而沒有憂鬱。

好書推薦

書 名 《是你選擇了憂鬱－善用選擇理論改善婚姻、家庭、學校和職場關係（Choice theory – A new psychology of personal freedom）》
作 者 威廉．葛拉塞(William Glasser,M.D.) 曾璿憓譯
出 版 者 商業週刊出版，城邦文化發行
出版年月 2003年4月

摘要

本書作者威廉．葛拉塞(William Glasser, M.D.)是美國南弗羅里逹州的心理學家，同時也是《現實治療》（Reality Therapy）暢銷書的作者。他深信人們的衝突源至於想操控他人的迷思，但實際上人們能控制的只有自己，沒有人能強迫他人做不想做的事。唯有放棄想要他 人按照自己的想法照章行事時，我們才可能過自己想要的生活。

威廉．葛拉塞認為「良好的關係對成功的人生非常重要」，他主張我們會煩惱及憂 鬱多半來自於「不滿足的關係」所造成。這本書探討不滿足關係的成因及如何做才能和別人的關係達到和諧，討論如何在夫妻關係、親子關係、師生關係、上司下屬關係都能大幅改善，使人類進步能跟上科技進步的腳步。

對專案假設的看法

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

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

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

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

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

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

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

創造 software review 的需求

鳥毅想要說服主管推行 review 的計劃，喲哪桑學長提了一些建議可以供鳥毅參考，不過我認為要說服主管不是一件簡單的事，如果沒有樣學長那樣的辯才無礙，反應敏捷，可能很難畢其功於一役，不過這個 argument 倒讓我想起了丹娜左哈爾的服務型領導者的概念，也就是仰賴機會與才能不如創造內在需求。

記得在多年前在做李國光老師所教授的策略知識管理課程的期末專題報告，題目是某科學園區的實務社群時，過程中學到一個重要的觀念，就是推行任何的計劃，與其告訴別人他需要什麼東西，不如創造他的需求。這真是一個 key point，對於工程技術背景出身的我而言，向來習慣先提出解決方案，結果常常費盡了唇舌，卻還沒有辦法讓人家採納我們的意見，甚至造成許多不必要的誤會。因為我們不知道對方真正的需求，卻天真地以為我們的解決方案可解決一切問題，我們所做的只不過是誘導對方採納我們的意見而已。

因此，要成為（being）一個服務型領導者，必先傾聽對方的心聲，要先清楚問題是什麼，才可能發展出正確的方法及解決方案，具體實施以求成效（doing）。先把推行 review 計劃放一邊，運用兩大招式，第一招是心智互動，運用(O)觀察－觀察對方的觀點與我有何不同。(A)評估－評估為何會有這樣的不同。(D)設計－根據評估設計出如何改進自己的心智模式。(I)實施－根據設計實施改進心智模式；第二招是知識轉化，即運用知識螺旋－社會化、外化、組合化及內化由他人身上取得問題的知識，並且用 3K1C 來思考問題的不同層次：先思考問題的關注焦點（Care what）及所需形成之概念（Know what），以打破框架，然後才是掌握解決方案的流程（Know how）及理解其原理為何可行（Know why），以落實常規。 我想這些是現在可以做的事。

對於一個軟體開發組織，是否採用某個流程其實與其軟體品質文化有關，對於一個開發流程未慣例化的組織而言（即未達 CMMI ML2），推行 review 可能會遭受極大的反彈；而對於一個開發流程未針對現況做回饋控制的組織而言（即未達 CMMI ML3），review 的推行可能比較徧向形式審查而較少的技術審查或 peer review。然而，做不做 review 不應把它視做是一種軟體流程的道德性問題，而是應該思考它對組織所要解決的問題及客戶的要求有多大的影響，如果推行 review 時候還未到，不妨坐視開發出來軟體的功能失常，等到它們實在多到令人窮於應付時，主管就會來找大家想辦法，到時自然有人會比我們更積極呢，正所謂道可致而不可求呀。

資訊系統設計的盲目

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

我看到電視的訪問，大部分的考生都對他們自己的解決方案很有信心，有考生說他設計了一個演算法可以解決這個問題，然而卻沒有看到有人對問題做深入的探討，大概以為問題非常明確－不能重覆訂位，然而造成重覆訂位的因素是很複雜的，這些才是真正的問題所在，如果不了解問題，如何能設計出符合需求及適用的系統呢？沒有問題卻可以有解答，這正是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)