“旅游之前，先上馬蜂窩” 已經(jīng)成為許多人習(xí)慣性的選擇。

2019年5月，馬蜂窩完成了新一輪融資，金額達2.5億美元。這也標(biāo)志著通過集內(nèi)容、社區(qū)、交易為一體的消費決策場景構(gòu)建，從攻略社區(qū)起家的馬蜂窩開始邁入在線旅游行業(yè)頭部陣營。

決定出門旅游，交通方式是用戶首先要考慮的事情，為了幫助用戶從行程起點開始，高效完成旅游消費決策的全鏈路閉環(huán)，馬蜂窩上線了“大交通”業(yè)務(wù)，主要提供機票、火車票及租車自駕游等服務(wù)，讓用戶從出行方式開始，享受旅游的樂趣。

一年多的時間里，馬蜂窩大交通研發(fā)既要滿足業(yè)務(wù)的需求，提升研發(fā)的效能；更要保證服務(wù)的質(zhì)量，降低線上故障率。這支從零組建的團隊經(jīng)歷了不小的挑戰(zhàn)。

第一階段? 成立初期

填補業(yè)務(wù)空白是首要目標(biāo)

在成立初期，團隊的首要目標(biāo)是快速支撐起業(yè)務(wù)，填補業(yè)務(wù)空白。

業(yè)務(wù)從無到有，功能開發(fā)需要具有快速迭代和交付的能力。我們采用的是雙周迭代模式，挑戰(zhàn)性比較強。從初期開始，我們就對項目研發(fā)全流程管理就非常重視，盡力使每一個環(huán)節(jié)都能做到規(guī)范、高效、透明。

1.?分類需求，明確迭代周期

初期團隊只有十幾人，但是每周并行的需求也不少。為了在項目快速上線的同時保證質(zhì)量，我們按照需求的不同類型和等級梳理了交付的核心時間節(jié)點，大致分為3類：

? 日常：開發(fā)工期較短，1個迭代（雙周）內(nèi)完成。? 項目：開發(fā)工期3天以上， 盡量在2個迭代（四周）內(nèi)完成。

? 線上事件：計劃外的突發(fā)狀況，通常來說緊急程度高，可能會直接影響線上業(yè)務(wù)，需要及時響應(yīng)。

圖1：需求交付核心時間節(jié)點

為了合理安排開發(fā)資源，除線上事件外，所有需求每雙周進行一次PK，根據(jù)項目價值、優(yōu)先級、資源情況等確認后續(xù)2周的需求范圍。

日常、項目需求主要流程如下圖所示：

圖2：項目流程示意

2.?借助TAPD，實現(xiàn)可視化管理

工欲善其事，必先利其器。

為了實現(xiàn)研發(fā)流程的高效、透明，團隊初期就決定用工具來管理研發(fā)項目全周期。經(jīng)過對比后，我們最終選擇了TAPD，主要是因為 TAPD 具有靈活配置、操作簡便以及支持移動辦公、項目間隔離性強等優(yōu)勢。

在團隊初期，我們主要用到的是 TAPD 的 “看板”功能進行需求管理、迭代管理和項目管理。

使用看板標(biāo)簽區(qū)分以下字段——

? 需求優(yōu)先級：P0、P1、P2、P3? 需求類型：項目、日常? 需求來源：技術(shù)、產(chǎn)品和線上

共創(chuàng)建了4種通用看板——

??待PK項目/日常看板??日常進度看板??項目進度看板??線上問題轉(zhuǎn)需求看板

以及針對每個項目的單獨看板。

圖3: TAPD 看板示例

這一階段的需求流轉(zhuǎn)流程如下圖：

圖4：成立初期需求流轉(zhuǎn)流程示意

通過使用“看板”功能，待處理的業(yè)務(wù)需求優(yōu)先級，拆解后各獨立項目的任務(wù)清單，研發(fā)、測試和上線各環(huán)節(jié)的進度都一目了然，使研發(fā)流程的各個環(huán)節(jié)實現(xiàn)打通，為團隊高效的協(xié)作帶來了很好的氛圍和基礎(chǔ)。

第二階段 快速發(fā)展期

保證交付效率和服務(wù)質(zhì)量是關(guān)鍵

在業(yè)務(wù)快速發(fā)展期，開發(fā)聯(lián)調(diào)和自測效果不佳，提測質(zhì)量較差，測試階段Bug較多，一個項目可能就有100多個Bug，導(dǎo)致項目工期不可控和線上質(zhì)量不可控。因此縮短線下項目工期、減少測試階段 Bug 以及線上問題數(shù)量、保證服務(wù)穩(wěn)定是我們的核心目標(biāo)。

這個階段，我們主要使用了TAPD的“缺陷”功能進行線上問題跟進，以及“測試用例”和“測試計劃”提升研發(fā)自測效率。

1.?構(gòu)建線上問題處理閉環(huán)

從前，大交通業(yè)務(wù)線上問題反饋的落地點主要是各種微信群，每天大約有將近10個問題，一出現(xiàn)問題相關(guān)人員就要在群里討論回復(fù)，正常的開發(fā)節(jié)奏總是被打斷，值班人員也要隨時盯著反饋群。

隨著時間長了、業(yè)務(wù)復(fù)雜了、人員多了，這種方式帶來了一系列問題：

? 反饋渠道分散，問題不聚焦，并容易漏掉問題；? 問題定位難，無效 Bug 多，影響修復(fù)效率；? 無法及時監(jiān)控解決過程，存在同樣問題反復(fù)出現(xiàn)的風(fēng)險

針對這些，大交通由測試團隊先行，優(yōu)化并完善了「線上問題反饋和處理機制」，并通過 TAPD 落地，提升問題解決的效率和質(zhì)量。??

1)標(biāo)準(zhǔn)化反饋流程

線上問題反饋的具體流程為：

圖5：線上問題反饋流程

內(nèi)部用戶和外部客服人員反饋問題后，由運營、產(chǎn)品統(tǒng)一記錄到 TAPD 中， 由值班的技術(shù)支持人員過濾問題，復(fù)現(xiàn)并確認是否為有效 Bug。如經(jīng)確認是有效Bug，則直接提交負責(zé)的開發(fā)人員排查修復(fù)并評估影響面，遇重大問題則通知 Team Leader 關(guān)注；如初步確認為無效 Bug，與問題反饋人進行核實驗證。無論何種類型的 Bug，都會統(tǒng)一錄入 TAPD 記錄， 直到問題關(guān)閉。最終，處理結(jié)果將反饋至產(chǎn)品、運營和值班人員。

每周，責(zé)任技術(shù)人員以周報的形式向上級同步線上問題處理情況。

圖6：線上問題處理流程

如此一來，問題記錄分布在了不同人員身上，專職記錄同學(xué)不用再全職盯微信群的聊天記錄，開發(fā)同學(xué)也可以根據(jù)自己的時間安排來處理問題和在TAPD中回復(fù)解決方案，不用即時回復(fù)群消息，化同步為異步。

這不僅大大解放了之前專職記錄同學(xué)的時間，使其投入到更多工作中去釋放價值，也有效提升了團隊的協(xié)同，保證每一條問題都能及時得到記錄、處理和反饋，提升問題解決的效率。

2)問題評級，影響范圍大的先處理

大交通線上測試團隊對可能出現(xiàn)的線上問題進行統(tǒng)一梳理，并將問題類型及其產(chǎn)生的影響進行了相應(yīng)的評級，不同級別的問題要求解決的時效性不同。

一旦發(fā)現(xiàn)問題，按照優(yōu)先級由高到低快速處理，最大程度縮小問題影響的范圍，降低業(yè)務(wù)損失，同時使技術(shù)人員在解決線上問題的過程中更加合理地規(guī)劃時間，提升問題解決效率。

圖7：事件等級和解決時效性要求

3)重大故障Review后，創(chuàng)建任務(wù)跟進

對于線上故障級別比較高的，問題排除后會緊急進行故障線下 Review， 復(fù)現(xiàn)問題發(fā)生的時間線，明確問題產(chǎn)生的原因，并制定可執(zhí)行的 Actions。

之前，在故障線下 Review 結(jié)束后，這些 Actions 不能得到有效監(jiān)督，有時超過5-6天都沒有往下落實。

現(xiàn)在，每個 Action 都會通過 TAPD 建立任務(wù)，根據(jù)不同等級設(shè)置 Deadline，分配給專人執(zhí)行。Team Leader 會定期跟進各行動項的執(zhí)行，提醒執(zhí)行人及時處理，有效提升處理效率，避免類似故障再次發(fā)生。

4)問題分類，提供改進方向參考數(shù)據(jù)

之前的問題記錄在文檔中，格式比較松散，所以回溯問題時，如果想進行數(shù)據(jù)的統(tǒng)計和分析是很困難的。

通過TAPD，問題記錄的格式和字段被設(shè)置為固定的格式和規(guī)范，就可以從不同角度，對問題進行統(tǒng)計和分析。

圖8：問題分類

圖9：TAPD 缺陷模塊使用示例

對于已經(jīng)解決的問題，通過 TAPD“報表”結(jié)合規(guī)定時間內(nèi)發(fā)布數(shù)據(jù)和線上問題數(shù)據(jù)的綜合數(shù)據(jù)分析，得出相關(guān)結(jié)論，制定有針對性的改進措施，生成 TAPD“項目報告”同步項目組成員，避免再次發(fā)生。

2.研發(fā)自測質(zhì)量提升

軟件的質(zhì)量是在整個研發(fā)過程中逐步形成的，離不開 QA 團隊，但只靠 QA 團隊關(guān)注肯定是不夠的，開發(fā)也要增強自測的意識。另外，為了縮短研發(fā)交付周期，對于一些簡單的日常和項目需求，我們采用了開發(fā)自測+產(chǎn)品驗收后直接上線的模式。

“測試左移”、“發(fā)現(xiàn)問題漏斗模型”等概念大家可能都聽說過，但真正讓“測試左移”落地并不容易。特別是開始的時候，測試團隊經(jīng)常碰到經(jīng)過自開發(fā)測后的提測需求，連冒煙用例都不會通過的狀況，只能把程序打回。這樣既影響交付，還造成了開發(fā)和測試同學(xué)之間的關(guān)系緊張。

后來，測試同學(xué)把研發(fā)自測用例都導(dǎo)入到TAPD用例中，創(chuàng)建研發(fā)自測執(zhí)行計劃，研發(fā)同學(xué)聯(lián)調(diào)后運行自測用例并在TAPD上標(biāo)注結(jié)果，提測時測試同學(xué)會首先在TAPD上檢查自測用例執(zhí)行情況，全部通過后再接收測試。

圖10：TAPD 測試計劃示例

從今年1月份開始，部分重點項目加入了提測時show case、上線前統(tǒng)一開會驗收的環(huán)節(jié)，有效地降低了測試階段bug個數(shù)，現(xiàn)在我們在測試階段發(fā)現(xiàn)的 Bug 相較從前減少了約 35%。

第三階段 業(yè)務(wù)擴張期

需要更精細化的管理

經(jīng)過一段時間的探索，對于未來一段時間內(nèi)的業(yè)務(wù)模式和技術(shù)方向，我們有了比較清晰的定位，隊伍人數(shù)也比最開始增長了幾倍。

上文提到，之前我們一直是用 TAPD 的“看板”功能進行需求、任務(wù)和項目的迭代管理。隨著使用的逐漸深入，我們發(fā)現(xiàn) TAPD 看板主要是針對團隊輕量級協(xié)作。但隨著團隊的壯大和職責(zé)細化，清晰地看到團隊里每個成員當(dāng)前的工作進度也變得很重要，不僅要管理需求也要管理人員，而且管理的方式也需要更加場景化、精細化。

因此，我們將看板的使用方式調(diào)整為對團隊事務(wù)的管理，對整體研發(fā)流程和項目質(zhì)量的管理轉(zhuǎn)為使用“迭代”，團隊人員之間的工作安排和進度管理使用“甘特圖”，這樣不同的項目和團隊都可以靈活地根據(jù)自己的場景和需求添加字段滿足自己的管理需求，比如業(yè)務(wù)線、需求來源、價值模型、優(yōu)先級、項目角色、關(guān)鍵時間節(jié)點、線上故障級別、人均有效 bug 數(shù)、需求變更次數(shù)等等。

日常和項目需求的狀態(tài)均有以下幾種：

圖11：需求狀態(tài)流轉(zhuǎn)

這一階段需求實施具體流程如下圖所示：

圖12：需求實施流程

每次需求PK前都會新建兩個迭代，雙周的日常迭代和四周的項目迭代，PK通過的需求進行相應(yīng)迭代，項目需求還會拆解成任務(wù)，全部任務(wù)完成更新狀態(tài)為已上線。

改用“迭代”后我們的月平均產(chǎn)出項目比“看板”階段提升了約25%。

下圖截取了某一個項目迭代，迭代中的需求全部完成后我們就把迭代關(guān)閉：

圖13：TAPD 項目迭代使用示例

改進后使用TAPD“甘特圖”在需求PK時可以查看個人名下的需求，Team Leader也可以隨時查看下屬的任務(wù)和任務(wù)完成情況。

圖14：TAPD 甘特圖使用示例

此外，隨著跨團隊、跨部門的工作越來越多，我們也非常重視對全員項目流程管理意識的培養(yǎng)。

大交通技術(shù)團隊目前沒有專職 PM，所有項目的 PM 均為產(chǎn)品或技術(shù)兼職。為了保障所有日常和項目均能如期甚至提前完成、更好地讓項目流程落地以及優(yōu)化項目流程，由兩名技術(shù)人員兼任 PMO，針對項目流程中的問題對研發(fā)和產(chǎn)品同學(xué)進行分享和培訓(xùn)，提升研發(fā)人員的項目管理能力和產(chǎn)品同學(xué)的流程意識。

制定規(guī)范的項目流程并落地、每個環(huán)節(jié)負責(zé)人都高質(zhì)量地交付給下一個環(huán)節(jié)的負責(zé)人，是實現(xiàn)項目持續(xù)集成和持續(xù)交付的基礎(chǔ)。

第四階段 未來展望

持續(xù)探索敏捷+DevOps 的整合之道

大交通團隊經(jīng)過一年多的摸索，在研發(fā)質(zhì)量管理上積累了一定的實踐經(jīng)驗，但我們才剛剛啟程。

在這個過程中，我們的研發(fā)流程和項目質(zhì)量管理方面的很多理念和方法都借助于 TAPD 實現(xiàn)落地。小結(jié)一下我們在不同階段使用 TAPD 的功能如下圖所示：

圖15：不同階段對 TAPD 的使用方式

隨著業(yè)務(wù)系統(tǒng)越來越復(fù)雜，對測試人員和質(zhì)量體系的要求也會越來越高，我們需要持續(xù)探索研發(fā)效能的統(tǒng)計度量以及敏捷研發(fā)和 DevOps 的整合之道，使開發(fā)、運維、質(zhì)量管理實現(xiàn)真正的一體化。相信這個過程也不會缺少與 TAPD 的密切合作。

近期，我們的 PMO 團隊設(shè)計了基于 TAPD ?API 的初版PMO系統(tǒng)，目前主要統(tǒng)計產(chǎn)出和延期率，期望給各Team Leader提供一些數(shù)據(jù)展示和數(shù)據(jù)分析。比如一個迭代究竟接多少項目需求、多少日常需求才是合理的？我們會計算已完成項目和日常的平均人日，和每個迭代的項目和日常個數(shù)以及到期完成情況供各Team Leader作為參考。此系統(tǒng)目前還不完善，我們也在逐步優(yōu)化中。

圖16: 項目數(shù)據(jù)統(tǒng)計

另外，我們還會將 TAPD 和大交通內(nèi)部 DevOps 平臺打通，實現(xiàn)業(yè)務(wù)、開發(fā)、運維、質(zhì)保的全流程自動化。

最后，感謝 TAPD 這款工具及官方團隊給予我們的支持，希望在未來更加深度的合作中，馬蜂窩和 TAPD 都能為更多團隊的研發(fā)效率和項目質(zhì)量提供更多更好的經(jīng)驗。

總結(jié)

以上是生活随笔為你收集整理的从0到1，马蜂窝大交通团队如何构建高效研发流程体系？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。