在公司工作中，我們經常需要資訊科技人員的協助，也就是IT人員。在我們的部門中，有一個專門協助我們的IT單位，擁有四位成員，你可以根據需求自行選擇聯絡誰來請求協助。結合多人的經驗，我們總結出這四個人的特性：
甲：通常需要等待數天或一至兩週才會處理需求，據說是真的事情很多，有些需求的處理甚至需要數個月的等待期。
乙：能夠即時處理需求，但是會邊處理邊碎念，有時會調侃你的能力不好。
丙：能夠即時處理需求，不會說多餘的廢話。
丁：能夠即時開始處理需求，態度熱情，但比較少根筋，可能會帶你繞一圈才解決你的需求。
後來每當有新人進來，我們習慣性地建議新人直接找丙尋求協助，這也漸漸地導致丙變得非常忙碌，在我轉調離開原來的部門後不久，就傳來了丙離職的消息。我們認為丙的離職與他過度的工作負擔拖離不了關係，這就像是劣幣逐良幣的情境，而我們也算是壓迫著丙的劣幣。
然而，如果我們遭遇到像丙那樣的情境，太多人來尋求協助，又該如何是好呢？這我沒有答案，或許是調整心態，像甲那樣，不要拼每件事都當下處理，先照顧好自己。
其實，在開發內部軟體的過程中，我們也可能會面臨類似的情境。我們的服務對象同樣是公司內的同仁，由於團隊規模有限，我們必須處理各種諮詢，包括軟體的使用方法。
在過去的面試經驗中，我就曾被問及一個挑戰性的問題：「在你手上有一個軟體正在開發，但使用者總是問一些基本的問題打斷你，又不願閱讀你提供的文件。若你一直耐心地回答他們，最後可能導致你的開發時程遲緩，你會如何應對？」當時我無法即時地回答這個問題，後來有機會時我向學長尋求建議。學長說：「當你回覆一個人的提問時，同時把這個問題的副本轉發給他的同事和主管，也是提醒說這可能是大家共同需要了解的事情。這樣那個人就會感到不好意思一再問一些基本的問題。」
在實際的工作場景中，這和你負責的軟體息息相關，我主要面臨的挑戰是不斷湧現的開發需求，而非過多的基本問題。相對地，有些同事負責的軟體則經常被詢問各種基本問題。我印象深刻的是有一位同事負責一個龐大且歷史悠久的軟體，功能繁多，用戶達到近百人，他經常被詢問各種基本問題。觀察他處理基本問題的方法，我發現他確實常像學長所言，會將相關訊息寄送給提問者的主管。當使用者透過即時訊息、電話，甚至親自走到他座位旁時，針對簡單的疑問，他是都會直接回覆；然而，對於複雜的問題，他還是會當場建議使用者回去透過郵件詳細描述。
那有效果嗎？很難確定。因為新的挑戰是，對方的主管鼓勵員工提問，等於由我們同事幫忙對方主管做新人訓練。有人是建議我們同事拔掉電話線，但這並不能阻擋信件的來信。我則是半開玩笑地建議說找外國人來當軟體窗口，因為當溝通轉為英文時，或許大家會更願意嘗試著自己查看軟體文件或是問自己的同事…
這樣的挑戰最終還是仰賴高層長官的介入，建立了階層結構的發問方式，由特定窗口發問，不再是每一個人隨便一個問題都直接找我們同事，才讓情況穩定下來。
