沒有范圍邊界的項目,產品經理做起來有多累
相信跟過項目的產品經理都有這樣的感受,范圍邊界不明確,在推進執行的過程中就會遇到一些問題。那么,該如何規避這個問題呢?本文對此進行了分析,一起來看看吧。
最近一段時間,忙著一個項目的上線,也算是全程跟到尾,其中的累,想必跟過項目的人懂的都懂。
真心說句實在話,想做成任何一件事情,都沒有想象中的那么容易。
不知道大家有沒有遇到這樣的情況,就是一個項目,沒有明確到底要做什么,要交付給客戶的方案始終來回變化。在這樣的背景下,還是時間緊任務重,要求項目成員抓緊開發上線。其結果,也就可想而知。項目里的人感覺到“累”,也就理所當然了。
一、沒有邊界帶來的問題
先來說說一個沒有范圍邊界的項目,在推進執行的過程中會遇到的問題。
1. 需求不能確定
很顯然,不用多說,范圍不明確,首當其沖的就是需求的不確定,這可就難倒產品經理了。
其實,無論是外部項目還是公司內部產品,明確的范圍是前提,在這個前提下,才有能夠生根發芽的土壤。
在項目制的運行體系下,一般都會有項目經理這樣的角色,TA在前期的主要作用,就是要和甲方明確對方的需求,然后給出相應的解決方案。這是作為項目經理這個角色所應該做到的,也是必須要做到的。
在有了確定的范圍后,接下來要做的,就是產品經理根據對應的需求內容,提供相對應的解決方案。在這個階段的時候,如果產品經理有不明確的地方,其實是可以直接面對甲方的。
那如果項目從一開始,就沒有清晰的目標,在這樣的情況下,產品經理該如何展開工作呢?我們能做的,就是根據項目經理目前能夠掌握的信息來規劃產品,盡自己最大的努力,提供目前所知的最好的解決方案,也僅能如此而已。
以我們自己的項目來舉例,最開始的時候,項目經理提供的信息是項目會分成1、2、3期來分期實施,但是每一期里到底要實現哪些功能并沒有敲定。比如說1期里,剛開始說不要A模塊,過了幾天,又說A模塊要有,再過幾天又說A模塊可以先只實現其中的幾個功能,再后來又說因為技術對接原因A模塊又要做調整。
在我們的項目中,像上面的情況比比皆是,產品方案改了又改,技術評審提了又提。要知道,每一次的改動和變化,都會帶來很大的機會成本,會造成很多的資源浪費,也會消磨掉大家的熱情。在來回改了3、4次后,有個開發同事說的話,很能代表大家的狀態,他說“剛開始做的時候還很有動力和目標,改著改著,已經不知道干啥了,也不想干啥了”。
可想而知,項目范圍的不確定,勢必造成需求的模糊不清,必然帶來產品方案的搖擺不定。
做項目,每一次變化,都是執行人的災難。
2. 開發優先級排期沒發做
項目的范圍不明確,產品的需求就不確定,這樣帶來的結果就是開發工作排期的問題。
在正常的流程下,到了開發工作的階段,產品的需求基本上都是定稿的,并且應該是經過評審可落地的那部分。有了這樣的前提和基礎,在分配開發工作的環節才能夠有條不紊的進行。
但是如果在一切都還是待定的情況下,僅僅指望開發自己去摸索去領悟項目的內容,這是不現實的,也是不可能做得到的。
在這樣什么都不明確的情況下,過早的讓開發接入也是比較欠妥的。這樣往往會導致什么情況呢,那就是開發所做的架構規劃和開發工期,會被不斷的來回修改,最終的結果就是啥也干不下去。
說回我們這個項目的例子,最初的方案,1期只做基礎的購買流程,2期開始深入優化,3期開始軟硬件整體升級。產品需求也是這樣安排的,開發優先級也是這樣做的。然后在某一次內部會議后,又被改成了1期時間點要上線的內容,包括之前規劃的1期+3期的內容。再到一次內測后,又改成1期時間點要上線的內容,包括之前規劃的1期+2期+3期的全部。你沒看錯,就是時間點不變,但是內容是全部。
然后就是無限的惡性循環,最后的結果就是,產品沒有主見,開發沒有方向,就這樣在混沌中繼續。
做項目,如果從一開始就想著一步到位,那基本上也就離“做不好”不遠了。
3. 項目的交付標準沒有
如果上面的需求和開發都沒有很好的規劃和執行,可想而知,項目的最終交付會是什么樣子,那該是有多么的災難。
所謂項目的交付,在我的理解里,就是按照項目預先規劃好的方案,分階段在規定的時間內高質量完成對應的內容。
一般情況下,項目的范圍明確好之后,就會形成相對應的解決方案,在這個解決方案里所涉及的點,就是最終要交付的點,就是最終項目要驗收的點。
交付團隊一般會做什么事情呢?那就是根據項目的規劃,要明確好每一期要交付的內容。而為了最終能夠順利交付,他們還需要進行相應流程的測試、模擬環境的搭建、賬號體系的準備、用戶培訓手冊的準備等等相關的配套服務,其實事情還是挺多的。
那如果項目的范圍變化了,也就意味著他們的那一些列工作都需要進行相對應的調整。
還是以上面項目的1期、2期、3期內容為例,剛開始的時候,按照1期的交付內容準備相應的內容,并且經過測試,已基本符合相關方的要求。接著就是交付內容的變化,從1期+3期,再到后來的全部。想必那段時間,交付團隊的工作一定是十分的忙碌且迷茫吧。
以上,就是一個范圍不明確的項目,給產品團隊、開發團隊、交付團隊所帶來的影響和挑戰。這樣的不明確,其實是對團隊的極大消耗,無論是時間還是精力,每個人都付出了很多,但最終的結果卻是所有人都不滿意。
二、如何盡量規避
上面說的那些問題,是不是就無解了呢,其實也未必,經過對項目的復盤,還是有能夠解決的辦法的。
1. 明確核心干系人的期望
所有的項目,最終都是要為人服務的,那就需要明確項目中的干系人,對這個項目的期望和所希望能夠達成的目標是什么,這是很關鍵的一個點,是決定項目最終是否成功的關鍵。
當然,在明確每個人的期望之前,是需要識別出項目中的關系人,說白了就是誰對這個項目有話語權,誰的決定能夠左右項目的內容。如果有遺漏,那么肯定會在某個時刻,對項目產生不可逆的影響。
上面舉例的項目中,我們就是犯了這樣的錯誤。在前期的調研和方案提報的過程中,都沒有征詢技術負責人的相關意見,項目經理也就理所應當的以為所給的方案就是最合理的。可是就在項目1期的時間點快結束的時候,這個技術負責人提出了他的想法,而他的這些想法,就直接打亂了項目的1、2、3期規劃和開發節奏。
當我們識別出了項目中的核心干系人之后,緊接著要判斷的,就是這些干系人的權力、職責、和影響力。這是很關鍵的,也是一個項目經理很核心的能力要求。在掌握了以上基本信息后,就需要和每個干系人進行深度的溝通,深度挖掘他們的需求,洞察他們的真實意圖。這是很難的,但是也是必需的,不得不做的事情。
明確了他們的核心訴求之后,如果大家目標都一致,那當然是皆大歡喜。但是,現實情況往往是每個人所關注的點都不一樣,而且很多時候還會沖突。這時候,項目經理要做的,就是權衡利弊,有的放矢。
像我們舉例的項目中,甲方領導的訴求是在他的任期內,打造一個業內標桿的成功案例;甲方下面具體做事的人要求是,系統平穩過渡,不要一下子就大刀闊斧的切換。我們公司領導的訴求是開拓對方市場,技術經理的訴求是將所有的成熟方案應用落地。
之所以我們后面會進行頻繁的變更,也就是從一開始并沒有十分的明確他們的訴求點,而在我們的項目中,他們每個人的話語權都挺重,每個人的要求都需要滿足。
識別項目干系人,明確他們的期望,了解他們的動機,知曉他們的目標。然后進行匯總、權衡,最后形成讓各方都滿意的方案。
2. 調整開發節奏
唯一不變的就是變化,為了適應現在的項目節奏,小步快跑快速迭代,敏捷開發及時反饋,才能夠適應不斷變化的節奏。
以前的項目開發流程,所遵循的基本上都是嚴格意義上的控制,也就是所謂的結構化開發方法?;旧隙际前凑枕椖恳巹?系統分析-系統設計-系統開發-系統測試-系統交付,這樣的流程來操作的。而且每一步之間都有強依賴關系,下一步的內容要嚴格按照上一步規定好的內容來進行。
這樣的方式,好處就是能夠比較按照流程推進,但是這對項目經理和團隊的要求都比較高。而且這樣的方式,很難適應和滿足快速變化的項目。
所以,如果項目的范圍在前期并不是很明確,可以嘗試換一種方式,迭代開發或者敏捷開發,都能夠很好的解決前期內容不確定的情況。
將開發的交付按照周為維度來進行劃分,大家只考慮這一周要做的內容。有變化要調整就直接記入下一個迭代周期中,快速的響應,及時的處理。
到了項目后期,所有內容都明確和固定之后,再慢慢將快速的迭代和長期的規劃相結合起來。
想要做好這點,最關鍵的還是要從心態上有所轉變。不要害怕改變,改變是肯定會有的。不要害怕調整,調整是在所難免的。我們要做的就是根據實際情況,做到靈活機動。
變化,從內部開始,就要升華,從外部推動,就是妥協。
3. 多溝通多確認
有效溝通,是團隊保持高效協作的前提。
由于每個人過往的經驗、知識的結構、認知的水平等差異,對待不同的事情會有不同的看法,對待相同的事情也會有理解的偏差。
如何才能消除這種團隊成員之間的信息差呢,以我目前的經驗來看,多次頻繁溝通確認是十分有必要的。
很多時候,說的人和聽的人,完全是不能夠同步的。因為對說的人來說,他所講的,必定是他自己腦海中有成形的概念的內容,也就是說他自己會在想象中構建一個自己所理解的畫面。而且,他也天然的認為聽的人能夠懂。但是現實情況是,聽的人是一頭霧水。
這就需要雙方進行信息同步確認,說的人,可以引導聽的人將聽到的內容用自己的方式理解一遍。聽的人,在有任何不確定的內容的時候,都需要向說的人確認,避免理想當然和不以為然。
還是以上面的項目來舉例,在前期溝通項目方案的過程中,技術負責人說表達出來的是將目前現有的方案進行賦能,而項目經理的理解是將目前正在運行中的模式復制一份到當前項目,然后項目經理和其他所有執行部門所傳達的也是項目經理自己所理解的意思。
但是在項目的開發和執行過程中,技術負責人提出了不同的要求和變化,因為在他的概念里,所謂的“現在的方案”內容包括目前正在運行的項目和規劃中還未實現的模式,他的腦海中是最后的全面的東西,而且他想趁著新的項目,將他的一些想法進行落地。這樣也就導致了項目組所完成的內容,在他眼里都是不值一提的舊東西,他想要的那些突破性的內容沒有任何體現。
結果就是項目組進行調整和修改,哪怕臨近項目上線的時間點。
前期可以多花點時間,將問題說透,不留任何有異議的地方,方能保證規劃和執行的統一。
一些想說的話
很多時候,并不是我們不想做,而是我們不知道怎么做。
很多時候,并不是我們不愿改,而是我們不知道怎么改。
很多時候,并不是我們不進步,而是我們不知道如何變。
專欄作家
明天上線,微信公眾號:明天上線,人人都是產品經理專欄作家。做過運營,當過客服。擅長原型設計、邏輯梳理,目前專注于B端產品領域。
本文原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 pexels,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
做產品就怕無邊界、不明確