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

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

本期案例

項(xiàng)目類別：IT

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

案例背景：

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

遇到的問題：

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

待解決的問題：

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

主治醫(yī)師

01昵稱：聞道有先后

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

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

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

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

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

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

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

02昵稱：米奇

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

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

正常版:

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

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

激進(jìn)版：

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

總結(jié)：

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

#我有話說#

@2022朱：

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

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

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

@錯(cuò)了別怪我：

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

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

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

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

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

@一碗鈔票：

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

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

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

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

問題處理辦法：

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

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

③驗(yàn)收節(jié)點(diǎn)提前溝通。

@SU：

案例中一共兩個(gè)問題：

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

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

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

@七月：

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

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

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

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

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