1、背景介紹

　　從 2020 年三月底開始做一個設(shè)計管理平臺的項目，我被指派為這個項目的項目經(jīng)理，項目成員包括產(chǎn)品經(jīng)理（1）、后端（4）、前端（2）、UED（1）、UI（1），共 10 位成員。從項目正式啟動，到七月初，第一個被需求方、發(fā)起人都認(rèn)可的 V1.0 版本原型才確定。在這接近四個月的過程中，幾乎項目管理的全部坑都踩了個遍，特別是干系人管理、沖突管理以及變更管理與項目管理的基本要求幾乎完成全部背離。這個項目為何會走到這個幾乎失控的地步呢？

　　下面全面來進(jìn)行一下問題的分析，可以從項目籌備階段開始

　　1、 項目定位不清晰（干系人管理）

　　關(guān)于這個項目的定位，業(yè)務(wù)方領(lǐng)導(dǎo)與技術(shù)方領(lǐng)導(dǎo)有完全不同的定位，技術(shù)領(lǐng)導(dǎo)認(rèn)為應(yīng)該要設(shè)計管理平臺，而業(yè)務(wù)方領(lǐng)導(dǎo)明確表示我們需要的設(shè)計協(xié)同平臺，雙方經(jīng)過幾次交流，但是始終未能夠?qū)Ξa(chǎn)品的定位達(dá)成一致。產(chǎn)品經(jīng)理找需求方確認(rèn)過的需求，技術(shù)領(lǐng)導(dǎo)不認(rèn)可，不僅技術(shù)領(lǐng)導(dǎo)不認(rèn)可，甚至業(yè)務(wù)領(lǐng)導(dǎo)也不認(rèn)可。

　　此處項目經(jīng)理有較大責(zé)任，需求的確認(rèn)完全交由產(chǎn)品經(jīng)理處理，但是在項目的進(jìn)行過程中，明確發(fā)現(xiàn)產(chǎn)品經(jīng)理確認(rèn)的需求、設(shè)計的原型得不到技術(shù)領(lǐng)導(dǎo)與業(yè)務(wù)方的雙方的認(rèn)可，此時應(yīng)該組織需求討論會議，讓相關(guān)的干系人（技術(shù)領(lǐng)導(dǎo)、業(yè)務(wù)領(lǐng)導(dǎo)）需同時參加，明確 alpha 版本的需求。而不是只埋頭在進(jìn)度控制中，需求沒有得到核心干系人一致認(rèn)可的時候，做的越多，偏離越遠(yuǎn)。

　　2、 責(zé)任權(quán)限不清晰

　　項目中有產(chǎn)品經(jīng)理、項目經(jīng)理，在項目啟動階段并沒有明確說明產(chǎn)品經(jīng)理與項目經(jīng)理的職責(zé)與權(quán)限。產(chǎn)品經(jīng)理管理需求，但是未對干系人進(jìn)行有效管理，項目經(jīng)理此時要不要去強力干預(yù)對干系人進(jìn)行管理 ？

　　項目經(jīng)理是作為整個項目的負(fù)責(zé)人，但是常常被定義在技術(shù)負(fù)責(zé)人的位置，管理技術(shù)選型，開發(fā)進(jìn)度控制，沒有對整體項目的成敗負(fù)責(zé)，常常對著兩位老總不同的產(chǎn)品定位嘆氣，但是沒有采取有效的措施來解決這種問題。

　　3、迭代內(nèi)容周期控制（項目進(jìn)度計劃管理）

　　項目節(jié)點是在 6.30 號發(fā)布第一版，實際開發(fā)時間有兩個月，產(chǎn)品一邊出原型，開發(fā)同時同步進(jìn)行開發(fā)。按照約定的第一個原型版本，是有足夠的時間進(jìn)行開發(fā)的。這時對接的業(yè)務(wù)方要求增加四個審批流程，并且這四個流程可以循環(huán)往復(fù)交替進(jìn)行。當(dāng)時接到產(chǎn)品經(jīng)理的這個需求時，我第一反應(yīng)是拒絕的。這個地方描述增加一下產(chǎn)品經(jīng)理背景描述，產(chǎn)品經(jīng)理有深厚的行業(yè)背景，產(chǎn)品開發(fā)經(jīng)驗稍有不足。 我跟產(chǎn)品進(jìn)行溝通，詢問是否可以放到下個迭代，得到的回復(fù)是可以，但是沒有這個流程，用戶是無法使用這個產(chǎn)品的。我考慮到有當(dāng)時還有較為充沛的時間，同時這個需求設(shè)計到核心的功能，決定在這個開發(fā)周期內(nèi)將這個新增的流程功能開發(fā)完成。最終完成了任務(wù)流程功能的開發(fā)，但是由于業(yè)務(wù)邏輯較為復(fù)雜，一方面產(chǎn)品并未完全梳理清晰全部業(yè)務(wù)邏輯，另一方面，此功能為經(jīng)過充分測試，在一次產(chǎn)品演示的時候，技術(shù)領(lǐng)導(dǎo)表示該流程交互太復(fù)雜，業(yè)務(wù)領(lǐng)導(dǎo)表示這這個任務(wù)流程完全不是他想要的。

　　這里的問題是在需求原型確定的情況下，項目經(jīng)理應(yīng)該縮短每個迭代的任務(wù)周期，最多不超過三周。一個迭代版本的時間近兩個月的時間，最后核心干系人告訴你這不是他想要的。應(yīng)該在每完成一次迭代的時候，舉行迭代回顧會議，演示產(chǎn)品，讓核心干系人對階段成果進(jìn)行演示。必須完成第一個迭代的驗收，才能進(jìn)行下一個階段的開發(fā)工作。 如若不然，還不學(xué)學(xué)新技術(shù)實在。

　　4、變更控制嚴(yán)重缺乏（變更管理）

　　由于文件版本管理做為其他應(yīng)用獲取模型信息的一個統(tǒng)一入口，技術(shù)領(lǐng)導(dǎo)對項目比較關(guān)心，時常要求產(chǎn)品演示，同時針對產(chǎn)品提出許多改進(jìn)意見，態(tài)度較為強勢，產(chǎn)品經(jīng)理與我扛不住壓力，頻繁變更。由于這個變更，業(yè)務(wù)方是不知情的，所以變更后的產(chǎn)品同時又得不到業(yè)務(wù)方的認(rèn)可，這樣最后就導(dǎo)致了一個干系人不認(rèn)可、目標(biāo)用戶不接受的產(chǎn)品的產(chǎn)生。

　　項目經(jīng)理在這件事情上負(fù)有主要責(zé)任，作為一個項目經(jīng)理，一定需要嚴(yán)格的管控變更。如果要進(jìn)行變更，必須核心干系人同意，技術(shù)領(lǐng)導(dǎo)的優(yōu)化意見必須要業(yè)務(wù)領(lǐng)導(dǎo)認(rèn)可，才能執(zhí)行變更。并且變更是不在當(dāng)前迭代周期內(nèi)進(jìn)行的，把變更作為需求記錄起來，在下個迭代內(nèi)進(jìn)行討論開發(fā)。

　　這種情況在 PMO 的強力介入后，得到了極大的改善，推了一個核心干系人都滿意的 v1.0 版本原型，那么是怎么做到的呢 ？

　　1、強力的干系人管理。 每次進(jìn)行需求確認(rèn)時，確保全部干系人認(rèn)可。具體流程是先與業(yè)務(wù)對接人進(jìn)行需求討論，然后與需求領(lǐng)導(dǎo)進(jìn)行需求原型評審確認(rèn)（需求確認(rèn)時最好技術(shù)領(lǐng)導(dǎo)在場），最后與技術(shù)領(lǐng)導(dǎo)進(jìn)行原型評審確認(rèn)。若有異議，組織與業(yè)務(wù)領(lǐng)導(dǎo)的討論，直到雙方都同意該原型為止，最終確定原型為 1.0 版本。不管領(lǐng)導(dǎo)多么強勢，一定要堅持自己的立場，守住自己的原則，不跟著領(lǐng)導(dǎo)天馬行空，只做跟需求方確認(rèn)過的需求，其他一切需求都要經(jīng)過討論后再進(jìn)行設(shè)計開發(fā)。

　　2、嚴(yán)格的范圍控制。確定一個最小 mvp 進(jìn)行迭代，迭代周期改為 2~3 周，這兩到三周內(nèi)任何變更都不做，只記錄變更點，在下一個迭代啟動時，再進(jìn)行變更的討論。

　　3、強力推動項目。對于設(shè)計管理與設(shè)計協(xié)同的爭議，先不去管他。將爭議擱置，先看需求方當(dāng)前最需要什么東西，我們先在最小范圍內(nèi)，用最簡單的方式滿足其需求。擱置爭議，推動項目。

　　這個項目遇到的問題都是項目管理中較為常見的問題。 PMO 介入后，用這一套組合拳，雖然非常簡單，甚至是許多方法有點老生常談，但是很有效。項目的新原型，業(yè)務(wù)方與技術(shù)方領(lǐng)導(dǎo)都較為滿意。其實許多項目的點，我們開始也有做，但是沒有強有力的去執(zhí)行，遇到強勢的領(lǐng)導(dǎo)以及需求方就妥協(xié)了。這種妥協(xié)的結(jié)果只能是一個妥協(xié)的產(chǎn)品，在可用性、穩(wěn)健性上都無法得到保證。

　　項目經(jīng)理一定要有對整個項目負(fù)責(zé)的準(zhǔn)備，不要只把自己定義在進(jìn)度管理的小慈祥的微笑里。此外就是項目經(jīng)理必須做好干系人管理，同時在遇到外界壓力時，必須堅持自己的原則，此時的一分妥協(xié)，后期需要十分的加班去填坑。