上面這張圖應該在 2009 年之前就出現了。網路上有很多改圖的版本。
客戶通常也搞不太清楚自己需要什麼，或是「真正想要」什麼，或是說出來的東西跟他腦子想的有落差。即使有 PM 來處理，有時候還是會有這類問題。就算 PM 能力稱職，我們工程師還是要正確的接收需求。所以我們作為工程師，不管怎麼樣都需要跟客戶溝通。
客戶不見得是甲方（組織外的委託方）。在敏捷的定義中，功能要交付給誰，誰就是你的客戶。可能一個小專案，甚至單一系統功能，就有一個負責的 PM。這個 PM 在這段時間內就是我的客戶。如果團隊很小或很扁平，那製作人就會是我的客戶。
但有些工程師會很想要展現所謂的「專業能力」，然後幹一些其實不太適合客戶的事情。例如：過度設計、過早最佳化、寫沒必要的工具……等等。
Note
這些錯誤我都犯過……。
雖然一部分會歸咎於經驗與能力不足，但我覺得理解他人的能力也是很重要的部分。做出來的東西之所以有落差，如果不是能力不足，就是溝通不良。正確了解客戶需求的層級，只做適合客戶的內容，才是溝通的目標。說穿了就是正確理解並適當實現他人的願望。
另外有些工程師會很討厭去同步需求，覺得這應該是 PM 的工作，不應該由工程師來做。雖然這有時候是公司的制度問題，我也可以理解職業劃分的思維，不過我還是傾向以能力為主體的方向來思考。軟體工程師應該不只是「使用軟體工程能力」的人，而是「透過軟體工程能力來解決問題」的人。溝通並搞清楚客戶的需求，也算是解決問題的一部分。
當然有些客戶沒辦法溝通，那是另外一件事情。