剛剛看到有個(gè)哥們兒講他的客戶讓他很郁悶，我有點(diǎn)想法，整理如下：

首先，我覺得開發(fā)人員遇到這樣的郁悶是因?yàn)榭刂菩枨笞兏Ψ驔]有做足。原因有幾點(diǎn)：
1.涉及需求變更的東西不應(yīng)該由最終使用的用戶和一線開發(fā)人員來溝通，這樣的溝通費(fèi)時(shí)費(fèi)力而且不具有權(quán)威性。
2.開發(fā)人員直接向客戶匯報(bào)的工作量往往比實(shí)際工作量要低，而且低的比較多。原因很簡單：客戶問開發(fā)人員一個(gè)功能是否困難的時(shí)候，一般技術(shù)人員往往只考慮了單項(xiàng)功能的復(fù)雜度，而可能對這個(gè)需求變更對整個(gè)系統(tǒng)的工作量估計(jì)不足（比如美工的工作量、該功能引發(fā)的管理功能的工作量、測試工作量等等）。
這種情況會對項(xiàng)目產(chǎn)生多個(gè)負(fù)面影響：a.向客戶提供一個(gè)低于實(shí)際值的工作量，導(dǎo)致客戶期望高，而實(shí)際無法按時(shí)完成導(dǎo)致客戶失望大，降低用戶滿意度。b.因?yàn)榭蛻魪拈_發(fā)人員口中聽到的工作量總是比從項(xiàng)目經(jīng)理口中聽到的工作量低，造成客戶對項(xiàng)目組內(nèi)部不一致，溝通不足的感覺。c.因?yàn)榭蛻魪拈_發(fā)人員口中聽到的工作量總是比從項(xiàng)目經(jīng)理口中聽到的工作量低，引誘客戶喜歡直接向開發(fā)人員提出需求變更，造成惡性循環(huán)，直接導(dǎo)致了項(xiàng)目組沒法按時(shí)拿到獎金，士氣下降。

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

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

從我做項(xiàng)目幾年的經(jīng)驗(yàn)來看，蠻不講理的客戶不是沒有，但是是極少數(shù)，大多數(shù)客戶，尤其是客戶方項(xiàng)目經(jīng)理都是通情達(dá)理的人。所以，只要你言之有理，對方都有可能接納。