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

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

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

    [LV.1]初来乍到

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

    EDA365欢迎您登录!

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

    x
    创业团队在组建和扩张时如何高效协作,是组织要解决的大难题。明确目标、确保成员清晰知道如何配合、过程中管理好干系人预期、关键环节做好变更管理和风险把控、采用增量迭代的敏捷项目管理机制、确保“做对的事情”和“把事情做对”,是微保业务快速、稳步发展的关键。: A4 I7 q3 [- r7 G, J) r
    01背景
    ' c# A7 @" \% K2 r/ g$ O9 l% [3 K! O& A
    1、互联网保险的机遇与挑战
    6 R% b4 o2 n- x4 x4 c1) 机遇
    / ~7 P; c) F9 K1 {4 g) S% ^# C
    6 d2 Y- y- C. }9 |) |- C2018年中国保险行业保费全球第二,保险深度(保费/GDP)4.57%,排名全球36位。保险密度(人均保费),排名全球46位。中国保民意识逐渐苏醒,保险市场增速20%+。互联网保民累计2.2亿用户,保民年龄年轻化,首单投保平均28.7岁。中国保险行业仍有很大的发展空间。8 [1 W1 o0 s8 E! t
    2) 挑战
    , ?6 G, ^* W8 \; ?# l/ |6 a" c$ X. r- t7 A& A& R
    2017年~2018年监管从严,对于违规开发产品,偏离保险本源,挑战监管底线的行为,做了明确严格的规定。让野蛮生长的保险行业回归第一性保障原理,确保行业更加健康的发展。' T; F1 O; S  D" I0 F7 W6 P! h0 a
    $ m/ J: G; r. u5 i" d0 B2 g+ _3 q
    互联网保险相比传统保险的优势在于:保费低,投保便捷,理赔方便,保单管理容易。但保险始终复杂,涉及续保,退保,理赔,定价,风控等。对用户来讲,产品难懂,学习成本高,保单常常厚得像一本书。诸如此类的问题,都为产品的开发和运营工作带来非常大的挑战:需求不断变化、新需求被识别、变更成为常态。需要配套合适的敏捷研发管理,才能确保业务稳定发展。0 \+ J6 B/ j, j/ k2 s# Q6 `9 g

    2 g# G( C3 D- x7 h2 N2、微保面临的挑战: N- R2 j% ~+ Z
    微保在过去的两年中,主要面临来自外部和内部的两方面的挑战。
    ; x; ]- C  D6 o+ D5 n* A" X
    % I8 b( z* l0 @) b: g) \
    5 O, a7 r! T$ e3 L) [1) 内部:
    , D7 T+ N! G* v- f& r6 p" K! b
    ! m/ h( @4 p( G9 Y3 ]; L如何确保正确的业务方向,管理好股东预期,组建团队,搭建基础,设置合适业务的组织架构,确定产品承载形态,在支持业务的同时,不断完善技术架构,解决技术债务。
    ( W- g; _& E6 [3 @' m/ g2) 外部:$ B' Q0 j0 W, f6 S$ h5 G4 m7 O

    ; l) k- \( W0 W  W1 k) _) D如何与腾讯生态深度合作,如何处理好与保险公司的关系,确保业务符合监管要求,如何打磨产品,确保用户对保险产品充分理解,如何做好用户教育,如何与友商竞争。
    & P6 X0 T" q4 _. p! n; v- F& R% _& Q/ \6 w# f* B- k
    早期我们希望打造一款爆款产品,但实际用户的保险诉求是丰富多样的,业务也随之调整。考虑到保险是低频产品,借助小程序的崛起,我们采用小程序来承载产品。在产品介绍上,反复打磨文案几十次,力求向用户讲明白保险产品特点,责任,投保条件等。投入用户教育内容板块,帮助用户学习保险知识,更好的为自己和家人配置保险。这些都是微保在创业期间需要不断优化和解决的难题。本文更多从项目管理角度出发,探讨研发项目管理在微保的敏捷落地,对一些关键问题的思考,以及解决这些问题的经验和教训。
    , S+ m8 M1 R( \: u) @, M# u, N1 c) m3 g- K: H
    02微保的敏捷历程  O! ^( J, b3 n- l

    ( {: x1 y9 J2 [5 t" x1、适应“需要”,完善敏捷  e# P7 ~$ Y! p$ h" j& _

    ) s* q. D: R1 ]1 g0 [" u6 ^% i
    # m' _" f* b' @7 F3 f
    5 p% K* ?( |/ S8 q) P( b9 e  A1 X按照组织在不同时期的需要,微保的敏捷研发管理大体分为三个阶段:
    9 s& x, G) u5 m# y& Q1)形成期:
    0 N1 H1 S2 H1 d# n7 d  h
    5 `# T7 r, k* X* @从团队组建到迭代上线。需要搭建基础,启动内部迭代,发布上线。这期间组织需要解决的问题是:做好风险管控的同时,高效的协作。+ _) a( z# G+ L) g  F
    % s; D5 P5 X' w2 C- c6 C3 @
    2017年5月初,技术+产品的团队大概50+人,那时正处于搭建基础的阶段,虽然每个人都有事做,但是大家既没有节奏也没有目标。为此我们召集骨干反复讨论并获得高层批准,定下目标:完成一个可以体验的产品雏形,以车险投保全流程走通为初期目标,定义了迭代节奏,产品story模板,状态迁移等流程和规范。
    ; H. I7 c. V0 m. M; g6 E% \* F, r/ k* i: v- F
    从此大家真正的开始协作起来,团伙变身团队:需求到设计,开发到测试,迭代到上线,各个环节都明确了过程和交付物。虽然期间也不断的踩各种坑,来自小程序本身的坑,来自保司上下游耦合的坑,在这样边踩坑边填坑的过程中,底层系统逐渐完善和稳定起来。经历6个月的内部迭代,11月2日,微保首款百万医疗险正式登录微信九宫格,迭代1.0正式发布。首款产品以流畅的投保体验和产品特色征服了用户,在保险行业引起了巨大的反响。, G: s& b0 ?  b1 i) h

    $ _( T, h% J" L. \! A# A# l, K( Y2)震荡期:( y8 x1 k! O: r  }

    ; T2 @+ E& {0 _7 [8 ]( a3 n5 m. r随着业务的发展和团队的扩张,产品线迅速增加,项目开始出现资源争夺,资源匹配不均,不同项目间重复建设。这期间组织需要解决的问题是:找到适合多业务并行的项目管理方法,顶住业务压力,并解决因此产生的技术债务,确保资源投入在正确的项目上。
    5 m$ Y4 Z- p" [
    7 V7 T1 P+ n$ s* e$ s6 i7 `2 C7 O& k研发管理方面,根据实际情况,做了多轮的研发流程优化,在优先级,评价标准,评价机制方面做了较多的优化和探索。在存量产品已经不少的情况下,新的项目的展开也受到集团审核的挑战。如何确保新业务与存量业务不冲突?新项目的长期用户价值是什么?长期赔付风险如何考虑?保险服务质量如何保障?产品战略布局如何思考?等等一系列问题,都有待解决。
    * b6 U* a. Z2 t, J6 }8 L/ \% i- B% W. ?; {+ O
    针对这些问题,我们有三个方面的经验:
    1 v7 s: n( V1 ^2 e- G! E5 E在研发管理工作上,着眼于让有限的资源投入到更有价值的业务上,工作的重心由初期主抓进度和质量逐渐转变为聚焦产品价值,人力和成本上;
    " k7 o  H6 W+ X' n" `! {4 x6 X在迭代节奏上,我们从最初的双周迭代,一步步转向现在单双周兼有的敏捷的迭代,并不断review不同项目特点,选取适合的迭代节奏;
    " n4 C( t6 O7 Z# Q+ j! {审核线流程优化,除了规范化审核材料以外,不断梳理审核要点,建立沟通机制和通道,建立高管内审的机制,保证了审核工作的顺利展开。# ~/ Y; m; T% f6 Y

    3 ?7 Q, u( p7 u1 z5 f. S3)规范期:
    0 U, E7 Z# z9 w" u+ k& t8 I0 e) C: O% M: N, ~. i1 j
    形成期和震荡期的5个关键问题,从19年开始进入不断优化和完善的过程。尤其是在如何确保做正确的事情方面。
    4 u* L+ ?& m3 J# [- |+ _/ {0 B. j3 i& Y
    7 N- Q, ?) t$ ?& H4 M早期研发管理工作仅关注封版后的过程,到规范期后,项目管理工作开始全流程管控,通过严格的立项准入机制,项目管理工作从最初特性封版到上线,转变为从idea产生即介入,全流程关注并透明进展,确保项目符合进度规划。2 f+ M4 J2 q9 m1 T

    # D! `) H5 k6 \6 g9 C# P' w6 P立项,成为研发项目管理初期的最关键环节。立项意义具体这里不赘述。实践中立项经常会被业务需求方抵触,这不可避免,因为立项工作会带来工作量。所以立项工作需要做好引导和机制配套,尽可能简化流程,完善立项checklist,帮助团队和组织做好立项。规范的立项让团队对齐项目价值,明确可能的风险和投入,确保团队最初的投入是正确的。" \3 ~7 s# ]! s" H) e9 t

    2 @( d" g8 @. O" t2、敏捷闭环,环环相扣
    / k9 @  ]/ ~, \7 e微保的敏捷工作一直是围绕两个闭环:需求环和研发环。9 ~+ X# N% }- Z2 t
    * T) J- G4 X) c" F6 t
    " v# {/ [. u7 Q$ }7 a) y. r

    ! _9 T/ L0 O" J  }# x7 {1)需求环:做正确的事情2 T* r* j8 w0 N

    3 P; Z( @5 m- j主要解决需求问题,起点是需要:市场或用户的需要,业务布局的需要。需要往往是不清晰的,需要团队一起不断讨论,确定好目标。目标包含条款,保险费率,合规要求,投保条件,产品定位,保护目标人群等等。在确立了目标以后,才真正是产品的方案开发和形态确认,交付物是明晰的需求。需求进行一步经过评审获得大家一致的理解和确认,然后进入下一个研发环。
    / I/ H4 C$ R3 N
    ( k% k! m5 H) a* R6 a& j* g$ R2 U3 d& B2)研发环:把事情做正确, C' X$ ]% A; _' U) q4 @7 D( V$ E

      _, U' l8 e2 c% e进入研发环的需求是明确的,可以执行的。包含架构设计,编码开发,保司联调,功能及系统测试,性能测试,发布验证,体验验收。上线配套的监控和数据报表,为决策层提供决策支持。如有缺陷,则修复改进再发版或再迭代。如根据报表发现业务存在设计问题,或不符合用户需要,则进行特性调整,进入轻量级需求环。重复迭代,不断完善产品。
    : ]2 R6 U( b9 F- @) b; c* p) S1 I* T' S! U2 A( m: s
    在展开项目管理的时候,我们遵循敏捷(Agile)增量迭代,采用Prince2强调的原则和流程框架,再结合Scrum的实操,形成微保自己的敏捷套路。
    ( d8 {" d% ~: Z5 w! ^& s& Y) B2 r( z
    为保持需求信息一致性,我们使用TAPD来承载微保敏捷实践中需求的管理和实现。每个月有900+story通过Tapd来进行生产和流转,线上和线下问题的跟进也通过Tapd来进行跟进和管理。3 h( M0 k9 F/ N5 f* O

    , g' v' [2 L$ E1 y' t6 y3 ?* J通过梳理,不断优化敏捷闭环中各个阶段的工作,微保C端产品发布频率从18年平均22次/月,提升到19年39次/月。效率提升了77%。
    ) W0 A* j: Z4 D& E
    , a# g6 b/ U  \1 y) ]% o* m& X% ?
    % \7 D3 ^8 M7 r7 q4 N3 {, H
    - S& \! [" l2 n8 O+ d0 V03增量迭代和关键环节管控
    + }: U7 X- M- S# W4 W
    + a0 p1 H9 {! i7 X4 }' k1、敏捷的核心
    2 Q, a( ~2 C* s2 [" M1 o微保的敏捷核心:增量迭代交付,满足组织“需要”,关键环节管控,解决业务“问题”。
    1 a8 W1 U! ^$ |2 s" y; L+ K& v: s. i9 q% \! a
    短周期增量迭代指的是我们有单周迭代、双周迭代以及紧急发布;关键环节是指立项环节、启动流程、内审外审流程,还有封版等重要环节。
    7 f# U# X0 G! u1 A  M0 Z; B% O/ T" b8 M) d' h1 t, j) s" X

    0 f+ z4 G+ Q9 p+ U
    * Z1 x/ a% X. G# i我们的迭代和大多数互联网产品迭代一样,采用流水形式。这对团队配合要求极高,同一时间不同角色成员需要并行多个迭代。但流水让产品获得更快的交付,能够及时的调整,符合敏捷的思想,满足组织和业务的需要。) j5 G) O0 v7 p

    2 Y  P+ \- b1 M) ?1 g. D6 S* L; Q2、组织的需要7 _# f. V& U# H. q" C  }
    回顾前文提到的5大类问题,其实就是组织对研发管理的5类需要:
    8 |" Z; d* h% t' u. \5 g8 L$ H9 g高效协作的需要:通过流程机制让互动更主动,更有效,需求质量更高。
    , s6 q/ b5 C- H. ^% e4 A顶住业务压力的需要:一开始即做测试环境,迭代环境建设,包括持续集成等。采用微服务,尽量复用,要考虑通用性,平台化。
    6 _* ~& }" }& q1 C3 W做好风控的需要:除常规的法务,政策和业务安全检查机制外,要做好变更管理,确保变更的有效性,必要性和风险可控。5 D$ g9 v$ A) T* V/ b. z  t/ ?
    线上服务质量的需要:解决技术债务,可测性,重复建设,监控不完善等问题,确保线上产品质量。& [2 N* l1 f. ?- s3 D% j- V" g
    做正确的事情:通过价值立项,审核,全链路把控,深度复盘。确保每个环节的交付质量和时效。确保在执行中不偏离正确目标,总体风险可控。9 h, W6 [4 N3 }4 a2 h5 |

    # G, [; Y2 Q2 M+ R( N1 T
    + n7 u2 P& ?( f1 A% S; @
    ; d' v* r+ K! `8 G这里选取5个典型且容易被忽视的关键点分享给大家:
    ! ?) t/ ]3 O  ~, ^, M
    ! }1 L$ ^% {. K7 \6 j8 X7 a6 M1)团队协作:流程帮助团队更有效的沟通协作
    + @% `/ ?1 z* f: P3 d" k2 I% l' O3 r: T8 g5 e
    迭代初期因缺少流程迭代无法有效进行。我们围绕贯穿迭代的需求,制定了项目迭代的流程。用TAPD把整个需求管理支撑起来。反复推敲,为产品迭代过程规划7个关键状态,形成模板,机制,并明确了各角色的工作职责。$ {4 @! y8 N1 d2 h
    4 p0 n/ Z& }/ h6 r2 V7 V9 d
    4 \- e. A, t7 a8 ~

    1 v1 e4 s& l# n针对需求的沟通漏损问题,我们强调双向沟通。除了产品同学向技术团队澄清需求以外,开发和测试同学也要进行需求反澄清。在多需求优先级无法判断的情况下,引入需求预审,排期会等关键会议,确保信息在初期能够充分的透明。% T, J- N8 n1 r

    ( Y3 |4 `# P- x1 D不要忽略体验的验收:验收工作非常重要,是产品与用户见面之前最后一次纠错机会。全面质量管理倡导全员参与,保障产品质量,完全依赖测试团队是不合理的。
    $ x7 I; p) Z. K' i
      t- J( X" V; Z# ?有一个真实案例,某次开发把一个30万元保额的文案说明配成20万,在上线之前被一个经验丰富的保险同学发现,避免了问题被遗留到线上。3 A5 V5 K0 b& X- V, S3 d
    ; E1 q% C+ V- C8 ]# b: G7 i
    我们对类似的线上问题进行了复盘,建立了验收机制,让更多的角色参与到线上验收,形成了固化的验收机制,避免了类似问题的再次发生。, V6 M, z) u$ \: Y: q
    ! {8 [3 U& k/ N" b! J
    ( F6 B; U9 _2 ]: j, g+ |" |9 p5 N
    6 s; g% G/ ?6 z4 X6 i% c7 A
    2)需求质量低:尝试寻找深层原因) o" }7 @/ }: i- \" L

    1 i# _* h' t6 y% T6 B( w2 y7 v9 P在一段时间内,需求质量成为引发技术和产品的矛盾点。我们尝试评价最好的需求和最差的需求。企图通过树立标杆,让需求都变得清晰,稳定,完备。虽然做了充分的推演,但当评选真正落地时,我们才发现评价成本非常高:除了心理障碍技术同学不愿意去评分以外,不同业务的技术评分标准也很难统一,导致评分最低的产品同学非常大的抵触,最终评分计划宣告失败。
    ' o" G! y( F3 Q* f- M  K. k6 c" J" @! y- O9 e* T: f

    & u1 }3 o: V$ @, F0 ?% G7 B% @. y
    需求质量问题的本质是什么?考虑不完善,不充分。回归问题本身:以问题为导向,尝试去就事论事的改进,倡导大家进行迭代总结,不求需求清晰,稳定和完备,只求需求能够充分被理解。通过这样的措施,化解了需求质量问题带来的冲突和矛盾。9 t9 b2 A: g) l8 P
    1 I) b) @0 t) A5 _2 O; I( w& K
    具体来讲,有三点:% c+ j" \/ H& n: O$ ]9 T# N& B5 U
    ①迭代复盘:发版之后,项目经理按需组织大家聚集在一起,互相吐吐槽,讲讲怎么改进。把问题摆在桌面上,很容易能够理解为什么出问题。当然,只吐槽治标不治本。需要引导大家一起思考,形成可落地的,达成一致的改进方案。
    & R$ \5 C6 `; D9 i) v
    * N2 _7 s$ D5 M# v& ~②需求的澄清和反澄清:往往团队可能没有意识到要做这个事情的重要性,这就需要项目经理介入去推动。技术团队(开发和测试),要进行反澄清。开发同学要对story分解task,测试同学需要明确的组织用例评审过程,进行反澄清。以确保产品,开发,测试对需求理解的一致性和完整性。在澄清的过程中,也可以对未考虑到的问题进行识别。有效的减少进入迭代以后的变更。- Q8 ^  {9 f9 w1 T
    , a) d) |% a9 y7 D7 U2 P4 H
    ③加强沟通:尝试去度量业务方面的需求质量是无意义的,更多要以目标为导向,和团队在一起互相沟通,解决需求一致性和需求完善的问题。需求质量低的根源也往往来自高层。常见原因是时间紧张导致需求考虑不完善。项目经理也需要和产品、技术团队一起,理清投入和产出,管理高层预期。: @, X9 q. x/ z# n5 L
    . `0 W' ]. B$ W
    3)变更管理:推动变更的合理化
    " I# N# o+ D# i8 L. L; G8 I6 T, j$ O! w0 I

    5 M9 @! y  l: b( s; W& Q
    # b" G# |  F. _8 C% z; W0 W% \2 J6 e* T  _' V; t3 x
    变化是客观存在的:业务复杂、时间短考虑不周、市场变化都会导致需求的变化。但有时变化可能是主观的:需求的提出者并没有想清楚为什么要变。甚至高层决策者可能自己也没有想清楚。团队需要给与决策者充分的决策依据也往往比较难。$ _. U8 C4 K4 O# u. @! z
    ( M+ V  P6 e& b/ p
    这时,变更管理就显得格外重要。为了确保信息的一致性,我们强调变更评审,这是非常重要的环节。变更记录需要同步到Tapd,以便未来维护。当团队内部认为变更会带来风险,就需要进行例外管理,上升问题,上升至研发总监、质量总监以及产品总监层面。如果这个层面还没法达成一致,可能还要继续上升。问题上升前,需要准备充分的变更决策依据,这也倒逼团队把问题考虑得更清晰。这样就可以尽量确保变更是有效并且是有意义的。这个过程很微妙,有时候大家在讨论如何上升的过程中,就已经达成一致的结论了。- a# ?% ]# Y4 P; ]; U

    1 L# p' a* s6 }- _变更中项目经理的角色如何扮演?在进行变更管理的时候,往往是产品和开发产生冲突的时候,需要进行一定的引导,我们实践中最有效的两个原则:+ ?' q8 P7 w- S# {
    帮产品争取合理的变更。% z! ]( r. ?6 j" S0 Q6 c) h
    帮开发挡住不合理的变更  K1 X" k. t% m# {8 r; B8 b
    合理的需求这里不再讨论,不合理的变更带来的风险和成本较高,要充分讨论,卷入有话语权的干系人,做正确的准确的决策。$ M* f1 G& [' ~* h

    0 D+ E+ y4 h$ F% j7 a. p4)产品可测性差:复杂上下游环境,多系统耦合
    - E1 R$ @. K- q" W' I
    ) m+ C! J$ D! x7 z/ t! p可测性问题目前在行业里被提及的不够多,这一点有点遗憾。可测性低,测试场景就难以构造,测试就只能依赖于开发搭环境,造场景,测试效率低下。因此从一开始,测试团队在可测性方面就投入人力。当然,可测性的工作也离不开开发同学的支持和配合。5 h- L2 K/ _5 y% i

    ! l. f6 a0 w$ O' T% i车险案例:传统车险需要自己构造数据,然后数据流要到中保协系统走一圈,再提供给测试。测试数据就像火柴,要验证火柴能不能点燃,必须要划一下,但划一下火柴就没了,测试数据非常稀缺,严重阻碍测试进度。. Q- O7 s/ [7 t' J8 A! ^5 r/ [
    $ a' R# S  @% h  |" ~( n- P, E/ @

    / N. E2 F. b! L+ ?2 _! m5 y8 g, q9 E6 _& X- U8 Y$ t) [5 \2 g
    为了解耦保司,我们投入测试和开发人力联合做mock,梳理了测试数据流转的各过程,及可测性需求,在线上线下环境都支持了虚拟保险公司mock服务,并对业务数据做了逻辑隔离。处理了上下游环境,解决环境过于复杂的问题。测试数据构造变得非常简单,可以构造不同车型,不同价格,不同年限,不同责任的投保车辆。测试效率得到极大提高。100%覆盖到异常测试场景。线上的虚拟保司mock,也基本解决了线上验证需要找真实用户的问题。
    + O" o$ i% E( L/ l" v
    5 g( a( `: x* L/ {) A4 s% t' v5)做正确的事:全链路管控
    0 {7 t; F/ F. f) j! S& O: ~+ `$ G9 _4 z: c* u5 N
    “这个需求很简单,怎么实现我不管,老板明天要看到”,这样的段子经常被技术同学拿来调侃产品。其实是业务侧顶不住老板压力的无奈写照。微保的产品从idea到上线过程中,也存在类似的问题。
    7 t- |) V0 n- F& N
    + b! b0 W; N6 I# ]7 R# H: C! V& @一款新的保险产品,要经历市场调研,保司合作,形态确认(费率,投保条件,保险责任,文案说明,风控设计),设计交互,需求细化等等环节才能真正进入开发阶段。而开发和测试阶段往往在整个产品生命周期中仅仅占很小一部分。
      n- A: V$ p5 z
    4 ?) w; c5 e& e3 w2 w: `4 J; F0 T$ P/ {' X, f3 g$ Y
    ! k: {* T/ Y6 g% ?5 Q9 [. h
    如图所示,中间点是SFM(需求封版会议),往前即需求环,往后即研发环。需求环往往损耗时间较久,就会导致产品看起来迭代周期太长。我们初期在需求环的管控上做的不到位,业务侧同学也无法给出高层干系人合理的时间估计,这也是“需求排不上”、“研发效率低”背后的原因。
    $ H) p* z' N* ?( r: e. S& _% x1 m/ b: x9 j# r  a
    我们结合过去的项目经验,与业务侧深入分析,归纳整理出项目全周期中的关键节点。对各环节的合理时间进行预估,并将其整合成工具提供给业务同学。帮助业务同学更好的管理高层干系人的预期。也避免了产品开发中的反复和变更,让产品的生产过程更加可控。
    ! `+ a. _# B9 Y3 X2 _6 n( F
    $ x; G) s' V8 {8 _2 w" n' D2 m3、小结
    - E0 w6 h' d5 O微保的敏捷就是在不断的满足组织需要的过程中,让敏捷的各环节能够高效的运转,确保整体的高效交付。6 H; ]) j# T, a9 V4 E
    " t4 b; z4 s8 U& u- ]7 m

    1 S" o* q' X  ?5 ?' U& @7 A! ]) J% @# k
    通过定规范,做研发复盘,让团伙变成团队,组织高效协作起来。
    ( L4 [2 j8 S& X/ P3 j1 n7 g: K7 O通过建平台,使用开源组组件开发通用框架,做好向上管理,顶住业务压力。
    8 U3 l$ B9 u5 q$ \% j1 m& q关键环节引入风控检查点,做好变更管理,整体上把控住了风险。
    ) [3 p% ~8 \: W1 x6 E通过技术专项,持续集成,可测性等工作,技术债务未导致严重线上事故。- L; S- u) l! T9 z- t
    通过抓立项,全链路管控和业务复盘,确保项目一直是在做正确的事。
    ! h" U4 J5 _6 i. M9 U04展望5 q* g3 G5 ?6 p" Y+ x3 [" A
    6 a$ x" P/ o# g* t: E8 ]
    回顾敏捷闭环,我们过去做的事情,和未来一直需要做下去的仍是两件事:做正确的事,把事情做正确。做正确的同时,还有一个隐含需求,就是快。具体来讲:+ M2 q3 x' I3 w3 U
    0 ~* T8 `, r4 B) l7 j. X2 ]
    1)协助组织做正确的事,并且在过程中确保一直在做正确的事。4 ]% |/ y0 B3 N" V% ^7 X, I

    0 R" U7 f8 m! k/ e& y价值立项:充分评估项目价值,确保项目值得做。
    , N; l/ R; Y2 J聚焦业务:减少业务重复建设,推动业务统一规划。- l/ W: I9 z/ t; M
    深度复盘:传承经验教训,避免反复试错和高成本试错。
    5 p2 }+ T+ n8 X7 x6 X
    7 r9 e. T8 u# j" q* t2)推进业务需求的落地,并高效的快速交付和反馈,帮助组织实现业务价值。
    ( |6 U2 e+ y$ C  @: @# g. S4 B8 X! u1 c( ?2 v" R% l' B
    度量体系:过程结果透明,可控,问题得到优化等。+ r. A- m: T8 N
    持续交付:CI/CD成熟度、自动化,UT投入等。) v% P9 z* y! F$ I6 D
    技术债务:监控,平台化,规范化,容灾降级等。
    . U: m1 o9 s  J+ \+ m
    . ^( J, t- Z4 R/ L0 p8 O  D敏捷研发管理是一个很大的主题,今天的分享要讲透是不够的,只是简单分享了我们在这个过程中遇到的几个关键问题。微保是一个互联网保险行业的新兵,在实践中其实都在摸着石头过河。希望大家可以多交流。探索互联网保险敏捷研发的成功模式。
      }" G5 T4 r* [; K3 \
    / Q) C# F. m, O2 z. h
    8 }' h8 O$ |2 q: m

    该用户从未签到

    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-11 02:20 , Processed in 0.140625 second(s), 23 queries , Gzip On.

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

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

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