小型團隊通用工作流程SOP方案
編輯導讀:所謂SOP,即標準作業程序,指將某一事件的標準操作步驟和要求以統一的格式描述出來,用于指導和規范日常的工作。實際執行過程中sop核心是符合本企業并可執行,不流于形式。本文作者基于自身工作經歷,歸納整理了一個適用于小型團隊的工作流程,與你分享。
我親身經歷由一個小型團隊從開始的混亂不堪,到后期有規律的迭代,其中從前輩的資料和自己的工作經驗中整理歸納了一個適用于小型團隊的工作流程,包括工作中常用的文檔模板和說明,供大家參考借鑒。
但是具體情況具體分析,希望大家能夠形成適用于自己團隊的sop。
一、跨部門工作流程
跨部門流程及職能如下圖展示。
二、運營
1. 日常提交需求
運營及業務同學,按照下方模板填寫后,提交給產品經理。
2. 活動需求
根據活動大小,至少提前15-30天,提交活動方案給產品經理。活動方案模板暫時未整理,后續專門開一篇文章講活動。
三、產品
產品經理的日常工作流程。
1. 需求池
每日需更新產品的需求池,做出對應的狀態變更??筛鶕路侥0鍏R總。
2. 需求評審
需求評審會召開前,發正式郵件通知相關干系人。郵件模板如下:
Dear all,
本人近期完成了對某某某功能的調研,并在此基礎上完成了某某某v3.0的版本設計,現邀請諸位舉行會議對此次需求進行評審,具體安排如下:
會議時間:2018年9月1日 上午10:00
會議形式:線下會議
會議目的:某某某v3.0需求評審
參會人員:
1)iOS-小張、android-小陳、研發……
2)測試小紅、產品小黃、設計小亮……
以下是本次會議的會議概要,請大家查閱:
××××××××××××
tips:請大家提前閱讀需求說明。準時參會。
可能出現的問題(討論要點)如下:
××××××××××××
以上
祝生活愉快!
需求評審的流程如下:
3. 原型及需求管理
需求以需求原型及標注的形式呈現,需求原型上傳至藍湖,具體的需求點,同步更新于禪道。
4. 數據埋點模板
小程序:
其他系統:
四、UI
1. 設計圖及標注
UI設計圖上傳至藍湖,并提供對應的切圖。
2. 統一設計規范
例如,后臺管理系統。
五、開發
1. git代碼規范(截取片段,詳見代碼規范文檔)
2. git工作流程規范(截取片段,詳見具體文檔)
3. 版本號命名規范
以 YinLiFang_1.0.0.170517_beta.apk 為例:
主版本號(1):當功能模塊有較大的變動,比如增加多個模塊或者整體架構發生變化。此版本號由項目決定是否修改。
子版本號(0):當功能有一定的增加或變化,比如增加了對權限控制、增加自定義視圖等功能。此版本號由項目決定是否修改。
階段版本號(0):一般是 Bug 修復或是一些小的變動,要經常發布修訂版,時間間隔不限,修復一個嚴重的bug即可發布一個修訂版。此版本號由項目經理決定是否修改。
日期版本號(170517):用于記錄修改項目的當前日期,每天對項目的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
希臘字母版本號(beta):此版本號用于標注當前版本的軟件處于哪個開發階段,當軟件進入到另一個階段時需要修改此版本號。此版本號由項目決定是否修改。
希臘字母所代表的版本階段介紹:
Alpha版:也叫α版,此版本主要是以實現軟件功能為主,通常只在軟件開發者內部交流,一般而言,該版本軟件的Bug較多,需要繼續修改。
Beta版:此版本相對于α版已經有了很大的改進,消除了嚴重的錯誤,但還是存在著一些缺陷,需要經過多次測試來進一步消除,此版本主要的修改對像是軟件的UI。
RC版:此版本已經相當成熟了,基本上不存在導致錯誤的BUG,與即將發行的正式版相差無幾,測試人員基本通過的版本。
Release版:此版本意味著“最終版本”、“上線版本”,在前面版本的一系列測試版之后,終歸會有一個正式版本,是最終交付用戶使用的一個版本。該版本有時也稱為標準版。一般情況下,Release不會以單詞形式出現在軟件封面上,取而代之的是符號(R)。
六、測試
1. 提測
開發完畢,以較為正式的形式提交給測試人員,模板如下:
測試版本的版本號:V1.0.0-beta
版本名稱:20190102發布內容
提測時間:2020-01-16
版本內容:
××××××××××××
測試環境地址:
××××××××××××
測試登錄賬號及密碼:
××××××××××××
其他注意內容:
如果驗收測試過程中發現嚴重bug,則退回版本,修復完畢重新提測。
2. 測試用例
模板如下:
測試要點:
UI測試:
- 確保手頭的原型圖與效果圖為當前最新版本。
- 確保產品UI符合產品經理制定的原型圖與效果圖。
- 一切界面問題以效果圖為準,若有用戶體驗方面的建議,必須先以郵件或口頭的形式詢問產品經理。
- 由于測試環境中的數據為模擬數據,測試時必須預先考慮到正式環境中可能出現的數據類型。
功能測試:
- 確保手頭的功能需求文檔為當前最新版本。
- 確保所有的軟件功能都已實現且邏輯正常。
- 一切功能問題以需求文檔為準,若有用戶體驗方面的建議,必須先以郵件或口頭的形式詢問產品經理。個人建議,用戶體驗方面的建議,優先級放在修復bug之后。
- 若有些功能在技術上難以實現或者由于排期的原因無法在短時間內實現,必須得到產品經理的確認,而不是單單只聽開發人員的技術解釋。此處確認最好以郵件形式存在。
- 所有的“外部原因”問題,都需要盡早地督促開發人員與客戶服務端人員聯系協調解決。并在之后的測試報告中予以體現。
- 所有的“設計如此”、“延期處理”問題,都需要和產品經理確認后再進行驗證。并在之后的測試報告中予以體現。
- 測試下單時,注冊的測試賬號必須符合公司規范;收貨地址必須包含“測試”關鍵字,最好每次下單的名稱中含有日期,以便查詢;在正式環境中下單后必須取消該訂單等。
兼容測試/性能測試:
- 確保軟件在所有兼容機型上都能正常使用(ios一般需要兼容到6, ios5可以不用考慮,用戶使用率已經低于5%以下)
- 性能測試方面必須滿足硬件壓力條件下的測試需要(例如多線程,用戶常用的app都要后臺運行的環境中測試。)
- 網絡響應用戶體驗方面的性能測試,需要保證在wifi、3g、2g網絡下的切換效果。比如wifi切換到2g,網絡響應的速度以及切換界面。
3. 測試日報
測試人員每天需對所測項目發送測試日報。測試日報所包含的內容為:
- 對當前測試版本質量進行分級
- 對較嚴重的問題進行例舉,提示開發人員優先修改
- 對版本的整體情況進行評估
- 對版本測試過程中修改的內容進行記錄
4. 上線報告
產品上線前,測試人員發送產品上線報告。上線報告所包含的內容為:
- 對當前版本質量進行分級
- 附上測試報告(功能測試報告、兼容性測試報告、性能測試報告等)
- 總結上線版本的基本情況。若有遺留問題必須列出并記錄解決方案
5. bug提交管理規范
模板如下:
【所屬功能】bug出現的功能模塊,比如個人中心。
【主題】一句話描述問題產生的模塊、現象、錯誤現象及正確結果。比如個人中心上傳頭像照片不成功。
【復現率】bug重現的概率,可以用百分比形容,也可以用always、sometimes。
【平臺】Android、iOS、H5、Web、PC
【問題類型】界面/功能/性能/兼容/安全/體驗
【嚴重級別】可以用P0、P1、P2形容,也可以用高、中、低或者是嚴重、普通、低級。
【復現環境】DEV、TEST、LIVE
【測試機型】iPhone 6、Google Pixel
【系統版本】9.1.1
【測試版本】給出發現bug的版本號、構建號、tag即可
【研發分工】前端、后端
【前提條件】
【復現步驟】
- XXX
- XXXXX
【預期結果】預期的正確結果
【實際現象】實際看到的錯誤的現象
【其他補充】可以提供附件文檔、日志、截圖等一切可以協助開發分析問題的信息。
七、發布
1. v1.0上線通知
上線郵件模板如下:
各位領導,各位同仁:
“某某”項目在全體同仁的共同努力下,于 X 年 X 月 X 日正式上線了!項目自 X 年 X 月 X 日立項,歷經 XX 天的艱苦奮戰,項目組克服了 XX 和 XXX 等困難,各部門都按時完成任務,整個項目才得以順利上線。感謝大家的辛苦付出,向項目組每一位成員致謝!
本次項目上線的平臺包括:
- iOS(版本號:V1.0.0 可在 App Store 搜索“XX”,大概排名第 N 位)
- Android(版本號:V1.0.0 可在應用寶、XX 軟件商店,搜索“XX”大概排名第 N 位)
- 下載二維碼如圖:【這里假裝有一個二維碼】
本次版本主要包含如下功能:
- XXXX 功能,解決了 XX 問題
- XXXX 功能,滿足了 XX 需求
歡迎大家下載體驗,在體驗的過程中遇到什么問題、有什么意見和建議,歡迎及時反饋給產品經理(郵箱 XXX)
“某某”項目承載著公司在追逐 XX 市場的期許,未來,我們將在 XX 領域劈荊斬刺,為公司創造無限可能!這里面需要我們付出更多的艱辛。上線只是起點,而非終點,我們也已經與各個小組制定好接下來要開展的工作,這將讓我們的產品進入市場,與競品真刀真槍地一分高下!
接下來我們要開展的主要工作:
- 做好產品優化工作,XXXX
- 做好產品推廣工作,XXXX
- 做好產品運營工作,XXXX
請各小組同學再接再厲,繼續為“某某”項目 XXXXXX。
謝謝!
2. 版本發布通知
通知模板如下:
版本號:v1.1.2
版本內容:XXXX
發版日期:2020-01-16
代碼更新時間:具體時間段(如影響正常使用,要前提告知。)
八、其他
1. 會議模板
會議記錄:
會議紀要:
2. 周報、日報模板
日報:
今日工作內容:內容+工時
明日工作計劃
問題及其他內容
周報:
本周工作進展
下周工作安排
問題及解決辦法
總結:希望大家能從中受益,制定符合自己團隊的sop,形成一個高效密切且具有戰斗力的團隊。
參考:文章部分內容歸總來源于互聯網
本文由@Olivia 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議
專欄作家
Olivia,微信公眾號:Olivia是只產品汪,人人都是產品經理專欄作家。一個致力于分享加倍干燥專業干貨的空想家。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
感謝分享~
很不錯,請問是否可已發下對應的源文件,感謝
111
謝謝謝謝,太感謝了,解燃眉之急
強啊
活動方案模板啥時候出文章
說的好詳細呀,棒?。?/p>
在WeTool里可以根據不同的人群屬性設置不同的sop,非常好用,最新官網好像是:https://wetool.plus/
非常實用的干貨,如果有相關的一些文檔下載就好了。
太棒了,非常有參考價值
可以的話講一下流程當中的文檔整理規范
文檔整理規范是指?
說的很詳細,很有借鑒意義!
謝謝~