最近做的一個項目從需求分析到上線綿延了四個月之久，這也是目前接手過功能點最繁復，產品線對接最多的一個項目。從中得到的一些關于設計較大型產品的心得，拿出來跟大家分享。

　　立項前

　　1、統一元素設計需考慮周全

　　也許是初創團隊的緣故，我不得不感嘆團隊對產品經理要求之嚴格之縝密，項目全程只有一個人負責，所以大到產品線對接，小到一句提示的位置和展示形式都需要一一推敲。

　　哪些元素應該做到統一？

　　A、提示方面：統一的操作成功/失敗提示；統一的彈窗形式；提示語言采用較統一的句型；為空情況的友好提醒；溢出情況的友好提醒；表單實時驗證的提醒形式等。

　　B、文字方面：是否有統一的段落前“·”號；統一的鏈接狀態；統一的字體、間距、行高等。

　　C、圖片方面：調取圖片的統一尺寸；如果是上傳圖片類的操作，需要考慮周全全站的調取情況，以及考慮是否統一預覽圖的尺寸等。

　　D、細節交互：未激活功能的按鈕做“灰色”處理（例如用戶沒有勾選信息時批量刪除按鈕不可使用）；按鈕點擊的狀態統一（例如增加“提交中”的按鈕狀態，以防止網速慢用戶狂點某一按鈕的情況）；特殊控件的統一等。

　　也許會有朋友說，上面有些是交互設計師需要做的事，但我一直認為作為一個產品經理考慮周全一些，沒壞處。這些“統一”同樣可以用在驗收階段，要知道，即使一個像素也可以改變整個產品的感覺。

　　2、原有功能的去留

　　我一直覺得升級已有產品比開發新產品難一些。這就像栽培植物一樣，新種下一棵果樹無非需要選對了土地，然后刨個坑種下去，然而成長期的去病枝、打頂等各種修剪所消耗的精力往往更多。

　　改進已有產品常常需要面對一個最棘手的問題：原有功能是去是留？

　　原功能去掉的話是不是會影響部分用戶使用？是否需要通過公告、站內信、界面引導等方式友好地告知用戶？怎樣把對用戶的傷害降至最低？

　　原功能留下的話是不是可以優化完善？聽到了什么用戶群怎樣的聲音？是否要在這次升級中做調整？

　　這些問題當接到項目的時候，產品經理就應該考慮周全了。特別需要注意的是，如果這個產品之前不是自己設計的，那么最好找到PRD說明文檔細細研究一遍，對把握不準的功能點找到原負責人確認，畢竟樹苗是Ta摘的，別把將來最能結果的枝干給砍了。

　　3、產品線上下游的對接

　　昨天有跟朋友聊起淘寶強勢之處，就是產品與產品緊密捏合，線上線下、跨平臺跨行業形成了一個盤根錯節、根深蒂固的根基，無可撼動。

　　所以把握產品線上下游和產品周邊很重要，即使一個看似簡單的新聞展示頁面修改也會牽扯到編輯后臺、廣告位管理、幫助中心，甚至是訪問統計、數據需求的變更。

　　這要求在產品設計開始前，需要把該產品“連根拔起”，仔細梳理相關脈絡，如果產品線夠長，一個清晰的產品線結構圖很有必要。

　　項目中

　　1、項目期間來自相關產品線調整的影響

　　項目期間相關產品線的調整是我最不愿意遇到的情況，這就像你在通往目的地的道路上高速行駛，就快要到達終點了，突然一個人告訴你：你走錯路了。

　　項目里有一個通用模塊，產品設計到一半，這個通用模塊改了；項目里有一個流程，產品做到一半，這個流程廢棄了；最要命的是已經立項開發了，你不得不硬著頭皮跟程序員說：“因為一些不可抗拒原因，這個需求咱不做了。”

　　對于一個耗時較長的項目來說，這種情況難以避免，事出原因私自總結有三：

　　A、嚴重體驗性問題：例如某個流程遭到大量用戶的不滿，為防止用戶流失，不得不做臨時調整，而倒霉的是，你也在用這個流程。

　　B、相關項目的影響：包括并行項目和新項目。例如你的同事在設計另一個產品，你們的產品相互牽扯較多，所以需求分析時做過很多溝通，但有一天，同事告訴你，Ta的一個需求做臨時調整了會影響到你，怎么辦？

　　C、老板的突然決定：不舉例。

　　最終的解決方法不外乎三種：立即調整、延期調整、不調整。個人的處理原則一般是對A種情況進行立即調整，對B、C情況討論并選擇性延期。

　　為什么這么做呢？A情況是必須要改的，時間早晚問題，長痛不如短痛，B、C兩種情況必須坐下來細細討論。需了解這個需求為什么要改？是長期對策還是臨時決定？能否延期，記錄需求等下一版本再開發？如果B、C情況提出來的需求沒過兩天又有改變，那與你配合的前端和程序員也太沒有安全感了。

　　這個時代能耐心閱讀完2000枚漢字的人越來越少，較大型項目的產品工作心得[下]未完待續，歡迎交流……

　　2、需求變更

　　承上，需求變更是每個程序員、產品經理、設計師等都會遇到的情況。產品經理不是神，項目組也不可能是開了無敵狀態抵擋任何外界的影響。

　　當遇到不得不變更需求的時候，產品經理應該怎樣處理呢？下面是個人的四條建議：

　　a、積極處理。往往，當一個設計愈是趨于完成，人們愈是傾向于局部調整，而不是做重新設計。當一個需求因為眾所周知的原因不得不調整的時候，作為產品經理需要做的第一件事便是積極面對問題，積極處理。

　　項目開發往往是一個緊張的過程，每半天甚至每幾個小時就有若干個功能點開發完成，當一個需求變更傳達出現“延遲”，這個變更對項目的正常進程的“破壞力”就會更大一些。

　　b、保持溝通。“說話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時候，溝通是個自己掙扎的過程”這話沒錯。需求變更直接會影響到下一道工序，產品經理需要將需求變更的細節和原因傳達給相關人員，包括視覺、前端、程序、測試等。

　　這是很多產品經理表示非常痛苦的過程，因為可能會遭到數落和冷眼，日本有一個禮儀原則是“不要給別人添麻煩”，但是在項目中，這不可避免。

　　個人認為所有溝通的障礙都源于思想的不統一，如果讓大家覺得這個需求修改是在浪費時間，那么溝通上的不暢快在所難免。項目不是這樣算的，需求既然更改一定有所目的，產品經理需要將這個原因講明白，不做修改或節約溝通時間導致的返工，后果往往更嚴重。

　　c、更新文檔。依然是為下一工序提供方便，產品經理往往不只負責一個項目，及時更新文檔和修訂文檔版本號也可以為日后的查看提供便利。另外，文檔不是萬能的，更新文檔是必要而非目的，任何時候都不要只丟下一些文字給別人，這好像在說“就這樣改，其他別問”，是不負責任的態度。

　　d、走好流程。每個公司的需求變更流程不盡相同，流程是為了項目更好的進行，不要看做累贅，流程不合理可以提出自己的建議，而私自繞過流程會為日后推卸責任埋下隱患。

　　3、上線前準備

　　在剛開始接觸產品工作的時候，對于一個產品的上線一直停留在“需求-設計-開發-測試-上線”的簡單流程模型里，實際操作起來才發現需要做的其實還有很多。

　　這些工作主要包括：

　　a、數據準備：產品中用到的數據（頁面內容）需要提前準備。比如一個頻道頁上線，頻道上的內容來自哪里？通過抓取？調用？還是后臺推薦？編輯錄入？如果是一個全新的模塊，還需要重新填充數據。這個工作往往需要其他部門（比如編輯部）配合完成，產品經理需要做的是：1、提前告知，方便部門負責人合理安排工作；2、預留充足的時間，至少保證上線前填充完畢；3、細節說明和特殊說明溝通清楚，避免返工。

　　b、統計需求：產品上線后需要跟蹤監測的數據統計需求，需要形成文檔告知開發人員。在產品設計期爭議較大、把握不準的功能點，在效果圖設計中存在顧慮的頁面元素設計都可以記入統計需求，以便后期更好的分析用戶行為，為下次產品的迭代和需求增減提供數據依據。

　　c、廣告位：頁面的廣告位變動，需要在產品設計期與銷售、市場部門溝通，并在產品上線前再次確認。廣告位的調整在產品設計中在所難免，為更好的保證客戶利益，需要多聽取銷售與市場部門的建議。產品上線前需要將重新整理的廣告資源交付平面設計，并替換在頁面上。

　　d、產品推廣：屬于產品運營的范疇了，產品與運營在工作中的碰撞更多一些，現在很多公司索性將兩者合為一部，這是后話。這里想說的是，產品上線所必要的上線（改版）公告、商業軟文、多渠道宣傳這些基礎的運營手段都是不能少的，產品經理前期可做簡單跟進，主要是做溝通與配合。

　　e、幫助內容：頁面幫助相關內容的修改。主要是類似“幫助中心”頻道的內容調整，如果是視頻的話需要考慮重新錄制。

　　上線后

　　產品上線往往意味著挑戰才剛剛開始，這和拍電影不一樣，經過緊羅密鼓精心籌劃，一部商業大片終于上線了。觀眾看了笑了怒了罵了那是觀眾的事，反正可以賺的盆滿缽溢。

　　產品設計更像一個打靶的過程，用戶需求就是靶心，每次產品改版都是在扣動扳機，我們需要做的就是——開槍，然后看看偏了多少，不斷調整，力求下一次正中靶心。

　　是的，產品上線意味著征戰又重新開始，沒有機會停歇。且回歸用戶需求，總結經驗，繼續投入到下一個項目中吧。[完]