一個互聯網項目從產品設計到上線的過程是怎麼樣的?

01-20

從產品設計到開發，到測試，到上線的流程是什麼樣的？都有哪些可參考的最佳實踐。

端和web產品一般流程比較完整：1.規劃：每個產品每半年都會有半年規劃和對應目標（這個目標可能是受益也可能是用戶口碑，微信就一直站在用戶角度思考和規劃，而不是為了kpi完成功能），目標明確後會劃分迭代周期，以及每個迭代所做的內容

2.宣講：產品經理驅動的團隊，每個迭代，產品會設計好需求策劃拉老闆拍版，拍版完成PM會拉團隊成員召開迭代啟動會議，說明本次迭代工作和關鍵時間點，並將需求按照優先順序排列；迭代會議後通過的需求會落地到需求文檔，由視覺交互介入設計，完成後拉團隊成員召開需求宣講會議

3.排期：宣講完成後pm會收集團隊成員的工作排期，開發工作量和測試工作量，根據迭代版本關鍵時間點增加或減少低優先順序需求，確定下來明確工作和關鍵時間點：開發聯調時間、提體驗時間、設計走查時間、提交測試時間、系統測試時間、上線時間

4.開發：開發按照需求落地技術實現、約定協議、聯調，其中每天pm早上召開晨會確定進度是否符合預期，是否有風險有需要調動的資源，根據進度確定是否加班，開發完成進行聯調和自測，完成後提交產品體驗和視覺走查，通過後提測；一般新功能是在分支開發，測試穩定後合入主幹進行集成測試和系統測試，其中包括一些兼容性測試、穩定性測試、專項測試、壓測，涉及前後端流程長的還有全流程驗證；測試完成後根據bug情況和風險確定是否可以上線

5.上線運營：如果功能較大質量存在風險一般涉及到功能灰度，功能灰度方式有多種：內部試用、外部用戶報名試用、白名單配置、按地域灰度，灰度階段收集質量數據修改；一般一個功能兩種展示也會選擇灰度來確定用戶偏好和功能效果；灰度完成後全量上線，運營同學收集線上運營問題反饋，一段時間後產品收集功能用戶使用上報數據

6.迭代總結：總結本次迭代做的好的和待提高的，以及產品show用戶數據，如果有重大運營事故還需要回溯

此外，對於另一些產品：api、sdk、後台等流程沒有這麼複雜，少了體驗等環節更偏重於穩定性。

樓上的暗滅同學寫的很全。

在我看來有如下階段：

定需求
出 PRD
開個會，定排期
各干各的，到時間，發測試
測試 bugfix
發生產

定需求

就是定，怎麼定都是定，有人說要 2-3 周，哪那麼多時間。

2 天，不能再多了。

出 PRD

一套原型 + 一些邏輯說明，不僅要有圖，圖只要能表達，這裡有什麼東西就行了，剩下的交給設計師就可以。邏輯要清楚，足夠清楚，比如這裡排序是啥，點了出來啥，數據哪裡來。

2 天夠多了。

開個會，定排期

把前後端、設計師都叫上，如果不想在需求溝通會上改需求，就不要叫上老闆。會上給大家講，這裡是啥功能，這裡是啥，這裡又是啥。

1 小時，最多 1.5 小時。一般我喜歡上午開個會，10:00 - 10:30 最佳，然後回來大家在中午吃飯之前把排期時間告訴我。

排期有個坑，千萬別說幾天，就告訴我「幾月幾號幾點交付」，交付標準是什麼，就行了。

各干各的，到時間，發測試

後端出他的 api，前端寫他的界面和邏輯，設計師設計他的圖。作為 PM 我從來不會要求設計師說，這裡不好那裡不好改這裡改那裡。我只看設計師的的界面，是不是跟我 PRD 里要求的功能部分一致，其他的應該信任設計師。

如果你聽到開發跟你講：沒圖我開發不了，先讓設計師把圖出了吧。

建議你告老闆辭退他，原型不是圖嗎？

時間有長短，盡量控制在 2 周內（10 個工作日）一個版本

測試 bugfix

不管怎麼說，一般我只用 2-3 天。測試的覆蓋率和完整度不高，但覺得大邏輯沒錯，先發一版再說，界面還原啊之類的問題，都先放放，可以先發一版再修完再發一版。

大概就是這樣。

前言：

這是IT修真院自問自答系列第十篇，同樣是乾貨和硬廣混雜。IT修真院系列 - 收藏夾，順手推薦一下修真院的專欄，各種IT行業的真實小故事。IT修真院 - 知乎專欄

正文
以敏捷開發為例，基本上會分成以下幾個階段。

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圖了。

評審結束，我們進入需求講解階段。

北京葡萄藤.IT修真院首頁 | IT修真院

===============================

免費，快速，高效的幫助IT新人入門，做一個「正直，善良，純潔」的程序員。

加QQ群：

1群2000人 185354188（已滿）

2群 1000人 424031650 (已滿)

3群 500人 493806441（已滿）

4群 500人 580626624 （已滿）

5群 500人 604****59 （已滿）

6群 200人 254078081（招募中）

微信公眾號：葡萄藤IT技能樹

IT修真院系列 ： IT修真院系列 - 收藏夾純乾貨+硬廣

專欄：IT修真院 - 知乎專欄各種IT行業的真實小故事

接需求，修改，修改，修改，上線。

進一個公司參與下