從需求到上線，產品經理你挖了多少坑？

本文由人人都是產品經理 @可飛（微信公眾號：abckefei） 原創釋出。

近期負責的一個卡券功能，即我們通常所說的代金券功能已在網站上線並投入使用。這部分工作算是暫且告一段落，也差不多可以就此做一個階段性的總結。

通常，一個產品（或功能模組）從需求到上線需要經過：

1. 認識產品
2. 分析產品
3. 互動原型
4. 介面設計
5. 技術開發
6. 測試
7. 上線
8. 反饋

這些流程。然後，我們在執行這些流程的過程中，會有各種大坑小坑，可能填完了一個坑又挖了另一個坑。為了下次挖的坑能夠少一點小一點，我們需要不斷的自我總結提高。

需求的收集&分析

需求的收集&分析，算是產品開始的一個七點，通常吹牛逼的往大了說我覺得就是日常所說的發現使用者的痛點，解決使用者的某個問題。但真相是：我們所謂的需求收集&分析，實際上是來源於領導或者其他部門的要求，更常見的是往往已經有了明確的目的，而我們所需要做的就是去想辦法實現它。本質上，領導或其他部門的要求就是我們這種初級產品汪的需求來源。在這一階段，我們所要做的就是了解我們要做什麼，目的是什麼。

最初，從運營部門接到了這個代金券功能的要求，之所以要做這個功能，主要有 2 個原因：

1. 對比其他同類平臺，我們網站欠缺該功能；
2. 網站的線上運營手段缺乏功能支撐，做這個功能可以增加運營手段，以此提高相關的業績。

可以說，最初的需求已經確定，增加代金券功能，作為一種線上營銷工具，為運營部開展線上推廣提供支撐。在這一階段，基本沒有遇到太大的問題。

分析產品

分析產品是在明確了我們要做什麼後，為自己接下去工作的開展所做的一系列準備工作，這一階段，最常見的就是競品分析（突然想到孔乙己說的，讀書人不叫偷，叫拿）。除此之外，還有流程的邏輯梳理，利用思維導圖、流程圖等工具將我們接下去打算做的事情形成一個體系，有一個最基本的架構。這一階段的工作，算是初期的一個重點。

在做代金券功能的時候，有調查了很多其他同類平臺，尤其是行內領先的平臺，對於前端平臺使用者的操作使用邏輯倒是較快的梳理了出來，因為這一階段，競品分析並不會有較大的難度，只要註冊其他平臺，就可以從一個正常使用者的角度去知道別的平臺如何做的，基本上算是大同小異。

比較困難的在於網站後臺對於代金券的建立管理，以及公司內部如何進行代金券的建立-操作-稽核的流程等。之所以這部分難度較大，有如下幾個原因：

1. 對於其他平臺的操作後臺，我們很難有渠道可以進行參考分析。

實際上，對於做後臺的產品經理，能夠做競品分析的很少，通常體驗競品的難度更大。因此，我通過其他途徑，例如淘寶、微博、微信公眾平臺的卡券功能出發，獲得一定的參考。但總體而言，這部分依然差的比較多。因此在後續原型的設計當中，也就遇到了較多的問題。

2. 流程方面的問題。

這方面主要（1）代金券的不同建立方式及流程;（2）內部稽核流程。其中，內部的稽核流程算是比較艱難。主要在於後臺卡券的建立及投放流程。這個流程的推演只是個人的假想，是從我自己的經驗知識角度出發。功能實現後，發現這個流程雖然能用，但並不是一個順暢的流程。

總之，從代金券功能來說，可以分為使用者端及管理後臺兩個埠，而這個功能的難點及絕大部分工作也基本集中在管理後臺。而對後臺的流程梳理上工作做得不充分， 雖然通常說做後臺的產品經理更重要的在於弄清業務邏輯。但實際上，絕大多數的業務邏輯也並不清晰，而且受限於職位角色，有些業務邏輯也不是產品經理容易理解的。不過，這階段我所犯的一個最大錯誤在於，沒有對從運營部接收到的所有需求邏輯進行更深次的衡量及分析。其中，最明顯的一點在於代金券的規則投放方式 ——即在後臺配置一系列規則條件，當使用者的行為觸發這個條件後，即可獲得一張代金券。而當時提出的規則是儘可能的要滿足所有可以想到的場景，方便以後的擴充，因此我對這一部分的構想是通過羅列十幾種單獨條件由運營人員進行各種組合排列，來形成不同的規則。然而實際上調查其他平臺，常規的規則也就基本只有兩三個，基本沒有其他特殊的規則條件出現。而現在想來，我當時如此做，原因在於對從運營接收到的這個需求沒有經過更深次的思考其是否確實會存在這種使用場景，以及競品的調查做得不夠充分，沒有及時的發現通常使用的常規規則只有兩三個，只要將其常態化即可。不過，技術在實現的過程中，認為這個實現難度非常大，最終是採用了將常規規則常態化的方案。

互動原型

再將所要做的功能模組梳理清楚後，通常要做的就是畫原型。感覺目前在初級產品經理的工作中，原型設計佔得比重較大。實際上，就我個人在工作中而言，通常是畫原型的過程中再去進行思維導圖的梳理，可能是因為覺得有逐漸成型的東西，才會再去考慮到更多的細節。

原型通常有低保真、高保真的說法，通常原型的輸出是為了能夠更好地進行溝通交流，交付技術、設計等相關人員進行開發。如果是較小的需求等，原型的輸出通常都比較快速。但在一些大的功能模組，或者新的產品規劃，原型的輸出需要耗費大量的時間。並且，如果有變動，改動起來也非常麻煩。

通常，比較好的做法是：以最小可能原型先簡單的輸出一個框架，然而邀請相關的人員進行初步的評審，快速的溝通想法見解，然後再進行更改；直到初步確認後，在開始輸出高保真原型。不過，我自己在實際工作中，畫原型可能會有點強迫症，或者說這是大部分初級產品的通病，總是糾結在畫原型無關緊要的細節中，比如按鈕的擺放，tab 的排列樣式，導航樣式或者某個小的功能的展現形式等，實際上這些並不重要。

快速的將產品框架通過原型進行輸出，然後邀請相關的人員進行初步評審，才是我們在互動原型中所該做的。當一切溝通得差不多後，在根據實際的需要去輸出原型的細節。

我覺得，一個產品經理是否成長，需要看他對工具的使用上，如果能夠儘可能快速的輸出互動原型，沒必要去死摳原型的細節。真正的介面設計等是需要依靠 UI 等去實現的，產品經理最核心的工作還是該聚焦在產品規劃的是否合理，如果一個產品的邏輯等沒有思考清楚，原型畫的再好看也只是個空殼。另外，當原型輸出後，通常會在輸出產品需求文件(PRD)，如果專業一點的，應該都是用 word 等形式輸出，但目前，我們都是直接在原型上直接進行相應的需求說明。這方面，老實說，真正的產品需求文件，還真是不專業。。。心塞。。。

講到這裡，我覺得需求評審可以重點說一下。實際上，產品經理只是一個產品的規劃設計者，並不是最終的使用者。對於後臺產品的開發，基本上是為公司內部的其他部門人員開發的。比如，這次的代金券功能，最終的交付物件是運營部。因為所處的角色不同，產品經理很容易在設計產品的過程中脫離實際的使用情況，但由於使用者在產品為上線使用時，通常也不清楚自己真正需要使用的是什麼。因此，在需求評審的過程中，實際上經常會出現的就是，產品經理在進行需求講述的時候，運營人員也不覺得有問題。這個時候，所有的相關人員都覺得是合理的。我想，這其中有個很重要的原因在於，當我們在進行講述的時候，聽的人很容跟隨著你的思路進行思考，也就是需求評審時，思維逐漸同步了，因此有很多問題，實際上在需求評審中也很難發現。我覺得要減少這種情況的出現，讓需求評審幫助產品經理發現更多的問題，有這麼幾種方法：

1. 在需求評審前，讓相關人員，尤其是產品完成後的一線使用者先熟悉你的原型。最好的辦法是，產品經理單獨跟一線使用者進行溝通，由他詳細的講解跟使用者。
2. 模擬使用者日常的一些操作流程，或者更多的觀察一線使用者實際工作中的情況。實際上，後臺的相關產品是日常操作流程的程式化。
3. 產品的快速迭代開發，一個新的產品功能規劃時，事實上的情況是使用者提出了很多的要求，可以說把他們能想到的都說出來了。而實際上，核心的只有幾項。而且，在產品沒有上線投入使用前，很多要求實際上都只是一種假想狀態。因此，很重要的一點，我們在接收到很多的要求時，實際上應該把所有可剔除的東西都剔除，只保留最核心的東西。快速進行開發輸出，只有在使用後，很多問題我們才能夠發現。這大概也是網際網路推崇敏捷開發的一個重要原因。要知道沒有經過實踐檢驗的產品，很多假想可能只是我們想得太多。而真正重要的一些東西，卻沒有提出來。

這次的代金券功能，有一個指定投放的需求，羅列了很多的篩選條件來篩選符合條件的使用者。但在功能上線後，發現這個功能更多的是需要一個匯入名單的功能。而這個功能在開發時浪費了很多的時間，但上線後，我覺得並沒有達到當初設計的目的。因此，我覺得在產品的技術開發過程中，如果有的功能技術實現起來很複雜，那麼需要認真的思考溝通，這個功能到底有無其意義。

最後，在原型設計時，通常隨著溝通及技術開發過程中，我們通常會發現很多問題，從而需要對原型進行修改。比較好的方式是又進行的任何修改等都需要有相應的版本記錄，改動記錄，以便可以進行追溯。不過與相關人員進行溝通後，例如和技術溝通後，有些功能實現需要修改，卻沒有對原型進行相應的調整修改，這會導致後期遇到一些問題沒辦法追根溯源。而且，我們很容易忘記當時溝通的內容，事後再檢視時需要花費很多的經歷，甚至回想不起來。這個問題，目前我在實際的工作中，做的並不是很好。

介面設計

介面設計就是 UI 設計稿的輸出，主要是設計的工作。這方面我一般接觸的較少，不做太多詳述。

有的時候，產品經理需要對介面設計的風格例如主色調、佈局等提出自己的一些要求~（這個老實說，我這方面挺差的）；還有一點就是在介面設計完成後，要檢查是否所有需要的元素都體現出來，設計師是否有遺漏。因為，實際上，你的原型設計出來後，一般技術也是不看的~通常是看 UI 進行開發的~相信我，這是真相。

另外，因為不同的設計方式，尤其是互動方式，對前端開發的影響非常大，所以如果是針對使用者的產品，對於 UI 設計出來後，進行檢查是很有必要的~起碼，你要保證，重要的元素沒有遺漏。不然，等技術實現了，你要再改，技術 GG 會想拿刀捅你的。

技術開發

技術開發階段，這方面產品的工作相對較少。

這一階段，主要是技術在開發過程中遇到問題，產品經理需要一起溝通解決，針對一些技術實現難度大或不合理的地方，需要去想辦法解決。另外，我覺得這階段重要的一點是，需要定期的和技術進行溝通。因為在技術開發過程中，通常也是階段或者一個模組一個模組的完成的，所以每完成一個模組，產品經理有必要去對完成的模組進行測試檢查。

這階段，如果能夠儘早的發現問題，改動的成本是最小的。在技術開發階段，不聞不問的產品經理實在是不太好。對，說的就是我~自我反省 ing……

之所以這一點要重視，是因為技術在實現的過程中，一些看似不起眼的改動可能是需要進行大的框架改動的，甚至程式碼需要重構。因此，在產品的規劃設計之時，框架一定要確保儘可能的無誤，並且要跟技術溝通，儘可能的為後續的一些想要實現的功能留有餘地。雖然不可能完全避免，但總歸是可以減少很多無用工作。儘可能的定期與技術溝通，並且對開發完成的功能模組進行測試檢查。及早的發現問題

測試

測試階段，一般主要是發現產品開的一些 bug。雖然主要是由專門的測試人員負責，但產品經理也需要參與測試，主要是去發現功能上的一些問題。比如是否有功能缺失，是否有重大的 bug。一些測試發現的問題，也需要產品經理去決定怎麼處理，是需要立即處理，還是可以暫時忽略。另外，因為整個功能是由產品經理進行規劃設計的，所以實際上，產品經理參與測試，才能夠判斷產品的實現是否有按照當初的規劃進行。

這次的代金券功能的測試，仔細回憶了下，我並沒有比較好的進行。所以，後面發現，沒有自己走一遍功能，有些地方的實現，測試也很容易忽略~

不過，雖然有測試，但要知道，測試只是減少 bug 的產生，有很多東西也是測試階段不能發現的。

上線

產品在經過了上面的一系列過程之後，就需要上線進行使用了。上線通常會有一個內測階段，例如幾個人進行小範圍測試，或者邀請一些使用者參與內測。上線前，通常產品經理需要做一些準備工作，包括對相關人員的培訓，針對相關人員輸出操作說明等。我覺得上線前的試用期最好是能夠長一點，因為這期間能夠發現很多的問題，需要快速的迭代改進，才能夠拿出一個差不多的版本。

在這次的代金券功能上線後，我發現了挺多問題。由於身份角色的不同，產品經理並不是最終的使用者，再設計產品時，考慮的角度都是完美情況，但實際的使用中，基本不存在這種完美情況。因為你是產品的設計者，所以你覺得整個使用過程很簡單， 沒有覺得有什麼不能理解的地方。但 too young too naive，事實上，當真正的使用者在使用的時候，一定會噴死你的。“這什麼鬼啊”、“怎麼是這樣的啊”、“產品經理這個傻逼”……表示到現在我還記憶深刻。

由於這次正式上線的時間很緊迫，在交付使用時，發現了很多問題。例如在建立代金券的時候， 有一個使用條件欄位，我在規劃的時候，使用條件有一個專門的樣式，所以沒發現什麼問題。但實際上，運營在填寫這個欄位時，輸入的內容跟設想的差不多少。所以我被吐槽了~更坑的可能就是指定投放做的是內部的條件篩選機制，而實際上運營是從外部匯入名單的，因此他們就一個使用者名稱一個使用者名稱的搜尋，然後去投放。 我想，那個時候他們一定是崩潰的。但老實說，在最初的規劃設計時，真的沒人提過這個外部匯入功能啊。。。而且，由於時間緊迫，外部匯入功能也並不能馬上加入。

所以，我覺得，產品在正式的上線時，先投入使用一定的使用週期；發現問題後，能夠預留一段時間進行。如此反覆幾次，在進行最終的上線， 是比較好的方式。預留較長的一段時間，進行反覆的測試迭代，在進行最終上線當然，這也印證了我前面說的，只有當產品上線後，實際使用才能發現產品設計的很多不足，很大程度上這是受限於你的身份角色，畢竟實際的工作流程你並不是真正的熟悉，所設計的會有很大出入，而使用者也很難表述自己真正需要的是什麼，所以快速的先做出一個最小的可用產品投入使用，不要考慮太多的複雜細節和功能。只有在使用過程中，才能發現真正的問題。

反饋

反饋階段就是產品在使用過程中，不斷地尋找發現不足，包括一些測試時沒有發現的 bug，沒有考慮到的功能，一些功能的設計問題等。這些都需要在使用過程中，不斷地收集。可以說反饋就是迭代的主要需求來源。

結語

做產品需要不斷的審視自己，不斷地反思總結。產品的設計事實上不存在完美的使用情況，你所設想的只是你自己認為的一種理想環境，這種理想環境通常都是不存在的。