【五千字總結】項目對外推進乏力,有何“破局之策”
在“對外”推動項目時,如果客戶方或合作方不配合,我們應該如何處理呢?本文作者從三個方面,對產品推進需求落地外部受阻該如何破局進行了分析,希望能給你帶來一些幫助。
前段時間整理了“如果自己提的需求,技術同學不愿意做怎么辦”(【七千字總結】如果你提的需求,技術同學“百般推諉”怎么辦?)
這篇文章更多是在“對內”層面,即公司內部范圍下的應對策略。相比而言,還有一類產品經理/項目經理在“對外”推動時受阻,即客戶方或者合作方配合不足時,我們要如何處理。
兩個問題結合起來,可以概括為一個問題:產品推進需求落地受阻時怎么辦?
從面試的角度來看,我們首先便要區分內部受阻和外部受阻兩類,再分別進行應對。
今天便來總結一下“外部受阻”時,我們如何破局。
同樣,以下內容均來自實踐經驗,可能存在場景考慮不足的情況,歡迎各位以小見大、舉一反三、不吝賜教。
按照習慣,本文將從三個方面進行分析:
- 歸類外部受阻的常見原因
- 尋找這些阻力的應對措施
- 試著深度挖掘表象背后的深層原因
一、他們為什么不想配合你?
在對外推進受阻時,原因大體歸結為這幾點:產品價值、利益分配、關聯難度、以及優先級排期。當然,優先級排期也是基于多種原因導致。
我們還需要針對不同的合作方來區分不同的原因,其中主要在于主辦部門與協辦部門之間的目標與價值。
1. 產品價值與利益的不匹配
無論是主辦部門還是協辦部門,此項目推進成功之后,能夠為其帶來哪些效果?下面我列舉幾個常見的例子來說明:
- 主辦部門通過前期的調研、立項、招標,進入實施過程之后,部門領導突然被調走,新來的領導對現有產品的合作模式、預期效果不認可,但是合作關系已經形成,那么很容易在后期推進的過程中不重視。
- 主辦部門和協辦部門本身對于此產品上線后的應用場景、預期用戶存在一定的重合,即便主辦部門在極力推進,但協辦部門配合的意愿度并不高。
- 前期調研時的結果,與落地交付時的結果存在偏差,可能是因為市場發生了快速變化,也可能在入場之后客戶發現此產品并不能完全匹配業務目標,因此要求實施方對方案進行大規模改造。而實施方因為交付成本、項目周期等因素無法做到快速響應,導致雙方在合作過程中出現了目標偏差。
以上三個例子,都是在實際工作中經常遇到的問題,而每一類問題又不是單方面因素導致,也可能不是由具體的執行人、負責人能夠決策,因此在推進過程中屢屢受阻
2. 交付難度比預期大很多
雖說雙方合作可能是基于標準化產品,但在產品落地過程中需要結合客戶的實際情況進行適配。包含了業務功能的適配以及關聯系統的適配。
業務功能的適配可能存在某個業務改造會對原有核心場景造成較大的影響,需要產品經理、項目經理進行更加全面的改造分析;
而關聯系統的適配,則受限于更加多變、更加特色化的現狀,導致現有系統無法滿足場景,修改起來又增加了協辦部門的配合力度,同時也為自身系統的聯調加大困難。
對于一些重點項目,有時也面臨政策的調整,用戶受市場環境的影響等原因,讓原本的標準化產品需要更具有業務拓展性和適應性。
而這些因素,都為產品的落地增加了層層困難,一方面反映出來便是客戶方內部的協調受阻,優先級排序延后,最終影響到我們自身項目的推進。
3. 從角色角度拆分
無論形成問題的原因是什么,最終表現出來的情況,大體可以分為四種組合(主辦部門、協辦部門;業務負責人、高層領導):
- 主辦部門業務負責人推進受阻
- 協辦部門業務負責人推進受阻
- 主辦部門高層領導推進受阻
- 協辦部門高層領導推進受阻
而且,很多時候當風險已然轉變成問題出現時,原因錯綜復雜,表現情況也是多方受阻。因此,對外的困難,比對內的困難更加難以解決,也更考驗我們的心態和能力。
二、不試試,怎么知道行不行?
1. 首先,要保證內部的工作沒有大的偏差
對外反饋時,更應該注意在反饋之前保證本身(個人、團隊)的工作在正常進行,否則很容易被“反客為主”。即便有些自以為已完成的工作,真正擺到會議上,也容易被對方系統甩鍋。
即便有些工作我們還沒有完成,或者因為某些原因導致延后,也要做到心中有數、有理有據有規劃、匯報。在此基礎上,再去推進外部進度則會更加主動。
這一點,我在剛入職的時候就被前輩多次提醒過。當遇到一些問題我想要找客戶方對接人反饋時,老領導都會先問我一句:如果XX系統說,你們的XX功能還沒有確定,所以他們才沒有啟動,你怎么辦?
2. 試著和對接人做好“私人關系”
和上一篇文章一樣,無論是對內、對外,協調這類問題時,“人情世故”依然是基礎。試想如果你們之間關系不好,沒有信任基礎,即便我們的要求有理有據,對方也很難積極配合。
所以,即便代表不同的公司,即便是甲乙雙方的合作關系,我們依然可以通過自身的正氣、自身的能力、自身的專業性來贏得對方的認可。還可以通過私下的交流來增進革命感情。
這一點,其實非常重要。
當我們和對接人存在較好的關系之后,對方也會主動幫我們想辦法,或者介紹一些靠自己很難了解的背后原因。而知道這些背后原因,對自己真正解決問題會有極大的幫助。
3. 幫助對方向上反饋
有時,對接人礙于上下級關系、或者同事關系,不太好向領導、向協作部門提出過多的要求。而這時,我們則需要在會議上,或者郵件里主動提出風險和方案,做好對接人的“高級嘴替”。
很多話,可能大家心知肚明,但就是沒人來捅破這層窗戶紙。如果不捅破,自己的團隊將長期位于高風險之下。
不過,真正在做“嘴替”時,也要講究語言的藝術,不要太直接,畢竟“槍打出頭鳥”。我們可以采用委婉,主動擔一小部分責任,或者帶著合理的解決方案等方式,在正式/非正式場合對外反饋。
4. 一起分析現狀和問題
無論是協辦部門配合受阻,還是關聯系統改造難度大,從態度方面我們都要積極面對,畢竟,自己所處的團隊是這個項目的第一負責人。我們可以和對接人一起分析現有的問題,討論可行性方案,方案可以有多個,有時也會陷入兩難的境地。具體如何決策可以由對接人結合現狀來決策。
涉及到較為復雜的問題,可以由對接人“攢局”,自己詳細和關聯方溝通,本著解決問題的態度,尋找多樣化的解決方案。當方案制定完成之后,再由對接人按照客戶方的流程進行推進。
于情、于理、于流程、于方法,努力做到“盡人事”。
5. 餅不要畫得太大、太滿
前期很多對接人不愿意配合,是因為覺得這個系統不重要。或者像上文提到的,可能主系統會把現有的某個輔助系統的客戶“搶”走,所以協辦部門也不愿意主動配合。
針對這類問題,其實更多的是執行人的困惑,對于上層的領導,在制定主系統建設規劃時,已經對此有過相應的權衡分析。因此,我們可以在私下,或者工作時間的非正式會議上,和對方闡述系統的價值,并結合客戶方現有業務現狀、痛點,以及系統的解決方案等方面進行表達。
畢竟,從客戶高層視角分析,是A產品價值高還是B產品價值高,對于整體而言都有益處。所以A與B之間的競爭、協作,只是達到整體目標的途徑之一。
不過,在這種情況下,切忌“冠冕堂皇”,要把語言潤色成簡潔、容易理解和記憶的口語。更像是一個30秒的電梯演講,或者幾分鐘的產品介紹。
提前準備好這些話術,在真正遇到問題,或者需要臨時表達的場合時,才能從容應對。這一點,無論是對內、對外,作為產品人都需要對自己各個產品的價值、意義理解清楚,形成不同的表達方式:
- 一句話介紹自己的產品
- 30秒的電梯演講
- 會議上的開場白
- 客戶營銷時的快速介紹
以上這些場景,都應該有理解、內化、隨用隨取。
6. 借助公司的資源
對于個人無法推進的問題,還要善于借助公司的資源。尤其是在客戶方高層領導方面,無論是從職位的匹配度,或者溝通經驗上,自己會很欠缺。
因此,我們需要自下而上進行反饋,主動推進,協調公司高層、商務團隊的力量,尋找契機和客戶方進行溝通,再通過自上而下的方式來推進。
但是,在借助公司資源之前,我們要做好定期的工作匯報,免得大家臨時“抓瞎”。
7. 做好每個節點的工作匯報
其實無論工作是否存在問題和風險,定期向上匯報、向客戶匯報,都是必不可少的。不同的團隊匯報方式不同、頻次也不同。我認為拋開形式,匯報的周期和內容要簡潔、全面。
- 首先是現階段的進度,以及重要的里程碑節點,整體的規劃安排;
- 其次是進度與規劃的偏離程度,偏離原因,以及自己正在采取、計劃采取的方案;
- 另外則是現在預估的風險,風險形成的原因,以及現在面臨的問題。今天所述的內容,大多都屬于風險和問題的范圍。
定期的文字匯報,再加上適時的會議、電話溝通,把現階段的情況如實反饋出來,當真正需要協調公司資源出面解決時,各個環節都有心理預期,自己也能夠更宏觀的審視現狀。
最終,大多數客戶還是會秉持契約精神,最終把項目推進下去,問題解決之后,我們更要注意的則是內部推進過程的速度和質量。如果后期經常被客戶催促、抱怨,那新一輪的風險又會潛移默化的積累起來。
三、困境的形成,更多在于前期的風險積累
這一節,我們試著跳脫出問題的表象,從更宏觀的角度來審視外部推進受阻形成的深層原因。(不一定最深,但比遇到問題解決問題,要更主動些)
1. 產品標準化程度不足
最近幾年,即便是定制的交付項目,也越來越看重標準化產品?!爱a品+定制”儼然成為大客戶采購的基礎。
而標準化,并不代表一成不變,更應是適配能力強、場景覆蓋全面、拓展能力強的一套綜合性產品。當然,這樣的產品市場上并不多見,除非是一些從行業政策上非常規范的業務。
所以,很多標準化產品更多在PaaS層、低代碼層、或者配置化程度上進行升級。而對于一個逐漸演進的產品進行這樣的架構升級,難度幾乎超過了重構。
很多定制化場景,因為產品的拓展性不足(業務拓展性+技術拓展性),產品交付手冊缺失(業務說明書、開發手冊等),在交付現場面對客戶的實際場景,猶如“盲人摸象”。
基于這些現狀,最終的產出物勢必會和客戶預期存在偏差,進而導致客戶的不滿以及在推進過程中的困境。
不過,這類問題如果想解決,那可太難了……
2. 售前階段,以及售前和交付對接過程的缺失
很多時候,無論是項目經理入場,還是產品經理接手,僅是針對本次項目的現狀進行臨時性方案討論。而一次定制化項目的合作,勢必涉及到從銷售階段,到售前階段,經歷多輪溝通和博弈,最終達成的合作。而前期的過程、以及預知的問題,真正的執行人了解嗎?
前兩年,我也做過售前,也和售前團隊一起整理過從售前到交付的交接清單,發現在正式開始實施之前,大多數團隊對于客戶的了解、背景的了解、合作方人員的了解、甚至建設范圍以及口頭承諾功能的了解,都非常欠缺。
而這些事項的欠缺,便為后期的風險和問題埋下了一個大大的隱患。
去年,我便想把售前和交付之間的交接流程形成文字,可惜至今也沒有開始,希望今年上半年能夠整理完成吧。
3. 對風險的重視程度不足
很多同行對于風險的重視程度嚴重不足,有的是自上而下,有的是即便上級反復強調,真正的執行人也不在意。而這些風險即便不會全部轉化為問題,但只要有幾個真正變成問題之后,都會讓自己的工作陷入艱難困境。
從時間管理的理論上,大體可以把事情分成四個維度:重要且緊急、重要不緊急、緊急不重要、不緊急不重要。
越來越多的團隊會把工作重點鋪在“重要且緊急”的任務中,反而忽略了“重要不緊急”的事項,等到這些不緊急的問題變成緊急的,才會納入排期,從而形成惡性循環。
從時間管理層面,我們更應該把時間投入到重要不緊急的任務中,從而形成一個良性的機制。但做到這一點,不僅困難,也得不到大家的重視。
說回工作,風險事件即可劃分到“重要不緊急”的范圍,因為我們對于風險的認知不足,重視程度不足,無法將其“扼殺在萌芽階段”,進而在后期形成一個又一個難解決的問題,讓自己疲于應對。
4. 團隊本身的拓展模式就是這樣
對于很多創業型團隊,產品本身的標準化程度不足,生存壓力也很大,因此只能通過一場又一場的硬仗,讓自己扛過去。都說扛過去之后,能夠撥云見日,但如果仍然采用傳統的拓展模式,越來越多的定制化之后,更會暴露越來越多的問題。何況還有很多團隊沒有扛過去。
定制化和標準化,本就是一場無休止的悖論,任何一種模式都有團隊成功,也有團隊失敗。原因有很多,包含了行業、客戶、團隊、市場方方面面。但如果定制化的攤子鋪的越來越大,從流程和策略上,勢必又將面臨一輪新的改革。
而一旦涉及到改革,其中的危機又會此起彼伏。
任何一次困境的形成,都不是一朝一夕、一人一事,筆者能力有限,無法把這些問題看透徹,講明白。所以點到為止,希望各位領悟精神,一起探討。
四、寫在最后
本文以項目推進難為切入點,涉及項目經理、產品經理在工作中的一些常見問題。若想解決問題,都要先找到關鍵的矛盾點。
這就像我們做一款產品一樣,要先找到真正的痛點,才能想出更合理的方案。同時要保持平和的心態,否則按照自己的角度,代入自己的情緒,一通輸出,最終也只能讓事情變得更尷尬、更為難。
換位看待、深入思考、有理有據、心平氣和、善用資源、主動解決。祝大家都能把自己面臨的問題推進下去。
專欄作家
不想延期,公眾號:不想延期,人人都是產品經理專欄作家。半路轉行的B端泛金融產品,堅持“以實踐驗證理論,以輸出倒逼成長”的目標。點滴珍貴,重在積累
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!