原文地址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圖了。
評審結束，我們進入需求講解階段。