微保在敏捷研發管理中的實踐

• 2019 年 12 月 3 日
• 筆記

創業團隊在組建和擴張時如何高效協作，是組織要解決的大難題。明確目標、確保成員清晰知道如何配合、過程中管理好乾系人預期、關鍵環節做好變更管理和風險把控、採用增量迭代的敏捷項目管理機制、確保「做對的事情」和「把事情做對」，是微保業務快速、穩步發展的關鍵。

01 背景

1、互聯網保險的機遇與挑戰

1) 機遇

2018年中國保險行業保費全球第二，保險深度（保費/GDP）4.57%，排名全球36位。保險密度（人均保費），排名全球46位。中國保民意識逐漸蘇醒，保險市場增速20%+。互聯網保民累計2.2億用戶，保民年齡年輕化，首單投保平均28.7歲。中國保險行業仍有很大的發展空間。

2) 挑戰

2017年~2018年監管從嚴，對於違規開發產品，偏離保險本源，挑戰監管底線的行為，做了明確嚴格的規定。讓野蠻生長的保險行業回歸第一性保障原理，確保行業更加健康的發展。

互聯網保險相比傳統保險的優勢在於：保費低，投保便捷，理賠方便，保單管理容易。但保險始終複雜，涉及續保、退保、理賠、定價、風控等。對用戶來講，產品難懂、學習成本高，保單常常厚得像一本書。諸如此類的問題，都為產品的開發和運營工作帶來非常大的挑戰：需求不斷變化、新需求被識別、變更成為常態。需要配套合適的敏捷研發管理，才能確保業務穩定發展。

2、微保面臨的挑戰

微保WeSure（以下簡稱「微保」）是騰訊首家控股的保險平台，攜手中國知名保險公司為用戶提供優質的保險服務。2017年11月2日，首款《百萬醫療險》上線微信錢包九宮格。在其後的兩年中，憑藉高效敏捷的研發管理，微保已經與24家知名保險公司合作，攜手打造了20多款訂製+嚴選保險產品。

微保在過去的兩年中，主要面臨來自外部和內部的兩方面的挑戰。

1) 內部：

如何確保正確的業務方向，管理好股東預期，組建團隊，搭建基礎，設置合適業務的組織架構，確定產品承載形態，在支援業務的同時，不斷完善技術架構，解決技術債務。

2) 外部：

如何與騰訊生態深度合作，如何處理好與保險公司的關係，確保業務符合監管要求，如何打磨產品、確保用戶對保險產品充分理解，如何做好用戶教育，如何與友商競爭。

早期我們希望打造一款爆款產品，但實際用戶的保險訴求是豐富多樣的，業務也隨之調整。考慮到保險是低頻產品，藉助小程式的崛起，我們採用小程式來承載產品。在產品介紹上，反覆打磨文案幾十次，力求向用戶講明白保險產品特點、責任、投保條件等。投入用戶教育內容板塊，幫助用戶學習保險知識，更好地為自己和家人配置保險。這些都是微保在創業期間需要不斷優化和解決的難題。本文更多從項目管理角度出發，探討研發項目管理在微保的敏捷落地，對一些關鍵問題的思考，以及解決這些問題的經驗和教訓。

02 微保的敏捷歷程

1、適應「需要」，完善敏捷

按照組織在不同時期的需要，微保的敏捷研發管理大體分為三個階段：

1）形成期：

從團隊組建到迭代上線。需要搭建基礎，啟動內部迭代，發布上線。這期間組織需要解決的問題是：做好風險管控的同時，高效地協作。

2017年5月初，技術+產品的團隊大概50+人，那時正處於搭建基礎的階段，雖然每個人都有事做，但是大家既沒有節奏也沒有目標。為此我們召集骨幹反覆討論並獲得高層批准，定下目標：完成一個可以體驗的產品雛形，以車險投保全流程走通為初期目標，定義了迭代節奏，產品story模板，狀態遷移等流程和規範。

從此大家真正的開始協作起來，團伙變身團隊：需求到設計，開發到測試，迭代到上線，各個環節都明確了過程和交付物。雖然期間也不斷地踩各種坑，來自小程式本身的坑，來自保司上下游耦合的坑，在這樣邊踩坑邊填坑的過程中，底層系統逐漸完善和穩定起來。經歷6個月的內部迭代，11月2日，微保首款百萬醫療險正式登錄微信九宮格，迭代1.0正式發布。首款產品以流暢的投保體驗和產品特色征服了用戶，在保險行業引起了巨大的反響。

2）震蕩期：

隨著業務的發展和團隊的擴張，產品線迅速增加，項目開始出現資源爭奪，資源匹配不均，不同項目間重複建設。這期間組織需要解決的問題是：找到適合多業務並行的項目管理方法，頂住業務壓力，並解決因此產生的技術債務，確保資源投入在正確的項目上。

研發管理方面，根據實際情況，做了多輪的研發流程優化，在優先順序、評價標準、評價機制方面做了較多的優化和探索。在存量產品已經不少的情況下，新的項目的展開也受到集團審核的挑戰。如何確保新業務與存量業務不衝突？新項目的長期用戶價值是什麼？長期賠付風險如何考慮？保險服務品質如何保障？產品戰略布局如何思考？等等一系列問題，都有待解決。

針對這些問題，我們有三個方面的經驗：

• 在研發管理工作上，著眼於讓有限的資源投入到更有價值的業務上，工作的重心由初期主抓進度和品質逐漸轉變為聚焦產品價值，人力和成本上；
• 在迭代節奏上，我們從最初的雙周迭代，一步步轉向現在單雙周兼有的敏捷的迭代，並不斷review不同項目特點，選取適合的迭代節奏；
• 審核線流程優化，除了規範化審核材料以外，不斷梳理審核要點，建立溝通機制和通道，建立高層內審的機制，保證了審核工作的順利展開。

3）規範期：

形成期和震蕩期的5個關鍵問題，從19年開始進入不斷優化和完善的過程。尤其是在如何確保做正確的事情方面。

早期研發管理工作僅關注封版後的過程，到規範期後，項目管理工作開始全流程管控，通過嚴格的立項准入機制，項目管理工作從最初特性封版到上線，轉變為從idea產生即介入，全流程關注並透明進展，確保項目符合進度規劃。

立項，成為研發項目管理初期的最關鍵環節。立項意義具體這裡不贅述。實踐中立項經常會被業務需求方抵觸，這不可避免，因為立項工作會帶來工作量。所以立項工作需要做好引導和機制配套，儘可能簡化流程，完善立項checklist，幫助團隊和組織做好立項。規範的立項讓團隊對齊項目價值，明確可能的風險和投入，確保團隊最初的投入是正確的。

2、敏捷閉環，環環相扣

微保的敏捷工作一直是圍繞兩個閉環：需求環和研發環。

1）需求環：做正確的事情

主要解決需求問題，起點是需要：市場或用戶的需要，業務布局的需要。需要往往是不清晰的，需要團隊一起不斷討論，確定好目標。目標包含條款、保險費率、合規要求、投保條件、產品定位、保護目標人群等等。在確立了目標以後，才真正是產品的方案開發和形態確認，交付物是明晰的需求。需求進行一步經過評審獲得大家一致的理解和確認，然後進入下一個研發環。

2）研發環：把事情做正確

進入研發環的需求是明確的，可以執行的。包含架構設計、編碼開發、保司聯調、功能及系統測試、性能測試、發布驗證、體驗驗收。上線配套的監控和數據報表，為決策層提供決策支援。如有缺陷，則修復改進再發版或再迭代。如根據報表發現業務存在設計問題，或不符合用戶需要，則進行特性調整，進入輕量級需求環。重複迭代，不斷完善產品。

在展開項目管理的時候，我們遵循敏捷（Agile）增量迭代，採用Prince2強調的原則和流程框架，再結合Scrum的實操，形成微保自己的敏捷套路。

為保持需求資訊一致性，我們使用TAPD來承載微保敏捷實踐中需求的管理和實現。每個月有900+story通過TAPD來進行生產和流轉，線上和線下問題的跟進也通過TAPD來進行跟進和管理。

通過梳理，不斷優化敏捷閉環中各個階段的工作，微保C端產品發布頻率從18年平均22次/月，提升到19年39次/月。效率提升了77%。

03 增量迭代和關鍵環節管控

1、敏捷的核心

微保的敏捷核心：增量迭代交付，滿足組織「需要」，關鍵環節管控，解決業務「問題」。

短周期增量迭代指的是我們有單周迭代、雙周迭代以及緊急發布；關鍵環節是指立項環節、啟動流程、內審外審流程，還有封版等重要環節。

我們的迭代和大多數互聯網產品迭代一樣，採用流水形式。這對團隊配合要求極高，同一時間不同角色成員需要並行多個迭代。但流水讓產品獲得更快的交付，能夠及時地調整，符合敏捷的思想，滿足組織和業務的需要。

2、組織的需要

回顧前文提到的5大類問題，其實就是組織對研發管理的5類需要：

• 高效協作的需要：通過流程機制讓互動更主動、更有效，需求品質更高。
• 頂住業務壓力的需要：一開始即做測試環境，迭代環境建設，包括持續集成等。採用微服務，盡量復用，要考慮通用性、平台化。
• 做好風控的需要：除常規的法務，政策和業務安全檢查機制外，要做好變更管理，確保變更的有效性，必要性和風險可控。
• 線上服務品質的需要：解決技術債務、可測性、重複建設、監控不完善等問題，確保線上產品品質。
• 做正確的事情：通過價值立項、審核、全鏈路把控、深度復盤，確保每個環節的交付品質和時效。確保在執行中不偏離正確目標，總體風險可控。

這裡選取5個典型且容易被忽視的關鍵點分享給大家：

1）團隊協作：流程幫助團隊更有效的溝通協作

迭代初期因缺少流程迭代無法有效進行。我們圍繞貫穿迭代的需求，制定了項目迭代的流程。用TAPD把整個需求管理支撐起來。反覆推敲，為產品迭代過程規劃7個關鍵狀態，形成模板、機制，並明確了各角色的工作職責。

針對需求的溝通漏損問題，我們強調雙向溝通。除了產品同學向技術團隊澄清需求以外，開發和測試同學也要進行需求反澄清。在多需求優先順序無法判斷的情況下，引入需求預審，排期會等關鍵會議，確保資訊在初期能夠充分的透明。

不要忽略體驗的驗收：驗收工作非常重要，是產品與用戶見面之前最後一次糾錯機會。全面品質管理倡導全員參與，保障產品品質，完全依賴測試團隊是不合理的。

有一個真實案例，某次開發把一個30萬元保額的文案說明配成20萬，在上線之前被一個經驗豐富的保險同學發現，避免了問題被遺留到線上。

我們對類似的線上問題進行了復盤，建立了驗收機制，讓更多的角色參與到線上驗收，形成了固化的驗收機制，避免了類似問題的再次發生。

2）需求品質低：嘗試尋找深層原因

在一段時間內，需求品質成為引發技術和產品的矛盾點。我們嘗試評價最好的需求和最差的需求。企圖通過樹立標杆，讓需求都變得清晰、穩定、完備。雖然做了充分的推演，但當評選真正落地時，我們才發現評價成本非常高：除了心理障礙技術同學不願意去評分以外，不同業務的技術評分標準也很難統一，導致評分最低的產品同學非常大的抵觸，最終評分計劃宣告失敗。

需求品質問題的本質是什麼？考慮不完善，不充分。回歸問題本身：以問題為導向，嘗試去就事論事的改進，倡導大家進行迭代總結，不求需求清晰，穩定和完備，只求需求能夠充分被理解。通過這樣的措施，化解了需求品質問題帶來的衝突和矛盾。

具體來講，有三點：

①迭代復盤：發版之後，項目經理按需組織大家聚集在一起，互相吐吐槽，講講怎麼改進。把問題擺在桌面上，很容易能夠理解為什麼出問題。當然，只吐槽治標不治本。需要引導大家一起思考，形成可落地的，達成一致的改進方案。

②需求的澄清和反澄清：往往團隊可能沒有意識到要做這個事情的重要性，這就需要項目經理介入去推動。技術團隊（開發和測試），要進行反澄清。開發同學要對Story分解Task，測試同學需要明確的組織用例評審過程，進行反澄清。以確保產品、開發、測試對需求理解的一致性和完整性。在澄清的過程中，也可以對未考慮到的問題進行識別，有效地減少進入迭代以後的變更。

③加強溝通：嘗試去度量業務方面的需求品質是無意義的，更多要以目標為導向，和團隊在一起互相溝通，解決需求一致性和需求完善的問題。需求品質低的根源也往往來自高層。常見原因是時間緊張導致需求考慮不完善。項目經理也需要和產品、技術團隊一起，理清投入和產出，管理高層預期。

3）變更管理：推動變更的合理化

變化是客觀存在的：業務複雜、時間短考慮不周、市場變化都會導致需求的變化。但有時變化可能是主觀的：需求的提出者並沒有想清楚為什麼要變。甚至高層決策者可能自己也沒有想清楚。團隊需要給與決策者充分的決策依據也往往比較難。

這時，變更管理就顯得格外重要。為了確保資訊的一致性，我們強調變更評審，這是非常重要的環節。變更記錄需要同步到TAPD，以便未來維護。當團隊內部認為變更會帶來風險，就需要進行例外管理，上升問題，上升至研發總監、品質總監以及產品總監層面。如果這個層面還沒法達成一致，可能還要繼續上升。問題上升前，需要準備充分的變更決策依據，這也倒逼團隊把問題考慮得更清晰。這樣就可以盡量確保變更是有效並且是有意義的。這個過程很微妙，有時候大家在討論如何上升的過程中，就已經達成一致的結論了。

變更中項目經理的角色如何扮演？在進行變更管理的時候，往往是產品和開發產生衝突的時候，需要進行一定的引導，我們實踐中最有效的兩個原則：

• 幫產品爭取合理的變更。
• 幫開發擋住不合理的變更

合理的需求這裡不再討論，不合理的變更帶來的風險和成本較高，要充分討論，捲入有話語權的干係人，做正確的準確的決策。

4）產品可測性差：複雜上下游環境，多系統耦合

可測性問題目前在行業里被提及得不夠多，這有點遺憾。可測性低，測試場景就難以構造，測試就只能依賴於開發搭環境，造場景，測試效率低下。因此從一開始，測試團隊在可測性方面就投入人力。當然，可測性的工作也離不開開發同學的支援和配合。

車險案例：傳統車險需要自己構造數據，然後數據流要到中保協系統走一圈，再提供給測試。測試數據就像火柴，要驗證火柴能不能點燃，必須要劃一下，但劃一下火柴就沒了，測試數據非常稀缺，嚴重阻礙測試進度。

為了解耦保司，我們投入測試和開發人力聯合做mock，梳理了測試數據流轉的各過程，及可測性需求，在線上線下環境都支援了虛擬保險公司mock服務，並對業務數據做了邏輯隔離。處理了上下游環境，解決環境過於複雜的問題。測試數據構造變得非常簡單，可以構造不同車型，不同價格，不同年限，不同責任的投保車輛。測試效率得到極大提高。100%覆蓋到異常測試場景。線上的虛擬保司mock，也基本解決了線上驗證需要找真實用戶的問題。

5）做正確的事：全鏈路管控

「這個需求很簡單，怎麼實現我不管，老闆明天要看到」，這樣的段子經常被技術同學拿來調侃產品。其實是業務側頂不住老闆壓力的無奈寫照。微保的產品從idea到上線過程中，也存在類似的問題。

一款新的保險產品，要經歷市場調研、保司合作、形態確認（費率、投保條件、保險責任、文案說明、風控設計）、設計交互、需求細化等等環節才能真正進入開發階段。而開發和測試階段往往在整個產品生命周期中僅僅占很小一部分。

如圖所示，中間點是SFM（需求封版會議），往前即需求環，往後即研發環。需求環往往損耗時間較久，就會導致產品看起來迭代周期太長。我們初期在需求環的管控上做的不到位，業務側同學也無法給出高層干係人合理的時間估計，這也是「需求排不上」、「研發效率低」背後的原因。

我們結合過去的項目經驗，與業務側深入分析，歸納整理出項目全周期中的關鍵節點。對各環節的合理時間進行預估，並將其整合成工具提供給業務同學。幫助業務同學更好的管理高層干係人的預期。也避免了產品開發中的反覆和變更，讓產品的生產過程更加可控。

3、小結

微保的敏捷就是在不斷的滿足組織需要的過程中，讓敏捷的各環節能夠高效的運轉，確保整體的高效交付。

• 通過定規範，做研發復盤，讓團伙變成團隊，組織高效協作起來。
• 通過建平台，使用開源組組件開發通用框架，做好向上管理，頂住業務壓力。
• 關鍵環節引入風控檢查點，做好變更管理，整體上把控住了風險。
• 通過技術專項、持續集成、可測性等工作，技術債務未導致嚴重線上事故。
• 通過抓立項，全鏈路管控和業務復盤，確保項目一直是在做正確的事。

04 展望

回顧敏捷閉環，我們過去做的事情，和未來一直需要做下去的仍是兩件事：做正確的事，把事情做正確。做正確的同時，還有一個隱含需求，就是快。具體來講：

1）協助組織做正確的事，並且在過程中確保一直在做正確的事。

價值立項：充分評估項目價值，確保項目值得做。

聚焦業務：減少業務重複建設，推動業務統一規劃。

深度復盤：傳承經驗教訓，避免反覆試錯和高成本試錯。

2）推進業務需求的落地，並高效的快速交付和回饋，幫助組織實現業務價值。

度量體系：過程結果透明、可控，問題得到優化等。

持續交付：CI/CD成熟度、自動化、UT投入等。

技術債務：監控、平台化、規範化、容災降級等。

敏捷研發管理是一個很大的主題，今天的分享要講透是不夠的，只是簡單分享了我們在這個過程中遇到的幾個關鍵問題。微保是一個互聯網保險行業的新兵，在實踐中其實都在摸著石頭過河。希望大家可以多交流，共同探索互聯網敏捷研發的成功模式。

TAPD思享匯

是由騰訊敏捷協作平台舉辦的分享沙龍。匯聚行業精英，探索敏捷協作趨勢，期望為企業搭建交流平台。您可以與業界同仁共同探討研發工程實踐經驗，助力企業提升研發效能、創造更大價值。

 推薦閱讀 

點擊圖片即可閱讀全文