事前藥

本文閱讀時長約10-30分鐘，建議先瀏覽下總綱，很多細節不一定是通用的，主要還是想引導大家為什麼這麼做，而不是套模板，靈活比什麼都重要，這個是初衷；

內容是全體測試同學及老大共同參與整 理，並得到了公司各職能的認可，目前已經在對某些團隊宣講及試點，並會不停優化整個流程，期望能形成一個好的團隊合作模式；

從內容而言，算是一個大而全的輸出，建議不同同學靈活運用，根據不同團隊制定合適的流程和規範；

前言

隨著網際網路的飛速發展，企業為了爭奪市場而快速迭代，隨之而來的，就是敏捷、免測、自動化等一系列規範化的誕生，為的就是確保專案在高速迭代時依然能保持好的質量及團隊配合；

而測試是處於整個迭代的最下游，一旦上游出現delay，專案在不延期的情況下，就會壓縮測試時間，從而產生上午寫bug，下午釋出的情況，而這情況越來越普遍；

在這種環境下，測試人員壓力很大，甚至喘不過氣，而且bug釋出後，一旦有線上問題，就歸根到測試沒有發現問題等，導致人員心裡越來越疲憊，說句話說，員工感覺不到幸福感；

而這種情況，往往在小公司裡會更明顯，因為流程不清晰，各種不規範，產品亂插需求等等，很不巧，jb也遇到，正如上面說的，亂排優先順序、delay家常便飯，老闆一看，什麼，又要delay？怎麼搞的啊！ 不用測試啦，快速迭代，然後出問題又怪到 測試這，怎麼那麼多問題等；

正如彈簧一般，被壓久了，就失去彈力，習慣了是個很可怕詞語，一旦習慣了，就麻木了，人就漸漸失去激情了；

為了改變這種現狀，測試團隊及老大（技術負責人）也想改變這種情況，因此就有了下文的內容，主要是制定一系列的專案流程規範，跟各職能達成共識，嚴格循序；

做什麼？

既然老大都支援做這個事，那就思考下要做什麼吧？

常見的專案流程應該是這樣的：

• 需求文件；
• 評審；
• 工作量評估；
• 制定專案計劃，立項；
• 開發；
• 提測；
• 測試；
• 延期&
  需求變更；
• 驗收；
• 上線；
• 結項；
• 線上問題跟進；

好像，大概，流程就是這樣啦，沒啥毛病；

但是，夠了嗎？可是要站在專案的角度想這個事情呢；

經過一輪腦暴，發現是還有很多細節，如：

• 職責；
• 開會效率；
• 郵件；
• 請假；
• 團隊意識；
• 辦公室命名；

還有嗎？肯定還有的，只是沒想到而已，但畢竟不是專業的專案經理，那先把想到的搞定先吧；

按照上面說的，會分幾塊：

專案迭代流程、職責分工（針對專案跟產品）、團隊意識、開會、郵件、請假、 通訊工具（如某釘、某信）；

總綱

專案迭代流程

1.產品經理建立confluence版本目錄;

新專案就先建新空間;

所有文件按照文件組織規範來存放；
2.產品經理收集各方（運營、客服等）需求後撰寫需求總表，包含需求概述（一到兩句話）和優先順序;

3.需求文件：按照需求總表的順序出，每個需求的細緻程度和優先順序一致;

寫需求期間設計師同步做設計初稿;

4.負責人評審：由研發、測試的主管評審可行性和資源可用性（人力、伺服器等）;

簡單的需求不一定需要開會;

5.設計師初稿：有客戶端或前端參與的需求，初稿要在全體評審前要做出來。
期間設計師有機會先提出產品文件缺陷;

6.全體評審：所有實際參與專案的同學參加。儘可能提前發現缺陷;

7.工作量評估：各職能給出時間長度和依賴關係，彙總給專案經理排期;

8.排期，立項：專案經理髮出郵件，包含所有的資訊;

設計師標註切圖;

9.開發設計評審（一般小於10個工作日的需求不需要，具體由研發主管判斷）;

10.測試用例評審（一般小於10個工作日的需求不需要，具體由測試主管判斷）;

11.開發，提測;

12.測試：先準備好冒煙測試案例給開發。每輪測試撰寫測試報告;

所有人都可以去報bug;

13.延期和需求變更;

14.加班;

15.驗收、上線：釋出後運營和測試再做一輪冒煙測試或持續監控，達到放量的標準才叫完成上線;

16.結項：資料分析、覆盤，專案經理彙總後發郵件;

17.線上故障;

專項版本流程

專項版本的特點是獨立版本專案，不跟隨版本迭代的需求；在專案空間的根目錄建一個資料夾存放專案相關的內容；確定搭車哪個版本上線後，可以把所有文件轉移到那個版本的目錄下；

具體流程規範儘量和版本迭代流程保持一致。

職責分工

產品經理對結果負責，專案經理對資訊傳遞負責，各職能主管對流程負責。

專案經理的核心作用是資訊樞紐，主要職責：

• 制定和優化專案流程規範；
• 收集工作量評估，排期，確認里程碑時間，如有必要可召開立項會議，最終發出立項郵件；
• 結項會議主持；
• 解決團隊資源衝突，確定專案的優先順序，協調人力資源；
• 發現團隊合作中可以提升工作效率的地方，並推動解決。例如建設產品的axure預覽空間；
• 發週報郵件；
• 對團隊的問題做監督、總結、給解決方案；

產品經理：

• 確保需求通過評審，得到各方確認，並宣佈立項；
• 收集來自運營、商務、客服的需求，做成需求文件安排到版本迭代中；
• 接收客服的反饋，bug就轉交給測試跟進，產品建議則統一回復，如果需要處理及插入到各版本迭代計劃裡；
• 版本釋出的最終決定人，即時有問題，只有產品同意，都可以釋出；

團隊意識

1.目標導向，不是為了任務而做任務；
2.所有規則都不是死的，哪些要哪些不要，要具體地判斷，按時高質量完成是最基本的目標；
3.所有事務都有優先順序順序，如果不清楚的話就詢問上司，直至boss；
4.及時反饋，並通知到應該知悉的人；
5.團隊互助：別人做得60分，如果你抱怨著等別人完善，你也是60分；
6.專案安排一旦定下來就是個承諾，能否兌現是職業素養的體現；

開會

1.主持人要做好時間控制，儘量一小時內討論完；
2.開會要說明會議目標和議程；
3.按需寫紀要：討論內容與結論，需要跟進的問題和責任人；
4.按時參會，有事不能來或遲到應該告知主持人請假；
5.在提前2小時有通知並說明了遲到要發紅包的前提下，會議主持人可以要求遲到未請假者發紅包，總額按參會人人均X元；

郵件

1.什麼時候要發：需要跟進和後續查閱的事項；
2.推薦使用foxmail為客戶端，也可直接使用釘釘；
3.郵件標題，簡明扼要，如果緊急，寫上【緊急】、【專案週報】、【測試周報】，以此類推；
4.稱呼：寫清楚是對誰說的，對全體就是“Dear All”；
5.要有簽名欄，至少有自己的名字；
6.抄送：自己的上司、涉及人員的上司（至部門一級）；

釘釘

1.每個專案組建一個群，拉上所有實際參與的人和各級主管；
2.專案事情不允許建立小群來討論，只要是說正事就不要怕打擾人。
只有討論非工作事宜的才能建，例如下午茶群。

請假

務必保證上司知悉。
如果自己身上有重要任務，必須讓專案組也知悉。

晨會

在專案迭代較快的時候，都要求進行晨會，目的是快速同步資訊，瞭解進度，如果有遇到問題，也及時提出，讓對應負責人推動，避免一切延期的風險；

在晨會反饋時，需要技巧，不能這樣：XX功能進度正常，按照原計劃執行；

應該是需要反饋做了什麼事情，這個事情的進度，大概什麼時候完成，這個事情不是一個專案，而是拆分出最小的一個功能，比如：

昨天做升級功能，介面及介面聯調已經完成，進度60%，今天會進行防劫持功能開發及自測,今天內開發完畢；複製程式碼

小結

看到這裡，是不是覺得很繁瑣？這種雞毛蒜皮的事都要管？
沒錯，看上去越是雞毛蒜皮的事，往往卻是最重要的，網際網路時代，什麼都要高效、注重使用者體驗，這些事情都不例外；

那接下來，就針對專案迭代流程裡的每個小點進行說明吧；

文件組織規範

總則

所有文件以Confluence（下文簡稱cf）為中心做管理，cf不方便存放的東西才放到svn。

專案組的釘釘公告欄只放置版本頁的cf連結和當前版本的提測記錄。

CF規範

每個專案由產品經理或專案經理建一個空間。

目錄規範如下：

• 主頁
• • 通用文件，包括第三方文件、全域性術語表、全域性資訊（測試伺服器地址、svn地址）等，跟具體版本無關聯;
• • 專項文件，跨版本的需求統籌、跟版本無關聯的運營活動需求;
• • x.x.x（版本號，按具體版本劃分）
• • • 需求總表；
• • • 立項。可以不獨立成文件，只存在於郵件或釘釘公告欄裡即可，或在需求總表文件上回復；
• • • 各個需求文件，以需求名稱命名文件名。如果用axure，在這裡填寫svn地址，還可以包括預覽空間的url地址；
• • • 測試文件，以作用命名文件名，主要是用例，可放svn。測試報告只存在於郵件中，如果不嫌煩可以在需求總表的文件那裡做回覆；
• • • 結項。這個必須要，不能只在郵件裡；
• • 垃圾桶（廢棄的需求、不再使用的第三方文件等移動到這裡）

SVN規範

目錄規範如下：

• 根目錄

• • 小程式(按產品形態或者具體業務來分，任君選擇)
• • • A專案
• • • • 設計文件
• • • • 介面文件
• • • • 測試工具
• • • • x.x.x（版本號）
• • • • • 需求文件（axure原始檔和匯出的html資料夾、各個需求的word，以需求名字命名）；
• • • • • 設計文件
• • • • • • ps原始檔，設計稿、標註、切圖
• • • • • 測試文件
• • • • • • xmind、excel用例整理
• • • B專案…

需求總表

表格格式

需求名稱	優先順序	產品	UI	前端	後端	測試	運維
A需求	核心	JXX、BXX	JAX	BAX	JBAX	JXX	BXX
B需求	高	AXX、CXX	EAX	DAX	FAX	EXX	IXX
A需求	核心	JXX、BXX		BAX	JBAX	免測	BXX

列填寫

• “需求名稱”和“優先順序”由產品填寫。
• 需求名稱：只能是1句話。如果這都做不到，這個需求肯定不清晰;
• 以優先順序排序。優先順序說明：核心：必做，先做，不能砍，不做完就不釋出新版本。可單獨形成一輪提測。高：必做。條件不允許的話可以降低為中優先順序。可單獨形成一輪提測。如果存在多個高優先順序，則產品繼續細分；中：如果時間允許，會做；低：可以不做；優先順序還可以用分數來表達，如核心100，高是99-90，從而充分體現各高優先順序裡更高優先順序的需求；
• 各職能人員名單，由對應主管決定，誰填寫都可以。如果人不多，直接寫在表格外更好；

執行說明

• 產品應該先寫總表再寫需求文件，需求文件的完善程度與總表的優先順序是一致的，優先順序低的需求還可以在核心需求開發過程中再完善;
  
• 怎樣算是一個需求？（成為表格裡的一行）
• • 跟其它需求無關聯；
• • 可以和其它需求並行開發的，多人合作不會產生交叉；
• • 優先順序相同且屬同一個模組，允許合併；
• • 重要的bug可以作為需求列上來；
• • 運維的工作獨立算成需求；
• 整個專案組都按優先順序做。核心和高優先順序的可以做完一個提測一個；

需求文件

前置說明

文件的標題是1句話，跟需求總表裡的一致。

• 需求描述的基本要求：條理清晰，邏輯嚴謹，用詞專業，格式規範，易於閱讀，重點詞句標紅；
• 全體評審時，需求文件上應該是設計稿，而不是原型圖，避免實際開發/測試時大量出現設計稿跟原型圖不相符的情況；
• 如果是基於舊需求的補充完善，把舊需求複製到新版本，加上修訂記錄並標記修改的部分。

寫作思路和本模板的設計原理

請參考 www.woshipm.com/pmd/1579154…
本文是公司大佬在人人都是產品經理發表的文章，也得到的產品經理的認可；

實際的示例，可以參考 www.woshipm.com/evaluating/…
但請注意要靈活運用，本文是來自於人人都是產品經理的文章，算是比較全面的文章；

修訂歷史

版本	日期	修訂人	修訂內容
V1.0	18.9.27	jb	初版
V1.2	18.9.29	jb	需求評審，修改XX功能
V1.3	18.10.28	jb	需求變更，原因是原來功能無法實現
V1.4	18.11.01	jb	1.增加XX功能，2.修改XX文案

目標

包括但不限於以下內容：

• 解決什麼問題、痛點；
• 此需求本身達到多少使用率、轉化率；
• 此需求能提升多少PV、UV、交易額等。（需要脫敏寫百分比，不需要就寫絕對值）；

主要是防止無腦、拍腦袋需求，凡事要用資料推動，有理有據，讓團隊都知道做這個事的目的，同時也避免浪費資源卻沒有好的結果；

術語表

術語	說明
自動還款	…

哪些東西需要在術語表裡列出？

• 沒有標題的頁面、區域，內部怎麼統一叫法；
• 新功能的名稱；
• 特殊的叫法、代號；
• 一些流程的簡稱；

之前在負責seo專案的時候就出現過，同一個功能，產品、前端、測試、UI各有各叫法，導致溝通造成成本；

參考資料

（這裡放關聯需求和第三方文件資料，沒有就不需要這部分）

產品結構圖

暫定新專案一定需要此章節，原因是梳理產品結構圖需要時間，在產品迭代如此快速的情況下，功能可能每個版本都在變化，考慮到人力成本，讓產品每個版本去維護也不可能，因為先要求新專案一定需要，迭代中的專案，酌情處理，能有是最好的；

原型和說明

• 如果用axure做，不要把axure的截圖貼過來，這裡直接放匯出網頁的svn路徑，還可放上http空間的連結，方便大家線上閱讀，免得到處找文件，其它工具畫的圖才截圖;
• 如果整個需求能用簡單圖文說清楚的，就不要用Axure，直接用cf簡短寫;
• 不強制要畫流程圖、狀態表，只要能表達清楚完整，什麼形式都可以；
• 前端和客戶端混合的需求，應標記一下是哪個端的實現；

非功能性需求

• 效能
• 統計
• 安全
• 相容性：系統(iOS8，Android4.4)、解析度&
  尺寸(4.7寸、長寬比>
  19：7的螢幕)、瀏覽器（Chrome、ie、火狐）

需求評審和工作量評估

兩輪評審

流程：

• 預審：產品提前2小時發出通知和初稿（不需要完善細節，可以只是原型），召集主管或負責人預審;
  未必需要開會，只要每個人能確認需求沒大問題就好;
• 全體評審：產品提前1天發出通知和需求連結（設計師已出完初步設計圖），全體人員參加；應該在會前審完大部分問題，而不是會後；會上只是查漏補缺；
• 跟運營有關的需求，應該在全體評審前由運營先稽核完畢；
• 產品經理根據問題修改完畢後，逐個找負責人確認。
• 都通過後，發出通知通知；
• 專案經理收集工作量評估進行排期，並在各方確認後發出立項郵件；

要求：

• 全體評審不能在上個版本未上線的時候進行，要給參會人足夠的時間精力做好評審；
• 如果問題太多，應該再舉行一次需求評審；

預審

核心作用就是向開發打招呼，知道要做什麼，好安排人力資源。所以產品文件不需要很完善，但一定要交代清楚目標和核心的功能點。

召集開發測試的主管或負責人簡單過一遍即可，主要是評審可行性。

不需要預審（免測）的條件：

• 開發工作量小於5個工作日；
• 改UI為主，沒有難度；

評審要評些什麼？

所有人都要評的：

• 目標是否清晰；針對目標，需求的設計是否合理；
• 針對需求：不完善的地方、影響範圍、使用者體驗；儘量在寫程式碼前發現需求問題；
• 具體工作量；
• 時間安排：限時上線的就砍需求，不限時就由大家來決定釋出時間；
• 風險點：所有導致評估不準和專案延期的可能性；

特別注意地：

• 技術要評估可行性，影響開發時長的難點，是否需要預研；
• 測試要評估測試資源的充足性（例如測試裝置）、自動化測試可行性；
• 運維要評估伺服器資源的充足性；

工作量評估

按照每個需求來評，各個職能都評。

以0.5人天為最小單位。

一個關於戰鬥力的評估法：

列出參與這個專案的所有人員。為了便於描述，我們把其中能力最強或工作效率最高的人稱為A。A一天（除去加班、小憩時間）能完成的工作量定義為1人天，同時把A的戰鬥力定為1.0。這個需求按照A的標準要幾天才能完成，則它的工作量可量化為多少人天。再對其他人員逐一跟A比較做評估，如果B一天能完成的工作量是A的70%，則把B的戰鬥力定為0.7。假如還有C的戰鬥力0.5，則這個團隊的總戰鬥力為1.0+0.7+0.5=2.2。如果某個需求的工作量是11人天，則最理想的情況下，這個團隊需要用11÷2.2=5天來完成。團隊的人越多，花在溝通上的時間也會增多。再加上可能有評估不準、部門會議、臨時請假的情況，在估算整體所需時間時，應乘以一個係數，例如1.2，來作為最終時間。即上例中，應為5×1.2=6天。類似地，如果要996，則可乘以一個小於1的係數，可以是0.85。在實際情況下，並非所有團隊成員都全天參與此專案，同時參加多個專案的情況很常見。如果A對本專案只投入一半的時間，則團隊的總戰鬥力應算成1.0×0.5+0.7+0.5=1.7。複製程式碼

設計師流程規範

前置說明

• 這裡只關注影響合作的規範，跟“好不好看”有關的標準是設計師內部的專業規範，這裡不涉及。
• 程式設計師期望的設計師能力，可參考https://www.zcool.com.cn/article/ZODIyODM2.html

設計圖規範

預審的目標是讓負責人評估可行性，設計稿著重表達出樣式的位置、形狀和互動即可，是原型還是設計稿都沒關係。

全體評審的目標是讓開發準確評估工作量。對工作量影響極小的東西可以不是終稿，例如顏色值、字型大小、間距。

終稿可在各需求實際寫程式碼前確定，允許在驗收階段再進行不需要測試迴歸的微調，當面除錯的需要記得到同步回設計稿。

切圖規範

• 設計師自身維護所有的圖片，每次都是給開發所有的切圖（包括新增和剔除廢棄），且同一張圖或有小改動但放在原位的圖檔名不變，自身知道哪些圖片在這個版本不需要了；
• 所有源件不是拆分版本上傳svn，每個版本下都是儲存當前用到的所有東西；
• 切圖檔案按規範命名，全小寫英文，下劃線連線；
• 寬高應是偶數；

對某些元件是否在切圖中應用透明邊距和對應做標註，應統一風格。

標註規範

• 最好能有全域性規範；
• web專案字號不能低於12px，app專案不能低於10px；
• 所有大小均為偶數；
• 標註不好說明的，應使用文字說明；

命名規範

UI檔案的命名規範，可參考下方：

排期和立項

術語解釋

• 里程碑（時間）：重要的時間節點，例如提測、釋出，來自英文milestone。風險點：任何可能造成專案延期的事項立項：經過核心和高優先順序的全體需求評審後，由專案經理收集各職能的工作量、風險、所需資源評估，協商得出里程碑時間，發出郵件。
• 每輪提測叫t1、t2、t3，t = test；
• 每輪提測內提交的修改，叫patch；
• 合起來看：第2輪提測打的第3個tag，叫t2p3；
• 全功能提測：所有在本版本要上線的需求都做完了，也可以讓UI提前驗收；

關於提測，很多大型公司叫rc1，全稱是Release Candidate的縮寫，意思是釋出倒數計時，這個階段大多數用於整合測試後的版本；

一般的不同流程的命名如下：

beta、rc、trial、release、patch、hotfix複製程式碼

專案排期

排期目標：

• 每個需求的職能依賴關係以及時間表，比如前端依賴ui和後端，被依賴者什麼時候做完；
• 分幾輪提測，每輪的時間點，提測內容，“核心”和“高”優先順序的需求，都可形成一輪提測；
• 釋出時間；
• 風險點；

里程碑時間安排示例：

• t1：11.2，需求A、B。UI在11.1前給出，後端介面在11.1前準備完畢；
• t2（全功能）：11.5；
• t3：11.7；
• 釋出：11.8；

可能的風險點：

• 參與人員業務不熟；
• 長假的前後，工作效率低；
• 人員請假；
• 第三方服務或政策因素；

版本管理

版本號格式：x.x.x，說明：

• 有新需求，第2位+1，第3位置0
• 大改版，第1位+1，第2、第3位置0
• 小bug改動，第3位+1

立項郵件

收件人：專案組釘釘群

標題：【立項通知】xxx（專案）y.y.y（版本），例如 【立項通知】XXXX產品3.2.4

正文：

Dear All，本期專案共有5個核心和高優先順序需求，3箇中低優先順序需求。有12個人參與實際工作。具體請看需求總表【url】；專案週期：10月4日-10月18日，共10個工作日裡程碑：1. t1：10月12日（週三）。提測需求A、B。UI在10.10前給出，後端介面在10.11前準備完畢2. t2：10月13日（週四）3. t3（全功能）：10月18日（週二）4. 釋出：10月20日（週四）風險點：1.新同學加入實現需求A，業務不熟，可能會延長解bug時間2.需求B需要技術預研，預留時間未必準確。請 @xxx 隨時彙報進度第三方合作商xxx在月中要進行資料遷移，影響我們對接複製程式碼

如何做版本規劃

需求池，關聯度梳理，拆解，優先順序評估，迭代週期，專項；

版本規劃的目的

在現代社會市場和需求變化快的情況下，產品經理制定迭代週期短的產品規劃，可根據市場的反饋，及時調整產品下一個迭代的需求功能和產品形態以滿足公司的戰略和業務需求；

需求池

產品經理在做產品設計之前，都會建立一個需求池，用來收集各種需求，防止有遺漏的需求和方便對需求的梳理；由產品經理管理維護，專案相關人員補充內容；無論需求是否可行，專案相關人員都可以將需求填進需求池中，且無數量的限制；需求梳理時，產品經理可從需求池中分析和篩選；製作需求池的方式有兩種：文件表格和OA系統。表格內可含以下內容：

• 需求名稱（必選）：
• 需求描述（必選），詳細描述需求功能，有以下分類：
• • 使用者需求：使用者想要的功能；
• • 業務需求：賺錢的功能；
• 需求型別（可選），包含以下分類：新增功能、功能優化、Bug修復、體驗優化；
• 來源（可選），包含以下分類：戰略規劃、競品分析、使用者需求、運營市場反饋；

需求梳理

產品經理收集完成產品需求之後，對需求池中的需求進行分析，梳理出需求功能結構圖，為產品迭代提供方向；需求分析時，可執行以下操作：

• 需求合併：合併同型別需求。
• 需求刪除：篩掉不合理、不符合產品定位的需求。
• 需求關聯：梳理需求之間的依賴關係，
• 需求拆解：將需求拆解成一個個可實現的功能，形成需求功能結構圖，可用腦圖表示；

需求優先順序評估

需求優先順序的評估就是在有限的資源（時間、人力、硬體），產品經理安排優先做的需求功能，以達到產品的階段性目標，符合公司的價值；

可按以下優先順序排序：

• 公司戰略： 公司戰略指定的核心功能/業務需求，能為公司帶來直接收益；
• 利於日活/拉新： 能夠有效的提成使用者活躍度和使用者量；
• 功能優化、Bug修復、體驗優化： 這類主要就是使用者體驗類，提升產品的使用滿意度；
• 提升運營、運維效率：減少成本；

迭代週期規劃

迭代週期就是要一個迭代從開始時間到結束時間的時間窗，完成設計、開發、測試、上線等活動；

固定的迭代週期就是固定的時間窗，有以下好處：

• 建立團隊的節奏感：有預期的節奏，容易讓團隊形成習慣，團隊生產效率更規律；
• 降低協同成本：能夠並行的去安排多個迭代的規劃，評審等活動。每個人都知道這些活動什麼時候進行，減低溝通和協同成本；
• 簡化規劃活動：固定的迭代週期，固定的人力，固定的產出交付，有利於產品規劃的合理性；

短週期：10個工作日（兩週）以內的時間窗；長週期：10-20個工作日（一個月）的時間窗；

根據需求優先順序，團隊的實際情況，選擇合適迭代週期，一般需要考慮以下因素：

• 專案週期：短週期迭代，快速取得反饋意見並改進；
• 需求數量：需求越少，採用短週期；
• 不確定的因素：專案組的工作效率、技術門檻等；不確定性越多，就應該採用短週期迭代；
• 需求優先順序變化：頻繁更改優先順序，採用長週期迭代；
• 迭代系統開銷：每次迴歸時間成本很高，採用長週期迭代；

專項

專項是在專案預審或需求評審時，涉及範圍（多部門合作、程式碼重構、功能優化）大，時間窗超過長週期的，需要專門設立的專案；

專項是所有專案集中優先順序最高，安排專人負責專案，集中當前的人力資源優先解決問題；

專項的特點：

• UI/UX 大幅度修改，耗時10工作日以上；
• 系統程式碼重構；
• 時間窗超過20個工作日；

如何做好專項：

• 適當調整其他專案的優先順序，由組長介入分配參與此專案的人力；
• 專項組員當前只負責當前專項工作，確保專案不被其他專案干擾，按期完成；
• 專案負責人定期去推進；

產品和UI協同規範

產品經理在描述某個需求功能有多個異常狀態時，在產品文件用不用顏色的文字或者表格來強調突出；

由UI同學在畫高保真設計稿時，針對不同狀態來進行設計；

有助於產品經理在驗收UI設計稿的時候，針對功能點和多種異常狀態的驗收；

運營介入需求

運營提前提前確認產品需求功能和迭代，確保當前迭代是符合產品整體規劃，有利於團隊協同效率；

但過多的流程會導致運營做不好自身的工作，因此簡化如下流程：

• 產品經理制定產品迭代規劃，需告知運營，如運營有異議，可溝通及時調整；
• 產品經理在預審時，需告知此版本迭代需求，如運營有異議，可溝通及時調整；
• 產品經理在需求評審時，提前通知專案組員，包括運營人員，進行產品的文件修正，如產品文案等；

開發規範（待梳理）

待梳理的原因是，開發規範目前來說是最內部的，優先順序應該是最低的，因此暫時不考慮，大致會涉及到這幾個內容：

程式碼風格規範api規範，資料結構、文件規範git 分支和log規範review制度對外文件規範設計文件：資料庫結構、系統設計圖複製程式碼

提測流程和免測標準

規則

• 右前端、客戶端、後端參與的需求，由對應開發來提測；

流程

• 開發自測，確保主路徑沒問題，如果測試組有提供冒煙測試，必須冒煙都通過；
• 在釘釘公告欄寫上本次提測的tag和測試重點，每個版本內累計更新，不要覆蓋上次的內容
• 如果質量不過關，測試可以打回；

提測通知示例

（術語解釋參考排期和立項）

前端t1 2.3.3/1803031104 已自測，自動XX、UI改版前端t2 2.3.3/1803041203 未自測，XX前端t2p1 2.3.3/1803051404 …… 解決一個崩潰，會影響所有需要登入的介面iOS t3 2.3.3/1803061203 已自測，全功能提測後端t1 1803061203 解決xxx問題複製程式碼

patch的提交頻率以天為單位，不建議解決一個bug就提測一個patch；如果實在需要，應該開發和測試同學單對單地驗證完畢，然後發patch時再由測試迴歸多個問題；

前端、後端、小程式、H5這種沒有tag概念的話，就用當前日期處理；

打回

標準：

• 測試環境沒搭好（提供部署環境的程式碼時未提供部署文件）；
• 主路徑跑不通；
• 開發未通過冒煙測試用例；
• 開發未寫明測試重點、修改程式碼的影響範圍；
• 開發未提供相關資料庫設計文件、介面設計文件；

通知：

• 釘釘群裡 @所有人 來通告，說明原因；

免測標準

免測的前提是確認測試已知悉，然後才是下面的條件：

• 只改UI佈局或文案，沒有改互動和業務；
• 只是改後臺報表統計；

測試報告

撰寫原則

• 最終目標不是故意找茬，而是讓管理者知道哪個環節有問題，能及時做調整；
• 要能反映質量，不要寫成在描述需求或業務；
• 質量問題要具體到職能或人；不能模稜兩可，看不出誰要為問題負責；
• 記錄測試手段，為線上故障的漏測找依據；

郵件模板

收件人：專案組的釘釘群抄送：測試組的釘釘群標題：【測試報告】xxx專案y.y.y（版本）[第z輪|release]，例如 【測試報告】jb專案1.2.1 t1

正文：

Dear All，1.結果概況

結果：[通過|有條件通過|失敗打回]；[有條件通過的原因]：產品同意部分bug不影響釋出，並已知曉問題風險，同意下次解決；

（一兩句話總結專案質量）例如：開發比上一版本的質量有明顯提升，需求變更數也少了，給大家點個贊！

遺留問題數：x個。

（不多的話下面直接列出來，帶有禪道url的超連結）

2.質量報告

質量指標：

• 需求變更數：10個，增加工作量：20人天；
• 測試案例一次通過率：76%；
• bug總數：108個；
• 效能指標：api介面平均響應時間：400ms；
• 相容性：測試裝置（列表見過程記錄）中沒有發現相容性問題；
• 每輪提測的patch數；

bug分佈：一系列的餅圖，數量和百分比。維度：責任人、報bug人、出錯原因、嚴重程度、解決耗時、異常狀態（打回和重新啟用）；

本輪測試後，處於未關閉狀態的bug，責任人分佈：

3.過程記錄

需求與測試人員參考立項文件：(url)

案例情況：

• 數量：76個；
• 型別覆蓋：功能測試，介面測試，介面自動化，相容性測試，效能測試；
• 自動化案例增加3個介面的監控；

測試環境：

手機型號：

系統型別與版本：

瀏覽器型別與版本：

• Windows Chrome Version 69.0.3497.100 (Official Build) (64-bit)
• Mac Safari Version 12.0 (13606.2.11)
• iPhone 7, iOS 11.3.2 Safari
• 小米6A， MIUI 10.2.2 系統瀏覽器，UC瀏覽器 V12.3.3.2342

bug系統使用規範

報告規範

指派：

• 直接指派給你知道的負責人，否則先給測試負責人；

模組：

• 儘量選對，不同模組通知到的負責人可能不同；
• 不知道的話選其它，由測試負責人再修改；

標題：

• 一句話總結出錯的位置、現象；或者是建議做法；
• 思考一下要搜尋出這個bug時會用什麼關鍵字，這個關鍵字應該存在標題裡；
• 標題可以用[]來存在重要內容，如【小說】小說模組出現無法載入問題；

重現步驟：

• 說明問題的現象是什麼，為什麼這算是一個bug；
• 可以補充說明要修復成什麼樣，如果是顯而易見的就不用說了；
• UI展示問題或文字說不清的問題，截圖說明，必要的話做成GIF或錄屏；
• 特定情況才觸發的問題，要包含測試資料，例如：
• • 賬號密碼；
• • app專案的操作路徑，例如 首頁->
    資訊廣場->
    點選第一條->
    白屏；
• • web專案的URL；
• • 如果覺得可能是相容性問題，寫上重現條件，例如手機版本、系統版本；
• • 其他能幫助重現的資訊；

嚴重程度劃分標準：（目前禪道對應1、2、3、4）

• 嚴重：崩潰、白屏、404/500錯誤；業務錯誤，流程不通，主要功能缺失，資料計算錯誤，效能；
• 一般：次要功能錯誤、缺失；資料長度；介面樣式影響使用
• 輕微：介面樣式問題但不影響使用
• 優化建議：體驗不好；速度太慢

優先順序劃分標準，產品經理對優先順序有最高決定權：（目前禪道對應1、2、3、4）

• 立即解決：主路徑問題，不解決無法繼續做測試；
• 下次提測時解決：預設項；
• 釋出前解決：相對獨立，對其它功能沒影響的問題；
• 下個版本解決：未嚴重影響使用者，但解決起來有難度，可能造成專案延期；

這裡需要注意，一般嚴重問題都是緊急的，但是要考慮到問題出現的概率及影響面，從而會有嚴重不緊急，緊急不嚴重的情況；

如啟動頁的logo錯了，雖然不嚴重，但會影響到公司聲譽，所以是緊急的；某個功能出現閃退，但是隻在極端的情況出現，考慮到修復成本及影響面，可能屬於嚴重不緊急；複製程式碼

使用規範

• 轉給他人時，可以考慮新增備註；
• 及時解決，產品的bug新增到需求池或其它地方有記錄就算已解決；

注意事項

切勿將需求當Bug報，報Bug之前，需要了解Bug和需求之間的區別：

• 需求是描述一件事情，作為什麼使用者，希望如何，這樣做的目的或價值何在；
• 需求需要構建使用者角色，描述使用場景，定義使用者問題；
• Bug是程式中隱藏或被發現的功能缺陷或漏洞。簡單說就是使用軟體時，出現的錯誤問題；
• Bug需要描述重現的步驟，環境及其他因素，以便定位問題；

但並不是說需求不能報禪道，只是希望能用更好的方式來區分出來，如標題寫上[需求]、選擇對應模組和優化建議，指派給產品經理；

延期和需求變更

延期

有延期風險時應及時通知專案經理，並由專案經理組織各負責人確認是否延期；

最終由專案經理髮出郵件，列明延期原因、修改後的里程碑時間，同步更新cf文件；

郵件標題：【專案延期】xxx專案延期說明mmddDear all，    XXX專案 上線時間由11.13 延期到 11.14，延期一天    延期原因如下：    1、處理XX問題，超出計劃時間。複製程式碼

需求變更

通知規則：

• 必須在需求文件的修訂記錄上有所體現；
• 在釘釘上@所有人 通知。如果增加的工作量超過1人天的，必須發郵件；
• 會導致專案延期的變更，必須產品主管確認；

通知內容：

• 以前是怎麼，要改成什麼樣；
• 更新文件在哪；
• 影響的具體工作量；
• 影響後的專案計劃安排；

操作流程

專案執行過程中，預計專案延期2天以內，與技術人員評估之後，發出延期通知；超過2天或者延期2天，召開會議，討論解決方案，發出延期會議郵件；

所有的延期說明，都需要給出具體可量化的原因；

集體加班制度

集體加班的標準

• 及時上線能帶來可觀收入；
• 外力因素（政府政策、第三方故障等）；
• 延期了太久，要把進度趕回來；

集體加班需要由產品和專案共同決定，並且有郵件通知；

不滿足條件的，不得隨意要求專案組加班，更不得由產品或專案私下要求加班；

別人過失導致的個人加班，應根據自己意願決定是否加；不加是合理的，專案延期是符合流程的；如果選擇加班，那是個人為專案順利所做的努力，是高績效的有力依據；加班完了最好有意識地記錄自己的貢獻，在述職時列出這些積極表現；

通知

由專案經理發郵件通知，模板：

標題：【加班通知】xx專案mmdd正文：（加班的原因、人員名單、目標）複製程式碼

補貼

集體加班，可由產品或專案申請經費購買週六下午茶，人均x元左右；如果領導同意，可協調成補休，不同團隊視實際情況落地，下午茶補貼是一定要有；

驗收、釋出、上線

驗收者

產品、UI、後臺系統使用者（運營、客服、風控等）；

驗收進入條件

測試流程結束的下一步是驗收；進入驗收的最理想標準是所有bug都已關閉；

如果時間緊張，可以放寬到同時滿足這兩個條件：

• 優先順序為“下次提測前解決”的bug都已關閉；
• 優先順序為“釋出前解決”的bug不超過人均2個；

測試環境驗收

• 測試向驗收者演示主流程，形式多樣，主要是要溝通清楚；
• 驗收者自己操作，或讓測試演示更多流程；
• UI核對，主要是顏色值和畫素級大小的比對你，肉眼能看出來的差異，應該在測試過程就發現；
• UX體驗反饋；

釋出與線上驗收

• 產品經理宣佈測試環境通過，讓開發釋出到生產環境，各職能核心人員待命應對故障；
• 釋出後，測試和產品再過一遍主流程，後臺系統使用者也應該做些操作來檢驗或持續一段時間觀察相關資料是否異常；
• 線上驗收標準由各驗收者自己決定儘量在週二或週四上午釋出，以便出現問題時大家有時間精力立即修復；

上線

生產環境驗收通過後，確認可以開始放量，這個結果視為“上線”；

由產品經理宣佈，如果沒什麼問題，釘釘群裡說完即可，如果有風險，應發郵件：

收件人：專案組標題：【上線通知】xxx專案y.y.y正文：...（風險預估）（應急預案）複製程式碼

結項

結項會議

時間：上線三天後主持人：專案經理或助理參會人員：實際參於專案的所有人員，主管酌情參與會前準備：把需要投影的東西給主持人，自己準備好發言提綱會議流程分為兩部分第一部分，結果總結，按以下次序發言：

• 專案：簡單回顧整體專案進度，消耗的人力時長，偏差多少與原因；
• 產品：線上版本相關資料（脫敏）。主要目的是讓大家知道勞動成果的意義；
• 測試：簡要說測試報告的重點，突出質量的部分；

第二部分，過程總結，這部分發言可進行討論：

按以下次序發言：專案->
運營->
產品->
UI->
後端->
前端->
客戶端->
測試->
運維；

發言內容指引：

• 對事不對人，主要目的是點贊和總結下次如何做得更好；
• 自己或合作方哪裡有改進，上次的問題解決得如何；
• 自己或合作方哪裡做的不好，有什麼解決方案或建議；
• 提升工作效率的心得（溝通方式，工作方式、專案安排、工具使用等）；

結項郵件

發件人：專案經理或助理收件人：專案組釘釘群**，可接著專案週報發**標題：【結項報告】xxx（專案）y.y.y（版本），例如 【結項報告】XX3.2.4正文：（下劃線表示是示例，真實郵件不要有）Dear All，（暫無模板，幾乎就是結項會議的會議紀要）複製程式碼

例子：

Dear all，XX小程式VX.X 整體概況如下：1.XX暴雷X.X的專案計劃是X.X -   XX.XX，預計消耗X工作日。實際專案執行是從X.XX -  XX.XX，總共消耗 XX工作日，延期XX工作日。2.小程式上線之後，使用分享解鎖和動態分享功能的人數很多，後續產品會針對分享功能進一步優化及挖掘使用者，詳情資料請檢視附件；3.整個專案測試反饋的總bug反饋數XX個，有效問題XX個，X個不處理，X個延期處理，X個轉為需求;
延期原因：1.專案人數不足，前端同學在專案中期才開發;
2.需求評審過後，沒有進行技術可行性分析，導致專案中後期才發現某些功能實現起來困難;
3.評審需求時，沒有足夠時間仔細閱讀文件。需求裡面隱藏著好多功能點，導致評審時間不準;
4.產品文件發生修改的時候，沒有馬上通知專案成員，增加溝通成本;
5.開發時發生UI及需求文件和後端介面欄位串聯不上，增加溝通成本和研發成本;
6.bug數量多，有效Bug 有93個，修復時間長;
7.訊息中心功能在專案後期才調通，處理時間久;
8.測試跟前端雙方在bugfix階段的配合存在問題，需要優化;
解決方案：1、XXX複製程式碼

表格說明

線上故障

##故障定義釋出生產環境並驗收通過，確認放量後，還發現的bug都算線上故障；

報告標準

什麼情況的線上故障需要報告？

• 對營業額有大影響，例如無法開啟頁面，無法買標；
• 對使用者口碑有大影響，例如功能無法使用；

什麼情況的不需要報告？

• 簡單的使用者體驗或純UI的問題

處理流程

• 無論誰發現的，首先應該反饋給測試同學；
• 測試確認重現步驟後，報bug給開發解決，並由產品經理決定是否緊急釋出修復；
• 修復後，由測試負責人彙總各職能的報告併發出郵件；
• 產品報告對運營資料的影響；
• 開發報告出錯的原因、（程式碼層面的）影響範圍；
• 測試報告沒測出來的原因；
• 由測試組織討論如何防範這樣的情況再出現；

報告郵件

原則：

要找出責任人（或指出是哪個職能即可）和出錯型別（程式碼、需求、溝通之類的），並明確寫到報告中；對事不對人，注意措辭；要有解決方案，且有明確的跟進人；複製程式碼

例子：

收件人：專案組釘釘群抄送：測試組釘釘群標題：【線上故障】xxx專案a月b日yyy問題正文：（下劃線表示是示例部分，真實郵件不要有）Dear All,本次故障的現象：散標詳情頁出現白屏，並一直彈框“資料異常”持續時間：10月3日14:30上線就存在，在10月3日18:00由後端修復，故障持續3.5小時發現時間：由客服在10月3日16:00收到使用者反饋而發現影響：使用者無法檢視和購買散標原因：後端……解決方案：解決程式碼錯誤即可未能更早發現故障的原因：後端上線前改程式碼未通知測試防範方案：需要開發自覺，開發主管要加強宣導。最佳解決方案是git提交都有監控，但目前可執行性太弱；複製程式碼

專案週報

原則

• 有事起奏無事退朝；
• 專案經理可在週一上午召開站會收集資訊，各職能負責人需積極配合；
• 週一下午3點前發出郵件；

郵件模板

收件人：接著立項郵件全體回覆，每週接著上一週發直到結項標題：【專案週報】xxx（專案）mmdd（月日），例如 徵信通1018正文：Dear All，（1-3句話總結情況。）（當前進度，是否存在風險。有就說明異常情況與原因，提醒注意，請求協助。）本週專案進度正常，按計劃進行中，無特別情況需要彙報。專案計劃參考立項文件；本週進度基本可控，可能的風險點：週三xxx要請假，也許會造成延期xxx需求還沒出UI稿，設計師在忙別的專案，可能造成前端延期10月4日週二上線了1.3.2版本，運營資料在持續觀察中。1.3.3的需求正在評審中。專案確定延期1天，改為10月28日釋出，原因：需求變更，xxx需求未考慮到yyy的情況，補上後產生新工作量，具體請參考 需求變更文件/郵件xxx臨時有事請假阿里雲伺服器故障，情況未知，@xxx正在處理10月5日發生了線上故障 xxx，具體請參考 測試 發的郵件，標題為：yyy本週運營資料：（由產品經理進行脫敏處理，有圖表更好）PV變化在5%以內，在合理範圍內UV下降了20%，應該跟國慶假期有關買標資料上漲30%，交易總額上漲50%，上線的新功能非常有用！xxx的運營需求，轉化率為7.8%，效果很差！複製程式碼

例子

例子1：

hi，all，上週XXX各專案進度如下：XXXAPP：VX.X.X版本：研發側：1）bugfix中，目前還剩下X個bug，開發進度約XX%；2）XX功能上週已開發完畢，計劃週二週三跟客戶端聯調，週四提測；3）對接XX工作，確定延期，需要等XX上線才可以對接，初定XX月上旬，產品已知曉；4）考慮XX可能存在風險，決定把該功能延期到X.X.X版本上，避免因XX功能導致專案延期或承擔風險；測試側：目前已提測t1、t2，均測試完畢，處於bugfix驗收環節；VX.X.X版本：該版本為小版本，主要是體驗優化（具體優化內容）；1）產品側：需求已與測試、後端、UI評審，前端因還在忙VX.X.X專案，暫時未參與；2）研發側：後端，除了版本相容需要跟前端討論可行性，其他功能能在本週內開發完成；3）UI側：已經提供了設計稿；VX.X.X版本：該版本為大版本，主要是新增XX功能；1）產品側：需求已與測試、後端、UI評審，前端因還在忙VX.X.X專案，暫時未參與；2）研發側：後端，除了版本相容需要跟前端討論可行性，其他功能能在本週內開發完成；XXX：1）研發側：上週已提測XX功能，目前開發進度XX%，進度正常，預計下週五全部開發完畢；2）測試：測試中，測試進度10%，在測試XX模組中，因頁面內容跳轉還未完全實現，因此後期存在返工量，後期可能會存在風險；XXX專案VX.X：上週已上線；複製程式碼

例子2：

Dear All，上週主要專案進度 已釋出 ： 針對線上問題修改預付利息演算法 產品：XXX   開發：XX  測試：XX萱 進行中 ：1.輕鬆投部分退出     測試階段 產品：蔡菁菁   開發：黃振廷，吳鼕鼕（本週增加），蔡曉萍，林博淳   測試：周佩萱風險：故障較多，主流程仍不通結算失敗，並且問題反覆出現。前期開發（業務）設計存在許多缺陷    原計劃本週上線解決方案：協調產品及開發負責人討論，決定增加一名開發。看故障解決情況明天早會再討論進一步解決方案2.App優化-XXX功能  測試階段  進度正常產品：XXX   開發：XXX   測試：XXX3.XXXX  測試階段  進度正常產品：XXX  開發：XXX   測試：XXX4.XXX  開發編碼階段產品：XXX  開發：XXX   測試：XXX5.XXX 開發設計階段產品：XXX 開發：XXX    測試：XXX複製程式碼

小結

上面的內容，是整個團隊的努力，大家一起完成的，完成這麼一件事不容易，雖然花費了很多時間，但真的很值得，因為之前只是在門外，而如今在門內，不親力親為，真的不知道需要了解這麼多內容；

好了，就這樣吧，如果有補充的，歡迎提出，謝謝大家；

來源：https://juejin.im/post/5bff83886fb9a049db72d808