PM項目案例：產(chǎn)品功能不適用，甲乙雙方如何平息紛爭

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

本期案例

項目類別：IT

崗位：項目經(jīng)理

案例背景：

需求調(diào)研和打合都是跟甲方領(lǐng)導(dǎo)進(jìn)行的，已順利通過簽字確認(rèn)，開發(fā)完成，到達(dá)培訓(xùn)驗收節(jié)點。

遇到的問題：

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

待解決的問題：

對于客戶方，領(lǐng)導(dǎo)簽字確認(rèn)但實際使用者不適用問題如何處理?對于驗收節(jié)點，甲乙方協(xié)調(diào)不一致的，如何處理?

主治醫(yī)師

01昵稱：聞道有先后

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

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

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

②如果新增的成本過多，可向上級反饋這件事，請上級出面與甲方領(lǐng)導(dǎo)溝通協(xié)商，得到進(jìn)一步的確認(rèn)后再行動。

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

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

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

02昵稱：米奇

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

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

正常版:

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

2、與實際使用人員進(jìn)行溝通，說明本次需求樣本采用高層級需求，并得到領(lǐng)導(dǎo)肯定，讓其認(rèn)可系統(tǒng)基本滿足使用需求，其中不適用部分為少數(shù)，并且收集其使用需求，承諾在某時間段內(nèi)完成更新或修改。

激進(jìn)版：

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

總結(jié)：

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

#我有話說#

@2022朱：

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

通過問題找解決辦法：首先項目初期相關(guān)方識別要細(xì)化，需求調(diào)研要包含到所有的相關(guān)方的期望，其次驗收標(biāo)準(zhǔn)驗收范圍需要明確，達(dá)到什么目標(biāo)才能進(jìn)行驗收等等。

其次項目進(jìn)行過程中，產(chǎn)品要多方面進(jìn)行確認(rèn)，所有相關(guān)方都要包含在內(nèi)確保滿足相關(guān)方的期望，最后產(chǎn)品在驗收前進(jìn)行試運行，出具試運行報告不符合項進(jìn)行修改。最后，達(dá)到使用驗收規(guī)定的標(biāo)準(zhǔn)后提交驗收申請。

@錯了別怪我：

可以看下實際使用者不適用的程度，如果是部分使用場景沒有覆蓋到，基礎(chǔ)業(yè)務(wù)流可以流轉(zhuǎn)的情況，那么建議梳理出現(xiàn)有功能模塊結(jié)合業(yè)務(wù)場景的使用幫助，沒有覆蓋到的情況看領(lǐng)導(dǎo)是賣人情給他做還是另外再簽合同補充開發(fā);如果整個系統(tǒng)無法保證正常的業(yè)務(wù)流程和業(yè)務(wù)邏輯，那改造的代價估計大于重做。

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

①這個紕漏就是我們問題，現(xiàn)在補漏;

②我們調(diào)研好了排除萬難就能做;

最好還是領(lǐng)導(dǎo)之間先確認(rèn)說情況，工具人們再進(jìn)行下一步的動作。

@一碗鈔票：

1、首先，相關(guān)方識別和溝通沒有到位。需求調(diào)研，需要包括所有人相關(guān)方，本次案例沒有把運營或者用戶包含在內(nèi)。領(lǐng)導(dǎo)實操少，實際使用還是用戶或者運營人員清楚產(chǎn)品的實用性;

2、需求清單、需求驗收標(biāo)準(zhǔn)需要在項目合同中確定清楚，這個就是避免對方扯皮，交付后不承認(rèn);

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

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

問題處理辦法：

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

②領(lǐng)導(dǎo)簽字確定，該甩鍋的甩鍋;

③驗收節(jié)點提前溝通。

@SU：

案例中一共兩個問題：

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

第二個問題，實際是第一個問題的延續(xù)，第一個問題解決了，第二個問題就解決了。如果是乙方開發(fā)技術(shù)問題，乙方當(dāng)然需要修改;如果是甲方認(rèn)為適用性的問題，而乙方是按合同開發(fā)的，則甲方先修改再驗收屬于違反合同?？梢允褂脜f(xié)商、ADR，最好不要走到司法層面。

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

@七月：

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

1、按照簽字確認(rèn)的功能需求進(jìn)行對標(biāo)確認(rèn)，要求客戶驗收簽字;

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

3、將用戶已確認(rèn)的功能和需要修改的以及優(yōu)化項進(jìn)行梳理，商務(wù)介入談判，首先確認(rèn)開發(fā)是按照需求進(jìn)行的，通過對需求項的分析，確認(rèn)是優(yōu)化項還是新增功能，對于必須要整改的內(nèi)容，協(xié)商簽署補充協(xié)議，結(jié)束原協(xié)議的開發(fā)進(jìn)程，簽字驗收;

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