原文地址https://www.zhihu.com/question/52525581/answer/130905959 來源：知乎
2.宣講：產品經理驅動的團隊，每個迭代，產品會設計好需求策划拉老板拍版，拍版完成PM會拉團隊成員召開迭代啟動會議，說明本次迭代工作和關鍵時間點，並將需求按照優先級排列；迭代會議后通過的需求會落地到需求文檔，由視覺交互介入設計，完成后拉團隊成員召開需求宣講會議
3.排期：宣講完成后pm會收集團隊成員的工作排期，開發工作量和測試工作量，根據迭代版本關鍵時間點增加或減少低優先級需求，確定下來明確工作和關鍵時間點：開發聯調時間、提體驗時間、設計走查時間、提交測試時間、系統測試時間、上線時間
4.開發：開發按照需求落地技術實現、約定協議、聯調，其中每天pm早上召開晨會確定進度是否符合預期，是否有風險有需要調動的資源，根據進度確定是否加班， 開發完成進行聯調和自測，完成后提交產品體驗和視覺走查，通過后 提測；一般新功能是在分支開發，測試穩定后合入主干進行 集成測試和系統測試，其中包括一些兼容性測試、穩定性測試、專項測試、壓測，涉及前后端流程長的還有全流程驗證； 測試完成后根據bug情況和風險確定是否可以上線
5.上線運營：如果功能較大質量存在風險一般涉及到功能灰度， 功能灰度方式有多種：內部試用、外部用戶報名試用、白名單配置、按地域灰度，灰度階段收集質量數據修改；一般一個功能兩種展示也會選擇灰度來確定用戶偏好和功能效果；灰度完成后全量上線， 運營同學收集線上運營問題反饋，一段時間后產品收集功能用戶使用上報數據
6 .迭代總結： 總結本次迭代做的好的和待提高的，以及產品show用戶數據，如果有重大運營事故還需要回溯
此外，對於另一些產品：api、sdk、后台等流程沒有這么復雜，少了體驗等環節更偏重於穩定性。
- 定需求
- 出 PRD
- 開個會，定排期
- 各干各的，到時間，發測試
- 測試 & bugfix
- 發生產
鏈接：https://www.zhihu.com/question/52525581/answer/130893378
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
正文 以敏捷開發為例，基本上會分成以下幾個階段。
1.設計需求 2.需求評審 3.需求講解 4.接口評審 5.方案評審 6.每日晨會 7.CodeReview 8.性能測試 9.Demo 10.打Tag&測試環境發布 11.Bug修復 12.線上環境發布
第一階段 設計需求 參與人員：PM 1人 預計時間：2~3周 產出物：PPT，Story，原型圖
一般而言，一個PM就夠了。天下PM一大抄，需求的來源往往源自以下幾種： 1. 1%來自用戶的反饋 2. 5%來自運營部門的要求 3. 1%是PM抽瘋了自己想做 4. 93%來自老板的要求
來自用戶的反饋往往是來自各種吐槽和抱怨，什么這個看不懂了，那個不明白了，為什么沒有這個功能了，為什么沒有那個功能了。會哭的孩子有奶吃，多多少少會影響PM的決策。
順便說PM分成兩種。一種是PM，一種是畫原型的。
來自運營部門的要求多數跟推廣宣傳或者是內容管理有關系，最常見也最Low的往往就是抽獎，積分，活動，兌換，推薦。能做出一個小游戲一樣，或者是一個真正的活動的很少很少。
PM自己抽瘋的時候很少，往往是對這個行業，這個功能，這個需求有很直觀的感受，這個東西做不出來他就會死。
最后一個，老板的要求往往是最常見的，也是最煩的。老板往往是壓根就不懂技術的，但是往往會比較懂行業，或者是經常虛心的聽從行業專家的建議。
本篇吐槽功能自動衰減，所以減少這方面的篇幅。主要講PM拿到需求之后要做什么。 PM拿到需求之后，第一步就是要去抄別的網站或者是App。呸呸呸，是參考，或者是競品調研。
總之就是要擴展視野，去看看別人怎么設計的。看了一圈，各種亂七八糟的東西觀摩一圈，大概就知道要怎么做了。
PM本身應該具備的能力就是在半小時之內了解一個不熟悉的行業的需求，大致知道他們要做成什么樣。
這個時候，強烈反對直接畫原型-如果你想成為一個真正的PM，畫腦圖也好，做PPT也好，拆解Story也好，一定是先去做這些事情，不要把自己局限在一個畫原型的怪圈里-我說過，PM分成兩種，一種是PM，一種是畫原型的。
拆解Story真心是一個好的梳理需求的辦法，它能幫助你理清楚優先級，每一個Story的意義和價值。怎么拆解是另一個話題。
拆解Story之前，最好是做PPT，把你的產品設計思路表達清楚，把你看過的別人的PM描述出來，講清楚背景，講清楚自己為什么要這么做，講清楚自己做的東西背后的邏輯。
PPT，Story做好之后，再去做原型。原型的意義在於展現出來Story的價值。 另外，做原型的時候，不要犯以下三個錯誤：
第一，把所有的交互都畫在原型上，做各種點擊跳轉。 這樣開發人員根本不知道原型上哪些能點，哪些不能點。就算是Axure支持了顯示熱點，也很煩，特別是層次比較深的。
所以，請遵循一個最簡單的規則。原型下面分模塊，模塊就是文件夾，文件平下面是各個獨立的頁面。
不要在文件下面掛文件，看着很煩。
第二。一個文件里面畫很多張頁面，各種拖拖拽拽的煩死個人了。
不知道從哪里開始，畫原型有這種風格了，一個大的頁面里放一堆頁面。很多少時候都是覺得這樣看起來，用箭頭標注起來更方面看跳轉，有點理解不能。如果要看各種轉跳轉，直接畫一個頁面跳轉圖就好了，折騰原型圖干嘛。
同樣的道理，還是導致各種分不清有多少東西，而且畫布太大拖拽好煩的。
第三。如果有分期的需求，在做第四期需求的時候，請不要把之前三期的需求全部混在一起。
馬丹完全分不清倒底哪個是新需求，哪些是已實現的。單獨的把四期的需求列出來就好了。
為什么時間是2~3周呢？這跟兩個因素有關， 一個是跟PM的設計周期有關系，一個是開發周期有關系。如果你有兩個8人團隊，能保證都按照這個正確的節奏走，那么一周發布一次版本輕輕松松，而且，完全不是各種趕需求。
不對以上言論負任何責任，純屬自己扯淡。
好的需求設計完成，我們進入需求評審階段。
第二階段 需求評審 參與人員：AppLeader PMLeader，后端Leader，QALeader，前端Leader UILeader 6人 預計時間：2H 產出物：需求評審結論，預計完成時間，開發團隊成員，需求講解時間
需求評審要注意的就是，一定是要評審完整的需求，一定要評審細節。 如果拿出來評審的需求並不是一個真正的，馬上就能開始做的需求，這個叫做頭腦風暴或者是內部評審，都成，叫之不是一個需求評審。
挨個去思考每一個需求的含義，每一個Story的價值。 如果說大家對某一個功能有意見，把意見反饋給PM，讓PM最終做決定，這是對PM這個職位的尊重。
如果大家提到的一些疑問，如果PM能想到了，這是PM考慮周全，這次評審完美。 如果大家提到的這些疑問，PM完全沒想到，這就是PM考慮不周，需要再加強內評。
需求評審要關注三個點， 第一個，哪些功能有難度。 第二個，哪些功能價值低，又耗費時間長。 第三個，能否在一個迭代周期（2~3周）內完成。
怎么拆需求，如果不確定的需求怎么做，這是另一個話題。
參與的各開發組Leader，接着要做的事情就是安排好開發人員。 這也是對Leader的要求，提前預估好人手。
此外，就是要確定需求講解的時間。 QA組也可以開始着手准備測試用例，UI組可以去畫UI圖了。
評審結束，我們進入需求講解階段。