產(chǎn)品經(jīng)理在工作中如何避免背鍋？先做好這三方面：業(yè)務(wù)邏輯（也有可能是產(chǎn)品形態(tài)），確定我們做什么；原型文檔，確定我們怎么做；UI設(shè)計，確定未來項目的“模樣”。

“背鍋”這個詞，對于產(chǎn)品經(jīng)理并不陌生，身為產(chǎn)品，每天都要背不同的鍋。甚至有些人還會找一些不明不白的鍋飛過來，如項目中的收款賬號不對，代碼出現(xiàn)bug等等問題，似乎項目中遇到什么問題，只要甩鍋給產(chǎn)品經(jīng)理就對了。

產(chǎn)品經(jīng)理能否不背鍋，答案似乎是否定，因為產(chǎn)品經(jīng)理對產(chǎn)品負責，產(chǎn)品出了問題都要找產(chǎn)品，這句話聽起來似乎并沒有錯。

產(chǎn)品經(jīng)理能不能甩鍋，答案似乎是肯定的，產(chǎn)品經(jīng)理工作性質(zhì)決定著需要大量的資源，并且需要各個資源之間的協(xié)同，需要各個資源之間的利益平衡。任何資源之間出現(xiàn)問題，都會導(dǎo)致項目不能正常進行。理論上知道找到會出現(xiàn)問題點，就能甩掉一些鍋。

如何找到這些點，或者說如何避免這些坑？最好的解決方案就是流程。在關(guān)鍵的點確認某件事情，而確認的結(jié)果，是開啟下一個進程的前提。

流程的是否通暢健康，決定著產(chǎn)品的成敗，也直接關(guān)系到產(chǎn)品經(jīng)理的工作成果。產(chǎn)品經(jīng)理是流程成是直接受益者。一個健康的流程實際上是對產(chǎn)品經(jīng)理最好的保護。如果一家公司完全沒有流程。那么產(chǎn)品經(jīng)理需要做的是，建立流程或者離開。

今天聊聊如何“甩鍋”給業(yè)務(wù)，及項目前期的流程。這里有一個限制，我說的一切都是圍繞著外包項目進行的。

抱歉本人只做過外包項目，而且還不保證是否專業(yè)。本文目的在于拋磚引玉，希望聽到不同的聲音和批評的意見。

一、確認產(chǎn)品形態(tài)和業(yè)務(wù)邏輯，確認我們要“做什么”

在項目立項之初，或者在產(chǎn)品立項之前，產(chǎn)品經(jīng)理首先要明確項目的產(chǎn)品形態(tài)。什么樣的產(chǎn)品形態(tài)能夠幫助客戶解決現(xiàn)有的問題。這樣在需求獲取之初就可以確定下來。有很多項目一開始是做微信公眾號，結(jié)果做著做著，就做成了APP。

確認產(chǎn)品形態(tài)可以通過多個維度，如客戶需要解決的問題，客戶對于產(chǎn)品有無長期的規(guī)劃等等，但是這些都不是最重要的，最重要的是客戶的為這個項目的投入和我們需要開發(fā)的成本。這也是確認產(chǎn)品形態(tài)的目的之一。畢竟外包公司是要通過項目來賺錢的。

其次就是業(yè)務(wù)邏輯，無論是官網(wǎng)還是龐雜的業(yè)務(wù)系統(tǒng)，貫穿整個系統(tǒng)的都是業(yè)務(wù)邏輯。通過業(yè)務(wù)邏輯的梳理，產(chǎn)品經(jīng)理可以規(guī)劃出產(chǎn)品的整體框架，模塊，甚至產(chǎn)品有哪些頁面都可以“推演”出來，可以說業(yè)務(wù)邏輯確定了，也就確認了整個項目的框架。確認了想項目的大方向。

如果業(yè)務(wù)邏輯錯了，系統(tǒng)的框架、模塊也就錯了，那么功能需求理解的再透徹、原型畫的再好，UI再完美，這個產(chǎn)品也是失敗的。并且項目會有推翻重做的可能，不僅工期要比預(yù)期延長一倍，成本也要增加一倍。

產(chǎn)品形態(tài)和業(yè)務(wù)邏輯承載體是BRD或者流程圖，或者二者想結(jié)合，這個要看項目。

BRD的作用在于證明我們的思路是和客戶的思路同頻的，包括項目的目的、幫助客戶解決的問題，項目受眾群體等。盡管這些是客戶在做之前就已經(jīng)想清楚的，但是還是要有一份BRD作為確認。尤其在官網(wǎng)，H5等項目時，這份文檔可以為設(shè)計提供設(shè)計靈感及范圍。

業(yè)務(wù)流程圖的作用在于描述復(fù)雜的業(yè)務(wù)流程時，直觀的顯示項目整個流程。這個時候的業(yè)務(wù)流程不要過于復(fù)雜，只要說明用戶從哪進，到哪出，設(shè)計到哪些模塊，每個模塊如何連接即可。這份文檔可以原型設(shè)計和開發(fā)文檔提供依據(jù)。

接下來就是溝通講解，無論是會議也好，還是線上溝通也好，這個業(yè)務(wù)的邏輯究竟如何，業(yè)務(wù)人員是需要知道的。

這里需要說明的是，如果需要客戶確認，不建議業(yè)務(wù)直接將業(yè)務(wù)流程轉(zhuǎn)發(fā)給客戶，客戶自己研究，而是根據(jù)自己的理解去和客戶講清楚，至于能否將清楚，那就要看產(chǎn)品經(jīng)理的理解能和業(yè)務(wù)的表達能力了。

二、確認原型，確認我們要“怎么做”

在同意了產(chǎn)品形態(tài)、業(yè)務(wù)邏輯之后，產(chǎn)品經(jīng)理進入了最喜歡的原型階段。

之所以確認原型，是告知客戶我們“怎么做”，從功能點，頁面的邏輯，頁面的設(shè)計結(jié)構(gòu)，用戶的進入項目，走出項目的動線，用戶都會通過原型有所知曉。

制作產(chǎn)品原型，每個產(chǎn)品經(jīng)理有都有不同的標準。不過我問過很多開發(fā)產(chǎn)品原型在他們心中地位，開發(fā)回復(fù)是，我們只看設(shè)計圖。

原型究竟要做到什么程度，還是要看項目，有些官網(wǎng)的項目，功能就是為了展示，只要把各個連接點在原型上提現(xiàn)出來就好，頁面上包含的文字也要和業(yè)務(wù)確認好就可以了。甚至有些官網(wǎng)都不會用到原型，只是一個文檔就可以解決問題。

但是項目如果是一套系統(tǒng)，那就需要將原型做細一些了，這里說的細并不是說在設(shè)計上，而是要考慮的全面一些，各個分支，各個異常情況都要考慮進去，并給與解決方案。不然在需求評審時，幾個問題下來，就會變得灰頭土臉。

對于產(chǎn)品原型，其實我沒有太多發(fā)言權(quán)，和我合作過的UI開發(fā)都埋怨我說原型做的不太細，很多字段都是很模糊的。在這里自我檢討一下。

除了原型，還有一份MRD文檔，這份文檔在外包的項目中，最大的作用就是用作合同附件，所以用詞一定一定一定要準確，盡量避免“等”這樣模糊的字眼，比如說，導(dǎo)航欄包括產(chǎn)品介紹、公司介紹、新聞媒體等。如果按照這樣寫，那么導(dǎo)航欄會包含很多內(nèi)容。開發(fā)會為這個坑不停的加班，同時也會不停的罵產(chǎn)品。

在這里我有個建議，業(yè)務(wù)和客戶在確認原型的時候，最好產(chǎn)品經(jīng)理也在場，這樣在遇到關(guān)于產(chǎn)品方面的問題是，產(chǎn)品也好解答，畢竟產(chǎn)品原型不是業(yè)務(wù)設(shè)計的。

在業(yè)務(wù)人員確認了原型之后，產(chǎn)品經(jīng)理就可以組織開發(fā)人員進行數(shù)據(jù)庫，運營后臺的開發(fā)，這需要確認的東西，我會在后面和大家討論。UI的設(shè)計是產(chǎn)品經(jīng)理需要和業(yè)務(wù)人員確認的第三個點。

三、確定UI設(shè)計，確認項目“什么樣子”

一般來說，在外包的開發(fā)過程中，第一次提交設(shè)計方案，多是項目的首頁，或者是項目的主要頁面，這樣的好處在于，客戶既能想到產(chǎn)品未來的樣子，也能節(jié)省設(shè)計的時間。待首頁確認后，再陸續(xù)提供其他頁面。

客戶在拿到UI之后，基本上都會有一些修改。畢竟大家考慮的角度會不一樣，客戶更多的是站在自己業(yè)務(wù)層面上思考這些設(shè)計圖，而UI設(shè)計師則是站在美學的角度來進行設(shè)計。這就造成了很多沖突。有的設(shè)計師設(shè)計的很好看，但是客戶卻說無法突出自己的品牌或者自己的產(chǎn)品。不過一旦按照客戶的要求進行設(shè)計，難免會成為設(shè)計師設(shè)計生涯的“污點”。

在這里產(chǎn)品經(jīng)理就應(yīng)該從這幾個方面進行協(xié)調(diào)：

• 聽取設(shè)計師從專業(yè)的角度來給出的意見，了解設(shè)計師為什么這么設(shè)計。
• 聽取客戶的建議，獲取客戶對設(shè)計的需求。
• 從這兩點中找到平衡，與客戶講設(shè)計的理念，以及該理念對客戶的好處。與設(shè)計師溝通，告知客戶的痛點，讓設(shè)計師在客戶痛點和美觀度方面找到一個平衡。

大部分設(shè)計基本上會按照原型進行設(shè)計，有些會根據(jù)自己的想法改變原型的結(jié)構(gòu)，但是原型的內(nèi)容不會改變。UI設(shè)計稿一定會比原型設(shè)計的要漂亮。當然也有UI設(shè)計的還不如原型的線框圖好看。如果你作為產(chǎn)品經(jīng)理拿到這樣的UI，我的建議是，趕快換人吧。

UI設(shè)計確認完了，業(yè)務(wù)方面算是搞定了吧，別急，你回頭看看，一群開發(fā)在虎視眈眈的看著你。

小結(jié)

上面說的確認、甩鍋，實則是對產(chǎn)品經(jīng)理的要求。產(chǎn)品經(jīng)理要在開發(fā)前提供這些東西交給業(yè)務(wù)人員。無論是業(yè)務(wù)人員自己確認也好，還是交給客戶確認，都是將項目方在一個框架內(nèi)，這樣在日后的開發(fā)過程中，不會出現(xiàn)太出格的需求。

開發(fā)前需要確認的：

1. 業(yè)務(wù)邏輯（也有可能是產(chǎn)品形態(tài)），確定我們做什么；
2. 原型文檔，確定我們怎么做；
3. UI設(shè)計，確定未來項目的“模樣”。

有了這些，就可以進行開發(fā)了嗎？

本文由 @大熊cc 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議