這篇文章是我6月份寫的，在負責的產品上線之后寫的反思總結。我想這個過程，對于中小創(chuàng)公司的產品經理來說會有一定的借鑒意義。因為中小創(chuàng)公司并不像大公司那樣把崗位分的非常細，產品經理經常會負責除了開發(fā)測試的其他工作。對于大公司的產品經理，我想就當做一個案例的了解吧。

從4月中旬開始做選股寶產品，開發(fā)一個月，測試兩周，最終App在6月底上線。作為一個新人，能夠有機會負責做一個全新的產品，是機遇也是挑戰(zhàn)，路上遇到的坑坑洼洼也是一筆寶貴的財富。

話不多說，開始吧。先說說產品線的情況：

• 移動網頁：用來App沒上線前的預熱、充當各種webview以及分享頁面；
• ios版/Android版：移動App；
• 內容生產后臺CMS：內容生產平臺；

下面我將按照立項、產品設計、開發(fā)、測試、上線五個階段來分別進行自我回測。

第一階段：立項

大抵創(chuàng)業(yè)公司的立項都是CEO敲出一個idea，然后就干的吧？

這個階段，我沒怎么參與，不過也沒有打醬油：一邊通過處理公司內部需求熟悉公司業(yè)務，一邊實戰(zhàn)炒股同時學習各種k線圖、技術指標、基本面等等知識，把自己變成股民來體會股民的心態(tài)以及行為。

然后，就是機會來臨吧，總負責人皮總讓我一起跟進這個項目，Let’s do it

從結果論上來說，炒股這個行為也讓自己做這款產品相對來說更加得心應手，因為對需求對用戶理解的更深。

第二階段：產品設計

這時候，大抵開始了作死模式，過程如下：

1. 和總負責人皮總溝通、撕逼產品的方向、功能；
2. 基于上面的前提，做出了App的動態(tài)原型1.0.0（基本功能、交互完善）；
3. 1.0.0的產品方向被CEO槍斃；
4. 和CEO&皮總溝通，做出App動態(tài)原型1.0.1；
5. 再被局部槍斃；
6. 產品總負責人變成了衣腫大人；
7. 和衣腫&CEO溝通，做出了App動態(tài)原型1.0.2，以及后臺CMS動態(tài)原型1.0.0；

這個階段總結下來，有以下幾點值得注意：

1、App動態(tài)原型1.0.0生產前，我默認了皮總和CEO是想法一致的，但事實上并不是，還相差略大，這給后面不斷改稿埋下坑點；

可以做更好：尤其是一個新生的產品，它的方向會直接影響到是否有資源匹配、后續(xù)的功能如何以及呈現(xiàn)方式如何等，因此，在開始著手做原型之前，一定要確認大家在方向上想法是一致的。如果不一致，那就“撕”到大致一致；

2、在第1點的情況下，畫了比較保真的原型。但是對產品方向的想法都不一致，再保真的動態(tài)原型也無用。雖然為了縮短時間，都是通宵趕稿出來的，然而這就跟“通宵念書很勤苦”一樣，感動的是自己而已，如果多注意到一層，就不會這樣了。

可以做更好：建議先畫手稿和決策人進行溝通，得到大致一致之后，再去畫比較保真的原型圖，那么很多無用功夫就可以避免。

3、競品分析做的遠遠不夠，無論廣度或是深度。當初覺得市面上沒有內容，原來只不過是因為看的少。這個項目當初是比較趕著要做完上線，希望抓住牛市行情進行推廣，因此在時間上非常的匆忙。

可以做更好：在時間匆忙的情況下，對于競品分析這塊我確實沒有更好的方法來解決這個問題。不過想說一點：產品經理最好是自己產品的忠實用戶。這樣，對于產品的可改進點以及用戶要什么，都會理解的更深。不僅對1.0的原型設計有幫助，同時對1.0之后的需求迭代也會有很大的助力。

4、雖然內心以及筆頭都有規(guī)劃過后面的功能，但是交付研發(fā)只給了1.0版本的東西，導致技術在架構上面容易沒擴展性。以現(xiàn)在迭代幾個版本的角度看，有些地方因為加了一些功能，確實導致了頁面的重構。

可以做更好：建議把能夠達到穩(wěn)定版要求的原型都呈現(xiàn)出來，這樣開發(fā)在代碼設計的時候就更容易考慮到一些以后可能的情況吧應該。

第三階段：開發(fā)

這階段，可以稱之為“無人領頭并行工作死翹翹”模式。這部分很大原因是，沒有領頭人的同時追求“快”，匆忙開發(fā)。

1、整個團隊的成員都非常年輕，也沒有做0-1項目的經驗，在產品設計、UI設計、開發(fā)過程中，都存在經驗問題。但是我覺得很可貴的是，整個團隊都非常合作和團結。雖然大家做的很累，但最終，都把這個產品扛下來了。關于這點，并沒有什么可更好的地方，畢竟，資源有限的情況下，團隊和個人都需要時間成長。

2、在1的情況下，產品設計階段的原型圖只是一個大概的圖，細節(jié)和邏輯并不完善。 細節(jié)不完善存在的問題是，當初畫原型圖就是個短時間的事情，有些地方的交互覺得并不那么符合習慣，那么就會存在修改了某個按鈕的位置，然后設計師就得跟著改，前端開發(fā)也得跟著改，然后惡性循環(huán)，大家都很累；邏輯不完善存在的問題是，我一邊補充更細的邊界條件，開發(fā)人員一邊進行開發(fā)，那么會造成開發(fā)和溝通上的壓力。

可以做更好：即使并行工作的前提無法改變，那么可以讓開發(fā)童鞋們先做功能實現(xiàn)，再統(tǒng)一修改UI，與此同時，產品和設計師確認好UI，避免開發(fā)在做功能的情況下還要一次又一次的修改UI；

3、因為要快，所以很多技術上的實現(xiàn)，能簡單就簡單，能套用公司原有的的東西就套用，這個在1.0項目上沒有辦法。但是從迭代幾個版本的眼光來看，確實在一些技術的實現(xiàn)上，因為之前做的太耦合，導致后面又重構。

4、在開發(fā)過程中，由于上文第2點，存在開發(fā)過程中，需求小變更的情況，但是這個變更沒有落在紙上。不是說落在紙面可以免責，而是口頭溝通的問題在于，不能保證各自雙方記憶力的完整。同時，某個需求如果同時涉及前后端人員，而大家沒有全部知曉，也是隱患的存在；

可以做更好：如果需求有變更，不管是因為產品設計原因，還是因為技術暫時實現(xiàn)原因進行的折衷，都需要進行對應的記錄標示清楚，以便于之后查詢以及后續(xù)人員的產品了解。

5、也是由于上文第2、3點，產品的某部分內容是由公司原來的管理后臺生產，要滿足這種工作場景，必須對其進行部分的改造，而這個改造會影響到整個公司原有的產品線的內容（網站、ios & android的App）。在第一次在改造的過程中只考慮網站，卻忘記了App端，好在第一次開發(fā)量不大，但是也是浪費了人力。

可以做更好：這個充分說明了PM在進行產品設計的過程中，大局觀很重要。在改造原有東西的情況下，要了解清楚原有內容影響的部分、如何適應新改造、以及改造后對原有部分的測試等。這一點，在另一文章中進行更加詳細的討論（《產品小白科普：你做產品的優(yōu)勢是什么》）。

6、這個產品在1.0版本的時候是沒有技術負責人/項目經理來管理需求的時間評估、進度的控制的。那個時候，由PM和需求相關的開發(fā)人員進行一個個需求分析的闡述、評估時間，最后測算開發(fā)時間。同時，在項目的過程中，也是PM進行進度的跟進、各種溝通協(xié)調。

這樣會造成非常大的問題：

1. 對項目時間的預估會存在很大的誤差。
2. 對項目進度的控制會存在很大的問題，或者說混亂。
3. 在一些技術問題的解決上，需要PM來“牽頭”問題的討論、解決，也是有點坑。

總體來說更像是團隊成員之間相互推動的結果。但是從管理上來說，這并不好。

可以做更好：一個團隊必須要有綜合的一個技術負責人對所有需求進行評估、開發(fā)上的設計以及和技術溝通。PM可以做這些事，但是從實際上來說，是真的做不好。同時，有比較科學合理的方法對項目進行管理也是比較好的。這個，在另一篇文章中提過Scrum敏捷開發(fā)管理（《產品經理如何用Scrum敏捷開發(fā)帶領團隊》）。

第四階段：測試

這個階段，不但臭婆娘的裹腳布，又臭又長，而且還不得重點：

1、產品整個1.0版本的時候，是沒有專門的測試人員的，也就是說完整測試、邊界條件測試什么的都是PM跟進。在iOS 1.0第一次完整測試的時候，沒有經驗，沒有寫完整的測試用例，不利于測試結果的追蹤也不利于其他人幫助測試。在第二次完整測試的時候，我結合了需求和第一次的測試結果，寫了很完整的測試用例，同時又讓其他人一起參與了測試，總算是提高了測試的效率。

可以做更好：

1. 要有專門的測試大人！專門的事就讓專業(yè)的人做，這樣總體性價比才會比較高。
2. 在沒有測試大人的情況向下，PM要兼顧測試工作，那么一定要寫很完整測試用例，包括行為、頁面、期望值、測試結果、開發(fā)反饋、回測結果等等。
3. 在完整測試過一次之后，就可以發(fā)起其他人幫助一起測試，測試用例云協(xié)作，提高測試效率。

2、測試也需要全局觀，這個在第三階段開發(fā)中也講到過。

舉個例子：利用原有管理后臺的發(fā)送新聞功能，把某條新聞發(fā)送到一個選股寶平臺中。臨近上線前1天，研發(fā)人員把對原管理后臺的改造給完成，但是當時我的注意力都選股寶的移動網頁、后臺CMS的測試中，并沒有對改造的部分做非常嚴謹?shù)尿炇諟y試?？墒?，原后臺的改造才是最需要測試的部分，因為它涉及到了公司原來三個端的產品內容正常呈現(xiàn)。

3、很無奈的一點，精力有限。沒有專門的測試的情況下，只能由PM來測，但這樣，產品2.0的功能以及邏輯、競品的了解等產品工作就往后推了，等上線完，所有的工作都停在了產品階段，OMG；

第五階段：上線

上線前要考慮非常多的因素，包括：

1. 上線的時間；
2. 對用戶的影響；
3. 上線的東西是否測試完全；
4. 上線需要準備的數(shù)據庫遷移、服務器等等是否ok；
5. 上線如果遇到問題，是否有有相關人員stand by；
6. App產品上線前就需要確定相關的素材是否準備充足；

上線是個需要非常謹慎對待的事情，謹慎！謹慎！謹慎！

好了，關于我們產品1.0的回測就到這里。希望以后有機會針對每一個坑能夠進行一一分析^_^

本文由 @梁露瑤（微信公眾號：killifer） 原創(chuàng)發(fā)布于人人都是產品經理?，未經許可，禁止轉載。