PM的價值，就在于解決產(chǎn)品發(fā)展過程中的各種阻礙。而解決這些阻礙，就要找到問題的根源，才能舉一反三，有效避免產(chǎn)品開發(fā)失敗。
《從0到1系列》已經(jīng)更新到第17集，系統(tǒng)地回顧了我在過去一個2B的平臺型產(chǎn)品從構(gòu)想到完整落地的全過程，特別是第三部分主要是針對產(chǎn)品研發(fā)過程中回顧、總結(jié)和反思。
包括：
產(chǎn)品經(jīng)理如何規(guī)劃產(chǎn)品的roadmap
產(chǎn)品經(jīng)理如何把控產(chǎn)品開發(fā)的進(jìn)度
今天則著重盤點在整個研發(fā)過程中的典型性問題，回顧過去經(jīng)歷的坑，試圖找到其規(guī)律和破解之道。
軟件開發(fā)過程，作為一個“富有創(chuàng)造性”的工作，其過程相比于其他項目過程都有它的特殊性，研發(fā)管理的思想和體系也隨著研發(fā)實踐逐步發(fā)展起來，從上世紀(jì)80年代的“門徑管理”，到NPD，以及后面的IPD模式都得到了廣泛的應(yīng)用，大大提高了企業(yè)的研發(fā)水平和研發(fā)能力。
但我們依然不斷在深坑里面掙扎。
我們學(xué)習(xí)了很多的管理方法和理論，也嘗試驗證了很多的技巧和工具，但這5個問題如果不能真正得到重視和妥善的解決，我們的產(chǎn)品開發(fā)工作依然困難重重。
未形成系統(tǒng)的產(chǎn)品理念嚴(yán)格來說，產(chǎn)品研發(fā)是一項投資行為，但在現(xiàn)實中它只是一個短期目標(biāo)，甚至只是一項任務(wù)，只重視功能的實現(xiàn)而輕視性能和可靠性。
我們常常能夠見到產(chǎn)品開發(fā)過程中簡單的功能疊加現(xiàn)象，一是認(rèn)為功能越多，用戶越滿意，二是喜歡所謂的“微創(chuàng)新”，東家加西家成為自家，并且以陷入到不到累加的功能池自豪。
最終考核的我們并不是創(chuàng)造了多少有價值的產(chǎn)品，而是完成了多少工作。之所以會出現(xiàn)考核工程師以“代碼行數(shù)”為指標(biāo)，原因就在于我們沉醉于完成“項目的數(shù)量”，交付了多少工作量，我們習(xí)慣于拉起了很多的項目敢死隊，并標(biāo)榜為突出的業(yè)績。
當(dāng)項目偏離價值目標(biāo)，又怎么能夠誕生出色的產(chǎn)品呢？
我所見證過的失敗項目中，一個突出的現(xiàn)象就是：在產(chǎn)品的立項階段，單純是以市場機會作為驅(qū)動，產(chǎn)品研發(fā)往往處于配合市場、銷售的位置，多數(shù)情況下僅僅是從“功能”的角度來定義產(chǎn)品研發(fā)，而沒有從用戶的產(chǎn)品整體體驗的角度去定位和研發(fā)產(chǎn)品。
這確實常常陷入一個兩難的境地，面對一個訂單，不接來吃一口怎么知道是毒藥呢？所以，什么客戶都敢做，什么訂單都想接。
但結(jié)果就是產(chǎn)品做了一大堆，好用的沒幾個，倉庫倒是堆得滿滿的，更不要說核心技術(shù)的積累，起了一個大早，趕了一個晚集。
單純的銷售機會主義文化，最終都會讓研發(fā)工作本身淪為附屬，始終無法上升到企業(yè)戰(zhàn)略的突出位置，并進(jìn)而把產(chǎn)品的研發(fā)工作視為一項成本。整體的研發(fā)投入明顯不足，不足以支撐日益復(fù)雜的業(yè)務(wù)需求，從而導(dǎo)致整個研發(fā)過程四處救火，拆東墻以補西墻。
甚至于把產(chǎn)品只是當(dāng)作研發(fā)部門的事情，而不是組織的一個整體活動，誰把事情搞砸了，誰就得背鍋。在這種理念下，團隊就愈發(fā)追求短期內(nèi)的任務(wù)目標(biāo)，而不是考慮用戶的體驗價值。
缺乏有效的產(chǎn)品規(guī)劃產(chǎn)品很多，目標(biāo)很遠(yuǎn)，就是規(guī)劃很少。
由于沒有能夠建立一個系統(tǒng)的產(chǎn)品發(fā)展路徑，總是被動的響應(yīng)市場端的要求和競爭的結(jié)果，產(chǎn)品研發(fā)團隊失去了清晰的路線圖的指引，臨時性的決策機制導(dǎo)致效率低下，陷入一種開發(fā)新產(chǎn)品，修復(fù)舊問題的循環(huán)打怪狀態(tài)。
在這種機制下，研發(fā)變成了只關(guān)注一個又一個產(chǎn)品的開發(fā)工作，眾多產(chǎn)品互相拼湊重復(fù)開發(fā)，必然導(dǎo)致整個產(chǎn)品系列缺乏系統(tǒng)化，更無法進(jìn)行平臺化。
效率降低只是表象，可能通過一些途徑還有提升的空間，這種模式帶來的最大問題就是缺乏核心技術(shù)，團隊無法學(xué)習(xí)和引入新技術(shù)，更無法從技術(shù)層去提供更優(yōu)的解決方案，最終是逐漸降低了產(chǎn)品競爭力。
但真實情況下，很詭異的一個事情就是，我們更樂于解決那些最能看得見的事情。
某個訂單下來，立馬開足馬力想要去搞定這個大客戶，吞下一個大蛋糕，循環(huán)往復(fù)直到所有的資源全部投入到火熱的項目交付中，哪怕是一個很小的業(yè)務(wù)方向，也是多項目并行。
這種局面，最終的結(jié)果就是沒有人有精力投入到未來的規(guī)劃中，沒有資源有能力沉淀的基礎(chǔ)性工作。團隊越來越忙，效率越來越低下，產(chǎn)品越做越差。
過程缺乏決策評審研發(fā)過程缺乏決策評審，產(chǎn)品研發(fā)的過程管理薄弱，沒有相應(yīng)的資源投入和配套的流程來確保過程的可控性，加之軟件研發(fā)工作本身的不確定性和復(fù)雜性，加劇了這個問題帶來的影響。
這種情況包括時間估計不準(zhǔn)確，總體計劃缺乏完整性（甚至沒有計劃性），各個環(huán)節(jié)的銜接極差，進(jìn)展情況得不到及時匯報，缺乏有效的監(jiān)控手段和措施，對風(fēng)險的防范能力很差，一些細(xì)小的風(fēng)險都可能帶來整個項目的延期，或者質(zhì)量事故。
屢見不鮮的是延期，返工，或者貨不對板。
有人說細(xì)節(jié)決定成敗，也有人說沉迷于細(xì)節(jié)缺乏大局觀。也許兩種說法都有各自的道理，但作為身處一線的PM而言，思考如何建立一種追求卓越體驗的項目文化，評審決策的管理機制，既難也緊迫。
流程缺乏紀(jì)律性產(chǎn)品研發(fā)工作變成了“大廚掌勺”，一旦高手缺席，就做不好一道好菜。
缺乏紀(jì)律性的明顯特征是流程粗放，層次不清，沒有規(guī)范，缺乏具體可操作的過程管理。各個崗位隨意按自己的喜歡和理解行事，加之沒有決策點的評審，導(dǎo)致各個環(huán)節(jié)各自為政。
“單點故障”，既有人為因素，也有環(huán)境使然。站在某些角度來看，單點故障來凸顯其價值，只是更大范圍的情況下，會帶來很多的傷害。
這種紀(jì)律性帶來的傷害最為明顯的就是上下游的銜接問題，整個開發(fā)過程變成了接力賽的串行流程，看上去每個環(huán)節(jié)都有人負(fù)責(zé)，都有人把控，但由于理解的不一致，交付成果參差不齊，接口不暢漏洞百出，從而進(jìn)一步降低產(chǎn)品的競爭力。
這種狀況還將形成另外一種可怕的局面，那就是問題總是被掩蓋，或者被拖延，直到最終暴雷。
職能化組織的僵化以“部門職能”為基礎(chǔ)的組織，很容易陷入部門墻壁壘中。
各個部門由于對產(chǎn)品成功的定義不同，標(biāo)準(zhǔn)不一，就很難在整個產(chǎn)品的全生命周期內(nèi)形成一致的目標(biāo)，從而帶來協(xié)作的困難。如果正好處于某種高速運轉(zhuǎn)的狀態(tài)下，部門之間必然會把產(chǎn)品工作當(dāng)作了事務(wù)處理，就像一個燙手的山芋，誰都想著盡快踢到下游。
最終負(fù)責(zé)研發(fā)的團隊背著整個黑鍋，賣不出去是因為體驗不好，用戶投訴更是因為體驗不好。
職能化組織的第二問題是容易導(dǎo)致PM們沒有發(fā)言權(quán)，有責(zé)無權(quán)或者有責(zé)少權(quán)。PM的角色更像是一個行政管理人員和協(xié)調(diào)人員，而不是一個產(chǎn)品或者一個項目的領(lǐng)導(dǎo)者，他們往往沒有辦法真正通過有效的途徑推動項目的落地，從而延期，或者質(zhì)量不足。
當(dāng)一個PM，缺乏一定的決策權(quán)時，通常都意味著項目正處于失控狀態(tài)。
#專欄作家#杜松，公眾號：產(chǎn)品微言，人人都是產(chǎn)品經(jīng)理專欄作家。專注于人工智能方向，擅長產(chǎn)品規(guī)劃和架構(gòu)設(shè)計。
題圖來自Unsplash ，基于 CC0 協(xié)議。
