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

通常，一個產(chǎn)品（或功能模塊）從需求到上線需要經(jīng)過

1. 認識產(chǎn)品
2. 分析產(chǎn)品
3. 交互原型
4. 界面設計
5. 技術開發(fā)
6. 測試
7. 上線
8. 反饋

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

需求的收集&分析

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

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

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

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

分析產(chǎn)品

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

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

比較困難的在于網(wǎng)站后臺對于代金券的創(chuàng)建管理，以及公司內(nèi)部如何進行代金券的創(chuàng)建-操作-審核的流程等。之所以這部分難度較大，有如下幾個原因：

1. 對于其他平臺的操作后臺，我們很難有渠道可以進行參考分析。實際上，對于做后臺的產(chǎn)品經(jīng)理，能夠做競品分析的很少，通常體驗競品的難度更大。因此，我通過其他途徑，例如淘寶、微博、微信公眾平臺的卡券功能出發(fā)，獲得一定的參考。但總體而言，這部分依然差的比較多。因此在后續(xù)原型的設計當中，也就遇到了較多的問題。

2. 流程方面的問題。這方面主要（1）代金券的不同創(chuàng)建方式及流程;（2）內(nèi)部審核流程。其中，內(nèi)部的審核流程算是比較艱難。主要在于后臺卡券的創(chuàng)建及投放流程。這個流程的推演只是個人的假想，是從我自己的經(jīng)驗知識角度出發(fā)。功能實現(xiàn)后，發(fā)現(xiàn)這個流程雖然能用，但并不是一個順暢的流程。

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

交互原型

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

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

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

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

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

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

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

這次的代金券功能，有一個指定投放的需求，羅列了很多的篩選條件來篩選符合條件的用戶。但在功能上線后，發(fā)現(xiàn)這個功能更多的是需要一個導入名單的功能。而這個功能在開發(fā)時浪費了很多的時間，但上線后，我覺得并沒有達到當初設計的目的。因此，我覺得在產(chǎn)品的技術開發(fā)過程中，如果有的功能技術實現(xiàn)起來很復雜，那么需要認真的思考溝通，這個功能到底有無其意義。

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

界面設計

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

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

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

技術開發(fā)

技術開發(fā)階段，這方面產(chǎn)品的工作相對較少。

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

這階段，如果能夠盡早的發(fā)現(xiàn)問題，改動的成本是最小的。在技術開發(fā)階段，不聞不問的產(chǎn)品經(jīng)理實在是不太好。對，說的就是我~自我反省ing……

之所以這一點要重視，是因為技術在實現(xiàn)的過程中，一些看似不起眼的改動可能是需要進行大的框架改動的，甚至代碼需要重構。因此，在產(chǎn)品的規(guī)劃設計之時，框架一定要確保盡可能的無誤，并且要跟技術溝通，盡可能的為后續(xù)的一些想要實現(xiàn)的功能留有余地。雖然不可能完全避免，但總歸是可以減少很多無用工作。盡可能的定期與技術溝通，并且對開發(fā)完成的功能模塊進行測試檢查。及早的發(fā)現(xiàn)問題

測試

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

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

不過，雖然有測試，但要知道，測試只是減少bug的產(chǎn)生，有很多東西也是測試階段不能發(fā)現(xiàn)的。

上線

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

在這次的代金券功能上線后，我發(fā)現(xiàn)了挺多問題。由于身份角色的不同，產(chǎn)品經(jīng)理并不是最終的使用者，再設計產(chǎn)品時，考慮的角度都是完美情況，但實際的使用中，基本不存在這種完美情況。因為你是產(chǎn)品的設計者，所以你覺得整個使用過程很簡單，沒有覺得有什么不能理解的地方。但too young too naive，事實上，當真正的使用者在使用的時候，一定會噴的。

由于這次正式上線的時間很緊迫，在交付使用時，發(fā)現(xiàn)了很多問題。例如在創(chuàng)建代金券的時候，有一個使用條件字段，我在規(guī)劃的時候，使用條件有一個專門的樣式，所以沒發(fā)現(xiàn)什么問題。但實際上，運營在填寫這個字段時，輸入的內(nèi)容跟設想的差不多少。所以我被吐槽了~更坑的可能就是指定投放做的是內(nèi)部的條件篩選機制，而實際上運營是從外部導入名單的，因此他們就一個用戶名一個用戶名的搜索，然后去投放。我想，那個時候他們一定是崩潰的。但老實說，在最初的規(guī)劃設計時，真的沒人提過這個外部導入功能啊。。。而且，由于時間緊迫，外部導入功能也并不能馬上加入。

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

反饋

反饋階段就是產(chǎn)品在使用過程中，不斷地尋找發(fā)現(xiàn)不足，包括一些測試時沒有發(fā)現(xiàn)的bug，沒有考慮到的功能，一些功能的設計問題等。這些都需要在使用過程中，不斷地收集?？梢哉f反饋就是迭代的主要需求來源。

結語

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

本文由 @可飛（微信公眾號：abckefei） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉載。