找回密码
 注册
关于网站域名变更的通知
查看: 351|回复: 1
打印 上一主题 下一主题

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

[复制链接]
  • TA的每日心情
    开心
    2019-11-21 15:51
  • 签到天数: 1 天

    [LV.1]初来乍到

    跳转到指定楼层
    1#
    发表于 2020-9-18 09:56 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

    EDA365欢迎您登录!

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

    x
    创业团队在组建和扩张时如何高效协作,是组织要解决的大难题。明确目标、确保成员清晰知道如何配合、过程中管理好干系人预期、关键环节做好变更管理和风险把控、采用增量迭代的敏捷项目管理机制、确保“做对的事情”和“把事情做对”,是微保业务快速、稳步发展的关键。
    ' y, _( x7 S! W& o+ U3 b1 E01背景
    & q, G. g# y# f% O) \( Y9 h6 g
    ' s& W% G/ `+ k% n; g1、互联网保险的机遇与挑战
      @  E  u- q& |4 y! f1) 机遇
    0 q! U% F# @6 k+ U; m! g1 [5 d
    $ B$ [7 l7 Q* Q2 R& V9 q9 W2018年中国保险行业保费全球第二,保险深度(保费/GDP)4.57%,排名全球36位。保险密度(人均保费),排名全球46位。中国保民意识逐渐苏醒,保险市场增速20%+。互联网保民累计2.2亿用户,保民年龄年轻化,首单投保平均28.7岁。中国保险行业仍有很大的发展空间。
    2 X  R9 D2 F- |3 o8 [3 V1 @2) 挑战0 A5 U3 E$ g4 `: S

    ) b* C4 y/ g) o( U, l4 [2017年~2018年监管从严,对于违规开发产品,偏离保险本源,挑战监管底线的行为,做了明确严格的规定。让野蛮生长的保险行业回归第一性保障原理,确保行业更加健康的发展。! [6 f- k5 J; y5 _! S& O& G/ r5 e( P) F
    5 S7 b( X* Z! U' o
    互联网保险相比传统保险的优势在于:保费低,投保便捷,理赔方便,保单管理容易。但保险始终复杂,涉及续保,退保,理赔,定价,风控等。对用户来讲,产品难懂,学习成本高,保单常常厚得像一本书。诸如此类的问题,都为产品的开发和运营工作带来非常大的挑战:需求不断变化、新需求被识别、变更成为常态。需要配套合适的敏捷研发管理,才能确保业务稳定发展。8 f( w7 G- {6 M& n# ?" _- b
    : t( D( l& C  X# H* ~( z$ K
    2、微保面临的挑战/ A* K$ g1 i3 c1 p7 b
    微保在过去的两年中,主要面临来自外部和内部的两方面的挑战。  \7 M4 E0 D9 @& D! q- D1 ~

    5 B/ I9 N) Y2 m. C) c6 l1 E2 r# _, u4 f5 z1 s1 v
    1) 内部:/ c7 z' B  v9 S& b
    " g' n/ e2 p% Y& `
    如何确保正确的业务方向,管理好股东预期,组建团队,搭建基础,设置合适业务的组织架构,确定产品承载形态,在支持业务的同时,不断完善技术架构,解决技术债务。2 \  s6 u! J" d7 D
    2) 外部:
    ! h8 O, {6 C- ]2 |& J( Q2 J2 }8 m9 ]3 F
    如何与腾讯生态深度合作,如何处理好与保险公司的关系,确保业务符合监管要求,如何打磨产品,确保用户对保险产品充分理解,如何做好用户教育,如何与友商竞争。% [; a" _' v8 a4 k- |5 S- N6 n4 I- Y, G

    7 T$ W- o( }  ~早期我们希望打造一款爆款产品,但实际用户的保险诉求是丰富多样的,业务也随之调整。考虑到保险是低频产品,借助小程序的崛起,我们采用小程序来承载产品。在产品介绍上,反复打磨文案几十次,力求向用户讲明白保险产品特点,责任,投保条件等。投入用户教育内容板块,帮助用户学习保险知识,更好的为自己和家人配置保险。这些都是微保在创业期间需要不断优化和解决的难题。本文更多从项目管理角度出发,探讨研发项目管理在微保的敏捷落地,对一些关键问题的思考,以及解决这些问题的经验和教训。# W3 q2 p9 h1 g9 ^# C" }. D/ ^

    8 z$ |9 P6 j+ I$ S& Y2 \02微保的敏捷历程, x+ o5 o6 p6 w* {6 [# `9 z# z
    : F+ M5 R& H) g9 W# F! s
    1、适应“需要”,完善敏捷
    $ w& N  Z2 }. o! a+ }0 x7 A  P7 j6 v( b: Y0 K
    + G2 t9 ?1 s$ m: C, s* L' [
      c* z; v4 O0 g% D# z& T, ?) E
    按照组织在不同时期的需要,微保的敏捷研发管理大体分为三个阶段:
    ( u" q2 N; _1 D. B0 m) Q1)形成期:
    1 s3 x7 c- E9 d( a4 j2 S* S4 u
    4 }* E' ~4 e- z! L5 H0 s0 T4 g" k从团队组建到迭代上线。需要搭建基础,启动内部迭代,发布上线。这期间组织需要解决的问题是:做好风险管控的同时,高效的协作。5 b% k, H; K/ ]- ^. H3 E" ?  y1 e

    # U; B  e+ q+ m2017年5月初,技术+产品的团队大概50+人,那时正处于搭建基础的阶段,虽然每个人都有事做,但是大家既没有节奏也没有目标。为此我们召集骨干反复讨论并获得高层批准,定下目标:完成一个可以体验的产品雏形,以车险投保全流程走通为初期目标,定义了迭代节奏,产品story模板,状态迁移等流程和规范。; Y  K# _7 x" H9 H

    8 x% L. D; C: b  Q从此大家真正的开始协作起来,团伙变身团队:需求到设计,开发到测试,迭代到上线,各个环节都明确了过程和交付物。虽然期间也不断的踩各种坑,来自小程序本身的坑,来自保司上下游耦合的坑,在这样边踩坑边填坑的过程中,底层系统逐渐完善和稳定起来。经历6个月的内部迭代,11月2日,微保首款百万医疗险正式登录微信九宫格,迭代1.0正式发布。首款产品以流畅的投保体验和产品特色征服了用户,在保险行业引起了巨大的反响。& }+ B2 }) n& R* m( ?3 u9 D6 {7 m

    * ^4 A$ r* V- _/ H$ ^# R( d2)震荡期:
    ! [, O0 c2 ], f( X2 Z
    ) r* F- ?6 K! q随着业务的发展和团队的扩张,产品线迅速增加,项目开始出现资源争夺,资源匹配不均,不同项目间重复建设。这期间组织需要解决的问题是:找到适合多业务并行的项目管理方法,顶住业务压力,并解决因此产生的技术债务,确保资源投入在正确的项目上。- I7 M7 E- F0 M3 ^1 s
    . C0 Z, X- J+ [' {+ x& K
    研发管理方面,根据实际情况,做了多轮的研发流程优化,在优先级,评价标准,评价机制方面做了较多的优化和探索。在存量产品已经不少的情况下,新的项目的展开也受到集团审核的挑战。如何确保新业务与存量业务不冲突?新项目的长期用户价值是什么?长期赔付风险如何考虑?保险服务质量如何保障?产品战略布局如何思考?等等一系列问题,都有待解决。# j+ \9 N4 f% [: f& ]- M
    6 z# x  K4 A/ P* C
    针对这些问题,我们有三个方面的经验:8 P2 s: u' S& ?: J
    在研发管理工作上,着眼于让有限的资源投入到更有价值的业务上,工作的重心由初期主抓进度和质量逐渐转变为聚焦产品价值,人力和成本上;: |# X5 r% d* N2 x
    在迭代节奏上,我们从最初的双周迭代,一步步转向现在单双周兼有的敏捷的迭代,并不断review不同项目特点,选取适合的迭代节奏;
    8 @' W7 k/ m+ w8 l4 G1 w审核线流程优化,除了规范化审核材料以外,不断梳理审核要点,建立沟通机制和通道,建立高管内审的机制,保证了审核工作的顺利展开。
    ( q; D" P0 R9 c& b/ J" {9 I
    5 ~7 l5 V/ d  E- _8 r8 P, B3)规范期:
    6 g8 H  \+ w, q" Y% P1 d% G! Y
    " r1 i/ D0 |& s形成期和震荡期的5个关键问题,从19年开始进入不断优化和完善的过程。尤其是在如何确保做正确的事情方面。
    ! {# k1 z9 D& ^. F
    - j% |) Y  `2 S# \3 ~* [/ N早期研发管理工作仅关注封版后的过程,到规范期后,项目管理工作开始全流程管控,通过严格的立项准入机制,项目管理工作从最初特性封版到上线,转变为从idea产生即介入,全流程关注并透明进展,确保项目符合进度规划。+ |* F$ B" M5 v. T* l
    ' I- i) Y" x( z: P5 `7 a
    立项,成为研发项目管理初期的最关键环节。立项意义具体这里不赘述。实践中立项经常会被业务需求方抵触,这不可避免,因为立项工作会带来工作量。所以立项工作需要做好引导和机制配套,尽可能简化流程,完善立项checklist,帮助团队和组织做好立项。规范的立项让团队对齐项目价值,明确可能的风险和投入,确保团队最初的投入是正确的。
    8 _: w; z. H- Y' h6 s3 d4 K) p8 T) ]: Y3 Y0 I
    2、敏捷闭环,环环相扣  {* S2 a0 O8 Y( ]+ [& z- r4 j2 _! G! x
    微保的敏捷工作一直是围绕两个闭环:需求环和研发环。  w9 J: d$ k( z
    + l4 }9 V8 i7 z9 _

    * c2 {+ i; X* q2 u1 Q: Z9 q5 B7 p7 w, f5 K5 }- Y7 T4 A3 A2 g
    1)需求环:做正确的事情
    * s4 v9 J! \) {  y- |! H! O& [' O3 L: A4 `  k; i' c
    主要解决需求问题,起点是需要:市场或用户的需要,业务布局的需要。需要往往是不清晰的,需要团队一起不断讨论,确定好目标。目标包含条款,保险费率,合规要求,投保条件,产品定位,保护目标人群等等。在确立了目标以后,才真正是产品的方案开发和形态确认,交付物是明晰的需求。需求进行一步经过评审获得大家一致的理解和确认,然后进入下一个研发环。! C, W; ~6 `; d/ `4 u- p
    3 S% j5 }  f9 |" y
    2)研发环:把事情做正确8 Q! ?2 i6 u$ y$ r" s6 |

    . I* S' C  {5 R5 Q4 G( b* q进入研发环的需求是明确的,可以执行的。包含架构设计,编码开发,保司联调,功能及系统测试,性能测试,发布验证,体验验收。上线配套的监控和数据报表,为决策层提供决策支持。如有缺陷,则修复改进再发版或再迭代。如根据报表发现业务存在设计问题,或不符合用户需要,则进行特性调整,进入轻量级需求环。重复迭代,不断完善产品。
    ( p* ~9 D+ G, k7 Y% \; F9 k/ J& r- _9 i( V3 k
    在展开项目管理的时候,我们遵循敏捷(Agile)增量迭代,采用Prince2强调的原则和流程框架,再结合Scrum的实操,形成微保自己的敏捷套路。) \# X- b' s( O9 ~9 w% X" s
    2 Q% W# n1 K8 M4 X+ o1 M- A
    为保持需求信息一致性,我们使用TAPD来承载微保敏捷实践中需求的管理和实现。每个月有900+story通过Tapd来进行生产和流转,线上和线下问题的跟进也通过Tapd来进行跟进和管理。4 s  }5 Y) l! }) Y+ X' C7 L7 J

    * \3 A+ q  i, ^3 z' m# N通过梳理,不断优化敏捷闭环中各个阶段的工作,微保C端产品发布频率从18年平均22次/月,提升到19年39次/月。效率提升了77%。3 p( m$ K# I( Q/ k* S/ U( A
    $ P6 C6 q2 A/ b$ u) N. ]( f

    ; j/ F. ^) X2 R' ^% y' ~, b0 j7 Y5 w, g% v& m" J/ n/ G- v
    03增量迭代和关键环节管控
    1 {$ g1 @! M8 |  W; B- f3 A: L4 _  H6 D* ~* G- `
    1、敏捷的核心
    ( |& W) w$ x$ Q; ~$ l" B# Z4 o微保的敏捷核心:增量迭代交付,满足组织“需要”,关键环节管控,解决业务“问题”。
    8 Q) q' `/ t1 B: X, [  B
    : }% X) [$ w) D$ o短周期增量迭代指的是我们有单周迭代、双周迭代以及紧急发布;关键环节是指立项环节、启动流程、内审外审流程,还有封版等重要环节。8 g( x; N/ F8 q0 W# k

    + d0 n2 ?+ N" k" g# M3 n6 `, G7 O9 z9 J# e' E0 K' p

    ) B2 Q$ h& @& n" d& Y0 J9 [  C我们的迭代和大多数互联网产品迭代一样,采用流水形式。这对团队配合要求极高,同一时间不同角色成员需要并行多个迭代。但流水让产品获得更快的交付,能够及时的调整,符合敏捷的思想,满足组织和业务的需要。/ l* H& X" k- }( K

    ' K5 ?" Y4 R% v2、组织的需要! a6 r0 K8 l  H/ {
    回顾前文提到的5大类问题,其实就是组织对研发管理的5类需要:
    8 F! q2 q0 m  W" G2 Q+ F$ y' [9 y高效协作的需要:通过流程机制让互动更主动,更有效,需求质量更高。) ^7 Q3 e* h  ?; u! @
    顶住业务压力的需要:一开始即做测试环境,迭代环境建设,包括持续集成等。采用微服务,尽量复用,要考虑通用性,平台化。
    5 c- T  _5 d, B做好风控的需要:除常规的法务,政策和业务安全检查机制外,要做好变更管理,确保变更的有效性,必要性和风险可控。5 E/ F( ]8 e" ?. g) T+ H
    线上服务质量的需要:解决技术债务,可测性,重复建设,监控不完善等问题,确保线上产品质量。
    . W+ f3 Q3 Y) Z2 p: v, r做正确的事情:通过价值立项,审核,全链路把控,深度复盘。确保每个环节的交付质量和时效。确保在执行中不偏离正确目标,总体风险可控。* v. w) X: e8 z; R

    5 q9 S5 ?. e+ G3 T. B" Z, t8 k7 M& D
    ; v- a( `5 [1 Q2 \; U4 X( \% o1 M* G1 C$ N( ]; X
    这里选取5个典型且容易被忽视的关键点分享给大家:
    1 [4 {- @/ @. a1 E8 L) X& }% ]3 D0 S
    1)团队协作:流程帮助团队更有效的沟通协作
    % y: E' @! J& e) q' E% S" H) L3 y* S, R7 e6 @' j
    迭代初期因缺少流程迭代无法有效进行。我们围绕贯穿迭代的需求,制定了项目迭代的流程。用TAPD把整个需求管理支撑起来。反复推敲,为产品迭代过程规划7个关键状态,形成模板,机制,并明确了各角色的工作职责。- o$ E9 [8 p1 u5 y

    ; h0 r6 g; |/ p' j/ ?0 w2 f  K' \0 l8 \5 s; L: ~
    . b% B- U0 k- e0 Y: i) p* R1 u
    针对需求的沟通漏损问题,我们强调双向沟通。除了产品同学向技术团队澄清需求以外,开发和测试同学也要进行需求反澄清。在多需求优先级无法判断的情况下,引入需求预审,排期会等关键会议,确保信息在初期能够充分的透明。
    3 {6 v% _! k3 z: v$ l5 h2 P+ O, T; n- u! H- s3 b4 X
    不要忽略体验的验收:验收工作非常重要,是产品与用户见面之前最后一次纠错机会。全面质量管理倡导全员参与,保障产品质量,完全依赖测试团队是不合理的。/ {4 z  H& C# I% _, F2 B& f

    " S/ T% W# e# J5 f2 }6 A有一个真实案例,某次开发把一个30万元保额的文案说明配成20万,在上线之前被一个经验丰富的保险同学发现,避免了问题被遗留到线上。$ P: q0 t: |8 F4 x5 j6 O
    0 l1 t, z+ j$ [  Q
    我们对类似的线上问题进行了复盘,建立了验收机制,让更多的角色参与到线上验收,形成了固化的验收机制,避免了类似问题的再次发生。3 E4 @  J5 z6 t* w1 O
    5 p' i0 I) \# }. @! m) [
    6 `6 X/ P* t- Z) w0 @" ^

    1 ~; s) M( o5 s2 ?2 n2)需求质量低:尝试寻找深层原因( f7 S/ {2 e3 a$ u

    " ?, o; i7 f& e* y- V- q& S0 l在一段时间内,需求质量成为引发技术和产品的矛盾点。我们尝试评价最好的需求和最差的需求。企图通过树立标杆,让需求都变得清晰,稳定,完备。虽然做了充分的推演,但当评选真正落地时,我们才发现评价成本非常高:除了心理障碍技术同学不愿意去评分以外,不同业务的技术评分标准也很难统一,导致评分最低的产品同学非常大的抵触,最终评分计划宣告失败。7 @1 r& L. z: Y8 \  U/ N; U7 H

    / m1 a  ?7 S; G
    ( |6 o+ b( S' ~6 T6 g2 ^  r8 @! n
    ; ^$ U+ f, t. ^0 @+ W5 |需求质量问题的本质是什么?考虑不完善,不充分。回归问题本身:以问题为导向,尝试去就事论事的改进,倡导大家进行迭代总结,不求需求清晰,稳定和完备,只求需求能够充分被理解。通过这样的措施,化解了需求质量问题带来的冲突和矛盾。& r* }- J& l, @4 @! v
      W5 \( I5 L8 b( g9 S
    具体来讲,有三点:
    - R2 ^5 f$ ]- L" z! N①迭代复盘:发版之后,项目经理按需组织大家聚集在一起,互相吐吐槽,讲讲怎么改进。把问题摆在桌面上,很容易能够理解为什么出问题。当然,只吐槽治标不治本。需要引导大家一起思考,形成可落地的,达成一致的改进方案。1 p( g& }! `4 ?+ ]1 `
    / M- X. @8 K# U5 Y
    ②需求的澄清和反澄清:往往团队可能没有意识到要做这个事情的重要性,这就需要项目经理介入去推动。技术团队(开发和测试),要进行反澄清。开发同学要对story分解task,测试同学需要明确的组织用例评审过程,进行反澄清。以确保产品,开发,测试对需求理解的一致性和完整性。在澄清的过程中,也可以对未考虑到的问题进行识别。有效的减少进入迭代以后的变更。3 X, [7 }% ~; x0 B
    $ k1 _5 ~: p- H" ]! Y- U" D) D  l
    ③加强沟通:尝试去度量业务方面的需求质量是无意义的,更多要以目标为导向,和团队在一起互相沟通,解决需求一致性和需求完善的问题。需求质量低的根源也往往来自高层。常见原因是时间紧张导致需求考虑不完善。项目经理也需要和产品、技术团队一起,理清投入和产出,管理高层预期。; d& F  ?. S1 Y6 H+ M1 z5 X
    - L; K: ]: q- i$ @- F# t
    3)变更管理:推动变更的合理化' S9 S% h( z4 q# q
    / n( [# G4 g& A7 y, t" A

    & g9 C0 h: ~9 z+ i6 b/ \3 p8 j& k4 ^7 d, S* F# f# {
    & {' P9 q1 e7 ^8 [$ {' g
    变化是客观存在的:业务复杂、时间短考虑不周、市场变化都会导致需求的变化。但有时变化可能是主观的:需求的提出者并没有想清楚为什么要变。甚至高层决策者可能自己也没有想清楚。团队需要给与决策者充分的决策依据也往往比较难。
    8 K, X& L$ Y! e* b8 I
    , I% [- j8 V" z这时,变更管理就显得格外重要。为了确保信息的一致性,我们强调变更评审,这是非常重要的环节。变更记录需要同步到Tapd,以便未来维护。当团队内部认为变更会带来风险,就需要进行例外管理,上升问题,上升至研发总监、质量总监以及产品总监层面。如果这个层面还没法达成一致,可能还要继续上升。问题上升前,需要准备充分的变更决策依据,这也倒逼团队把问题考虑得更清晰。这样就可以尽量确保变更是有效并且是有意义的。这个过程很微妙,有时候大家在讨论如何上升的过程中,就已经达成一致的结论了。8 b! O8 z# A( t- c% @
    " x6 t3 h/ h, Y( i6 T8 g1 l3 |
    变更中项目经理的角色如何扮演?在进行变更管理的时候,往往是产品和开发产生冲突的时候,需要进行一定的引导,我们实践中最有效的两个原则:
    & `# I. W5 I# i* c1 O帮产品争取合理的变更。
    - B" u0 u: b, J  y7 p帮开发挡住不合理的变更0 d0 F6 L+ i) u- O) I4 l* E
    合理的需求这里不再讨论,不合理的变更带来的风险和成本较高,要充分讨论,卷入有话语权的干系人,做正确的准确的决策。% D3 [0 o5 s( u
    0 R  R; P0 a: k( t  C
    4)产品可测性差:复杂上下游环境,多系统耦合
    , f! j; X4 V/ G$ x7 R" d5 J+ P4 g5 {. R
    可测性问题目前在行业里被提及的不够多,这一点有点遗憾。可测性低,测试场景就难以构造,测试就只能依赖于开发搭环境,造场景,测试效率低下。因此从一开始,测试团队在可测性方面就投入人力。当然,可测性的工作也离不开开发同学的支持和配合。
    9 H6 o" B/ c5 m) G6 `8 b5 m, j& x7 C6 r
    车险案例:传统车险需要自己构造数据,然后数据流要到中保协系统走一圈,再提供给测试。测试数据就像火柴,要验证火柴能不能点燃,必须要划一下,但划一下火柴就没了,测试数据非常稀缺,严重阻碍测试进度。
      ]9 `7 ?5 A) @; N: ]' b3 U( E. ?$ z
    ' O! o5 E  l9 K* A7 N9 x
    * {7 i' l8 ?$ ?/ y; w% o
    为了解耦保司,我们投入测试和开发人力联合做mock,梳理了测试数据流转的各过程,及可测性需求,在线上线下环境都支持了虚拟保险公司mock服务,并对业务数据做了逻辑隔离。处理了上下游环境,解决环境过于复杂的问题。测试数据构造变得非常简单,可以构造不同车型,不同价格,不同年限,不同责任的投保车辆。测试效率得到极大提高。100%覆盖到异常测试场景。线上的虚拟保司mock,也基本解决了线上验证需要找真实用户的问题。3 [" ~0 m8 h1 \; @6 `2 b6 d0 I
    1 r0 o2 m0 H/ Q! u
    5)做正确的事:全链路管控
    & m' C, @0 ^/ [# S) B- p. c& j  s/ `: A( ?5 q* `: _
    “这个需求很简单,怎么实现我不管,老板明天要看到”,这样的段子经常被技术同学拿来调侃产品。其实是业务侧顶不住老板压力的无奈写照。微保的产品从idea到上线过程中,也存在类似的问题。# j2 s+ X" e& n
    1 `+ g) @2 M# s$ F& }
    一款新的保险产品,要经历市场调研,保司合作,形态确认(费率,投保条件,保险责任,文案说明,风控设计),设计交互,需求细化等等环节才能真正进入开发阶段。而开发和测试阶段往往在整个产品生命周期中仅仅占很小一部分。4 `) V" d2 i* R/ [! o# I

    & ~0 ~8 z5 M4 J3 V9 K% O
    7 b1 [+ c4 x8 m9 ~, J6 }: P" O% T! r+ @- z9 ]! ^4 _
    如图所示,中间点是SFM(需求封版会议),往前即需求环,往后即研发环。需求环往往损耗时间较久,就会导致产品看起来迭代周期太长。我们初期在需求环的管控上做的不到位,业务侧同学也无法给出高层干系人合理的时间估计,这也是“需求排不上”、“研发效率低”背后的原因。2 v3 `8 {. d1 D  f
      U8 \% Z6 `) y/ o
    我们结合过去的项目经验,与业务侧深入分析,归纳整理出项目全周期中的关键节点。对各环节的合理时间进行预估,并将其整合成工具提供给业务同学。帮助业务同学更好的管理高层干系人的预期。也避免了产品开发中的反复和变更,让产品的生产过程更加可控。) @: x. ]0 ^0 `0 R6 M7 ?9 }

    - J2 [4 i; @+ }5 {5 T: z3、小结
    & c  i6 Q, ]! O2 P/ p微保的敏捷就是在不断的满足组织需要的过程中,让敏捷的各环节能够高效的运转,确保整体的高效交付。
    7 I/ I. ]3 @& y) j8 E3 @5 b, r3 b0 u% l' @3 m6 ~" H

    + \  Y. @+ v5 k% D: m) p. b) ?, F4 T
    通过定规范,做研发复盘,让团伙变成团队,组织高效协作起来。
    8 ^. G4 Y& m1 P! ?通过建平台,使用开源组组件开发通用框架,做好向上管理,顶住业务压力。- C0 @, r( ?0 o% h3 ?
    关键环节引入风控检查点,做好变更管理,整体上把控住了风险。0 q+ r+ z7 g4 o& A' O0 H1 ~
    通过技术专项,持续集成,可测性等工作,技术债务未导致严重线上事故。
    , [2 K- d8 |) O  o: W通过抓立项,全链路管控和业务复盘,确保项目一直是在做正确的事。: k' ^1 |" M+ T2 \* V
    04展望
    + U( @, p3 K5 i9 ?; P7 K$ l! n
    " E" D# g9 j3 D0 V回顾敏捷闭环,我们过去做的事情,和未来一直需要做下去的仍是两件事:做正确的事,把事情做正确。做正确的同时,还有一个隐含需求,就是快。具体来讲:  e' w0 L; e# Y4 @8 S! O/ q7 `/ N
    # h8 `0 Y+ b9 m
    1)协助组织做正确的事,并且在过程中确保一直在做正确的事。
    ! q' H3 x6 f$ H. a
    # x. r1 q5 Z# V价值立项:充分评估项目价值,确保项目值得做。
    / n* A  |2 n$ [! @  \2 b, R4 B聚焦业务:减少业务重复建设,推动业务统一规划。7 R4 A0 K' |8 d' c+ r
    深度复盘:传承经验教训,避免反复试错和高成本试错。
    - v+ U5 F5 x/ g4 O# I) c! B8 q' f  [7 ~) D! _7 P: |
    2)推进业务需求的落地,并高效的快速交付和反馈,帮助组织实现业务价值。) f# d' A* k* N1 V! Y; a2 ~. U; D
    9 E& g& _# L/ r
    度量体系:过程结果透明,可控,问题得到优化等。
    / @0 h0 N% D7 u! j; ^2 X# }持续交付:CI/CD成熟度、自动化,UT投入等。! a- L1 x2 \$ D* T$ n
    技术债务:监控,平台化,规范化,容灾降级等。
    ! ?& W% m4 \$ X& f5 E  t
    ; ]9 k/ ?* R( d9 r. p: K敏捷研发管理是一个很大的主题,今天的分享要讲透是不够的,只是简单分享了我们在这个过程中遇到的几个关键问题。微保是一个互联网保险行业的新兵,在实践中其实都在摸着石头过河。希望大家可以多交流。探索互联网保险敏捷研发的成功模式。
    ( y% Y/ n: {+ [4 Z; i
    & M- C! w; f' ^8 Q/ b
    " n3 P0 ~1 |/ j1 b* m; |; e- G

    该用户从未签到

    2#
    发表于 2020-9-18 10:49 | 只看该作者
    2018年中国保险行业保费全球第二,保险深度(保费/GDP)4.57%,排名全球36位。保险密度(人均保费),排名全球46位。中国保民意识逐渐苏醒,保险市场增速20%+。互联网保民累计2.2亿用户,保民年龄年轻化,首单投保平均28.7岁。中国保险行业仍有很大的发展空间。
    您需要登录后才可以回帖 登录 | 注册

    本版积分规则

    关闭

    推荐内容上一条 /1 下一条

    EDA365公众号

    关于我们|手机版|EDA365电子论坛网 ( 粤ICP备18020198号-1 )

    GMT+8, 2025-7-10 16:38 , Processed in 0.140625 second(s), 23 queries , Gzip On.

    深圳市墨知创新科技有限公司

    地址:深圳市南山区科技生态园2栋A座805 电话:19926409050

    快速回复 返回顶部 返回列表