來源：明天上線

最近一段時間，忙著一個項目的上線，也算是全程跟到尾，其中的累，想必跟過項目的人懂的都懂。

真心說句實在話，想做成任何一件事情，都沒有想象中的那么容易。

不知道大家有沒有遇到這樣的情況，就是一個項目，沒有明確到底要做什么，要交付給客戶的方案始終來回變化。在這樣的背景下，還是時間緊任務(wù)重，要求項目成員抓緊開發(fā)上線。其結(jié)果，也就可想而知。項目里的人感覺到“累”，也就理所當(dāng)然了。

一.沒有邊界帶來的問題

先來說說一個沒有范圍邊界的項目，在推進執(zhí)行的過程中會遇到的問題。

1.需求不能確定

很顯然，不用多說，范圍不明確，首當(dāng)其沖的就是需求的不確定，這可就難倒產(chǎn)品經(jīng)理了。

其實，無論是外部項目還是公司內(nèi)部產(chǎn)品，明確的范圍是前提，在這個前提下，才有能夠生根發(fā)芽的土壤。

在項目制的運行體系下，一般都會有項目經(jīng)理這樣的角色，TA在前期的主要作用，就是要和甲方明確對方的需求，然后給出相應(yīng)的解決方案。這是作為項目經(jīng)理這個角色所應(yīng)該做到的，也是必須要做到的。

在有了確定的范圍后，接下來要做的，就是產(chǎn)品經(jīng)理根據(jù)對應(yīng)的需求內(nèi)容，提供相對應(yīng)的解決方案。在這個階段的時候，如果產(chǎn)品經(jīng)理有不明確的地方，其實是可以直接面對甲方的。

那如果項目從一開始，就沒有清晰的目標(biāo)，在這樣的情況下，產(chǎn)品經(jīng)理該如何展開工作呢？我們能做的，就是根據(jù)項目經(jīng)理目前能夠掌握的信息來規(guī)劃產(chǎn)品，盡自己最大的努力，提供目前所知的最好的解決方案，也僅能如此而已。

以我們自己的項目來舉例，最開始的時候，項目經(jīng)理提供的信息是項目會分成1、2、3期來分期實施，但是每一期里到底要實現(xiàn)哪些功能并沒有敲定。比如說1期里，剛開始說不要A模塊，過了幾天，又說A模塊要有，再過幾天又說A模塊可以先只實現(xiàn)其中的幾個功能，再后來又說因為技術(shù)對接原因A模塊又要做調(diào)整。

在我們的項目中，像上面的情況比比皆是，產(chǎn)品方案改了又改，技術(shù)評審提了又提。要知道，每一次的改動和變化，都會帶來很大的機會成本，會造成很多的資源浪費，也會消磨掉大家的熱情。在來回改了3、4次后，有個開發(fā)同事說的話，很能代表大家的狀態(tài)，他說“剛開始做的時候還很有動力和目標(biāo)，改著改著，已經(jīng)不知道干啥了，也不想干啥了”。

可想而知，項目范圍的不確定，勢必造成需求的模糊不清，必然帶來產(chǎn)品方案的搖擺不定。

做項目，每一次變化，都是執(zhí)行人的災(zāi)難。

2.開發(fā)優(yōu)先級排期沒發(fā)做

項目的范圍不明確，產(chǎn)品的需求就不確定，這樣帶來的結(jié)果就是開發(fā)工作排期的問題。

在正常的流程下，到了開發(fā)工作的階段，產(chǎn)品的需求基本上都是定稿的，并且應(yīng)該是經(jīng)過評審可落地的那部分。有了這樣的前提和基礎(chǔ)，在分配開發(fā)工作的環(huán)節(jié)才能夠有條不紊的進行。

但是如果在一切都還是待定的情況下，僅僅指望開發(fā)自己去摸索去領(lǐng)悟項目的內(nèi)容，這是不現(xiàn)實的，也是不可能做得到的。

在這樣什么都不明確的情況下，過早的讓開發(fā)接入也是比較欠妥的。這樣往往會導(dǎo)致什么情況呢，那就是開發(fā)所做的架構(gòu)規(guī)劃和開發(fā)工期，會被不斷的來回修改，最終的結(jié)果就是啥也干不下去。

說回我們這個項目的例子，最初的方案，1期只做基礎(chǔ)的購買流程，2期開始深入優(yōu)化，3期開始軟硬件整體升級。產(chǎn)品需求也是這樣安排的，開發(fā)優(yōu)先級也是這樣做的。然后在某一次內(nèi)部會議后，又被改成了1期時間點要上線的內(nèi)容，包括之前規(guī)劃的1期+3期的內(nèi)容。再到一次內(nèi)測后，又改成1期時間點要上線的內(nèi)容，包括之前規(guī)劃的1期+2期+3期的全部。你沒看錯，就是時間點不變，但是內(nèi)容是全部。

然后就是無限的惡性循環(huán)，最后的結(jié)果就是，產(chǎn)品沒有主見，開發(fā)沒有方向，就這樣在混沌中繼續(xù)。

做項目，如果從一開始就想著一步到位，那基本上也就離“做不好”不遠了。

3.項目的交付標(biāo)準(zhǔn)沒有

如果上面的需求和開發(fā)都沒有很好的規(guī)劃和執(zhí)行，可想而知，項目的最終交付會是什么樣子，那該是有多么的災(zāi)難。

所謂項目的交付，在我的理解里，就是按照項目預(yù)先規(guī)劃好的方案，分階段在規(guī)定的時間內(nèi)高質(zhì)量完成對應(yīng)的內(nèi)容。

一般情況下，項目的范圍明確好之后，就會形成相對應(yīng)的解決方案，在這個解決方案里所涉及的點，就是最終要交付的點，就是最終項目要驗收的點。

交付團隊一般會做什么事情呢？那就是根據(jù)項目的規(guī)劃，要明確好每一期要交付的內(nèi)容。而為了最終能夠順利交付，他們還需要進行相應(yīng)流程的測試、模擬環(huán)境的搭建、賬號體系的準(zhǔn)備、用戶培訓(xùn)手冊的準(zhǔn)備等等相關(guān)的配套服務(wù)，其實事情還是挺多的。

那如果項目的范圍變化了，也就意味著他們的那一些列工作都需要進行相對應(yīng)的調(diào)整。

還是以上面項目的1期、2期、3期內(nèi)容為例，剛開始的時候，按照1期的交付內(nèi)容準(zhǔn)備相應(yīng)的內(nèi)容，并且經(jīng)過測試，已基本符合相關(guān)方的要求。接著就是交付內(nèi)容的變化，從1期+3期，再到后來的全部。想必那段時間，交付團隊的工作一定是十分的忙碌且迷茫吧。

以上，就是一個范圍不明確的項目，給產(chǎn)品團隊、開發(fā)團隊、交付團隊所帶來的影響和挑戰(zhàn)。這樣的不明確，其實是對團隊的極大消耗，無論是時間還是精力，每個人都付出了很多，但最終的結(jié)果卻是所有人都不滿意。

二.如何盡量規(guī)避

上面說的那些問題，是不是就無解了呢，其實也未必，經(jīng)過對項目的復(fù)盤，還是有能夠解決的辦法的。

1.明確核心干系人的期望

所有的項目，最終都是要為人服務(wù)的，那就需要明確項目中的干系人，對這個項目的期望和所希望能夠達成的目標(biāo)是什么，這是很關(guān)鍵的一個點，是決定項目最終是否成功的關(guān)鍵。

當(dāng)然，在明確每個人的期望之前，是需要識別出項目中的關(guān)系人，說白了就是誰對這個項目有話語權(quán)，誰的決定能夠左右項目的內(nèi)容。如果有遺漏，那么肯定會在某個時刻，對項目產(chǎn)生不可逆的影響。

上面舉例的項目中，我們就是犯了這樣的錯誤。在前期的調(diào)研和方案提報的過程中，都沒有征詢技術(shù)負責(zé)人的相關(guān)意見，項目經(jīng)理也就理所應(yīng)當(dāng)?shù)囊詾樗o的方案就是最合理的?？墒蔷驮陧椖?期的時間點快結(jié)束的時候，這個技術(shù)負責(zé)人提出了他的想法，而他的這些想法，就直接打亂了項目的1、2、3期規(guī)劃和開發(fā)節(jié)奏。

當(dāng)我們識別出了項目中的核心干系人之后，緊接著要判斷的，就是這些干系人的權(quán)力、職責(zé)、和影響力。這是很關(guān)鍵的，也是一個項目經(jīng)理很核心的能力要求。在掌握了以上基本信息后，就需要和每個干系人進行深度的溝通，深度挖掘他們的需求，洞察他們的真實意圖。這是很難的，但是也是必需的，不得不做的事情。

明確了他們的核心訴求之后，如果大家目標(biāo)都一致，那當(dāng)然是皆大歡喜。但是，現(xiàn)實情況往往是每個人所關(guān)注的點都不一樣，而且很多時候還會沖突。這時候，項目經(jīng)理要做的，就是權(quán)衡利弊，有的放矢。

像我們舉例的項目中，甲方領(lǐng)導(dǎo)的訴求是在他的任期內(nèi)，打造一個業(yè)內(nèi)標(biāo)桿的成功案例；甲方下面具體做事的人要求是，系統(tǒng)平穩(wěn)過渡，不要一下子就大刀闊斧的切換。我們公司領(lǐng)導(dǎo)的訴求是開拓對方市場，技術(shù)經(jīng)理的訴求是將所有的成熟方案應(yīng)用落地。

之所以我們后面會進行頻繁的變更，也就是從一開始并沒有十分的明確他們的訴求點，而在我們的項目中，他們每個人的話語權(quán)都挺重，每個人的要求都需要滿足。

識別項目干系人，明確他們的期望，了解他們的動機，知曉他們的目標(biāo)。然后進行匯總、權(quán)衡，最后形成讓各方都滿意的方案。

2.調(diào)整開發(fā)節(jié)奏

唯一不變的就是變化，為了適應(yīng)現(xiàn)在的項目節(jié)奏，小步快跑快速迭代，敏捷開發(fā)及時反饋，才能夠適應(yīng)不斷變化的節(jié)奏。

以前的項目開發(fā)流程，所遵循的基本上都是嚴格意義上的控制，也就是所謂的結(jié)構(gòu)化開發(fā)方法。基本上都是按照項目規(guī)劃-系統(tǒng)分析-系統(tǒng)設(shè)計-系統(tǒng)開發(fā)-系統(tǒng)測試-系統(tǒng)交付，這樣的流程來操作的。而且每一步之間都有強依賴關(guān)系，下一步的內(nèi)容要嚴格按照上一步規(guī)定好的內(nèi)容來進行。

這樣的方式，好處就是能夠比較按照流程推進，但是這對項目經(jīng)理和團隊的要求都比較高。而且這樣的方式，很難適應(yīng)和滿足快速變化的項目。

所以，如果項目的范圍在前期并不是很明確，可以嘗試換一種方式，迭代開發(fā)或者敏捷開發(fā)，都能夠很好的解決前期內(nèi)容不確定的情況。

將開發(fā)的交付按照周為維度來進行劃分，大家只考慮這一周要做的內(nèi)容。有變化要調(diào)整就直接記入下一個迭代周期中，快速的響應(yīng)，及時的處理。

到了項目后期，所有內(nèi)容都明確和固定之后，再慢慢將快速的迭代和長期的規(guī)劃相結(jié)合起來。

想要做好這點，最關(guān)鍵的還是要從心態(tài)上有所轉(zhuǎn)變。不要害怕改變，改變是肯定會有的。不要害怕調(diào)整，調(diào)整是在所難免的。我們要做的就是根據(jù)實際情況，做到靈活機動。

變化，從內(nèi)部開始，就要升華，從外部推動，就是妥協(xié)。

3.多溝通多確認

有效溝通，是團隊保持高效協(xié)作的前提。

由于每個人過往的經(jīng)驗、知識的結(jié)構(gòu)、認知的水平等差異，對待不同的事情會有不同的看法，對待相同的事情也會有理解的偏差。

如何才能消除這種團隊成員之間的信息差呢，以我目前的經(jīng)驗來看，多次頻繁溝通確認是十分有必要的。

很多時候，說的人和聽的人，完全是不能夠同步的。因為對說的人來說，他所講的，必定是他自己腦海中有成形的概念的內(nèi)容，也就是說他自己會在想象中構(gòu)建一個自己所理解的畫面。而且，他也天然的認為聽的人能夠懂。但是現(xiàn)實情況是，聽的人是一頭霧水。

這就需要雙方進行信息同步確認，說的人，可以引導(dǎo)聽的人將聽到的內(nèi)容用自己的方式理解一遍。聽的人，在有任何不確定的內(nèi)容的時候，都需要向說的人確認，避免理想當(dāng)然和不以為然。

還是以上面的項目來舉例，在前期溝通項目方案的過程中，技術(shù)負責(zé)人說表達出來的是將目前現(xiàn)有的方案進行賦能，而項目經(jīng)理的理解是將目前正在運行中的模式復(fù)制一份到當(dāng)前項目，然后項目經(jīng)理和其他所有執(zhí)行部門所傳達的也是項目經(jīng)理自己所理解的意思。

但是在項目的開發(fā)和執(zhí)行過程中，技術(shù)負責(zé)人提出了不同的要求和變化，因為在他的概念里，所謂的“現(xiàn)在的方案”內(nèi)容包括目前正在運行的項目和規(guī)劃中還未實現(xiàn)的模式，他的腦海中是最后的全面的東西，而且他想趁著新的項目，將他的一些想法進行落地。這樣也就導(dǎo)致了項目組所完成的內(nèi)容，在他眼里都是不值一提的舊東西，他想要的那些突破性的內(nèi)容沒有任何體現(xiàn)。

結(jié)果就是項目組進行調(diào)整和修改，哪怕臨近項目上線的時間點。

前期可以多花點時間，將問題說透，不留任何有異議的地方，方能保證規(guī)劃和執(zhí)行的統(tǒng)一。

一些想說的話

很多時候，并不是我們不想做，而是我們不知道怎么做。

很多時候，并不是我們不愿改，而是我們不知道怎么改。

很多時候，并不是我們不進步，而是我們不知道如何變。