微保在敏捷研发管理中的实践

freedom1 · 发表于 2020-9-18 09:56

EDA365欢迎您登录！

您需要登录才可以下载或查看，没有帐号？注册

x

创业团队在组建和扩张时如何高效协作，是组织要解决的大难题。明确目标、确保成员清晰知道如何配合、过程中管理好干系人预期、关键环节做好变更管理和风险把控、采用增量迭代的敏捷项目管理机制、确保“做对的事情”和“把事情做对”，是微保业务快速、稳步发展的关键。
01背景

1、互联网保险的机遇与挑战
1) 机遇

2018年中国保险行业保费全球第二，保险深度（保费/GDP）4.57%，排名全球36位。保险密度（人均保费），排名全球46位。中国保民意识逐渐苏醒，保险市场增速20%+。互联网保民累计2.2亿用户，保民年龄年轻化，首单投保平均28.7岁。中国保险行业仍有很大的发展空间。
2) 挑战

2017年~2018年监管从严，对于违规开发产品，偏离保险本源，挑战监管底线的行为，做了明确严格的规定。让野蛮生长的保险行业回归第一性保障原理，确保行业更加健康的发展。

互联网保险相比传统保险的优势在于：保费低，投保便捷，理赔方便，保单管理容易。但保险始终复杂，涉及续保，退保，理赔，定价，风控等。对用户来讲，产品难懂，学习成本高，保单常常厚得像一本书。诸如此类的问题，都为产品的开发和运营工作带来非常大的挑战：需求不断变化、新需求被识别、变更成为常态。需要配套合适的敏捷研发管理，才能确保业务稳定发展。

2、微保面临的挑战
微保在过去的两年中，主要面临来自外部和内部的两方面的挑战。

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投入等。
技术债务：监控，平台化，规范化，容灾降级等。

敏捷研发管理是一个很大的主题，今天的分享要讲透是不够的，只是简单分享了我们在这个过程中遇到的几个关键问题。微保是一个互联网保险行业的新兵，在实践中其实都在摸着石头过河。希望大家可以多交流。探索互联网保险敏捷研发的成功模式。

turth · 发表于 2020-9-18 10:49

2018年中国保险行业保费全球第二，保险深度（保费/GDP）4.57%，排名全球36位。保险密度（人均保费），排名全球46位。中国保民意识逐渐苏醒，保险市场增速20%+。互联网保民累计2.2亿用户，保民年龄年轻化，首单投保平均28.7岁。中国保险行业仍有很大的发展空间。

帐号		自动登录	找回密码
密码			注册

微保在敏捷研发管理中的实践

EDA365欢迎您登录！

推荐内容 /1