項目上線后，如何減少客戶對交付成果的質疑

背景

背景描述

早些年前，軟件行業剛剛興起，當時的軟件產品功能簡單，用途單一，軟件研發方法也都遵循“計劃-->需求分析-->設計-->編碼-->測試-->運維”這樣一個流程按部就班的開發，最后產品基本能滿足客戶的需求。這種研發方法被很多公司沿用至今，可與之前不同的是，客戶對項目交付成果的質疑越來越多。

有家公司就問了類似的問題：“項目上線后客戶提出質疑，導致交付出現問題，項目管理上如何操作可以避免或減少這種情況的發生？”在交流過程中，我們了解到該公司在使用傳統的瀑布模型進行研發，同時也了解了客戶主要有哪些方面的質疑。

質疑描述

客戶質疑大致有三方面，一方面：交付成果和合同要求對不上：客戶認為合同明明說的是A，可是產品做出來的功能卻是B，比如地處西北的客戶吃餃子，想蘸點老陳醋，簽了份合同讓公司提供“餃子蘸料”，接單的是東北人，根據“蘸料”開發了一瓶醬油，于是客戶認為自己表述的足夠清晰，是公司內部管理不善造成功能開發錯誤；另一方面，產品按需求研發，但是整個研發過程中，客戶一直沒有接收到研發團隊關于產品或研發進度的信息，導致客戶對項目的焦慮，從而對產品產生質疑；還有一方面，有的產品按需求正確開發，也定時向客戶匯報進度，可交付時客戶認為功能不夠，在當下市場沒有競爭力就像當下做電商不支持移動支付；這些質疑讓公司很頭疼。

你是否也經歷著同樣的問題？如何減少客戶對交付成果的質疑？

問題分析

上文提到的質疑可以概括為：雙方對需求理解不一致，產品功能規劃沒有隨市場變化而刷新和溝通不足引發客戶不了解情況而焦慮。接下來我們推測下產生這些質疑的原因。

雙方對需求理解不一致

需求被制定后，可能沒有做進一步澄清，導致開發人員理解有誤，照著自己的想法開發出偏離預想的產品；或者客戶想表達的意思是A，但是由于自己表述有問題，需求描述成了B，那自然無法開發出令人滿意的交付成果。

還有一種情況更要命：客戶在制定需求的時候自己只有一個模糊的想法，具體要做的自己也不清楚，這種情況按計劃做出的產品想令客戶滿意就只能靠運氣了。

溝通不足，客戶因不了解情況而焦慮

我們試想一種場景：小張在網上買了個手機想要送給女朋友作為生日禮物，眼看生日快到了，商品顯示已發貨，卻始終看不到詳細的物流信息，客服也不告知小張商品目前是啥情況，換做你是小張，你急不急，就算商品按時到達，也會因為物流過程不可見而而很難獲得好評。

實際生產中也是一樣，客戶下了訂單之后，研發團隊一直悶頭干活，不與客戶溝通項目進度，客戶一樣會因為不了解項目進展而焦慮，最終對交付成果產生質疑。

產品功能規劃沒有隨市場變化而刷新

正所謂計劃不如變化，傳統研發模式是計劃驅動，而市場是瞬息萬變的，想要占領市場，需求變更在所難免。計劃就像一張地圖，一條路經歷世事變遷會發生很多變化，按照一張兩年前的地圖找上面標注的店鋪很可能走了半天也找不到地方；同樣，照著兩年前制定的計劃做出的產品，按交付時的背景去審視它，會給人一種“乃不知有漢，無論魏晉”的感覺，客戶難免會對產品提出質疑。

解決措施

傳統研發模式的交付類似流水作業：做完計劃和需求，就可以按照計劃進行開發，然后交付驗收。在這種研發模式中，客戶參與度類似U型：客戶在計劃階段和定義需求階段參與較多；之后項目進入研發階段，客戶參與度驟降甚至不參與；最后交付階段客戶參與進來，進行驗收工作。客戶在研發階段參與度降低，很容易造成雙方對產品溝通不到位：比如需求被錯誤理解沒人引導；市場上出現新功能，產品想不到變通等，這些“不到位”最后都會轉化成對交付成果的質疑。為避免這種情況，可以嘗試做敏捷轉型，客戶對交付成果的質疑在所難免，但敏捷可以大大減少客戶的質疑。

敏捷開發的價值觀是：“個體和互動重于流程和工具；可工作的軟件重于面面俱到的文檔；客戶合作重于合同談判；響應變化重于遵循計劃，盡管右側重要，但左側更重要”。敏捷按迭代進行交付，每個迭代持續時間不會很長；同時敏捷更注重給客戶帶來的價值，客戶（或客戶代表）可以全生命周期的參與并影響整個項目。下圖是傳統開發和敏捷開發客戶在不同生命周期參與度對比。

敏捷具體可以從哪幾個方面減少客戶對交付成果的質疑呢？

使用標準的用戶故事方法分析和記錄需求，確保雙方理解一致

傳統研發模式以計劃為導向，使用詳細的文檔比如：概要設計、詳細設計記錄需求，這種方法有他的優點，但是缺點也比較明顯：首先制作計劃需要花費很長的時間，其次需求描述過于產品化，不易解讀。

敏捷開發以價值為導向，區別于傳統研發模式的文檔，敏捷開發使用用戶故事記錄需求：用戶故事是站在用戶的角度去描述需求，并且給出用戶期待實現的價值，這樣開發人員更容易開發出客戶真正想要的功能（用戶故事細節詳見《 “用戶故事等于需求說明”——你一定沒有寫好用戶故事》）。

舉個例子，使用用戶故事描述需求：客戶吃餃子想要一瓶蘸料，用戶故事可以寫成：“作為生長在山西的小王，我想要一瓶餃子蘸料，以便于讓餃子吃起來更美味”。通過用戶故事可以看出，客戶是“生長在山西的”，所以餃子蘸料可能是老陳醋而不是醬油，交付起來會比“客戶想要一瓶蘸料”準確很多。

另外用戶故事并不是寫好之后就一成不變的。用戶故事的“INVEST”原則中的“N（可商議的）”原則要求用戶故事是可以商議的。當開發人員不理解用戶故事中的需求，可以將問題拋出來，由產品負責人進行澄清，直到雙方對需求的理解達成共識。下圖是使用DevCloud編寫的用戶故事，以及需求分析討論。

綜上所述，使用標準的用戶故事記錄需求，可以解決雙方對需求理解不一致的問題，從而減少客戶對交付成果的質疑。

通過評審會等方式與客戶保持定期或不定期的溝通交流

敏捷開發方法眾多，Scrum是最主流的敏捷方法之一。Scrum中有四個活動：計劃會議，每日站會，評審會議，回顧會議，每個活動都幫助著團隊更好的踐行敏捷，更高質量的交付，各活動詳細信息如下：

從表中可以看出，計劃會議，每日站會，評審會議都是圍繞產品開展的。評審會議在每個迭代即將結束時開展，定期邀請客戶參加評審會議是最直接有效的與客戶溝通的方法：會上團隊向客戶演示迭代交付成果，客戶通過演示了解產品已經具備哪些功能，哪些功能沒有完成，哪些功能和理想中有偏差，對于偏差部分可以和開發團隊溝通，后續迭代進行改進。

如果客戶很忙或者時間不穩定，不能參與每次評審會議，那么可不定期邀請客戶參加每日站會，站會每天早晨都進行，客戶可以在有空或有興趣的時候參與。每日站會不是必須和客戶一起開展，但是通過站會客戶能了解到小部分交付成果以及團隊工作狀態，減少焦慮。客戶不參加會議的話，可由產品負責人在評審會議結束后整理評審會議紀要，通過拜訪，電話，郵件等形式告知客戶，讓客戶了解當前項目進度，減少焦慮，從而減少對交付成果的質疑。

對標市面主流產品，更新差異特性，讓產品跟隨市場變化

除了澄清需求、增強與客戶的溝通等手段之外，我們還可以帶著客戶，用產品對標市面上其他主流產品，找到差異并更新，減少客戶的質疑。比如一款電商產品的結算功能在計劃時未考慮移動支付，只支持網銀支付，按傳統模式運作項目的話，最終交付時產品不會支持移動支付，使用起來會很麻煩；如果使用Scrum運作項目，可以在項目進行過程中，或者評審產品的支付功能時，對標主流電商產品，這時候會發現移動支付是目前最主流的在線支付方式，產品需要支持移動支付，所以可將“結算功能支持移動支付”作為一個優先級高的新需求加入項目，并與產品負責人協商下個迭代或盡可能快的完成這個需求，讓產品的支付功能跟隨市場變化，增加產品的競爭力。

參考附錄

Kenneth S.Rubin:Scrum精髓. 北京：清華大學出版社

Scrum Guide

DevOps 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。