起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識客戶端產品：如何高效穩定地迭代開發
客戶端產品相較PC、移動web而言，更重、更繁瑣，需要綜合考慮的因素多。因此有一個系統、全面的項目管理流程是很有必要的。特別是用戶量到達一定級別之后，產品和項目會變得愈加復雜，如果項目管理跟不上，就會導致開發效率下降，產品方案實際落地與預期偏差大、溝通復雜且困難，團隊內部矛盾加深等問題。一個客戶端產品如果想高效而穩定的進行迭代和版本開發，科學的項目管理方法至關重要。接下來的文章就本人的經歷和思考提供一些解決方案，以供參考。
既然是項目管理，當然就得按一定方法將項目從起始到結束的整個流程切分為一個個的節點，然后根據各個節點的情況來提煉共性并輸出指導方法論。就像打游戲一樣，哪一關的boss應該如何打？以下提供一種思路做參考。將客戶端產品項目的產品需求調研、收集及策劃定為項目開始，版本穩定上線設為結束，這就是一個完整的流程，中間的環節及順序見下圖：
下面，我們仔細分析每一個節點需要處理的事情和一些需要注意的事項。
策劃：
作為一個項目管理者，在這個階段需要做的就是明確各個需求方的需求，從大的角度（整個APP）去審視各個需求方的方案是否存在短視的行為。比如：是否遵循了端的設計交互、設計規范（后文會補充說明），是否有可以合并實現以降低開發成本的交叉區域，是否有現階段做不合適的需求等。
從細節展開來講就是先了解清楚各個需求方的需求、優先級和產品預期；然后經過全盤的思考后，給出意見和輸出結論。
例：
需求方A想在這一版本中賣會員，方式是走自己的交易系統進行結算；
需求方B希望在這一版中賣虛擬道具，方式是使用自己產品的虛擬貨幣體系M幣來進行結算。
當前的情況是客戶端上沒有接入任何交易體系。在這個case的背景下，作為端的項目管理者就要思考：既然大家都有支付的需求，是否值得做（接入）一套支付體系來整體承接。比如接入貨幣體系M幣，所有的支付需求都走M幣結算，用戶僅需購買M幣就可在這個產品上兌換所有的付費服務。
在這個環節，這種例子不勝枚舉，大家可以舉一反三去處理實際遇到的問題?？偟乃悸肪褪茄劢缫獙捯恍苤貜屠玫谋M量重復利用，能協調到一塊的就盡量協調，以節約開發成本。關鍵點是讓產品從用戶的角度看不會感覺明顯割裂，體驗是完整的。
舉個反例：如果單純的滿足上例A、B方的需求并上線，某用戶C需要購買A、B方的東西，他充值M幣之后用來購買B方提供的虛擬道具；剩下的M幣想買A方提供的會員，卻發現無法用M幣支付。此時，體驗就是割裂的，不完整的，用戶會迷失。這種情況非常嚴重，大家一定要重視，竭力避免。
交互、視覺：
和交互、視覺同學打交道，要注意自己的溝通和闡述方式。注重輸出需求本身而不是浮于形式，這個很關鍵。比如：告訴設計師你要做這件事的初衷以及期望達到的產品目的（例：通過附近的人來為陌生人創造場景，提供沉淀關系的機會），而不是直接告訴他照著微信（陌陌）抄。
有很多公司PM本身就兼任交互設計師，那么在這種情況下在產品設計過程中建議多跟視覺同學溝通，保持信息通暢。原型設計過程中盡量別帶干擾因素（上色、限制死元素尺寸等）。
溝通過程中一定要以目標為導向，不要沉溺于形式。比如：某一個地方兩種設計方式都能達到目標，且效果評估相近，設計師贊同A，產品贊同B，這種時候可適當妥協。
設計方案過程中產品一定要有邏輯、有體系的去檢查各個頁面的細節，盡量減少后期返工的可能性（問題前置一定比后置要好）。
例：設計好方案后將其拆解為幾個大方向，分別去檢查case是否健全，有無遺漏情況，下面分享一個檢查表，大家可以根據參照這個思路去進行產品設計的檢查。
做設計的時候一定要去考慮細節，不然后期可能因為一個很小的點（致命）而導致大返工。
例：
假如我來設計網易新聞中新聞tab下頭條tag中的新聞卡片。例圖如下：
我會從UI、交互、緩存、異常這幾個關鍵點入手對產品方案做細節梳理，梳理腦圖（case）如下：
上述腦圖（case）只是舉例，大家可以按照自己的實際情況及偏好借鑒這個思路去做變形或延展。但是在做產品設計時一定要考慮，不然后期可能會因為不確定性因素造成delay甚至是大返工。在跟需求提出方對方案時，最好也按很細的角度，思維去檢查。
很多產品同學認為case是QA同學負責的，自己不用在意，其實這種思路非常錯誤和不負責。試問如果產品考慮得不夠細致和全面，那最后產品還是會被QA同學不停的追問。那么你的整個工作節奏肯定會被打斷，每天被瑣事纏身，工作效率下降。對于QA同學而言，寫case的時間也會成倍增加。
評審：
評審是產品全流程中的分水嶺，理論上講評審過后則需求凍結（不能再改了）。作為項目管理者，在這個階段一定要確定好游戲規則并嚴格執行，在各方心中建立信任度。評審過程越激烈越好，大家充分的提出自己的想法和觀點，以及自己預判的一些風險點，在評審中一定要盡量暴露問題（問題前置）。如果需求評審會一團和氣，那一般情況下后期開發、驗收過程中都會存在大量撕逼、扯皮、delay的情況。
個人提供一種規則思路：
項目管理者收集匯總各方的PRD及feature list，統一交付給評審參與者。有兩點較為重要：
- 文檔寫清楚版本號，方便多次修改、調整后各方都還能明明白白；
- 文檔做好留檔工作，日后追查線上功能時，有據可依。
*PRD大家都有自己的玩法，我就不獻丑了，feature list我提供一點點想法：
還是按照上文的例子進行舉例
方向是指需求提出方，模塊是指屬于客戶端哪個部分，頁面就是功能所在的頁面，需求點是需求的提綱和概述，優先級是指緊急程度，負責人是跟進這個需求的PM（有問題就找他了解、協助推進）。有了feature list后可以保證版本需求很繁瑣時不出現遺漏，減少了很多后期的風險，也方便開發人員快速找到需求的接口人，提高溝通效率。所以作為項目負責人有必要讓各需求方按照統一的方式提交feature list。
評審開兩次，第一次小范圍（負責各需求的PM、項目管理者、UI負責人、RD負責人、QA負責人）評審和討論；第二次全體（所有置身于項目中的人）評審和討論。
第二次評審結束，開發和測試就此版本需求情況進行排期，輸出每個需求的開始及結束時間節點以及最后完成版本開發（封版）的時間節點。
第二次評審出結論后，即是產品、開發對此次項目達成共識。對產品而言意味著需求不能再改（增）。當然了，如果砍需求，我相信開發們會很樂意（所以PM同學在這之前一定要仔細考慮清楚需求和邊界情況）；對開發而言需要則是要對輸出的完成時間點、功能實現負責。后期存在delay，需求無法實現的情況都是需要開發同學背鍋的（所以開發同學評審時一定要了解透徹，認為不靠譜的地方一定要在這個環節提出并解決）
這個環節的重點是在于不保留的提出問題，明確劃分好權責，把之前階段所有不透明、不明確的因素全部解決好。
跟進：
這個階段的重點在于按照之前的協議卡好時間節點來開展相關工作。項目管理者在這個階段需要雙眼盯好時間點，一切為時間服務。項目管理者在此階段是需求提出方和開發方的接口人
要積極幫助雙方推動事情，解決問題，關鍵的時候需要能站出來拍板并承擔責任。很多有明顯交叉的地方（不屬于此版本中任意一個需求方，但是又必須要做）需要項目管理者來進行處理。
例：
需求A的開發、測試時間是8.1-8.10，需求方是B，開發是C。
- 情況1：B和C就某一細節爭執起來了，你需要根據評審時的結論以及端的規則來協調雙方達成共識
- 情況2：需求A較復雜，還要協調另一個team加入工作。這時還是得盯著時間，做出決策和應變。如果可以，結論最好告知雙方老大，這對雙方而言是一種約束（跨團隊、跨部門、跨公司協作這種事情應情況而異，我個人的秘訣就是要保持理智和耐心，積極的扛起責任和處理事情，無止境的抱怨是無濟于事的）
- 情況3：由于高優項目插入或人力出現變動，導致項目有delay風險。這種情況需要判斷delay風險是否會影響整個版本的總體時間規劃。如果不影響，那見機行事；如果有影響，就要考慮精簡，砍掉這個需求或者是延長開發時間（簡單來說遇到這種情況盡量精簡需求或者是delay此項目吧，棄車保帥。保證整個版本的時間計劃不被打亂才是最重要的）
上述列舉了一些頻發的情況，其他的就不一一贅述了，大家見機行事。決策原則是少扯皮、多扛事，眼睛盯住deadline。
驗收：
此環節對經驗的要求很高，大家平日一定要多積累，見多就識廣了。Demo拿在手上體驗一會就知道哪里有問題，哪里要返工。個人的經驗也說說，大家可以自行判斷和參考：
- 驗收要有科學的方法：拿著feature list保證不會漏看，根據PM和QA同學寫的腦圖（case）驗收每一種情況是否都符合預期。最后按照用戶可能的使用路徑做無規則體驗。
- 驗收分為分個驗收和總驗收兩種情況。在跟進環節時，每做好一個需求就拉上相應的PM進行驗收，確認每個分塊沒問題。最后組織一次大的整體驗收，多邀請一些角色（運營、交互、UI設計師、用研同學、銷售同學等），從不同角度來體驗和驗收。
- 驗收時發現有問題一定要及時跟進并解決。如果是由于PM特別是項目管理者自身失誤導致的問題，一定不要推卸責任，勇敢的擔下來并尋求彌補方案。人都會犯錯，關鍵是把結果達成。但是如果出現的是重大問題…那一定是工作沒做到位，回去慢慢反思吧。
灰度：
灰度主要有兩個用途：
- 就產品方案進行A/B test，基于測試結果來判斷使用哪種方案；
- 投放給客戶端小規模的用戶，觀測crash（閃退）率以及用戶對于版本新功能（改變）的態度來決定是否做出改變等。
需要注意的坑：用戶反饋的不一定就是對的，一定要有自己的判斷力，實在拿不準就去聯系這些用戶問清楚場景和他們吐槽的問題。
比如：
- 用戶說的不一定是事實：用戶反饋新版本字太小看不見；你一改，另外一撥用戶馬上又來反饋說字太大。
- 好的不一定是對的：某個東西大家都覺得好。從理論上推導更簡單、更順暢，從視覺上更漂亮、更精致。上線以后用戶狂噴…..原因是用戶已經養成習慣了，你去挑戰他的習慣，他當然要反抗。這一點，有個高人曾經給過指導：好鋼用在刀刃上。做得爛的趕緊改，做得好的擴大優勢，做得一般的千萬別動它（要么你下定決心把它下線了，要么就等他爛透了再動）
灰度的具體實施方法：
Android的話有很多應用商店，可以選擇其中一兩個作為灰度渠道，發出新版的包，然后再收集用戶的反饋意見。比如在百度手機助手、應用寶發布灰度包。
iOS的話可以在一些越獄渠道放灰度包進行測試，同時可以使用官方的testflight測試（大致幾百到一千用戶可以提前體驗未上架App Store的包并進行反饋）
上線：
灰度一兩周后，確定該解決的問題都OK了，沒有重大的問題或者是大量的集中反饋就可以正式發布啦（如果灰度時還有很多問題，比如crash率很高，那建議修復后再次進行灰度，確保不出問題）。
循環節奏：
如果你們的產品穩扎穩打，節奏較慢，那么在上述流程走完之后，進入下一次大循環即可。
如果你們需要敏捷開發、快速迭代，那么下一個版本的完整流程應該從當前版本中間時就啟動，在此提供一種思路：
其實非常簡單，當前版本進入灰度時，下一個版本的流程剛好走到評審即可
整體的環節不變。這樣做的好處是對于開發來說，一直處于
的節奏中。正常的版本迭代，進入灰度之后開發的時間相對會充裕起來，任務基本是解當前版本需求的bug，空出來的時間可以開始下個版本需求的調研工作。
補充：
客戶端規范：
產品大了以后涉及到多團隊并行設計和開發，有一套大家共同遵循的客戶端設計規范就顯得尤為重要了，這是保障客戶端用戶擁有完整體驗的必要手段。
在此提供一種思路：項目管理者協調好交互和UI設計師，從文案、按鈕、導航欄、文字樣式及大小、詢問彈窗、toast、icon使用規范（描邊？實體？彩色？）、基礎設置、手勢操作等制定出一套詳細的要求發給各個團隊，各個團隊在進行產品設計時，涉及到上述元素時只可在規則許可的范圍內進行自由發揮（比如app主題色是藍色，你不能搞個紅色的東西出來吧？標題用XX號字，摘要用YY號字，你不能反過來吧？雙擊是點贊，你不能設計成刪除吧？）這部分細節很多，只提供一個大體的思路，就不展開進行講述了，大家把握好關鍵點：大的客戶端一定有個圈，大家都得遵守規則，跳舞不能跳出這個圈。
多開發團隊并行開發：
客戶端發展到需要多個開發團隊進行協作配合時，項目管理的方式需要有一些調整，在此提供一個思路：
其中一個（或獨立）團隊負責版本的合并和發版工作。定一個灰度時間點，根據灰度時間點倒推出封版時間點（間隔時間應情況而異，這段時間QA同學整體回歸所有的需求，驗收通過后方可進行灰度），從開啟合并到封版的這段時間中各需求方將需求（提前將規范交由需求方，可以是準入文檔等一類的東西，整個開發過程可以適當進行檢查，確保他們是沒跑偏的）合并入主干，過時不候。
客戶端管理雖然是一件繁瑣的事情，但是相比較產品工作而言不確定性更少?；緦儆谡莆湛茖W方法、經過一定的時間運行并優化后即可掌握的技能，有很多的細節只可意會不可言傳，所以在文章中不贅述。大家可以按照這個思路去衍變出適合自己情況的管理方案。
本文由 @蕭尼瑪 原創授權人人都是產品經理發布 ，未經作者許可，禁止轉載。
挺實用的管理規范，有很大幫助！