TA的每日心情 | 开心 2019-11-21 15:51 |
---|
签到天数: 1 天 [LV.1]初来乍到
|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
创业团队在组建和扩张时如何高效协作,是组织要解决的大难题。明确目标、确保成员清晰知道如何配合、过程中管理好干系人预期、关键环节做好变更管理和风险把控、采用增量迭代的敏捷项目管理机制、确保“做对的事情”和“把事情做对”,是微保业务快速、稳步发展的关键。1 {9 w5 U# ]- Q) n& [: M6 O: w
01背景( c- T# K( z: B0 v" @8 p: ?
* v+ H" Y& V! }5 L1、互联网保险的机遇与挑战
# _$ I6 X) Z) p: W. H1) 机遇: g9 {; v, A+ l6 j: J9 r
" z3 H0 z2 U4 ^, O. t2018年中国保险行业保费全球第二,保险深度(保费/GDP)4.57%,排名全球36位。保险密度(人均保费),排名全球46位。中国保民意识逐渐苏醒,保险市场增速20%+。互联网保民累计2.2亿用户,保民年龄年轻化,首单投保平均28.7岁。中国保险行业仍有很大的发展空间。
2 v0 ^$ c+ D5 B0 p( c2) 挑战* p Z: a6 t# i1 a' q/ ?
5 x% ]( l# m! `1 ?! z) b
2017年~2018年监管从严,对于违规开发产品,偏离保险本源,挑战监管底线的行为,做了明确严格的规定。让野蛮生长的保险行业回归第一性保障原理,确保行业更加健康的发展。
4 ?6 j1 d9 q% N. y3 z9 \( c- B1 N. {
互联网保险相比传统保险的优势在于:保费低,投保便捷,理赔方便,保单管理容易。但保险始终复杂,涉及续保,退保,理赔,定价,风控等。对用户来讲,产品难懂,学习成本高,保单常常厚得像一本书。诸如此类的问题,都为产品的开发和运营工作带来非常大的挑战:需求不断变化、新需求被识别、变更成为常态。需要配套合适的敏捷研发管理,才能确保业务稳定发展。
0 S% G4 ~6 }8 b: X+ r9 U3 Q: k8 w& e/ Q' P6 f! n5 q
2、微保面临的挑战& L9 A& o6 F6 L6 C
微保在过去的两年中,主要面临来自外部和内部的两方面的挑战。9 B& _7 q4 o& M* A3 X3 ?
: p$ u* U: m& \2 V
# }% F) H1 b1 z& T7 p- F8 L p1) 内部:
8 ?1 j- J! c+ \/ C3 S, ]3 r& C
" @# }: i7 e/ z/ O如何确保正确的业务方向,管理好股东预期,组建团队,搭建基础,设置合适业务的组织架构,确定产品承载形态,在支持业务的同时,不断完善技术架构,解决技术债务。
. f+ G/ G+ P! E4 A5 l5 d2 S0 n4 P2) 外部: O4 A6 ~- P9 B, N" F
) r# b6 z) _ g9 `
如何与腾讯生态深度合作,如何处理好与保险公司的关系,确保业务符合监管要求,如何打磨产品,确保用户对保险产品充分理解,如何做好用户教育,如何与友商竞争。% R3 C' b0 [; \/ }% h4 w
; ]$ K# w" f& D2 W& O
早期我们希望打造一款爆款产品,但实际用户的保险诉求是丰富多样的,业务也随之调整。考虑到保险是低频产品,借助小程序的崛起,我们采用小程序来承载产品。在产品介绍上,反复打磨文案几十次,力求向用户讲明白保险产品特点,责任,投保条件等。投入用户教育内容板块,帮助用户学习保险知识,更好的为自己和家人配置保险。这些都是微保在创业期间需要不断优化和解决的难题。本文更多从项目管理角度出发,探讨研发项目管理在微保的敏捷落地,对一些关键问题的思考,以及解决这些问题的经验和教训。$ [' y4 F( A( N- e) Y, X
/ H/ b9 J3 P3 k( X: w7 p
02微保的敏捷历程
4 c0 H. G3 D' a9 `' M( m% ]" V, e. x- h( Q) V6 U6 M$ A
1、适应“需要”,完善敏捷
, z4 }9 m u6 A- S
) z: d! K8 a+ x9 P* ]. ]9 }: J( X
% Q% j$ d- _& E& k% E K6 _' g( q6 Z按照组织在不同时期的需要,微保的敏捷研发管理大体分为三个阶段:- h7 _/ a/ |. G& d0 [
1)形成期:
6 u3 t, m7 F5 J R6 D% u
6 Z3 e& U# l3 S) e& j* @9 t" ]1 W从团队组建到迭代上线。需要搭建基础,启动内部迭代,发布上线。这期间组织需要解决的问题是:做好风险管控的同时,高效的协作。
& s2 t) o7 {# ?0 z0 D- P4 E+ ?2 U7 t: i% @' n! L: f
2017年5月初,技术+产品的团队大概50+人,那时正处于搭建基础的阶段,虽然每个人都有事做,但是大家既没有节奏也没有目标。为此我们召集骨干反复讨论并获得高层批准,定下目标:完成一个可以体验的产品雏形,以车险投保全流程走通为初期目标,定义了迭代节奏,产品story模板,状态迁移等流程和规范。
3 Z6 y5 P$ X' j# F1 n: |/ g+ l0 |( q& _5 Q5 g* T
从此大家真正的开始协作起来,团伙变身团队:需求到设计,开发到测试,迭代到上线,各个环节都明确了过程和交付物。虽然期间也不断的踩各种坑,来自小程序本身的坑,来自保司上下游耦合的坑,在这样边踩坑边填坑的过程中,底层系统逐渐完善和稳定起来。经历6个月的内部迭代,11月2日,微保首款百万医疗险正式登录微信九宫格,迭代1.0正式发布。首款产品以流畅的投保体验和产品特色征服了用户,在保险行业引起了巨大的反响。1 B4 ]7 E6 V2 m
: j9 a! O; k! [2 a0 Y2)震荡期:
. s, n" H9 f1 {* n; y4 ^! E$ F* E {- `
随着业务的发展和团队的扩张,产品线迅速增加,项目开始出现资源争夺,资源匹配不均,不同项目间重复建设。这期间组织需要解决的问题是:找到适合多业务并行的项目管理方法,顶住业务压力,并解决因此产生的技术债务,确保资源投入在正确的项目上。/ |( W J3 S' R' Y$ T3 c0 @
! ]4 L* P$ }/ e, [5 s3 _6 n研发管理方面,根据实际情况,做了多轮的研发流程优化,在优先级,评价标准,评价机制方面做了较多的优化和探索。在存量产品已经不少的情况下,新的项目的展开也受到集团审核的挑战。如何确保新业务与存量业务不冲突?新项目的长期用户价值是什么?长期赔付风险如何考虑?保险服务质量如何保障?产品战略布局如何思考?等等一系列问题,都有待解决。
8 V/ S2 W! }/ h* k% d7 R9 x/ e$ D* j3 E
针对这些问题,我们有三个方面的经验:
: N3 a e1 Q; c$ t在研发管理工作上,着眼于让有限的资源投入到更有价值的业务上,工作的重心由初期主抓进度和质量逐渐转变为聚焦产品价值,人力和成本上;; i8 {; {* _/ m2 _# X8 q
在迭代节奏上,我们从最初的双周迭代,一步步转向现在单双周兼有的敏捷的迭代,并不断review不同项目特点,选取适合的迭代节奏;! x8 `* }7 e8 \$ K: m. g- z
审核线流程优化,除了规范化审核材料以外,不断梳理审核要点,建立沟通机制和通道,建立高管内审的机制,保证了审核工作的顺利展开。
. C) i* h# R8 G4 ^; R' \8 h% f5 K: t7 l: O$ ]; |3 S
3)规范期:
( I) K: t" Q, t+ ?% g6 w. }0 R$ ` y( {. k& t
形成期和震荡期的5个关键问题,从19年开始进入不断优化和完善的过程。尤其是在如何确保做正确的事情方面。
2 h! F5 \# r9 H2 N8 M6 a: E+ e# @% Q( q e& M8 m
早期研发管理工作仅关注封版后的过程,到规范期后,项目管理工作开始全流程管控,通过严格的立项准入机制,项目管理工作从最初特性封版到上线,转变为从idea产生即介入,全流程关注并透明进展,确保项目符合进度规划。, N* S" Y7 p6 r3 R: @' K
- L/ u$ B4 q$ T( W' x立项,成为研发项目管理初期的最关键环节。立项意义具体这里不赘述。实践中立项经常会被业务需求方抵触,这不可避免,因为立项工作会带来工作量。所以立项工作需要做好引导和机制配套,尽可能简化流程,完善立项checklist,帮助团队和组织做好立项。规范的立项让团队对齐项目价值,明确可能的风险和投入,确保团队最初的投入是正确的。
m) J& a& H5 n7 L
4 h& |' A. H# j) X2、敏捷闭环,环环相扣' ] B1 |! j* w/ Q
微保的敏捷工作一直是围绕两个闭环:需求环和研发环。- D4 p1 R" P1 K0 K' A" E; d
. S# }. D" s3 _; `
( \. y N) ~/ K. g# p/ e& P& Q' n6 h- r+ G X- @* T! u) \: f
1)需求环:做正确的事情/ @# J' O/ y% B6 d& K* w) L
) X* q- N5 ~( ?! p& M( w
主要解决需求问题,起点是需要:市场或用户的需要,业务布局的需要。需要往往是不清晰的,需要团队一起不断讨论,确定好目标。目标包含条款,保险费率,合规要求,投保条件,产品定位,保护目标人群等等。在确立了目标以后,才真正是产品的方案开发和形态确认,交付物是明晰的需求。需求进行一步经过评审获得大家一致的理解和确认,然后进入下一个研发环。1 C/ C: J+ h, u0 r
1 k& I6 _8 F* _ W/ _9 b- X2)研发环:把事情做正确- g1 V' Y3 E; x: s$ y3 U7 T
- |- F/ @2 ?' V0 g2 @3 R进入研发环的需求是明确的,可以执行的。包含架构设计,编码开发,保司联调,功能及系统测试,性能测试,发布验证,体验验收。上线配套的监控和数据报表,为决策层提供决策支持。如有缺陷,则修复改进再发版或再迭代。如根据报表发现业务存在设计问题,或不符合用户需要,则进行特性调整,进入轻量级需求环。重复迭代,不断完善产品。% t% @0 f2 g M, r7 p
9 ?& j8 E! D$ m4 }9 a
在展开项目管理的时候,我们遵循敏捷(Agile)增量迭代,采用Prince2强调的原则和流程框架,再结合Scrum的实操,形成微保自己的敏捷套路。- J: ~/ Y$ `3 j: ~. W1 R6 D
1 w) O' f* p. g
为保持需求信息一致性,我们使用TAPD来承载微保敏捷实践中需求的管理和实现。每个月有900+story通过Tapd来进行生产和流转,线上和线下问题的跟进也通过Tapd来进行跟进和管理。
' ?7 D A! y: t l. x6 g' y- {5 i/ s: t% z5 G( c8 v ~$ R0 U
通过梳理,不断优化敏捷闭环中各个阶段的工作,微保C端产品发布频率从18年平均22次/月,提升到19年39次/月。效率提升了77%。
! j. X" f0 d( H- j5 Y4 Z- j
$ D$ V5 }! q5 W! n$ o' p4 ]+ q( I K' O" x) v1 b
; J4 p6 Y2 X S# Q/ X; _1 E: {1 |
03增量迭代和关键环节管控
; H2 X& r& j }3 y2 I
& [3 r# b5 B' W: d6 n* y. O1、敏捷的核心$ G \0 g" v1 w6 A* Q/ p
微保的敏捷核心:增量迭代交付,满足组织“需要”,关键环节管控,解决业务“问题”。2 O I9 w1 s- R* C- O& k2 J. \- Y
' L) f8 }5 w+ V短周期增量迭代指的是我们有单周迭代、双周迭代以及紧急发布;关键环节是指立项环节、启动流程、内审外审流程,还有封版等重要环节。3 E2 j L3 a. E1 B, z9 y; D) t
" }. K; \! O @* _# I3 X
, s4 Y6 W, |; }& O! {* |/ R% ]0 q+ i. m
我们的迭代和大多数互联网产品迭代一样,采用流水形式。这对团队配合要求极高,同一时间不同角色成员需要并行多个迭代。但流水让产品获得更快的交付,能够及时的调整,符合敏捷的思想,满足组织和业务的需要。$ L: i0 T( ?1 o+ {0 k0 A" y
- a$ K1 H1 s5 k& |0 W( h2、组织的需要
! O S! j Z, n1 z回顾前文提到的5大类问题,其实就是组织对研发管理的5类需要:2 Z6 f) }% l: `* U
高效协作的需要:通过流程机制让互动更主动,更有效,需求质量更高。
' L, t% [+ j8 z* @3 q5 Q顶住业务压力的需要:一开始即做测试环境,迭代环境建设,包括持续集成等。采用微服务,尽量复用,要考虑通用性,平台化。& \0 j" K1 [ U# P& R" x: P7 b B |& q
做好风控的需要:除常规的法务,政策和业务安全检查机制外,要做好变更管理,确保变更的有效性,必要性和风险可控。
/ q1 P' x. p/ a. X; d O: ]4 `+ X线上服务质量的需要:解决技术债务,可测性,重复建设,监控不完善等问题,确保线上产品质量。
, u5 r) A' p1 `8 i6 U3 N做正确的事情:通过价值立项,审核,全链路把控,深度复盘。确保每个环节的交付质量和时效。确保在执行中不偏离正确目标,总体风险可控。
' q7 G7 A* U8 M4 o4 N- E- f% [ Q9 C- d$ }) x" `- j( C
: Y- T+ }8 W& T# b F" g9 ~8 I5 i4 L
这里选取5个典型且容易被忽视的关键点分享给大家:
5 W# l: L8 a* g: X% o3 n# P7 l) S$ r5 E$ N$ j4 `! e9 Z( {8 ^
1)团队协作:流程帮助团队更有效的沟通协作
6 l2 e- j. q* I# l1 C/ h# D& H6 D9 {3 H! j
迭代初期因缺少流程迭代无法有效进行。我们围绕贯穿迭代的需求,制定了项目迭代的流程。用TAPD把整个需求管理支撑起来。反复推敲,为产品迭代过程规划7个关键状态,形成模板,机制,并明确了各角色的工作职责。
* L: d+ o" g$ I$ T9 v% e% D" j$ A, W3 Y X2 [! A# z) Z
4 i, ~0 p$ x- t
9 o) ^8 P% P/ d# w" j2 N针对需求的沟通漏损问题,我们强调双向沟通。除了产品同学向技术团队澄清需求以外,开发和测试同学也要进行需求反澄清。在多需求优先级无法判断的情况下,引入需求预审,排期会等关键会议,确保信息在初期能够充分的透明。
4 h% N% J) r& R! d+ e
! n! B, A/ k& e, z( p不要忽略体验的验收:验收工作非常重要,是产品与用户见面之前最后一次纠错机会。全面质量管理倡导全员参与,保障产品质量,完全依赖测试团队是不合理的。' o/ ?$ C4 w) N% r( V& H
- N0 T( t' r7 q! c( D5 [有一个真实案例,某次开发把一个30万元保额的文案说明配成20万,在上线之前被一个经验丰富的保险同学发现,避免了问题被遗留到线上。! D2 Y- z( C* X+ O4 O
' b$ ]" l+ r9 V& q% f y+ c我们对类似的线上问题进行了复盘,建立了验收机制,让更多的角色参与到线上验收,形成了固化的验收机制,避免了类似问题的再次发生。
, q+ M7 k- x% W% |" J
5 S3 ?" k8 s: A0 j/ l7 i$ \7 F" o& _ k0 A. P, {& l
, p$ q2 @$ `) `, E2 V2)需求质量低:尝试寻找深层原因
t t$ H/ @+ z# w( ~) G
+ n1 M7 Q4 d8 ]# n0 g在一段时间内,需求质量成为引发技术和产品的矛盾点。我们尝试评价最好的需求和最差的需求。企图通过树立标杆,让需求都变得清晰,稳定,完备。虽然做了充分的推演,但当评选真正落地时,我们才发现评价成本非常高:除了心理障碍技术同学不愿意去评分以外,不同业务的技术评分标准也很难统一,导致评分最低的产品同学非常大的抵触,最终评分计划宣告失败。
$ S/ ~- q" {! w# s6 @ h$ e+ J" W) E3 {" I. X
: z4 N. ~. P2 X6 X; f( P6 }
. J9 z3 m+ Z' V5 w- Z: p4 l' Y需求质量问题的本质是什么?考虑不完善,不充分。回归问题本身:以问题为导向,尝试去就事论事的改进,倡导大家进行迭代总结,不求需求清晰,稳定和完备,只求需求能够充分被理解。通过这样的措施,化解了需求质量问题带来的冲突和矛盾。
1 t% d5 q M/ g( {4 [1 a
+ P% G* b: n, m6 O: S具体来讲,有三点:
7 t2 b, A7 m5 |3 z4 o( X①迭代复盘:发版之后,项目经理按需组织大家聚集在一起,互相吐吐槽,讲讲怎么改进。把问题摆在桌面上,很容易能够理解为什么出问题。当然,只吐槽治标不治本。需要引导大家一起思考,形成可落地的,达成一致的改进方案。" V+ A7 t& A! q" C8 ?: f
$ n6 s7 q3 Q$ f! Z: ~; C5 _; y②需求的澄清和反澄清:往往团队可能没有意识到要做这个事情的重要性,这就需要项目经理介入去推动。技术团队(开发和测试),要进行反澄清。开发同学要对story分解task,测试同学需要明确的组织用例评审过程,进行反澄清。以确保产品,开发,测试对需求理解的一致性和完整性。在澄清的过程中,也可以对未考虑到的问题进行识别。有效的减少进入迭代以后的变更。
, |: ]8 S: {/ H+ A8 K2 t/ H
* I. Z* G% o6 w, r1 R6 D③加强沟通:尝试去度量业务方面的需求质量是无意义的,更多要以目标为导向,和团队在一起互相沟通,解决需求一致性和需求完善的问题。需求质量低的根源也往往来自高层。常见原因是时间紧张导致需求考虑不完善。项目经理也需要和产品、技术团队一起,理清投入和产出,管理高层预期。
6 E+ a. L }" j2 I _, e @$ I( {% O$ x0 U$ E0 ^
3)变更管理:推动变更的合理化$ ~1 M# `" u1 Z* ~- ?* f
( w7 E8 e7 C# w7 U) T' r* a. _" l2 t) Y' M0 ?
. E( D5 R/ j5 V# ?( f4 L, B
9 j2 f, e/ g+ s, C" N7 x变化是客观存在的:业务复杂、时间短考虑不周、市场变化都会导致需求的变化。但有时变化可能是主观的:需求的提出者并没有想清楚为什么要变。甚至高层决策者可能自己也没有想清楚。团队需要给与决策者充分的决策依据也往往比较难。1 m- K3 `* [0 f# M
( [' H1 D; I$ ^3 F+ q8 U4 y
这时,变更管理就显得格外重要。为了确保信息的一致性,我们强调变更评审,这是非常重要的环节。变更记录需要同步到Tapd,以便未来维护。当团队内部认为变更会带来风险,就需要进行例外管理,上升问题,上升至研发总监、质量总监以及产品总监层面。如果这个层面还没法达成一致,可能还要继续上升。问题上升前,需要准备充分的变更决策依据,这也倒逼团队把问题考虑得更清晰。这样就可以尽量确保变更是有效并且是有意义的。这个过程很微妙,有时候大家在讨论如何上升的过程中,就已经达成一致的结论了。
, F2 H6 }' ]: _" I
! v( j- O2 o1 o) i4 _% [2 F0 w变更中项目经理的角色如何扮演?在进行变更管理的时候,往往是产品和开发产生冲突的时候,需要进行一定的引导,我们实践中最有效的两个原则:
/ f# Q, v( v! |/ r/ J$ e帮产品争取合理的变更。' B0 G' e. z- }6 ?! ~5 q+ P
帮开发挡住不合理的变更
7 Y* h; Q5 d4 V/ }1 ~6 z合理的需求这里不再讨论,不合理的变更带来的风险和成本较高,要充分讨论,卷入有话语权的干系人,做正确的准确的决策。
9 p' d0 w3 f. j4 y) O1 Q p( S% \/ g2 J* r" D- t" _
4)产品可测性差:复杂上下游环境,多系统耦合
" N6 y8 I& i4 T Y$ u; w" G3 D' {" @* r3 M5 R% Q
可测性问题目前在行业里被提及的不够多,这一点有点遗憾。可测性低,测试场景就难以构造,测试就只能依赖于开发搭环境,造场景,测试效率低下。因此从一开始,测试团队在可测性方面就投入人力。当然,可测性的工作也离不开开发同学的支持和配合。
1 J( s' d( P* P( ]. W" S; `2 n8 O+ o- Z9 p% \1 N
车险案例:传统车险需要自己构造数据,然后数据流要到中保协系统走一圈,再提供给测试。测试数据就像火柴,要验证火柴能不能点燃,必须要划一下,但划一下火柴就没了,测试数据非常稀缺,严重阻碍测试进度。2 a- a! o7 X2 Y y& M- |: w! l
6 j/ k! c. H. x7 ?
/ e, C4 x% t4 l* Q3 o2 a/ C. m2 \" X1 N4 \9 M. v& c9 ` }
为了解耦保司,我们投入测试和开发人力联合做mock,梳理了测试数据流转的各过程,及可测性需求,在线上线下环境都支持了虚拟保险公司mock服务,并对业务数据做了逻辑隔离。处理了上下游环境,解决环境过于复杂的问题。测试数据构造变得非常简单,可以构造不同车型,不同价格,不同年限,不同责任的投保车辆。测试效率得到极大提高。100%覆盖到异常测试场景。线上的虚拟保司mock,也基本解决了线上验证需要找真实用户的问题。
5 U, D& i5 K8 k3 ^, W1 o1 p& }9 Y4 \. J T' I y
5)做正确的事:全链路管控
4 S8 F2 P6 L! J# T$ V+ ^9 E: K6 c6 d
“这个需求很简单,怎么实现我不管,老板明天要看到”,这样的段子经常被技术同学拿来调侃产品。其实是业务侧顶不住老板压力的无奈写照。微保的产品从idea到上线过程中,也存在类似的问题。! P+ j7 G2 E: G0 P
) q) y+ q( |( g3 i4 t一款新的保险产品,要经历市场调研,保司合作,形态确认(费率,投保条件,保险责任,文案说明,风控设计),设计交互,需求细化等等环节才能真正进入开发阶段。而开发和测试阶段往往在整个产品生命周期中仅仅占很小一部分。
y2 `5 Z! z; M/ u# \4 K( u4 v) c8 D' Y8 m8 b5 A
: X7 ]* X9 l% y$ i# I3 H- m3 E/ ?
2 j# ], d7 y& }5 P3 f- Y如图所示,中间点是SFM(需求封版会议),往前即需求环,往后即研发环。需求环往往损耗时间较久,就会导致产品看起来迭代周期太长。我们初期在需求环的管控上做的不到位,业务侧同学也无法给出高层干系人合理的时间估计,这也是“需求排不上”、“研发效率低”背后的原因。
& r6 u' m+ V& m7 a3 T# y- K# u( h) k: k7 I/ F6 E: w8 _$ k
我们结合过去的项目经验,与业务侧深入分析,归纳整理出项目全周期中的关键节点。对各环节的合理时间进行预估,并将其整合成工具提供给业务同学。帮助业务同学更好的管理高层干系人的预期。也避免了产品开发中的反复和变更,让产品的生产过程更加可控。% k/ M4 E+ s n" r+ m5 N1 |, e* T J
' d# f2 t8 ~/ Y) b" [3 g$ f* i1 b3、小结) W V2 t0 ~# y5 _
微保的敏捷就是在不断的满足组织需要的过程中,让敏捷的各环节能够高效的运转,确保整体的高效交付。3 }. x& S% ]( |+ D% p9 f) R
$ l- T% I0 d5 E: J. x, H
! q3 \6 H7 y, R- B3 j
( _6 o$ \ h0 i3 P; K( p2 O通过定规范,做研发复盘,让团伙变成团队,组织高效协作起来。2 a; t* p7 j/ t& Q$ ?5 p9 H7 x
通过建平台,使用开源组组件开发通用框架,做好向上管理,顶住业务压力。$ E/ {* v9 ]2 f- Y& @' u
关键环节引入风控检查点,做好变更管理,整体上把控住了风险。
9 {5 Q. e5 X7 {! W通过技术专项,持续集成,可测性等工作,技术债务未导致严重线上事故。! b0 D2 I5 d+ a2 N1 j) m- w
通过抓立项,全链路管控和业务复盘,确保项目一直是在做正确的事。
, @, v0 y( M6 c' l" X04展望
6 B& k) f5 b: m4 k
5 S1 b2 \: C; @% C5 L# B回顾敏捷闭环,我们过去做的事情,和未来一直需要做下去的仍是两件事:做正确的事,把事情做正确。做正确的同时,还有一个隐含需求,就是快。具体来讲:
! O2 C0 }2 m2 Z j
. Y+ S% L+ P5 K1)协助组织做正确的事,并且在过程中确保一直在做正确的事。: D2 t* J% Y& i7 d# D
; V( M% d) D- _/ L0 w价值立项:充分评估项目价值,确保项目值得做。) R9 _( N! h0 P; F" `
聚焦业务:减少业务重复建设,推动业务统一规划。
4 [8 m0 S$ t5 `; {* c深度复盘:传承经验教训,避免反复试错和高成本试错。
G2 u" O X5 w- [; _# S" O1 a$ V/ ]3 C, `* P- \9 Z& K
2)推进业务需求的落地,并高效的快速交付和反馈,帮助组织实现业务价值。# y. G7 X+ e* @3 p8 p: s7 ^) _
' K' T! o- d8 ?- A/ g
度量体系:过程结果透明,可控,问题得到优化等。+ ?# X: l2 [; a( D+ Z- d( l& H
持续交付:CI/CD成熟度、自动化,UT投入等。
8 y9 n1 [( G3 _ e; p技术债务:监控,平台化,规范化,容灾降级等。1 a6 D, K1 T6 |3 I2 s6 b
* b! q% k1 |9 u敏捷研发管理是一个很大的主题,今天的分享要讲透是不够的,只是简单分享了我们在这个过程中遇到的几个关键问题。微保是一个互联网保险行业的新兵,在实践中其实都在摸着石头过河。希望大家可以多交流。探索互联网保险敏捷研发的成功模式。1 ` M2 d* P: E, D- r. {; X" J. `* R, U
. n* O# J# K* ^% m
" p* J& C i6 c2 D* a- T; m7 s; A |
|