剛剛看到有個哥們兒講他的客戶讓他很郁悶，我有點想法，整理如下：

首先，我覺得開發人員遇到這樣的郁悶是因為控制需求變更功夫沒有做足。原因有幾點：
1.涉及需求變更的東西不應該由最終使用的用戶和一線開發人員來溝通，這樣的溝通費時費力而且不具有權威性。
2.開發人員直接向客戶匯報的工作量往往比實際工作量要低，而且低的比較多。原因很簡單：客戶問開發人員一個功能是否困難的時候，一般技術人員往往只考慮了單項功能的復雜度，而可能對這個需求變更對整個系統的工作量估計不足（比如美工的工作量、該功能引發的管理功能的工作量、測試工作量等等）。
這種情況會對項目產生多個負面影響：a.向客戶提供一個低于實際值的工作量，導致客戶期望高，而實際無法按時完成導致客戶失望大，降低用戶滿意度。b.因為客戶從開發人員口中聽到的工作量總是比從項目經理口中聽到的工作量低，造成客戶對項目組內部不一致，溝通不足的感覺。c.因為客戶從開發人員口中聽到的工作量總是比從項目經理口中聽到的工作量低，引誘客戶喜歡直接向開發人員提出需求變更，造成惡性循環，直接導致了項目組沒法按時拿到獎金，士氣下降。

所以對于客戶提出的需求變更，一般技術人員最好的處理方式是：委婉的告訴客戶，這個問題需要項目經理來評估。哪怕用戶用挑釁、教訓的語氣和你講這個功能如何簡單，如何如何就可以實現，你都不能告訴他是否可以接受這個變更，更不能說實現需要多長時間。
拒絕了客戶之后并不是大功告成，你最好能夠早于客戶通知自己的項目經理，客戶想進行怎樣的需求變更，你自己對工作量的評估是怎么樣的。這樣可以給項目經理一個準備時間，來完善的考慮需求變更的影響。

對于項目經理，尤其是從開發一線轉向做項目經理的兄弟，應該主動的從項目全局來考慮一個變更的影響，而不是單純從技術角度考慮。最好能按照公司的規范和制度以及項目實際情況為自己積累一份check list，以免在考慮需求變更時遺漏一些事項。作為開發方更要強化對于需求變更的控制。
控制需求變更最理想的辦法當然是由客戶方、開發方的項目經理和需求顧問共同組織CCB(變更控制委員會)
，文檔化所有需求變更，雙方簽字然后歸檔需求變更。不過這樣比較難以實現。但是最起碼的要求是，必須由客戶方項目經理（也就是甲方最終用戶需要把需求變更匯總報告給甲方項目經理）向開發方項目經理提出需求變更，開發方項目經理評估工作量，并文檔化需求變更，在與客戶方負責人充分溝通后，使用正式方式將溝通結果（最好是打印出來給甲方簽字，最起碼是要求回執的電子郵件）通知客戶。必要的時候需要業務人員協助，比如要求簽署附加合同或者新開一個項目等等。

從我做項目幾年的經驗來看，蠻不講理的客戶不是沒有，但是是極少數，大多數客戶，尤其是客戶方項目經理都是通情達理的人。所以，只要你言之有理，對方都有可能接納。