摘要：對標市面主流產品，更新差別特性，讓產品跟隨市場變化。
本文分享自華爲雲社區《項目上線後，如何減小客戶對交付成果的質疑》，原文做者：敏捷的小智。運維
背景
背景描述
早些年前，軟件行業剛剛興起，當時的軟件產品功能簡單，用途單一，軟件研發方法也都遵循「計劃-->需求分析-->設計-->編碼-->測試-->運維」這樣一個流程循序漸進的開發，最後產品基本能知足客戶的需求。這種研發方法被不少公司沿用至今，可與以前不一樣的是，客戶對項目交付成果的質疑愈來愈多。ide
有家公司就問了相似的問題：「項目上線後客戶提出質疑，致使交付出現問題，項目管理上如何操做能夠避免或減小這種狀況的發生？」在交流過程當中，咱們瞭解到該公司在使用傳統的瀑布模型進行研發，同時也瞭解了客戶主要有哪些方面的質疑。工具
質疑描述
客戶質疑大體有三方面，一方面：交付成果和合同要求對不上：客戶認爲合同明明說的是A，但是產品作出來的功能倒是B，好比地處西北的客戶吃餃子，想蘸點老陳醋，簽了份合同讓公司提供「餃子蘸料」，接單的是東北人，根據「蘸料」開發了一瓶醬油，因而客戶認爲本身表述的足夠清晰，是公司內部管理不善形成功能開發錯誤；另外一方面，產品按需求研發，可是整個研發過程當中，客戶一直沒有接收到研發團隊關於產品或研發進度的信息，致使客戶對項目的焦慮，從而對產品產生質疑；還有一方面，有的產品按需求正確開發，也定時向客戶彙報進度，可交付時客戶認爲功能不夠，在當下市場沒有競爭力就像當下作電商不支持移動支付；這些質疑讓公司很頭疼。測試
你是否也經歷着一樣的問題？如何減小客戶對交付成果的質疑？ui
問題分析
上文提到的質疑能夠歸納爲：雙方對需求理解不一致，產品功能規劃沒有隨市場變化而刷新和溝通不足引起客戶不瞭解狀況而焦慮。接下來咱們推測下產生這些質疑的緣由。編碼
雙方對需求理解不一致
需求被制定後，可能沒有作進一步澄清，致使開發人員理解有誤，照着本身的想法開發出偏離預想的產品；或者客戶想表達的意思是A，可是因爲本身表述有問題，需求描述成了B，那天然沒法開發出使人滿意的交付成果。url
還有一種狀況更要命：客戶在制定需求的時候本身只有一個模糊的想法，具體要作的本身也不清楚，這種狀況按計劃作出的產品想令客戶滿意就只能靠運氣了。spa
溝通不足，客戶因不瞭解狀況而焦慮
咱們試想一種場景：小張在網上買了個手機想要送給女友做爲生日禮物，眼看生日快到了，商品顯示已發貨，卻始終看不到詳細的物流信息，客服也不告知小張商品目前是啥狀況，換作你是小張，你急不急，就算商品按時到達，也會由於物流過程不可見而而很難得到好評。.net
實際生產中也是同樣，客戶下了訂單以後，研發團隊一直悶頭幹活，不與客戶溝通項目進度，客戶同樣會由於不瞭解項目進展而焦慮，最終對交付成果產生質疑。設計
產品功能規劃沒有隨市場變化而刷新
正所謂計劃不如變化，傳統研發模式是計劃驅動，而市場是瞬息萬變的，想要佔領市場，需求變動在所不免。計劃就像一張地圖，一條路經歷世事變遷會發生不少變化，按照一張兩年前的地圖找上面標註的店鋪極可能走了半天也找不到地方；一樣，照着兩年前制定的計劃作出的產品，按交付時的背景去審視它，會給人一種「乃不知有漢，不管魏晉」的感受，客戶不免會對產品提出質疑。
解決措施
傳統研發模式的交付相似流水做業：作完計劃和需求，就能夠按照計劃進行開發，而後交付驗收。在這種研發模式中，客戶參與度相似U型：客戶在計劃階段和定義需求階段參與較多；以後項目進入研發階段，客戶參與度驟降甚至不參與；最後交付階段客戶參與進來，進行驗收工做。客戶在研發階段參與度下降，很容易形成雙方對產品溝通不到位：好比需求被錯誤理解沒人引導；市場上出現新功能，產品想不到變通等，這些「不到位」最後都會轉化成對交付成果的質疑。爲避免這種狀況，能夠嘗試作敏捷轉型，客戶對交付成果的質疑在所不免，但敏捷能夠大大減小客戶的質疑。
敏捷開發的價值觀是：「個體和互動重於流程和工具；可工做的軟件重於面面俱到的文檔；客戶合做重於合同談判；響應變化重於遵循計劃，儘管右側重要，但左側更重要」。敏捷按迭代進行交付，每一個迭代持續時間不會很長；同時敏捷更注重給客戶帶來的價值，客戶（或客戶表明）能夠全生命週期的參與並影響整個項目。下圖是傳統開發和敏捷開發客戶在不一樣生命週期參與度對比。
敏捷具體能夠從哪幾個方面減小客戶對交付成果的質疑呢？
使用標準的用戶故事方法分析和記錄需求，確保雙方理解一致
傳統研發模式以計劃爲導向，使用詳細的文檔好比：概要設計、詳細設計記錄需求，這種方法有他的優勢，可是缺點也比較明顯：首先製做計劃須要花費很長的時間，其次需求描述過於產品化，不易解讀。
敏捷開發以價值爲導向，區別於傳統研發模式的文檔，敏捷開發使用用戶故事記錄需求：用戶故事是站在用戶的角度去描述需求，而且給出用戶期待實現的價值，這樣開發人員更容易開發出客戶真正想要的功能（用戶故事細節詳見 《 「用戶故事等於需求說明」——你必定沒有寫好用戶故事》 ）。
舉個例子，使用用戶故事描述需求：客戶吃餃子想要一瓶蘸料，用戶故事能夠寫成：「做爲生長在山西的小王，我想要一瓶餃子蘸料，以便於讓餃子吃起來更美味」。經過用戶故事能夠看出，客戶是「生長在山西的」，因此餃子蘸料多是老陳醋而不是醬油，交付起來會比「客戶想要一瓶蘸料」準確不少。
另外用戶故事並非寫好以後就一成不變的。用戶故事的「INVEST」原則中的「N（可商議的）」原則要求用戶故事是能夠商議的。當開發人員不理解用戶故事中的需求，能夠將問題拋出來，由產品負責人進行澄清，直到雙方對需求的理解達成共識。下圖是使用DevCloud編寫的用戶故事，以及需求分析討論。
綜上所述，使用標準的用戶故事記錄需求，能夠解決雙方對需求理解不一致的問題，從而減小客戶對交付成果的質疑。
經過評審會等方式與客戶保持按期或不按期的溝通交流
敏捷開發方法衆多，Scrum是最主流的敏捷方法之一。Scrum中有四個活動：計劃會議，每日站會，評審會議，回顧會議，每一個活動都幫助着團隊更好的踐行敏捷，更高質量的交付，各活動詳細信息以下：
從表中能夠看出，計劃會議，每日站會，評審會議都是圍繞產品開展的。評審會議在每一個迭代即將結束時開展，按期邀請客戶參加評審會議是最直接有效的與客戶溝通的方法：會上團隊向客戶演示迭代交付成果，客戶經過演示瞭解產品已經具有哪些功能，哪些功能沒有完成，哪些功能和理想中有誤差，對於誤差部分能夠和開發團隊溝通，後續迭代進行改進。
若是客戶很忙或者時間不穩定，不能參與每次評審會議，那麼可不按期邀請客戶參加每日站會，站會天天早晨都進行，客戶能夠在有空或有興趣的時候參與。每日站會不是必須和客戶一塊兒開展，可是經過站會客戶能瞭解到小部分交付成果以及團隊工做狀態，減小焦慮。客戶不參加會議的話，可由產品負責人在評審會議結束後整理評審會議紀要，經過拜訪，電話，郵件等形式告知客戶，讓客戶瞭解當前項目進度，減小焦慮，從而減小對交付成果的質疑。
對標市面主流產品，更新差別特性，讓產品跟隨市場變化
除了澄清需求、加強與客戶的溝通等手段以外，咱們還能夠帶着客戶，用產品對標市面上其餘主流產品，找到差別並更新，減小客戶的質疑。好比一款電商產品的結算功能在計劃時未考慮移動支付，只支持網銀支付，按傳統模式運做項目的話，最終交付時產品不會支持移動支付，使用起來會很麻煩；若是使用Scrum運做項目，能夠在項目進行過程當中，或者評審產品的支付功能時，對標主流電商產品，這時候會發現移動支付是目前最主流的在線支付方式，產品須要支持移動支付，因此可將「結算功能支持移動支付」做爲一個優先級高的新需求加入項目，並與產品負責人協商下個迭代或儘量快的完成這個需求，讓產品的支付功能跟隨市場變化，增長產品的競爭力。
參考附錄
Kenneth S.Rubin:Scrum精髓. 北京：清華大學出版社
Scrum Guide