每位產品經理在處理需求和項目的路上，都會遇到無數的坑。在周而復始的挖坑和填坑的過程中，我們散落了青春，也迎來了成長。木筆梳理了一下那些曾經趟過的10個產品坑，相信總有一個命中你。

「 以下故事情節及人物均為作者杜撰，若有雷同，純屬巧合：

小Q：某互聯網公司后臺產品經理」

每個人的一生中，都會遭遇那么幾次難過的坎，或早或晚。跨過了，是風輕云淡、亦無風雨亦無晴；跨不過，便來之坎坎，風雨飄搖山河碎。

前不久，小Q和一位許久沒聯系的老友聊天，才知道對方在這幾年里發生了不少事。孩子很小，正需要人照顧的時候，媽媽查出患癌，需要定期化療，原本平靜幸福的生活一下子跌入低谷，壓力巨大，自己幾度抑郁到看心理醫生。最后憑著自己的堅強爬了出來，開始重新思考生活，現在一邊努力掙錢替媽媽看病，一邊努力擠出時間多陪伴父母，日常往返于公司、家和醫院之間，雖然苦累，但話語間充滿了不服輸的倔強和堅強。相比許多年前剛畢業那會兒對未來的懵懂憧憬，現在愁苦嘗遍，更能體會天涼好個秋的平淡心安。

心比寒冬暖，苦難俱融之。

近期做項目復盤，小Q對以往項目中趟過的坑做了一次集中梳理，雖然比起朋友的人生大坎不值一提，但也是對過往的一次很好的總結。那些曾經為此付出的血汗和代價，終將在將來筑建起最堅實的城墻，這道墻喚做:經驗。

產品“十”坑

坑1：缺乏全局視角：上下游系統聯動考慮不周

一個新的項目上線，往往會涉及到多個系統之間的聯動，而產品經理經常會更加聚焦于新項目本身，而忽略了對外圍系統的影響，導致上線后問題多多。

例：A君負責的新WMS系統上線，在上線之前，內部所有功能均測試通過，結果上線以后發現ERP庫存錯亂了，因為庫存的錯亂，影響了財務賬和線上銷售。排查原因才發現是臨上線前，根據業務需求，調整了WMS的庫存變更邏輯，而此變更并未及時通知ERP調整，導致上下游系統的庫存處理機制產生了差異。原計劃1個月順利切換的項目，因為此庫存問題，后續不斷修復改進，持續了半年之久，各部門痛苦不堪。

【經驗說：內部問題是最容易解決的，與外部系統的交互才是項目的關鍵，涉及到不同的團隊、不同的系統，產品經理一定要盡可能多的了解上下游業務系統，梳理方案時要多考慮上下游系統的關聯性，要是涉及到上下游系統的改動，一定要提前與對方打招呼，安排好充裕的時間進行聯調】

坑2：不貼合業務現場，閉門造車

有很多自認為很有經驗的產品經理，接到需求后不與需求方充分溝通，更不實地考察，想當然的閉門造車，如果再碰到一個稀里糊涂的業務方，就有可能出現新需求上線后無法使用，嚴重的會導致現場停擺的情況發生。

例：為節約成本，A君給庫房設計了一套新的復核流程，將打印面單和清單的模塊后置到復核環節。這本是一個很好的想法，可以為庫房節省兩到三個人力，同時提升了作業效率。但新功能設計時并未考慮到現場的操作情況，導致上線后，打印機的打印速度跟不上現場復核的速度，每復核一單要等待6到8秒才能打印完成，然后才能進行打包，直接導致復核爆倉。項目運行半天后，不得不回滾，損失慘重。

【經驗說：系統設計一定要與業務流程相結合，切忌閉門造車。只考慮系統實現，不關注實地操作，是很多產品經理特別是產品新人很容易踩的一個雷區。往往系統流程是閉環了，但發現現場無法使用，所有的努力功虧一簣，所以在設計系統時，操作角色-操作流程-系統流程要緊密結合。同時，大的流程改造，在上線前進行實地測試是非常必要的】

坑3：流程不閉環，忽視逆向和異常流程

在梳理業務流程時，正向流程的通暢，意味著項目成功了80%，但復雜點往往在于逆向流程和異常流程的處理，如果逆向和異常沒有處理好，流程就不是一個完整的閉環，一旦出現了，就會變成死節點，再也無法向下流轉。

例：A君為庫房新上線了入庫流程，改進后的流程從操作性和準確性方面均提升不少，得到了庫房的一致好評。但由于沒有考慮到收貨拒收，以及驗收環節出現錯誤的修改流程，導致有一批收貨無法進行日結，只得找技術從后臺進行處理，項目上線效果大打折扣。

【經驗說：設計流程時，閉環是個基本原則，逆向和異常的處理流程可以設計的很簡單，甚至人肉處理都行，但一定要考慮周全，否則如同定時炸彈一樣，一旦情況出現了而無法處理，就是巨坑。】

坑4：項目周期太長，計劃趕不上變化

在互聯網行業，計劃永遠趕不上變化。一些從傳統行業做大項目過來的產品經理容易落入”大而全”的項目圈套中，追求極致，認為只有面面俱到，所有風險都考慮到位的項目才能上線，殊不知，市場不等人，當系統做出來的那一刻，也許就已經過時了。

例：A君接到公司指令，要求打造一套生鮮的O2O供應鏈系統，老板想借此整套解決方案進行業務推廣和融資。于是一行人浩浩蕩蕩設計了一個宏偉目標開始實施，種種原因，原計劃3個月的工程持續了8個月的時間，好不容易項目上線，最佳融資機會卻已經錯過了，公司資金吃緊，項目組只能就地解散。

【經驗說：在市場尚不明朗的前提下，項目以MVP的形式推進無疑是成本最低的，先設計出最簡單的模型來輔助業務進行試錯，小步快跑、快速迭代，待模式清晰以后再加大投入。當然，MVP不是要放棄系統建設，最基本的底層設計和流程閉環還是要充分考慮的】    

坑5：追求效率，缺乏體系化建設

項目周期不易過長，太過追求效率而不考慮未來也是大忌。做供應鏈類項目，要注重體系化建設，就像蓋樓一樣，如果根基不穩，蓋得越高，風險就越大，如果長期如此，只會造成崩塌，釀成大患。

例：A君受命搭建履約系統，原本規劃的核心功能要3個月才能開發完成，但老板覺得時間太長，要求項目砍到2個月。2個月以后，一個不完善的系統終于上線，A君本計劃針對上線的隱患問題做一次架構升級，但新項目一個接一個，根本不給緩沖的時間，而且每一個項目都是要求盡快上線而不考慮擴展性建設。直到有一天又來了一個大項目，A君評估后發現現有系統架構已無法再繼續支撐，提出要重構，而老板不領情，認為是A君能力問題，A君無奈選擇離職。公司高層火速招了B君上崗,新官上任三把火,B君按以往經驗評估此項目難度并不算大,于是在老板面前立下軍令狀,保證完成任務。在梳理需求的過程中,方知系統最核心的履約模塊都是千瘡百孔,根本無法再往上添加新功能,于是悔不當初,只得在項目啟動之前負罪離職,當了逃兵。

【經驗說：產品經理在系統搭建之初，一定要和架構師一起針對最核心的架構進行辨識和評估，就算項目周期再緊，基礎建設也不能偷懶，否則后患無窮；如果不能反向管理業務預期，最好使用二八法則，優先保證核心底層建設工作，針對非必要功能進行適當取舍】

坑6：目標不一致，項目多方不在同一高度對話

項目過程中,經常會遇到產品經理和業務、技術不在同一個維度對話，相互之間溝通半天如同對牛彈琴，了無結論。更有甚者，大家以為達成了共識，實則各自理解相差甚遠，導致項目效果達不到預期，身心俱疲。

例：A君主導的中央庫存系統終于上線，但上線以后由于業務的復雜性，很多場景考慮不周，導致庫存計算不準，很多訂單由于系統問題產生缺貨無法下發庫存生產，A君找到負責的技術小B排查，一通操作以后，所有訂單均正常流轉到了庫房，中央庫存再無報錯信息。還沒來得及高興時，庫房又爆出超賣問題，原因是很多訂單下發庫房以后，WMS沒有實物庫存無法定位生產。A君再找小B，小B很淡定的解釋道，中央庫存增加了一個自動加庫存機制，一旦發現無庫存，就自動加100，保證訂單能順利下單并下發庫房，如此也導致了某些訂單的超賣。A君大怒，但小B委屈的認為自己此舉有效的解決線上卡單的問題，并不覺得自己錯在哪里,也沒有意識到超賣的嚴重性.....

【經驗說：遇到此類坑，產品經理需要搞清楚大家不在同一緯度對話的緣由，如果是大家概念不統一、需求理解不一致，產品經理最好能轉變語氣和溝通方式；如果是某些技術同學心懷鬼胎想偷懶，揣著明白裝糊涂，那就要上升到工作態度問題了；如果大家一致認為已經達成了共識， 推薦使用復述承諾法，由技術同學對方案進行復述，大家一起指正，直到各方均不再有分歧為止】    

坑7：需求管理不善，頻繁的需求變更

很多時候,業務部門只有一個想法,剛開始這個想法并沒有想的特別明白,于是提交過來一個模棱兩可的需求,產品經理就基于自己的理解開始設計系統,在項目過程中,業務訴求越來越清晰,卻發現產品方案和自己的預期相去甚遠,于是,需求變更在所難免。如果產品經理不對過于頻繁的需求變更進行有效管理，就會直接影響到系統設計和項目進展了。

例:采購部基于資金壓力考慮,需要做代發貨業務,即由自營采購變為和經銷商合作,由經銷商代為發貨。項目開始之初,業務方要求以某些商品作為試點。A君以采購部的需求,設計了一套代發貨系統,采購部確認方案無誤。但在系統開發過程中，公司高層又好幾次冒出新的想法，要求擴大品類、擴大代發貨范圍，導致項目范圍一再擴大，系統底層架構也跟著調整，無法按時交付，影響了業務的開展。

【經驗說：需求變更在所難免，但過于頻繁的話，不僅影響系統設計，還會嚴重動搖項目組軍心。作為產品經理，一要學會拒絕，有困難時一定要學會say no；二要會分輕重緩急，評估變更帶來的影響，如果確認影響重大，可以向上匯報，由高層之間商議決定項目延期，還是暫緩實施變更。千萬不要只報喜不報憂，等到項目出問題了再匯報，就為時晚矣】

坑8：老板想法太多，一言堂

很多公司只有一個最大的產品產品經理，加上一群需求轉化師，這名產品經理就是老板其人，普通產品經理們只能充當將老板的想法轉換為產品文檔的角色。老板做產品經理不可怕，可怕的是老板想法太多，還朝令夕改，經常變。朝令夕改也不可怕，最可怕的是老板還一言堂，不接受挑戰和建議。

例：A君的老板最近心血來潮，經常晚上11點以后對自家產品進行試用，隨時把一些或大或小的想法發到高管群里。因為老板向來強勢，沒人敢反駁，一眾高管順著老板的想法進行討論，終于得出一個各方都滿意的解決方案，并各司其職領取改進任務。老板是伺候好了，卻苦了A君和技術，因為細想下來，老板的想法若要實施，就要進行底層改動，牽涉面甚廣，而且改進效果未知。正在為難之際，部門老大又傳達命令下來，老板想法又變了，此方案不用實施了。A君慶幸的同時，充滿了無奈和對對未來的迷茫.....

【經驗說：遇到一言堂的老板,拒絕是不可能的，如果想學魏征一樣死諫,除非你有魏征一樣的才能和不可替代性,你的老板也具備唐太宗一般的胸襟,否則還是要慎重, 畢竟你領取工資,是要為老板解決問題的,而不是對老板說不的。最好的方式是找機會多和老板溝通，適當的加以引導。有方案以后也不要著急動工，先跟老板匯報，得到確認指令后再動工。說不定在你匯報的過程中，老板的想法就又變了呢？】

坑9：多方產品各自為戰，沒有主次

在做大型項目時，往往不止一個產品經理參與，這種項目上，各位產品經理的分工一定要明確，主次分清，主產品負責整體方案的把控，以及把各子系統方案串到一起；其他產品負責各個子系統模塊的細節梳理，聽從主產品經理的調配。如果各自為戰，就如同一盤散沙，失敗風險極高。

例：A君接到一個大項目，需要涉及到3個系統的聯動，于是老大又派了B君、C君對項目支援，安排每人負責一個系統。B、C二人仗著資歷比A君老，不聽A君安排，各自出完方案找到自己的技術評審開發，到進行技術方案對接的時候才發現三個系統的方案有嚴重出入，要求重新進行需求評審。此時B、C仍不以為然，兩人私下對完方案，并不告知A君。A君無奈，找到老大出面協調，才保證了項目的需求方案的統一，卻與B、C結下了更深的梁子。

【經驗說：新人初來乍到，遇到倚老賣老，沒有團隊意識的同事，是非常棘手的事情，建議擺正心態，先從自身找原因，同時抱著把事情做好的態度進行溝通，要注意溝通的語氣。如果溝通不暢，及時上報風險，尋求領導的支援。如果連領導也不支持你，那就要考慮一下是自身問題，還是體制問題了。如果體制風氣便是如此，或許這里并不適合你發揮，是不是要考慮換個環境？】

坑10： 只顧投入，不問產出

如果從結果上看，很多公司做的大部分項目都會以失敗而告終，這種失敗不是指項目本身，而是業務層面達不到預期。為了盡量避免這種現象，產品經理在接需求時，最好能站在業務角度進行分析，多問為什么，多用數據說話，反向驅動業務方為產出負責，堅決杜絕業務隨便動動嘴，產品技術跑斷腿的亂象。

例：A君在年底做復盤時，發現近兩年為庫房做了200多個報表需求，而實際用到的不到30個，很多都是提需求的時候特別著急，上線以后一次都不用。曾經嘗試過溝通，效果并不理想。于是A君和技術合計，為每個菜單增加了埋點功能，如果某報表超過3個月不用，就做下線處理，同時，會將統計結果告知業務方，要求業務方書面說明原因。經過半年的整頓，終于將報表控制到50個以內，后續報表類需求也減少了90%。

【經驗說：需求應該雙向考量，業務部門考量技術部門的需求產出質量，技術部門也應該反向考量業務部門對需求的使用情況和業務預期。一味投入、從不問產出，會讓所有人陷入一個僵局中，業務方覺得提需求很輕松，也不用承擔后果，技術部門只顧著實施，從不問結果。表面的和氣帶來的是諸多的資源浪費。所以，從現在起，讓各方均為成本負責，多一些ROI意識吧！】

人生難免不如意，淚與歡笑成對比。成長的過程中充滿了未知的苦難，我們在一個個大大小小的坑中匍匐前行，前方荊棘密布，刺痛雙腳，于是我們痛苦、焦慮、彷徨、不安，有人堅持不下去就停留在原地打轉，從此迷失在泥潭中；有人拔掉身上的倒刺奮勇前行，跨過重重阻礙，終將坑填平并種下希望的種子，接著繼續探索前行，周而復始的找尋自己心中的阿爾卑斯山。回過頭來看，那些曾經趟過的坑已經綠樹成蔭、滿目青山，曾經滴血的傷口也長出了蒼鷹之翅，讓我們更加強大。

前一陣小Q工作中受挫，特別迷茫，去找老領導聊天，事后老領導給小Q發來一段文字，看完以后如遇良藥，豁然開朗：“人生遇見瓶頸和低谷是正常的自然規律，正是在這個時候才是你真正總結和開悟的階段。人生想打贏勝仗一定是長期積累的過程，不是靠局部小戰役。珍惜自己的時間和境遇無關，安心做好現在的事情，上天自會給我們更好的安排。”

（以上文字原創為亦師亦友的老領導曲老師，感謝老師的一路栽培和鼓勵，分享出來與諸位共勉，希望現在還在泥潭中掙扎的你再堅持一下，也許再往前走一步就能看到你的滿目青山）

昨日漸多，明日愈少，今日還在，不增不減，這就是人生。珍惜自己的時間，就從今天開始吧，要知道這個世界上最容易和最難的事，都是開始去做你該做的事。

END

文中圖片均來自百度