來源：明天上線

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

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

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

一.沒有邊界帶來的問題

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

1.需求不能確定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.項目的交付標準沒有

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.多溝通多確認

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

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

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

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

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

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

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

結果就是項目組進行調整和修改，哪怕臨近項目上線的時間點。

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

一些想說的話

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

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

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