今天，我們邀請了希賽創造營的小伙伴們出謀劃策，通過剖析具體問題進而提出解決方案，讓大家在實際工作中可以有所參考。

本期案例

項目類別：IT

崗位：項目經理

案例背景：

需求調研和打合都是跟甲方領導進行的，已順利通過簽字確認，開發完成，到達培訓驗收節點。

遇到的問題：

培訓過程中，實際使用者反饋功能不適用，不支持驗收結項，甲方堅持先修改后驗收，乙方希望先驗收后修改。

待解決的問題：

對于客戶方，領導簽字確認但實際使用者不適用問題如何處理?對于驗收節點，甲乙方協調不一致的，如何處理?

主治醫師

01昵稱：聞道有先后

1、首先要確認使用者反饋需要修改的部分，是否屬于已簽核確認的工作范圍內。如果是，那沒說的，乖乖修改符合要求，一起校核驗收即可。

2、如果使用者反饋的功能超出既定的工作范圍，可分幾步走：

①團隊內部緊急評估，要完成這份額外的工作，需要新增的成本是多少。如果新增成本不多，內部協商一致后，可向上級反饋，是否同意免費修改。

②如果新增的成本過多，可向上級反饋這件事，請上級出面與甲方領導溝通協商，得到進一步的確認后再行動。

③如果領導同意免費修改，團隊可和實際使用者協商，要求實際使用者出具份變更請求(可告知其是免費改)，以最快的速度跑完變更流程后，即可著手修改，靜待校核驗收。

④如果確認使用者反饋的實際功能超出既定的范圍，且上級與甲方溝通失效。團隊需要整理下手上的資料，和甲方約定個時間召開會議，需要邀請甲方簽核的領導和自己的上級共同出席，共同協商來解決這個問題。最終目的都是要求甲方出具變更請求，以此請求為據來修改額外的需求。

⑤會上要商議確定好各自的需求和時間節點，簽字確認;會后及時發送會議記錄給甲方和團隊內部。然后依照既定的節奏來開展工作，直至完成驗收，達到節點目標。

02昵稱：米奇

其實這是一個項目需求管理應該自上而下還是自下而上的分歧。個人判斷在項目進行過程中應該就已經遇到過高層級需求和底層需求不符的情況了，只是當時這位項目經理考慮高層級需求優先度較高，有點忽視了基礎使用者的需求了。

其實在本次案例中，最好的處理時機是在確認高層級需求的同時將需求分發到底層使用者知曉，或在收集需求的時候同時兼顧底層使用者意見。次好機會是在研發過程中收集使用者意見并反饋給高層領導。但考慮到目前開發工作已經完成，建議可以從以下幾個方面入手。

正常版:

1、與甲方領導溝通，根據項目合同及需求溝通確認書與甲方領導進行協商，說明根據合同及需求確認情況，目前項目已屬于完成階段，懇請甲方領導進行付款流程并提交承諾書。后期將收集并分析實際使用者的需求，并將需求完善，進行升級或增量。但此刻需要領導支持，針對使用者進行高層推進。

2、與實際使用人員進行溝通，說明本次需求樣本采用高層級需求，并得到領導肯定，讓其認可系統基本滿足使用需求，其中不適用部分為少數，并且收集其使用需求，承諾在某時間段內完成更新或修改。

激進版：

召集甲方領導及甲方使用人員代表一起開需求溝通會，會上講明需求來源及需求原因，并說明如需針對使用者提出的問題進行二次開發，需要追加成本約XXX，并請甲方領導批示。此時需要堅持超出預算部分需要追加資金。大致兩至三次會議后甲方領導就會強力推進驗收了。

總結：

其實項目按照高層級需求去實現的，最終驗收應該也抓住高層級領導來處理。只要甲方領導同意強推，那么剩下的問題就非常好解決。但是強推的話需要和甲方領導有較好的業務關系，否則可能會做不了長期業務了。為了避免出現類似的問題，建議還是從需求初期就避免此類問題，或采用敏捷而非瀑布形式進行開發。

#我有話說#

@2022朱：

觀題目前存在幾個問題：譬如相關方識別不到位;范圍確認不到位(需求確認的目的未達成);項目監控過程未進行確認;驗收前未進行試運行。

通過問題找解決辦法：首先項目初期相關方識別要細化，需求調研要包含到所有的相關方的期望，其次驗收標準驗收范圍需要明確，達到什么目標才能進行驗收等等。

其次項目進行過程中，產品要多方面進行確認，所有相關方都要包含在內確保滿足相關方的期望，最后產品在驗收前進行試運行，出具試運行報告不符合項進行修改。最后，達到使用驗收規定的標準后提交驗收申請。

@錯了別怪我：

可以看下實際使用者不適用的程度，如果是部分使用場景沒有覆蓋到，基礎業務流可以流轉的情況，那么建議梳理出現有功能模塊結合業務場景的使用幫助，沒有覆蓋到的情況看領導是賣人情給他做還是另外再簽合同補充開發;如果整個系統無法保證正常的業務流程和業務邏輯，那改造的代價估計大于重做。

這個時候再去了解其他相關方的實際需求場景，還比較容易讓對方誤會：

①這個紕漏就是我們問題，現在補漏;

②我們調研好了排除萬難就能做;

最好還是領導之間先確認說情況，工具人們再進行下一步的動作。

@一碗鈔票：

1、首先，相關方識別和溝通沒有到位。需求調研，需要包括所有人相關方，本次案例沒有把運營或者用戶包含在內。領導實操少，實際使用還是用戶或者運營人員清楚產品的實用性;

2、需求清單、需求驗收標準需要在項目合同中確定清楚，這個就是避免對方扯皮，交付后不承認;

3、培訓驗收節點前，可推出測試版先行邀請用戶或者運營人員使用，提前收集意見;

4、制定培訓文檔和操作手冊，培訓演示操作手冊，讓使用者按照文檔操作。

問題處理辦法：

①實際使用者不適用問題，收集需求，按照優先級排期，該加錢的加錢;

②領導簽字確定，該甩鍋的甩鍋;

③驗收節點提前溝通。

@SU：

案例中一共兩個問題：

第一個問題，領導簽字代表甲方正式確認乙方開發有效，按照契約精神，乙方開發所付出的成本、人力都得到甲方驗收。而甲方實際使用者認為不適用的情況，是甲方內部上下溝通的問題，如果甲方需更改，雙方可協商走新開發項目流程，甲方與乙方重新確定開發內容及成本等。

第二個問題，實際是第一個問題的延續，第一個問題解決了，第二個問題就解決了。如果是乙方開發技術問題，乙方當然需要修改;如果是甲方認為適用性的問題，而乙方是按合同開發的，則甲方先修改再驗收屬于違反合同。可以使用協商、ADR，最好不要走到司法層面。

最后，解決問題的最好方式是雙方都通過協商，各讓一步，甲方不能讓乙方自己承擔重新開發或修改的成本。

@七月：

前期的溝通過程很明確，需求簽字確認。現在的問題是，在交付時，實際使用人員認為系統使用不好用，希望按照使用者的反饋進行功能修改。

1、按照簽字確認的功能需求進行對標確認，要求客戶驗收簽字;

2、同步收集使用者的修改建議，評估改動開發量以及實現可能性，或是對于某些建議可以使用現有功能進行彌補;

3、將用戶已確認的功能和需要修改的以及優化項進行梳理，商務介入談判，首先確認開發是按照需求進行的，通過對需求項的分析，確認是優化項還是新增功能，對于必須要整改的內容，協商簽署補充協議，結束原協議的開發進程，簽字驗收;

4、對于功能模糊的地方，對開發量進行分析，避免不必要的小功能扯皮，將原合同的約定內容盡可能的快速收尾。