標題似乎有點過火，卻是親身見聞。相信從事軟體專案開發的人，多少也都碰過類似的場景：
客戶：「這個地方我想要這樣....這樣.....可以嗎？」
開發團隊：「不好意思，這個做不到喔。」
接下來，客戶可能會有以下幾種反應：
逆來順受
第一種反應不會引起甚麼爭執（至少當時不會）。也許客戶知道自己的要求是有些不合理，所以只是提一下，拗到賺到，沒拗到也就算了。又或許客戶本身沒有技術背景，屬於逆來順受型的 nice 客戶－－當然，所謂的 nice，是從開發團隊比較「方便」的角度來看。只是這樣容易寵壞開發團隊，也比較容易被唬弄。但話說回來，如果自己真的不懂，又不知道如何去查證或研究，也就只能完全聽別人的意見了。
再想想看
第二種反應，客戶也許覺得開發團隊的答案不盡合理，或者有未經仔細評估就斷下結論的可能，因此提醒團隊可在會議結束之後再仔細評估看看。這是比較正面的建議，而且有緩衝的作用，不容易當場引發衝突。其實，有經驗的開發團隊通常都知道何時該主動以這種方式回答。畢竟軟體江湖，花樣何其多，沒有人是百曉生、萬事通。斷然以「做不到」回絕，不僅易傷和氣，而且也許客戶才是對的，甚至對這部份的技術比開發團隊還熟悉，也不無可能（例如已經事先諮詢過技術顧問）。
華山論劍
第三種反應就有點麻煩了。這往往會演變成華山論劍，雙方針對技術上是否可行的看法互拼高下。如果彼此都有技術背景，或許真理愈辯愈明，來場技術交流，只要不流於意氣之爭，也可以歡喜收場。最怕的是稍有閃失，演變成一場惡鬥。尤其是話又說得那麼難聽，實在很難收場。
無論對自己的看法多有把握，一旦把話給說絕了，說狠了，到後面往往已經不是純粹技術問題的辯論，而是意氣之爭、面子之爭了。
技術、面子、信任
如果開發團隊一開始回答做不到時，有再嘗試解釋原因，例如：哪些客觀因素的限制、或那樣的功能反而會產生其他更嚴重的副作用（如資料或操作錯誤）等等，那麼無論客戶當時是否聽得懂，至少開發團隊表現出希望客戶能夠理解、諒解的態度，當下比較不會陷入爭執的僵局，而且就算客戶對開發團隊的說法存疑，也能事後再去多方查證。我想，以誠懇的態度盡量解釋，是開發團隊應該要做到的基本工夫。
我碰過最糟的狀況，就是第三種回應，可見當時客戶已經不相信開發團隊講的話了。後來，兩邊都有人私下來找我，想確認那個需求到底做不做得到。技術本是中性的東西，可一旦牽涉到人，往往政治的觸角就伸進來了。所以碰到這種問題，都必須非常謹慎。
幾次經驗下來，我發現我好像愈來愈像算命仙－－說那樣也通，阿說那樣好像也通。我的意思倒不是八面玲瓏、兩面討好，而是答案往往不會是單純的 Yes 或 No。例如，我可能會這樣回答：
「如果用單純的 HTML+JavaScript 技術，確實做不到。可是如果使用 ActiveX 技術的話，我們的網頁程式就能做到這個功能。可是使用 ActiveX 技術會有其他因素需要考量....。」（這時候通常有人會開始不耐煩了）
也就是說，其實大部分使用者能想到的功能或操作方式，重點都不在技術上能不能做到，而是有其他因素，例如作業環境、技術平台、軟體架構、甚至時程、資源...等方面的考量。如果只是簡單回答 Yes 或 No，等於是把腦袋裡一連串複雜的決策過程隱藏起來，最後只吐出決策的結果。這樣簡化的答案當然容易引發爭議了。
以剛才舉的例子來說，難道開發團隊會沒想到可以用 ActiveX 嗎？怎麼就直接回答做不到呢？
一個可能的原因，是 ActiveX 在那個專案裡從來就不是個選項，亦即打從一開始的技術規範中可能就已經包含不要使用 ActiveX 技術的限制。因此，開發團隊壓根沒想到要補充：「其實要做到還是有辦法，可是......」
結語
我曾在一場會議上被逼問同樣的 Yes/No 問題：「你只要回答我，技術上能不能做得到？」
當時我是第一次碰到這種狀況，老實說，我真的被那股 non-sense 卻又盛氣凌人的態度給惹惱了，回答的口氣自然也比較衝。現在事過境遷，才能以比較平靜的心情、旁觀者的角度，把這些想法整理出來。
有時候，真的不是技術上做不做得到的問題，而是該不該這樣做的問題。
而該不該這樣做，就如前面所說的，往往必須衡量諸多因素（也許「誰出錢」、「誰的階級高」也是隱性因素，但希望不是決定性因素）。
如果除了單純 Yes 和 No 之外，其他解釋都聽不進去，也不想陷入取捨的兩難，那麼，何妨試著信任別人的建議？
客戶：「這個地方我想要這樣....這樣.....可以嗎？」
開發團隊：「不好意思，這個做不到喔。」
接下來，客戶可能會有以下幾種反應：
- 好吧，那就算了。
- 你們可以回去再仔細調查評估看看嗎？或者幫我們想看看有沒有其他更好的解決方案？
- 騙肖也！這麼簡單的功能也做不到，你當我 XX 啊！（「XX」請自行帶入與智商有關的負面名詞）
以下簡單談一下這三種反應。
第一種反應不會引起甚麼爭執（至少當時不會）。也許客戶知道自己的要求是有些不合理，所以只是提一下，拗到賺到，沒拗到也就算了。又或許客戶本身沒有技術背景，屬於逆來順受型的 nice 客戶－－當然，所謂的 nice，是從開發團隊比較「方便」的角度來看。只是這樣容易寵壞開發團隊，也比較容易被唬弄。但話說回來，如果自己真的不懂，又不知道如何去查證或研究，也就只能完全聽別人的意見了。
再想想看
第二種反應，客戶也許覺得開發團隊的答案不盡合理，或者有未經仔細評估就斷下結論的可能，因此提醒團隊可在會議結束之後再仔細評估看看。這是比較正面的建議，而且有緩衝的作用，不容易當場引發衝突。其實，有經驗的開發團隊通常都知道何時該主動以這種方式回答。畢竟軟體江湖，花樣何其多，沒有人是百曉生、萬事通。斷然以「做不到」回絕，不僅易傷和氣，而且也許客戶才是對的，甚至對這部份的技術比開發團隊還熟悉，也不無可能（例如已經事先諮詢過技術顧問）。
華山論劍
第三種反應就有點麻煩了。這往往會演變成華山論劍，雙方針對技術上是否可行的看法互拼高下。如果彼此都有技術背景，或許真理愈辯愈明，來場技術交流，只要不流於意氣之爭，也可以歡喜收場。最怕的是稍有閃失，演變成一場惡鬥。尤其是話又說得那麼難聽，實在很難收場。
無論對自己的看法多有把握，一旦把話給說絕了，說狠了，到後面往往已經不是純粹技術問題的辯論，而是意氣之爭、面子之爭了。
技術、面子、信任
如果開發團隊一開始回答做不到時，有再嘗試解釋原因，例如：哪些客觀因素的限制、或那樣的功能反而會產生其他更嚴重的副作用（如資料或操作錯誤）等等，那麼無論客戶當時是否聽得懂，至少開發團隊表現出希望客戶能夠理解、諒解的態度，當下比較不會陷入爭執的僵局，而且就算客戶對開發團隊的說法存疑，也能事後再去多方查證。我想，以誠懇的態度盡量解釋，是開發團隊應該要做到的基本工夫。
幾次經驗下來，我發現我好像愈來愈像算命仙－－說那樣也通，阿說那樣好像也通。我的意思倒不是八面玲瓏、兩面討好，而是答案往往不會是單純的 Yes 或 No。例如，我可能會這樣回答：
「如果用單純的 HTML+JavaScript 技術，確實做不到。可是如果使用 ActiveX 技術的話，我們的網頁程式就能做到這個功能。可是使用 ActiveX 技術會有其他因素需要考量....。」（這時候通常有人會開始不耐煩了）
也就是說，其實大部分使用者能想到的功能或操作方式，重點都不在技術上能不能做到，而是有其他因素，例如作業環境、技術平台、軟體架構、甚至時程、資源...等方面的考量。如果只是簡單回答 Yes 或 No，等於是把腦袋裡一連串複雜的決策過程隱藏起來，最後只吐出決策的結果。這樣簡化的答案當然容易引發爭議了。
以剛才舉的例子來說，難道開發團隊會沒想到可以用 ActiveX 嗎？怎麼就直接回答做不到呢？
一個可能的原因，是 ActiveX 在那個專案裡從來就不是個選項，亦即打從一開始的技術規範中可能就已經包含不要使用 ActiveX 技術的限制。因此，開發團隊壓根沒想到要補充：「其實要做到還是有辦法，可是......」
結語
我曾在一場會議上被逼問同樣的 Yes/No 問題：「你只要回答我，技術上能不能做得到？」
當時我是第一次碰到這種狀況，老實說，我真的被那股 non-sense 卻又盛氣凌人的態度給惹惱了，回答的口氣自然也比較衝。現在事過境遷，才能以比較平靜的心情、旁觀者的角度，把這些想法整理出來。
有時候，真的不是技術上做不做得到的問題，而是該不該這樣做的問題。
而該不該這樣做，就如前面所說的，往往必須衡量諸多因素（也許「誰出錢」、「誰的階級高」也是隱性因素，但希望不是決定性因素）。
如果除了單純 Yes 和 No 之外，其他解釋都聽不進去，也不想陷入取捨的兩難，那麼，何妨試著信任別人的建議？
沒有留言: