假如上面的話是成立的，那麼代表只要徹底重構系統就不會造成「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」嗎？如果是這樣，那 XP 根本就不需要 Refactoring 這個實務來改善程式的結構，因為你都徹底重構程式，程式結構變差的情況是根本不可能發生。

而且依照本人 20 年來軟體開發的經驗，我還不沒有看到有程式一開始就寫得很好，到後來可以不用改變架構而符合新需求的。倒是隨著對問題的更清楚，或是程式需求的變化，讓程式必須重構的現象時常履見不鮮！

所以如果自以為自己博覽群書，很懂得TDD的實務。也不要忘了用心思考，以免自己對TDD的最佳實務的認知，不小心犯了根本上的邏輯繆誤？

結果，後來同人在 Facebook 的 Scrum community in Taiwan 看到 Steven 做了以下的回應：

先說件簡單易明的事情，其實我很不喜歡閣下把 TDD 放到 『精神』 層次，卻忘記了基本步驟。

之前的討論根本連事實層次都被忽略，根本談不上是什麼多少年的經驗或者如何用心思考，連 TDD 的最基本步驟也忘記，TDD 的基本步，不是閣下做多少年工作就可以把人家的定義去改變的，我也不明白為何有 20 年工作經驗就可以把 『Refactoring』 說成 『並不必然是 TDD 的必要的步驟』，這不是邏輯問題，更不是有過什麼開發經驗然後用心思考就可以改變的事情，這是就算對軟體開發的認知不夠閣下那麼 『全面』 的都能看出的謬誤，如果閣下這樣就認為是因為說不過閣下就建議多看書本，本人深表遺憾。

我是來討論問題的，我沒有興趣去傷害閣下感情，好好閱讀書本，只是反映 TDD 三個步驟是什麼根本不存在爭議，更沒有 『好好閱讀什麼書或文章才能跟我討論』 的意思，我還未自大得要別人看過多少書才可以討論問題，亦正如討論問題我也不用跟別人說我有多少年工作經驗一樣，而且本人是衷心認為多讀書是有益的（不管是閣下還是什麼人），多讀書亦不是為上來辯論的，不過閣下如果感到有所不悅的，我就先行道歉，還是希望冷靜一點討論問題。

而簡單的例子也是思辦的過程的一部份，一方面是簡單易明地討論問題，另一方面是如果連簡單的例子也說不通，又怎麼能去談更複雜的問題呢？

上面提到：』那XP根本就不需要 refactoring 這個實務來改善程式的結構，因為你都徹底重構程式，程式結構變差的情況是根本不可能發生。』

不如冷靜一點再讀讀這句子，』XP 不需要 Refactoring 是因為徹式地進行 Refactoring』，我就看不明白這是什麼邏輯，一邊說不需要，另一邊說徹底地進行。

這裡的問題是軟件是會改變的，可能是新增功能，也可能發現有其他問題，每次帶來的變更其實都需要進行重構的。所以說 XP 不需要 Refactoring 也不正確。

世上的確沒有一寫就好的代碼，而且世界是會變的，Refactoring 就是避免以後的更改越來越困難。把 『徹底地進行重構』 理解成 『XP 不需要重構這實踐』 完全沒有邏輯可言。

我也沒有反對不用改變程式架構就能滿足新需求，亦沒有否定 Refactoring 的重要性，只不過我還是建議新的功能以 TDD 方式進行開發，有測試、有代碼、然後進行重構的。

在足夠測試覆蓋下進行重構是可使系統在不斷演進及需求不斷改變之下，使架構或設計仍然處於可以維護的狀態，相反我指出的是，如果程式架構和設計越來越難維護，是重構的力度不足夠。

前面還提到：』但重構的目的為何？就重構的定義在不改變功能的情況下改善程式結構，以增加程式碼的彈性以利未來增加或改變功能。因此如同那第三步所言，為了去掉重覆性而重構。』

如果重構只是為了去掉重覆性，那 TDD 的第三步不如叫 『Remove Duplication』 好了，無可否認代碼重覆是很常見的問題，但把這裡的重構限制成消除代碼其實會局限系統的將來發展，而且到了 TDD 的第三步，系統是應該有足夠的測試去覆蓋系統，重構的力度沒理由只局限於新增功能和現有程式的重覆。

我就相信閣下是 Refactoring 的專家，也應該會知道一些 Refactoring 的模式是完全相反的，例如 『Pull Up Method』 和 『Push Down Method』，更是需要觀察當時的情況來作決定，而沒有一面倒那個才是好的模式，我實在不明白為何要把 TDD 的 Refactoring 局限到只做 『去掉重覆性』。

這是實務上會發生的事情，消除代碼重覆以外的重構還是會發生的，如果只是單單只是 『消除重覆』，這會是另一個我認為進行重構不夠徹底的事情。

上面已經不單單是用心思考，而是由理論到實踐都可以看得到的事情。

跟討論 Refactoring 和 TDD 觀點以外的聲音，就引用 Chet Henderickson 的說法，全部都是我錯好了，現在可以解決問題嗎？

看了 Steven 的回應，同人當下的反應是不想浪費時間與心力與他周旋下去，但後來想到或許是因為 1/9 敏捷開發分享會我要分享實施 XP 的經驗與心得，也許這是一個巧妙的同步事件。我可以趁這個機會，導正對 XP 或是 Agile 的一些錯誤觀念。

例如敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但一些詞句有略為做過一番修飾，以清楚表達我對測試驅動開發步驟的看法。

呵呵，Steven Mak 的回應很有趣，把別人說成錯的不代表自己就是對的。這跟他先前面對觀點的差異就要人好好的看書的行為是如出一轍，但問題是要別人好好看書也不代表說這句話的人書看得比別人廣泛或是深入。更何況，看很多書是一回事，有沒有讀懂書中作者所傳達的意思又是另外一回事。從 Steven 喜歡用斷章取義的方式解讀我的觀點，以抽取他想要的意義來看，恐怕他看書的目的只是揀選他要的部分，沒有弄懂作者想要傳達的意思的可能性可能居多吧！

對了，我忘了 Steven 的中文可能不夠好，沒辦法弄懂我所表達的意思。如果是這樣，他其實大可以告訴我，我不會叫他去好好地學中文，或是嘲笑他那麼簡單的句子都看不懂，而是想辦法要怎麼表達才會讓他了解我的想法。省去他猜錯我的意思，而顯露出他並沒用心體會或是根本不想思考別人的觀點的窘態。

當然，以上的假設可能是不成立的，他的中文其實很好。但如果是這樣，他的邏輯思維能力真的要加強，因為思考為什麼是最基本的能力，不是什麼經神層次。

記得去年同人應邀到中山大學演講，有機會與鄭炳強教授在餐敍之中交流軟體開發的觀念。他特別強調軟體工程最重要的不是 know how，而是 know why。因為遇到不同需要而要採用適當的方法，唯有具備 know why 的能力才能做到。以 Steven 那麼重視看書來增加知識的態度來看，他應該也很重視軟體工程的學界權威的看法吧？可是如果鄭教授看到 Steven 把 know why 的思維定位成精神層次，我想也很可能會令他很搖頭吧！

回歸正題，Robert C. Martin 在《敏捷軟體開發》這本書（林昆穎，吳京子，2005）中提到測試驅動開發法，他說：

所有的產出的程式碼都是為了讓失敗的單元測試通過而編寫的。首先，我們先寫一個單元測試案例，由於它所要測試的功能並不存在，所以它不會通過，然後我們再編寫程式碼，使得測試案例通過。

編寫測試案例與程式碼之間的反覆來回非常快速。只花費一會兒的功夫。測試案例與程式碼一起演進，而測試案例會比程式碼更早一點。

結果，一組非常完整的測試案例隨著程式碼一起增長，這些測試可讓程式員檢驗程式是否正常運作。如果有一組小搭檔做了些小修改，他們可執行這些測試案例，以確保修改並未對程式碼造成任何破壞。這會極有利於進行重整。

咦，堂堂一位敏捷開發大師級人物，怎麼他也沒提到 TDD 要重構，只說可以有助於未來的重構，難道他也擅改了 TDD 的步驟了嗎？讓我們看另外一本書。點空間的朱子傑和陳盈學翻譯的《The object primer 3/e 中文版－靈活模型驅動開發與UML2》中有更具體說明TDD的步驟，而且還附了流程圖（有興趣自己買書來看）。

1. 快速地加入一段測試，基本上只要能夠測試一段程式碼即可，此時你的測試結果會是失敗的。
2. 執行你的測試，一般是全部的測試套件（test suite）。有時候為了速度上的考量，你可能只決定執行這一部分的測試。目的是確認新的測試結果確實是失敗的。
3. 更新你的功能程式碼，使得測試可以通過。
4. 再次執行你的程式。
5. 如果測試還是失敗，再執行步驟3。
6. 如果通過測試，便重新開始（此時若有重複的程式碼，你便需要重構你的設計）

上面的步驟有提到重構，但也提到重構的前提是如果有重覆的程式碼才要重構。那如果沒有重覆程式碼，那還需要重構嗎？還是如 Steven 所說，去除重覆的程式碼的重構還是不夠徹底的重構？

答案很顯而易見，TDD的步驟本來就沒有規定一定要重構。事實上，重構對有經驗的開發者就是像吃飯或喝水般如此直覺，在開發程式的過程中，諸如像改變函數或變數的名字讓它們變得有意義或容易了解，一段重覆被呼叫的程式碼把它們提取成函數或類別。他們經常無意識地去重構，但有意識地面對他們開發過程所遇到的問題，諸如程式碼的重覆或不易了解等問題，而不是漫無目的的為重構而重構。

是以在開發功能的程式碼，因為編程手法的熟練，重覆碼根本就不存在，難道還需要一個重構的 process 嗎？由此可知，Steven 的徹底重構之說，其實就是邏輯上所謂的以偏概全，用部分的事實擴大到全面性的觀點。但真相是 TDD 未必要進行重構，除非你需要它。所以這當然是邏輯的問題，其實從我指出他邏輯的矛盾之後，他的反應更顯出欠缺邏輯的思辨能力。

不如冷靜一點再讀讀這句子，』XP 不需要 Refactoring 是因為徹式地進行 Refactoring』，我就看不明白這是什麼邏輯，一邊說不需要，另一邊說徹底地進行。

Steven 上面的質疑乍看來似乎有道理，但仔細看看，原來他把時間的因素拿掉了，有偷換觀念的嫌疑。我原先的說法是說因為先前徹底地重構，所以未來就不需要重構了，被他偷換成一邊說不需要，另一邊說徹底進行。

照他原來的邏輯，如果先前徹底重構的程式碼到後來還需要再次重構，那原來的重構還能叫徹底重構嗎？我們常看到有些人會在問題發生的時候，會說因為別人寫的程式碼出問題，是因為沒有徹底的重構，但在明眼人的眼中，這種說法可以用台語說「出一支嘴」！要嘛有徹底重構先見之明的人，你就再一開始就告訴大家什麼叫做徹底的重構，保證以後不會出問題，省得以後出了問題再說重構不夠徹底，後見之明說重構不夠徹底，這種說法誰都會說但卻根本做不到！

更何況重構的方法有好幾種，決定該怎麼重構的時間還沒到，如何徹底重構？或許有人會想依據未來的預測來徹底重構，但這樣想的人大概忘了敏捷方法是不進行預測的，只有因應現實而改變。

蘇格拉底說：「事情的好壞不重要，重要的是你的想法和看法。」本來針對事情來討論是一件好事，目的是為了思考彼此之間的差異點而獲得成長。無奈 Steven 一開始為了捍衛他的觀點，就針對和他觀點不同觀點的人，拼命強調同人說 TDD 不必然需要 Refactoring 的觀念是錯的，叫我要多看書暗示我不夠用功，其實這樣的行為模式突顯他面對意見紛歧沒有反省思辨的能力。

至於同人提出邏輯思辨的想法就叫做精神層面的說法，同人只能說這其實表現出 Steven 自以為是的「自我感覺良好」，運用修辭技巧閃來閃去還是難逃嚴謹的邏輯批判。他要表演這些同人其實沒什麼意見，他可以繼續活在他的象牙塔之中。但對於同人而言，我的收穫只是多看到一個負面教材，這對我 1/9 敏捷開發分享會的聽眾和閱讀我文章的讀者來說可是一大貢獻呀。Steven 說他不小心傷害我的感情；呵呵，少來了，不禮貌與不尊重的行為代表他不夠理性，只是顯出他的無理而已。

…here’s what we do: we drive development with automated test, a style of development called Test-Driven Development(TDD). In Test Driven Development:
* Write new code only if an automated test has failed
* Eliminate duplication
……

The two rules imply an oder to the tasks of programming.
1. Red – Write a little test that doesn’t work …
2. Green – Make the test work quickly…
3. Refactor – Eliminate all of the duplication….

Red/green/refactor – the TDD mantra

在這段敘述中，Kent 認為 Red/green/refactor 是 TDD 的三字箴言，是 TDD 這個 practice 重要的工作。

所以 Steven 才會強調在做 TDD 時，』測試是第一步』，』Refactoring 本身是 TDD 三步之中其中必要的一步』

假如正如 David Ko 所說，測試與 Refactoring 是 TDD 很重要的一環，而來強調 TDD 不應該忽略 Refactoring 的工作，這樣的觀點我可以接受，但同人隨後又看到 Steven 的說法，覺得他自以為是的論點讓我很遺憾。

本人從來沒有指出 TDD 是測試 Practice，亦沒有認為測試是 TDD 的目的。

上面的 『功能』 指代碼的內容規格，寫測試時候就是思考新功能的行為，用測試用例的方式去表達出來。就正如：

AssertEquals(3, add(1,2))

那麼簡單，已經是對 add() 作出規範，投入兩個參數，輸出一個數字作結果，並規範了新 fn 的名字是 『add』。寫這句 Assert 時候就應該思考到 add 有兩個參數，投入 1 和 2 就會得 3 這個數字。

重構是 TDD 其中一步，不存在混淆點，再者，沒有測試覆蓋下的根本不能說成重構；另一方面，先寫代碼後補測試是很痛苦的事情。

如果像閣下文中說：「系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護」，我則認為是在進行 TDD 時候沒有徹底去重構系統。

我建議閣下好好閱讀 TDD 的書本，Refactoring 是 TDD 必需的步驟，由 Kent Beck 到 Robert Martin 以至其他不太有名的 TDD 書本作者，都指出 TDD 的第三步是重構，而不是 『Refactoring 並不必然是 TDD 的必要的步驟。』

看到「我建議閣下好好閱讀 TDD 的書本」這種不尊重不同觀點的說法，同人根本就不想浪費時間來跟對方爭論。即使耐著性子仔細看他的論點，像那些「沒有測試覆蓋下的根本不能說成重構；另一方面，先寫代碼後補測試是很痛苦的事情。」、「如果像閣下文中說：『系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護』，我則認為是在進行 TDD 時候沒有徹底去重構系統。」等說法，更讓同人懷疑他對 TDD 的認知，其實是過於偏向理念化而不夠切合實際。

不過，對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 的 Scrum Community in Taiwan 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼代表一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
—————————————————————————————————
柯兄，

我想在點空間，您應該曾看到我與某些只談理論忽略實際的顧問級大師論戰吧？即使當時我和他私下交情還不錯，但看到他用簡單的例子把軟體開發化約成不需要研究 how，或系統分析不需要懂領域知識的觀念，就不得不告訴他，他對軟體開發的認知是不夠全面的。這次對 TDD 實務的分歧點，我想也是差不多的情況。

只不過我不喜歡』我建議閣下好好閱讀 TDD 的書本』這樣的說法，在實務上我看過太多空談理論而不懂思辨問題的人，這種自以為是的論調讓我不想浪費時間回應他，但以下針對柯兄所提來說說我的看法。

單就字面來看，測試是第一步，重構是最後一步，看起來是沒錯，但問題是為什麼呢？測試先行我想應無疑義，我文章也談了很多，在此不再多說。但重構的目的為何？就重構的定義在不改變功能的情況下改善程式結構，以增加程式碼的彈性以利未來增加或改變功能。因此如同那第三步所言，為了去掉重覆性而重構。

但為什麼需要去掉重覆性呢？答案不外乎兩種，一種是日後重覆性造成程式維護的困難與增加錯誤機率，另一種是程式員擔心發生以上的現象或是因為個人對程式設計的信仰所致。

第一種狀況的重構是合理的，因為開發者是針對現實來解決問題；第二種狀況的重構很常見卻不見得是應該被鼔勵的做法，因為開發者是針對理想或信仰來行動，卻不見得符合實際的需要。但這兩種狀況都可以用重覆程式碼的壞味道的概念來合理化重構的行動，所以重構是正確的行動嗎？答案是視情況而定。

一些 TDD 的書籍或教本所舉得例子都很簡單，使得每一步驟都顯得理所當然。但真實的專案真的是這樣嗎？但個人當初在導入 XP 實務的時候，所遇到的困難，都沒辦法從那些書中得到答案，而是要親身體驗；書中教你的 what 其實需要你實施後的 how 及 why，才能更為全面把那些實務做到好。

最後，提一提測試涵蓋面的問題。在我還沒實施 TDD 的時候，當時我很肯定 TDD 的方法，但我想到的問題是測試程式要寫到什麼程度。但等到我開始實施 TDD 的時候，才發現測試程式的涵蓋面根本就不是問題，而是你需要 test driven 幫你做什麼。如果問題具體而明確，那那會有涵蓋面或不涵蓋面的問題？這時，才了解 Peter Ho 及盈學兄當年在點空間說過 TDD 不是測試而是設計的手法。還有那三句擺在我心中的經典名言：

Without refactoring, there is no room for plugging in new functionality to adapt the coming force.

Without testing, we couldn’t know where the edge is.

Without integration, the spark of life will die out.

一點淺見，供參考，但我絕不會叫別人好好閱讀什麼書或文章才能跟我討論…

我常在做的 『教練』 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 『一致性』 , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 『教練』 已經離開工程師角色一段時間, 這又是另一個挑戰

同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。

而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。所以是管理能力的不足而非技術，也是我文章著墨於領導觀點重於技術觀點的主要原因。

對於領導，MaoYang 認為最好的領導是當顧問而不是教練；他提到工程師可以自己發現問題，來請教 『顧問』 ，當然如果工程師都看不到問題，那麼就另當別論。MaoYang 還提到他很欣賞上次 David Ko 在敏捷開發分享會提到的經驗；團隊主動提出要使用 Scrum，這時候身為經理的 David 只要做順水推舟的工作即可。

不過同人倒是認為，David Ko 的經驗是可遇不可求的。同人的經驗顯示，在台灣的軟體開發機構，是很少經營者有願意改變的胸襟與勇氣，即使有些老闆在口頭上說改革，但骨子裡卻是很畏懼改變而使所謂的改革只是流於表相化。

MaoYang 提到他在職場現實看到的一個現象；他說我在文中提到教練最好可以不給答案，而是提出問題讓工程師去思考。但是他在現實職場看到的是一堆人在揣摩老闆在想什麼？要怎麼做，老闆才會滿意？因此有時候他反而不太喜歡這樣的領導模式。同人覺得 MaoYang 這段說到重點了，但為什麼會形成這樣的企業文化呢？

MaoYang 說他覺得在中國人的企業都會有這種問題，這是為什麼 『雍正王朝』 被列為某些企業的管理教材。在雍正王朝裡面一堆這種範例，沒有正確答案，正確答案在主子的腦袋裡面。 這種文化要改，可能是領導者的腦袋要先改。

然後 MaoYang 還分享後來他想到他說技術經理下來當教練是不得不，意思是說理論上應該不用走到這一步，問題出在當初找人時，沒有嚴格把關，沒有找到對的人。他還提到 《Peopleware》 裡面也有講要如何 interview 工程師，所以《從 A 到 A+》裡面也有講企業要成功，要找到對的人。所以他認為技術經理當教練的徵兆對一家公司其實是不太好的，技術經理應該去看前瞻的東西，而不是當一名 『教練』。

其實同人很同意找到對的人來做事的想法，但事實上這卻是不容易做到的，尤其是軟體開發工作的專案，更難以找到對的人來做事。這種困難包括兩種情境，一種是找不到合適的人才來執行任務，另一種是把真正的人才放到不正確的任務上。

第一種情境雖然很常看到，但經常也可能是技術經理沒辦法慧眼識英雄或因材施教，而使好的人才淪為的犧牲品。在這種情狀下，其實問題不在找不到人才而是經理人本身領導或管理的問題。寫到這裡，我想到溫伯格在《第一級評量》講的一句話：沒有不好的士兵，只有不會帶兵的將領。

所以技術經理當教練如果對公司是不好的徵兆，問題應該還是出在領導上，誠如同人過去發表過的文章所講的：強將手下無弱兵，但也不會有強將。沒有辦法訓練培養人才的教練，還是因為技術經理不諳教練之道呀！

技術經理有時候要扮演 『教練』 的角色, 這時候要將正確的觀念傳遞, 這是有點困難的, 因為往往會被自己的極限所限制, 想起了一位朋友,他是長笛老師, 他說他知道那個音要如何如何才是完美的, 但是他確無法示範出來

對於 MaoYang 兄的觀點，通達人認為 MaoYang 的朋友應該要學如何示範，不然就不是個夠格的老師。這代表了技術經理應該要學習如何正確示範，否則就不能算是個好教練。MaoYang 兄進一步解釋他對技術經理擔任教練角色的觀察：

在公司內部, 技術經理當 『教練』 並不是明定的工作, 但是當團隊的程度良莠不齊的時候, 技術經理帶頭出來當 『教練』 , 是不得不的, 但是技術經理有時當管理職太久, 要把許多實作交代清楚, 這是當技術經理累人的地方

以上的解釋，通達人認為他同意當「教練」並不是技術經理明定的工作，但為了要避免身為技術經理的時間都被部屬瓜分了，較佳的方案還是當教練，讓部屬有成長的機會和空間。另外，有一位噗友 Daniel Li 也認為，身為技術領導者，給部屬魚吃不如教他如何釣魚。因為總是有一天，他們會離開教練單飛，就像教小孩走路；我們不可能一直挨著他隨時扶著他，只能教他方法、鼓勵或強迫他嘗試，並獎勵或誇大他的小成功。

在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。

技術經理應該要教導他的團隊成員什麼東西呢？MaoYang 的長笛老師朋友說知道什麼才是完美音符，但自己卻不知道怎麼示範，然而如果技術經理知道如何示範他所知道的完美，那麼是否他就能夠傳遞正確的觀念了呢？答案並非如此，因為在這個地方存在一個陷阱；對於藝術而言，或許追求完美是有所意義，但在技術的領域中，完美真的是那麼絕對而必須去追求嗎？

在科技的領域中，我們通常找不到真正的完美。站在解決問題的角度來看，以前被認為是完美的方法，也許在今天會無法解決我們面對的問題。換言之，很多表面上看起來相似的問題，但在問題的本質上卻是全然是完全不同的，而且人們通常沒有辦法一眼認清它們，而是要深入研究後才能知道如何找到適合的方法來解決問題。這其實也是技術開發工作最困難的地方，很多問題很難找到最佳的解法，而只能基於現實用最適解來處理它們。

所以對於逐漸不再接觸技術的管理者而言，他們過去以為的完美是否到了今天還是那麼如此絕對呢？答案未必見得。就像溫伯格評論「成熟度」是偏頗字眼的道理一樣；所謂完美通常是基於個人信仰的價值判斷，這只是基於個人的感情需要，而非專案的真正需要。

因此，技術經理應該要教導他的團隊成員的東西，不應該是他已經知道的東西，而是他還不知道的東西，這樣他的團隊才能不被自己的所知有限而限制住。但如何可以做到呢？同人認為好的教練不會給答案，而是提出關鍵的問題教人們去思考，使人們在困惑產生學習的動機，以及有勇氣質疑權威與傳統上以為的理所當然。這樣才能增進團隊成員解決問題的能力，提供答案不會讓他們得到成長，只會造成依賴而削弱他們的力量。

至於技術經理擔任教練的目的為何，MaoYang 說當團隊的程度良莠不齊的時候，技術經理才不得不帶頭出來當 『教練』。那是否意味著技術經理當教練是為了讓團隊素質可以齊一化呢？但如果答案是肯定的，那代表在團隊的多樣性會慢慢消失而由—致性來取代，那麼喪失一致性的代價是否值得。但如果答案是否定的，那麼技術經理擔任教練的目的終究為何呢？

對同人的這個疑問，通達人認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。通達人說的沒錯，但在實務上，同人經常看見技術經理會犧牲團隊成員的多樣性來增加一致性。

比如說運用制度或規章來抑制團隊成員的行為，不希望成員面對問題採取不一樣的想法與做法，但這通常是因為技術經理的管理彈性不足，才會對團隊成員處處設限。因為依據「必要多樣性法則」，系統的行為會由系統最有彈性的部分來掌控，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他在管理上的困難。因此他必須設法降低多樣性才有辦法管理好他的團隊，但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。

當然團隊合作需要一致性，但技術經理當教練當拿一致性來取代多樣性卻不見得是明智的。就拿所謂的基本動作來說好了，很多人都忽略了基本動作需要以成員背景能力與組織文化為前提。因為如果不考量專案臨時與獨特的特性，你可以找到適合的人依據某種方法來訓練，但專案的特性讓你找不到適合的人來達到目的。

因此對專案而言，基本動作是夠用就好，但何謂夠用，正考驗著經理人面對現實的勇氣與智慧；縱使團隊的一致性可以降低管理的困難度。但一致性不是技術經理當教練的目的，只是用來達成最終目的－提昇團隊績效的手段之一。因此，如果解決專案問題的需要更高的團隊多樣性，恐怕如何提昇管理的彈性，才是技術經理成為好教練的關鍵因素吧！

經過一個月來的使用，這台 FE3000 用起來還蠻順手，直到最近因為無法透過 USB 連接線輸出照片，才發現 USB 的連接埠故障。老婆到總代理元佑實業要求維修，才發現 OLYMPUS 這個世界名牌數位相機的維修服務，竟是如此糟糕而令人失望。

同人聽到老婆告訴我客服要求我們付錢才能維修，這實在令人感到不可思議。老婆轉述客服的話說，連接埠的故障是因為人為操作錯誤造成，因為連接埠上的接頭凹陷下去，他們認為正常操作絕不會出現這樣的狀況。

老婆當然不能接受客服的說法，但客服說完卻忙著處理另一位客戶的大發雷霆；因為他送修的機器沒修好而吵著要找元佑的總經理處理問題。這時候，輪到另一位女性的客服人員來處理老婆的問題，她還是說這是人為操作不當，如果是按照正常的操作，USB 拔插 10 次都不會有問題。

老婆聽到客服人員這樣說，立即反應說：「這是什麼爛照像機，USB 只能使用 10 次，我以前用過其它廠牌的機型都沒有這樣的問題！」客服人員這時表示請老婆不要生氣，但她還是堅持修理 USB 連結埠故障必須要收費，要不然就只能買讀卡機來處理相片的輸出。老婆因為帶著還不到三歲的女兒，沒辦法也不想花太大的精神找對方理論，只好悻悻然地帶著相機回家。

聽到老婆送修數位相機的過程，實在讓同人覺得這個名牌數位相機維修服務真是離譜。在台灣的今天，竟然還有如此缺乏品質意識的公司，真是令人匪夷所思。

OLYMPUS 的 FE3000 並不是我們家所使用的第一台數位相機，過去我們用過很多其它廠牌的數位相機，而且也經常利用數位相機所附的 USB 界面來進行照片的影像輸出，從來也沒發生過 USB 連結埠那麼不堪使用的問題。

如果真如客服說是因為人為操作不當而造成損壞，那麼什麼樣的操作會造成這種問題呢？老婆轉述客服說可能是接頭方向對錯了，我聽到客服人員這樣說倒是想請對方表演如何將 USB 接頭反接給我看！事實上，這台相機的 USB 插槽有防止反接的缺口設計，根本就不可能發生將 USB 傳輸線反接的現象。

如果使用者不可能將 USB 傳輸線接反，再加上我們並非第一次使用 USB 的傳輸界面，對我們而言，連結 USB 傳輸線是那麼單純而簡單的步驟，我們應該不可能會弄錯而導致 USB 連結埠的損壞。如此看來，USB 連結埠的損壞的原因根本就並非人為操作不當，而是機器本身的設計不良或是構件本身的瑕疵。

所謂設計不良是指使用者在正常操作下會造成機件故障的比率。換言之，就像客服人員說得 USB 傳輸線正常拔插 10 次也不會故障。假如她說的沒錯，那麼就代表這台數位相機的 USB 傳輸線拔插的設計，只能保證正常使用拔插 10 次不會導致連結埠的損壞。因此站在使用者的觀點來看，這種設計當然是設計不良。

然而以常理來推論，實在很難讓人相信 OLYMPUS 的 USB 連結埠會設計成只能拔插 10 次而已。這樣看來，如果 USB 連結埠損害的原因不是因為設計不良，那麼就是 USB 連結埠構件本身的瑕疵，才會如此不堪使用。而那位客服人員如此缺乏 common sense 的說辭，不是想掩飾產品品質不良的真相，就是想要推拖維修的責任而刁難顧客。

這種罔顧客戶權益的行為，是客服人員的素質太差，還是因為元佑本身的企業文化所致？有網友告訴同人，在網路上元佑的相機維修，早就劣跡斑斑了。聽過老婆跟元佑接觸的經驗，再看看到網路上的文章、以及一些網友的經驗，讓人相信除了客服人員的問題之外，更嚴重的問題是他們的企業文化根本不重視「服務品質」這回事；對於客戶的維修需求，能夠推掉一件就賺一件，如果推不掉就再來修。換句話說，就是會吵的孩子才有糖吃。

一件商品在正常使用之下，在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來，同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是，有朋友認為消費者碰到這種情形不應該生氣。而是要怪自己沒有看清楚服務條款，以免因為憤怒而喪失理智，但同人認為這樣的想法反而會助長劣質服務的氣焰。

因此，相機的保固問題自然有法律來保障我們的權益，但除此之外，我們仍舊可以將不愉快的相機維修經驗，用來降低其他消費者因為資訊不對稱而增加的交易成本，以自然淘汰不良的服務品質。希望透過這篇文章的分享，也能夠讓更多人了解，數位相機除了品牌形象與功能外，不要忽略了售後的維修服務呀。

網路上其它有關元佑維修的討論：

數位相機不防水

戰勝元佑的例子

同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義：「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態；過去做過行不通的做法，卻認為在今天可以行得通，結果讓人一直瘋狂或是不斷地精神錯亂。

但為什麼人們要盲目地做些行不通的事呢？其實以同人這麼多年軟體開發的經驗來看，他們不見得是意識不到這些做法行不通，而是可能因為害怕與恐懼，讓他們不敢嘗試新的方法來解決問題。

縱使無法解決問題的挫折是令人沮喪的，但如果要放棄過去習慣的做法來開發系統，他們更會茫然不知所措，擔心因此對現況失去掌控能力。於是明知過去的做法有問題，但更害怕失去它就會一無所有，於是只好將它緊緊地捉在手上，並期待這一次會有奇蹟出現，改寫過去失敗的命運。

不過如果人們理性一點，都會意識到要改變命運不應該期待奇蹟，而是需要「勇氣」讓我們改變心智模式，然後採用有效的方法來解決問題。在這方面，同人覺得比較幸運的是我常碰到好主管，能夠支持我想要把事情做好的想法。

記得過去的主管 Y.L. Liu 曾經告訴過我的話：「如果過去這樣做行不通，那今天就應該嘗試不一樣的做法」即使改變必然會遭遇到阻礙，然而當我們勇於面對阻礙而因應問題時，才能促使我們打破過去的習慣來進行有紀律地思考與行動，進而更有效地解決問題。

紀律，也就是 discipline 這個字。它的意義並不是做我們過去熟悉的事，而是熟悉了解問題是什麼，並加以解決問題的過程。如同我過去的文章所強調的，軟體開發不只是工程，或是工藝，而是解決問題的過程。敏捷開發其實並非依賴制式的軟體開發流程或方法，而是基於重要價值觀與原則發展出來的實務，而最重要的價值觀就是為了思考如何「解決問題」，至於使用流程方法都只是手段而不是目的。

然而，根據同人的經驗，想要軟體開發過程運用以上的觀念，我認為最困難的是對專案目標的混淆。在這次的分享會之中，同人也發現有些 PMP 背景的朋友，他們很關心如何準確預估專案的範圍、時程與資源，因此希望了解敏捷開發如何來解決這樣的問題。但其實敏捷開發方法根本不需要做精確的預估，因為改變是無法預估的。所以它強調的是反應變化的能力，而不去為預期或抑制變化做太多的努力。

或許有人會把精確的專案預估，看成是專案成功的重要目標之一。但以同人這位 PMP 對專案管理的認知來看，精確預估並非專案的目標，而是達成降低專案風險目標的手段之一。或許用這種手段來蓋房子，或生產看得到、摸得著，可以明確度量的產品可以做得很好，但用它來開發軟體卻不見得可以行得通。

我們應該改變對軟體開發專案的傳統思維；假如軟體開發的本質，就是難以精確預估，那麼我們就不該將力氣浪費在預測上，而是應該用來進行對專案更有效益的事情上。但這不代表敏捷開發方式不做規劃，而是規劃的重點不在精確地預測未來，而是用來定義專案的基準線；利用每一次的反覆過程的回饋，用來改善或調整後續的計劃，以增進我們回應變化的能力。

因此，使用敏捷開發我們不需要具細彌遺地預測未來的改變，只需集中心力面對今天所發生的問題。換句話說，開發者也不需要一份不會變更的功能需求清單，而是了解專案目前所要解決的實際問題，進而運用(adopt)思考及創意、調適(adapt)方法然後再熟練(adept)所需要的技能來解決問題。

那麼，以上敏捷開發的思維是否打破專案管理的基本觀念？同人從不認為如此。依照 PMBOK 的專案管理知識領域與流程本來就支援管理改變的做法，問題只在於管理者是否掌握住變更管理的重要原則並熟練它們：

首先、必須確認改變對專案有正面效益；

其次、必須確認影響變更的因素已發生；

最後、最重要的是管理變更。（PMI，2000）

我們看到這些原則不但並不違背敏捷開發的思維，同時兩者是相通並且相輔相成的。的確，對於軟體專案而言，改變意味著增加軟體開發的風險，但害怕專案風險的心態，也代表你的團隊面對風險只能迴避它們以確保安全，但你所獲取的利潤也相對變得較低（DeMarco & Lister，2007）。於是你必須辛苦地在市場上試圖降低軟體價格來與對手競爭，除非你能夠勇敢地面對挑戰，選擇快速回應變化才會創造機會，為專案產生更大的正面效益。

那麼對於環境或需求的變化，軟體開發團隊要如何快速回應呢？依據同人的經驗，大規模的事先設計（BDUF，Big Design Up-Front）通常無法立即迅速地反應變化，而且常常會造成過度的工程化（over engineering）的問題。而依賴開發組織導入某些流程、工具或方法論其實也並非成功的關鍵。我認為只有增進團隊溝通與合作，讓團隊能為面對問題而共同努力，才能夠快速地回應變化。

或許有人會認為詳盡的文件可以增進溝通，但實際上它的成效不高而且常常要人們花費很多的心力，除非你發現它真的有幫助，否則你應該只需要寫必要的文件。雖然工具或方法論可以增進開發的效率，但它們也會讓工作變得艱難。因為無法被替除的工作，它們是更具備知識密集的特性，需要更有才幹的人來完成任務（DeMarco & Lister，2007）。所以在導入任何工具或方法論之前，你應該提醒自己，敏捷開發是以人為基礎，面對的是現實而非理想。

誠如 David Ko 在分享會中說得好，任何方法的導入如果最後變成政令宣導時，那就非常不妙了。同人則以為快速回應的關鍵不在於遵循方法論的做法，而在於面對專案的現實問題，讓團隊共同因應問題而改變。David Ko 提出了很多他的專案所導入的做法，同時分享他感受到團隊成員自動自發的喜悅，也讓同人希望能夠見賢思齊。

同人看到這則新聞的第一個反應是，總統在救災過程中受到批評，心裡面會產生一些情緒是人之常情。因此透過 email 中將這些情緒發洩出來，跟家人訴訴苦以免情緒積壓而損害身心健康，我認為是很自然的一件事。只不過，馬大姐把這些用來宣洩情緒的對話，在公開場合中公開，似乎只會為她的弟弟帶來麻煩，顯然她又失言了！

不過，除了馬以南的失言之外，同人認為這則新聞更重要的意義是，讓我們看到領導者應該如何面對批評。在現實上，領導者所碰到的難處是，不管領導者碰到問題怎麼做，他都很難做到沒有人批評。因此想要成為優秀的領導者，其實無須太在意外界的批評，而是應該將這些批評轉化成更積極正向的領導作為。

就像在《領導的黃金法則》中，作者約翰‧麥斯威爾提到「當你後面被踢一腳，你知道你已超越在前」。身為領導者，我們應該要有面對批評的準備。那麼領導者應該如何面對批評呢？麥斯威爾認為下面四個步驟可以幫助領導者處理批評：

第一，認識你自己，這是真相問題；

第二，改變你自己，這是責任感問題；

第三，接納你自己，這是成熟度問題；

第四，忘掉你自己，這是安全感問題。

麥斯威爾認為領導者無須理會對領導者職位的批評，但對個人缺點的批評，卻必須要設法改正。要認清人們是基於領導者的職位，或是領導者個人本身，唯一的方法就是認識自己。其次，改進自己的缺點是領導者的職責，但也必須能夠分辨善意批評或是惡意批評，可以問自己下列三個問題：

誰在批評？智者的忠言逆耳勝過愚者的熱情贊助。批評的人是誰很重要！

如何批評？試著分辨對方武斷還是提出疑問、好言相勸。

為何批評？是出自傷害我的動機或是為了我好？會傷害他人的人不會手軟，他們猛烈抨擊他人是想讓自己好過，而非幫助對方。

對於領導者的言行，在一開始人們通常會說你錯了，但後來卻又會說你是對的，而且重點不是你做什麼，而是他們知道你做的事情很重要。面對旁人這種多變的反應，麥斯威爾說領導者應該學會接納自己，並且指出為了做我們理想中最好的人和領導者，我們需要做好我們自己。

可是那並不代表我們不用改變或成長，而是表示必須努力做到最好的自己。真實做自己是邁向更好的自己的第一步，而接納自我是成熟的象徵。如果我們擔心別人怎麼看我們，那是因為我們對他們的意見比對自己更有信心。

有效處理批評的最後一步就是不再把焦點放在自己身上，麥斯威爾認為領導者不需要花太多時間擔心別人怎麼看自己，其實別人並沒有那麼在意我們。

麥斯威爾說有安全感的人忘記自己，所以他們可以把焦點放在別人身上，以面對任何批評，甚至為批評他們的人來服務。他說一個有安全感的領導者永遠不需要為自己辯護。做為領導者應當看重責任，但卻不應該把自己看得太重。

從麥斯威爾的觀點來看總統府對這次風波的回應，同人覺得有信心的領導者實在不應該花時間來為自己辯駁。如果埋怨「好人（心）沒好報」只是為了一時情緒的宣洩，就算不小心被馬大姐把在家裡面說的話公開出來，但只要承認自己的情緒及壓力確實存在，並表示自己會想辦法好好處理它們，讓自己能夠把事情做好。這樣就足以代表領導者在行為上是接納自己與放下自己，也就表現出足夠的成熟度與安全感。

可惜馬總統似乎是太在意旁人對他的觀感，因而太維護自己「被曲解」的形象。其實同人過去在〈新官上任三把火〉及〈當專案一再出現相同錯誤時〉這兩篇文章中，就曾經探討過馬團隊在管理或領導上的問題，從這些文章中似乎可以歸納出來馬總統領導的問題在「完美」兩字上。

或許在理念上，馬總統認為按照他的理想去做，就能夠讓事情達到完美的結果。但事實上，理想上的完美是不存在的，真正的完美是要你認識自己，並接納自己是不完美的，然後你才能改變自己而成就真實的完美。

因此，對外界的批評，如果馬總統一直把焦點放在自己身上，他就很難理解別人為什麼看不到他的辛苦與努力，也就無法體恤別人受到的痛苦。在缺乏安全感及成熟度的反應背後，我們看到根本的原因是領導者不能認識自己並加以改變。例如在報導中看到：

杜勇明則指出，他說「馬總統您來晚了！」這句話是針對馬政府團隊救災一團亂有感而發，總統原本就該承擔政府所有責任，但把這件事拉到個人問題是不對的。

會發生這樣的誤解，顯然馬總統不夠認識自己，才會分不清批評是針對個人或是職務而來。不過，同人這篇文章並不是期望改變，只是藉由對他人領導行為現象的觀察，帶來有助於自我成長的學習。因為生命的學習與成長是無止境的，所以即使在位的領導者未能改變，但或許只是時間還沒到。多點耐心給別人，也希望能讓我們從別人的錯誤中學習成長。

相關文章：

• 領導者的黃金法則~處理批評-領導者需要學習的功課

延伸閱讀：（其它有關領導的文章）

• 領導是信任關係
• 結構性無作為
• 當專案一再出現相同錯誤時
• 新官上任三把火

尤其是女兒又是那種聰明又調皮的小孩子；她總是會想辦法來破壞你所設立的規矩，用理性來溝通又似乎並不適用在她這個年紀。不過打罵的懲罰看起來雖然可以達到喝阻的效果，以控制她的行為，但同人和老婆也發現這種管教法副作用很大。我們常發現在公園她會對其他的小朋友施展暴力，而脾氣也變得愈來愈情緒化。

當然，前一陣子同人夫妻帶女兒參加控制理論的研習課程，對我們學習教養女兒的獲益很大。但除此之外，有沒有更簡單而直接的教養法能夠矯正女兒的行為呢？最近同人在《一分鐘爸爸媽媽》看到一分鐘教養法。它包括三項教養的秘訣，也就是對孩子實施一分鐘懲罰與一分鐘獎勵、以及幫助孩子設定一分鐘目標。

同人覺得一分鐘教養法是相當不錯的教養法。它的方法看起來很簡單，而且能讓子女感受到父母的愛、以及對他們自我的肯定，以產生優良行為的動機。這樣的教養方式可以將子女的行為與父母對他們的觀感分開來；讓子女清楚父母認為他們要比他們的行為還要來得好，管教代表父母不喜歡他們的行為但卻愛著他們，讓孩子先相信自己是好孩子，然後才會做出好孩子應有的行為。

在孩子出現不好的行為時，父母可以實施「一分鐘懲罰」來導正孩子的行為。首先我們在孩子犯錯時，要指出孩子行為的錯誤在那裡，接著再告訴他這個行為的後果，以及我們對這件事情的感受。這個過程大約會經過半分鐘，接下來停下來讓孩子感受到我們的不滿，同時也會讓他覺得不安。

然後父母要在接下來的半分鐘沉殿心情，然後拍拍孩子的肩膀，告訴他的行為很不好，但他是好孩子，這才是讓我們覺得困擾的地方，最後抱抱他表示「我愛你」讓這件事從此過去，一分鐘懲罰就此結束。

如果一分鐘懲罰可以在孩子做錯事的時候，讓他們立即知道錯誤，並且感受到父母對他們的愛與肯定，讓他們在以後不再犯錯。那麼在他們做對事的時候，當然也會需要父母對他們表達愛與肯定的行動，否則他們可能會故意犯錯，只為換來父母的擁抱與表示「我愛你」。因此，父母應當挑出孩子做出「大致正確」的行為，對他們實施「一分鐘獎勵」來鼓勵他們。

在一分鐘獎勵的前半分鐘，父母應當指出他們做得不錯的行為，並且表達我們對他們行為的快樂感受。同樣地，在後半分鐘父母應當告訴孩子，他們的行為棒極了，因為他是好孩子。然後再抱抱他向他們表示「我愛你」來結束一分鐘獎勵。

此外，父母還可以和小孩共同設定「一分鐘目標」，幫助孩子專注在家庭成員與他們自身想要達成的目標上。這些目標之所以稱為一分鐘目標，是因為它們非常簡短，可以將它們寫在一頁紙上供人們在一分鐘的時間唸完。同時它們也必須非常具體，並包括目標何時會達成的時間，以供父母與孩子可以在周末的時間來加以檢視執行的成效。

例如對二歲的孩子的一分鐘目標，父母可以幫孩子設定每天晚上九點開始上床，讓他能夠在一周之內達成十點半前完成就寢。如果孩子做得不錯，我們就對他施以一分鐘獎勵，若做得不好則對他施以一分鐘懲罰，並在達到目標後再設定新的一分鐘目標。這樣就可以培養孩子為自己設定目標的習慣，並且讓他的行為專注在他想要達成的事情上。

這本書強調，教養孩子的時間絕對不只一分鐘，但成為一分鐘爸爸或媽媽讓父母把時間花在對孩子最重要的事情上，也讓父母省下時間去享受自己的生活。讀完這本書，發現遵照書中的觀念並按照書中方法的實踐，要達到新時代思維的教育理念真的不困難。

不過，可能是東方人比較不習慣表達自己的情感，同人發現自己在向孩子表達感受的方面還要多學習。最近接觸的親子教育觀念都告訴我情感的表達比理念的灌輸更容易讓孩子接受，我想我該多多練習，努力朝向成為一分鐘爸爸的目標邁進嘍。

同人曾經和老婆一起探索我們的家族圖，那是她在研究所「家族治療」課程的家庭作業。我協助她繪製出我們婚姻結合的家族圖，並且透過探索與討論，我們看到家族之間的三角關係是如何影響雙方的家庭，並且發現那些傷人的秘密其實是因為上一代關係的需求沒有被滿足，轉而將希望投注在下一代身上。而下一代就不知不覺地受到上一代的陰影所影響，甚至因此造成一些家庭悲劇。

那麼家族中的三角關係是如何形成的呢？當父母沒辦法從他們之間的關係得到滿足時，通常會傾向於向兒女要求援助或尋求慰藉，而在多方拉扯之間形成三角關係。舉個例子來說，當母親表現出受到父親不盡責任以或是暴力相向時，孩子常會站出來幫忙母親來對抗父親，或是母親會希望孩子幫她跟父親交涉。

但這往往使父母之間的問題變得複雜，父母會變成依賴孩子，孩子也會因為父母而不勝其擾。而更嚴重的是，讓父母無法為發生在自己身上的事情負起責任，而孩子也沒辦法為自己的生命而活，並且會不知不覺地遺傳父母的行為，讓悲劇一再地重演。

以薩提爾的家族治療觀點來看，她說父母因彼此相同而在一起，因發現並尊重彼此差異而成長。但尊重與成長不是自動發生，兩人最初的希望落空，常為事實染上其它的色彩。一些未實現的夢想可以引發內在或外在的對話，如自我懷疑、指責、衝突、有時則是暴力。或是人們可能相信他們的夢想不再是必要的，只有接受現實。

父母之間得不到滿足，通常會指望孩子。他們常在粉碎夢想之餘，期望他們的孩子代替他們去完成夢想。因此，孩子不知不覺地將父母的渴望納入他們如何看待與應對這個世界的一部分，這就是生命以一種被投射的方式在自我完成。

由此可知，父母與孩子之間的三角關係是如此深遠地影響我們，陷入其中的我們已難以評斷其中的是非恩怨，生命也只有成熟度的問題而沒有對錯可言。

從同人自身的親身體驗，我很清楚上一代的恩怨要由上一代自己去解決，這一代有這一代的事情去面對，實在沒有多餘的心力來幫上一代解決問題，這是相當吃力不討好的事情。尤其是介入上一代的恩怨只會削弱父母面對及處理問題的動機與能力，在這種情況下，除了複雜的情感糾葛之外，他們不會滿意孩子為他們所做的一切。因為扮演弱者與強者之間的依存，只是逃避自由的一種心理機制。缺乏心靈上的極積自由，他們其實沒有認真想過，到底他們想要得到的東西是什麼。

要處理好家族的三角關係，同人認為我們應該加強自我分化的能力。分清楚自我與父母需要的差異，做好在情感上支持父母的角色，但不去介入幫他們處理問題，而是促成由他們處理自己的問題。只有「割斷臍帶做大人」，才能發展出成熟、穩定而健康的人生，也讓父母的關係按照他們想要的方式去發展。

或許有人會認為孩子要幫父母解決問題，這一切都是孩子應該面對的宿命，而且，也會擔心父母自己沒有辦法把問題處理好。但宿命其實也只是我們對生命的一種選擇。事實上，我們還有其它不一樣的選擇，這也是我們無可避免的成長課題。如同薩提爾的觀點所言：家人因為彼此相互尊重差異而成長。

因此，痛苦不是理所當然的實相，而是要我們從過程中學習成長，用更寬闊的視野來看生命，才能用更成熟的方式來處理家族中的三角關係。「幻滅是成長的開始」我們必先清除存在我們心中不切實際的期待，同時也讓父母瞭解到他們的問題只有自己才能解決。身為子女最多也只能在精神上支持父母並給予關懷，這樣才能讓家族之中成員的情感，產生健康而均衡的連繫。

但沒想到第二天，不到八點半同人和老婆就聽到電鑽和榔頭敲打的聲音了。這個時間出現這些聲音，會干擾女兒的睡眠而影響她的正常發育與成長，這實在令我們十分困擾。

其實早在幾個月前，同人就曾要求裝修承包商，要她請工人在九點前不要使用會發出巨大聲響的機具，以免干擾女兒的睡眠。最近發現在九點前，還是會發現工人使用那些機具發出聲響，本來以為他們就快完工了，所以就沒有向承包商反應噪音問題。但現在噪音的問題很嚴重，於是同人在上班前打電話給承包商，向她反應噪音問題，並得到她的允諾會讓工人遵守及配合。

後來老婆告訴我接下來的故事發展。她和女兒被噪音吵得受不了，倉皇走避時碰到承包商。她質疑承包商為什麼時間還沒到就開始施工，害她連早飯都來不及吃，好像逃難一樣。承包商連忙向她賠不是，但表示是工人沒有按照規定的時間來施工。老婆聽到這理由更生氣，如果承包商不能約束工人照規定施工，那住戶根本不能信任承包商在公告所做的承諾。

大樓管委會主委這時候出現了，老婆藉這機會消遣他。問他說：「不是說保證今後不會有噪音出現了，怎麼今天噪音那麼吵？」主委聽到也不甘示弱的轉向承包商說：「我最倒楣了啦，他們租房子還好（指我的老婆）受不了退租不住了就好。我呢？跑也跑不掉！」老婆看到主委只會抱怨而不想解決問題，而且又戴口罩，所以不想跟他吵，就先離開了。

還好住我們家對面的媽媽這時候經過，在弄清楚大家的爭議之後，想到解決問題的方法。她建議請大樓警衛在施工開始時間之前，阻擋工人不讓他們進入大樓施工，等施工開始時間到了之後才放行。結果這個方法果然得到效果，讓大樓的住戶不用清早就忍受噪音的襲擊。

同人聽完老婆告訴我以上故事的後續，讓我覺得對面的媽媽果然是處理問題的高手，不像主委只會感情用事。如果我聽到主委說那句話，我大概會說：「主委您真是愛說笑，你怎麼可能會倒楣呢？大不了你把房子租給別人，這樣就可以把你的問題變成別人的問題呀！」不過話說回來，我相信承包商有誠意解決問題，但當工人無法配合遵守她訂出的辦法時，問題該如何解決呢？

解決問題的關鍵就是正視「人不是完美的」的事實。同人是工程師出身，我很能體會工人希望早點把事情做完早點走的心態，對擾鄰後果的嚴重性他們可能沒有明顯的感受，而不是故意不去配合。所以以為訂下工作時間的規則就可以讓他們去遵守，其實是太天真的想法。那位媽媽的辦法正是對人性弱點的積極管理，不去假設人們一定會照你的方法去做事，而去思考問題的對策。看在同人的眼中，實在是令人激賞呀。