最近跟朋友聊天聽到這麼一個故事。

她的老闆交代下來一個工作。 大意是要幫老闆一個朋友免費開發一個小網站。 雖然做網站不是他們公司的本業，但她知道下面有工程師是會這類工作的，加上是老闆交代當然也就得進行。 於是她花了些時間跟老闆的朋友(後稱客戶)討論。 大致架構雙方都談清楚了，只是技術上客戶希望透過PHP + MySQL來開發。 她本身因為不是開發者、對技術細節也不熟，為確認這件事情，就回來找內部的工程師討論。

她跟工程師問說：「你有辦法用PHP + MySQL開發這樣這樣需求的網站嗎？ 如果可以，大概要花多少的時間呢？」

不過，工程師並沒回答這問題，反倒開始批評PHP + MYSQL這樣的方案。 批評完後，又花了十幾分鐘解釋這樣方案為何不好。 最後他一句話總結：「所以我覺得我們不該這麼做。」

這位PM跟我抱怨。 她說：「當場一直想要打斷對方。 因為我只是想要一個簡單的答案；只要知道到底你會不會做？ 會的話，要做多久？ 這樣簡單的兩個問題，為何不能直接給我簡單的答案呢？」

她就又問工程師說，「所以，這樣聽起來… 你並不會PHP + MySQL囉？ 那你比較擅長的技術是甚麼？」

工程師說他會.Net搭配MSSQL。 在接下來又花了十幾分鐘解釋這兩者有甚麼好處，相較於前一個解決方案為何該用第二方案。 也再三強調他不是不會，只是覺得不好。

這位PM心理的OS是，「你一開始就直接說你會甚麼、與不會甚麼不就好了？ 幹麻花了大半個小時在解釋這些技術細節呢？ 這不是徒然浪費了彼此的時間嗎？」

雖然我是同意這位PM朋友的抱怨，覺得討論的過程應該可以更簡潔一些，因為我自己也是喜歡會議能迅速簡潔的那種人；但同樣的，我卻也完全理解她的工程師為何要解釋這麼一大串。

因為在這情境下，不能快速談完，通常有三個可能性。

第一個可能性，是工程師真的覺得某種技術優於另一種，然後努力說服PM用另一種。 就算業主有偏好、老闆有決策，但站在「專業性的評估」下，他還是希望逆勢而為。 這當然還有很多變形，有時候也或許只是技術人員的偏見。 明明業主選的方式沒有不好，只是他覺得那不夠Cool、覺得不夠有品味、不夠先進，也是有可能努力反對、試圖想說服你。

第二個可能性，是我們這種非技術出身的PM，很容易忽略兩件事。 不懂技術的人，常常會忽略的技術上的困難度；要不就是輕易的覺得A與B是很容易相互替代的，可是在工程師的眼裡其實有很大的差異。 不懂技術的人也有忽略細節的傾向，很容易覺得大方向既然可以，那細節一定也沒問題。 但通常細節執行上其實要花很多時間，這也是執行人員常常會遲疑的原因。

加上很多工程師不太擅長簡單的用一般人能聽懂的方式解釋狀況，所以會選擇從頭開始把整個狀況、兩種技術差異、不同選項的優缺點整個說明一遍。 這時候、又是術語又是技術的解釋的太詳細了，確實會讓聽的人有點暈頭轉向。 可是耐心聽完，對於後續案子的穩當，還是很重要的。 也可以避免執行者覺得PM缺乏同理心的抱怨。

第三個可能性，是他真的不會另一種技術。 雖然我們當PM的，通常都希望討論能簡潔、會議別開太久，所以都希望討論是類似下面這樣的對話：

「客戶說要A，你會不會A？」
「不會A？ 那你會甚麼？」
「會B嗎？ 那若用B來做，多少錢多少時間可以？ 這個B能滿足所有需求？」
「好，那我去跟客戶討論。」

花兩分鐘的時間討論，然後各自就能回去處理正事，自己也能趕快去找客戶商量。

可是我們常常沒注意到，這問題對執行者壓力其實是很大的。 試想，大部分人在同事(或主管)問他某個東西「會不會」時，哪敢直接說「我不會」！ 就算真的不會，也要勉強「說些甚麼東西」。 在這狀況下，批評那種技術不好，彰顯自己會另一種更佳的東西也就是很自然的狀況了。 隱含的意思是：「拜託~ 我不是不會那東西，我只是覺得那種技術問題很多才不學的。 請用我會的方法吧！」

如果對話時，我們沒有理解對方這層心理上的顧慮，只是逼著他承認自己不會，那兩邊就很容易產生衝突與對立。 PM覺得幹嘛不簡潔一些；工程師覺得受到挑釁，就很可能就會埋下彼此怨懟的種子了。

這尤其在工作發生問題時最明顯。 有時候PM或是主管只是想找當事人趕快找出一個問題解決方案。 可是當事人會很擔心被責怪，而把99%的腦力及時間都花在「解釋事情出問題不是他害的」。 這時候若沒有花心力告訴他「我不是要怪你，只是希望趕快找到解決方案」(通常都得強調好多次對方才會信)，那這討論就可能冗長且難有進展了~