本文由人人都是產品經理 @可飛（微信公眾號：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，沒有考慮到的功能，一些功能的設計問題等。這些都需要在使用過程中，不斷地收集。可以說反饋就是迭代的主要需求來源。

結語

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