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