溝通是雙向的，擁抱變化不是一昧地接受客戶要求

同人在《Time-Boxing 於軟體反覆演進的必要性》之中所說的情形，我也有碰過。

有時，客戶提出的需求變化其實並不是個好方法。在這種時候，我會示範或舉個例子，告訴客戶一個更好的方式。如果有示範品的話，客戶通常會很快接受。接著，我會告訴客戶這些實作方式是不是現有的。如果沒有，大約需要多少工時，並評估其重要性及時程。換言之，要評估這樣的需求變化要不要立即處理。就算客戶不能當天看到修正結果，也要在溝通的過程中，讓客戶了解前因後果以及處理時程。畢竟，「溝通」是雙向的，而不是盲目地接受客戶的要求。開發團隊單純地接收客戶指令，算不上溝通。

當然，這些內容在敏捷方法的書中都有提到，我就不再多說。我接著要提我個人的所見所聞，是上述內容在國內實行時的困境。

在《eXtreme Programming 理論與實務》一書中，提到專案經理(PM)是專案開發角色中的三根支柱之一，另外兩根是顧客和開發團隊。僅靠兩點不足以保持平面的穩固，要三個點成正三角形才是保持平面穩固的最適解。專案經理必須要在顧客需求和開發團隊的技術限制之間維持平衡，才能使專案順利進行。然而，國內的軟體開發公司中，如果開發團隊有個硬頸的專案經理，那真是萬幸。有時候專案經理只是一昧地接受客戶的要求，而不知開發團隊的狀況。如果開發團隊反應問題，專案經理只會丟一句「顧客永遠是對的」。專案開發的三支柱一開始就偏了。碰到這種情形，開發團隊就倒楣了。隨時有突如其來的需求打斷時程，永遠有趕不完的修改變更。

此外，開發團隊中沒有熟悉各種技術的資深工程師，也是問題。如果專案經理想問開發團隊某某需求做起來如何？有沒有更好替代方法？結果沒人能回答。就算專案經理有心，也只能徒呼無奈。

我本身有個例子。客戶使用 Xoops 系統的入口網站要改版，其中一項需求是要加入失效連結頁面的偵測功能。我們 PM 說公司有一套失效連結偵測的程式，但是是用 .Net 寫的命令列工具。但客戶用的是 Linux 系統，軟體是 PHP 開發的 Xoops 。有沒有什麼方案可用？我說這用 Ajax 就行了。當時其他人都是一臉疑惑，等到我第二天下班前展示了一個 Ajax 版本的失效連結偵測功能之後，大家才知道原來可以這麼搞，並且都肯定這個方式比原先的方式還好。當開發團隊中有一個較資深的程序員提供專案經理更好的建議或資訊時，專案經理才有依據可以和客戶溝通。

在國內的市場環境中，小企業客戶佔多數，客戶本身並不具備足夠的軟體開發知識。他們在提需求時，多半有些試探性的意味。只要有憑有據 - 最好是可以展示的雛型 - ，通常客戶會接受開發方回應的解決方案。當然，開發方要有這能力才行。