TA的每日心情 | 开心 2019-11-21 15:51 |
---|
签到天数: 1 天 [LV.1]初来乍到
|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
创业团队在组建和扩张时如何高效协作,是组织要解决的大难题。明确目标、确保成员清晰知道如何配合、过程中管理好干系人预期、关键环节做好变更管理和风险把控、采用增量迭代的敏捷项目管理机制、确保“做对的事情”和“把事情做对”,是微保业务快速、稳步发展的关键。8 ~: k4 E# P4 ?
01背景
F5 A8 Y! I% ^6 j, c: o( I2 @2 b9 ]! y+ p8 s
1、互联网保险的机遇与挑战$ y. {& @5 E+ }6 }
1) 机遇
$ w" M8 V- u' d+ x
: H" Z+ I3 _: |9 v! h" i2018年中国保险行业保费全球第二,保险深度(保费/GDP)4.57%,排名全球36位。保险密度(人均保费),排名全球46位。中国保民意识逐渐苏醒,保险市场增速20%+。互联网保民累计2.2亿用户,保民年龄年轻化,首单投保平均28.7岁。中国保险行业仍有很大的发展空间。* j2 \$ }# k) a
2) 挑战- v" _% j4 J2 g1 }
9 H7 f* z( M, N% ^" r8 I- B2017年~2018年监管从严,对于违规开发产品,偏离保险本源,挑战监管底线的行为,做了明确严格的规定。让野蛮生长的保险行业回归第一性保障原理,确保行业更加健康的发展。$ M1 z6 i' u2 {; l4 R
; A! l, X0 r/ r* T4 U1 q1 r
互联网保险相比传统保险的优势在于:保费低,投保便捷,理赔方便,保单管理容易。但保险始终复杂,涉及续保,退保,理赔,定价,风控等。对用户来讲,产品难懂,学习成本高,保单常常厚得像一本书。诸如此类的问题,都为产品的开发和运营工作带来非常大的挑战:需求不断变化、新需求被识别、变更成为常态。需要配套合适的敏捷研发管理,才能确保业务稳定发展。5 {! q) z' Z0 T4 u
) ]1 J' B2 g1 R \. u; M
2、微保面临的挑战) @( I0 ?+ d: r8 N( v2 b% ^
微保在过去的两年中,主要面临来自外部和内部的两方面的挑战。
3 H- \- W- o( G. c! @" }+ Y7 E0 s3 l; e
9 h3 m$ c L+ I1) 内部:
* s7 J7 S: z9 O U/ `+ j% L; W: H7 r5 q4 U
如何确保正确的业务方向,管理好股东预期,组建团队,搭建基础,设置合适业务的组织架构,确定产品承载形态,在支持业务的同时,不断完善技术架构,解决技术债务。0 k. t& H# `/ t# e2 F
2) 外部:
/ |. ]; W/ B* y) o1 N
* M3 ~' }/ E A9 c- e如何与腾讯生态深度合作,如何处理好与保险公司的关系,确保业务符合监管要求,如何打磨产品,确保用户对保险产品充分理解,如何做好用户教育,如何与友商竞争。6 B" j/ N7 ]7 @( m9 J5 X c
: i% H" H4 a0 h3 ]早期我们希望打造一款爆款产品,但实际用户的保险诉求是丰富多样的,业务也随之调整。考虑到保险是低频产品,借助小程序的崛起,我们采用小程序来承载产品。在产品介绍上,反复打磨文案几十次,力求向用户讲明白保险产品特点,责任,投保条件等。投入用户教育内容板块,帮助用户学习保险知识,更好的为自己和家人配置保险。这些都是微保在创业期间需要不断优化和解决的难题。本文更多从项目管理角度出发,探讨研发项目管理在微保的敏捷落地,对一些关键问题的思考,以及解决这些问题的经验和教训。
& p# |( z5 B+ [. ?! V; z$ t" D
" {; Y q* O* \3 ~$ ^2 j$ E8 z$ T02微保的敏捷历程
2 X" y- x2 G8 I" ^# ^% m# C
e' R) u' F% s/ z7 O+ ^5 Q2 w1、适应“需要”,完善敏捷
' t! M2 p; a. M2 I% |/ [' O2 E- ~8 e! w2 |$ ?3 m+ s" k1 W+ |. K1 P h
+ L, p$ J# ]* L$ ^
4 h3 v- o3 a8 E+ B R8 E8 b
按照组织在不同时期的需要,微保的敏捷研发管理大体分为三个阶段:
6 W+ M1 C! l; e$ o \7 V1)形成期:. S# ^6 i4 v$ R6 t& ?
* e$ c- L* c j- m从团队组建到迭代上线。需要搭建基础,启动内部迭代,发布上线。这期间组织需要解决的问题是:做好风险管控的同时,高效的协作。 ~( H* P; s7 m8 s& F: `% ?% [
! Z5 v! C; ]/ p: {& H, ]2017年5月初,技术+产品的团队大概50+人,那时正处于搭建基础的阶段,虽然每个人都有事做,但是大家既没有节奏也没有目标。为此我们召集骨干反复讨论并获得高层批准,定下目标:完成一个可以体验的产品雏形,以车险投保全流程走通为初期目标,定义了迭代节奏,产品story模板,状态迁移等流程和规范。9 b7 P/ y, m; ?) i* b) k# W3 M
$ y6 n# u2 }5 C, w6 m. M从此大家真正的开始协作起来,团伙变身团队:需求到设计,开发到测试,迭代到上线,各个环节都明确了过程和交付物。虽然期间也不断的踩各种坑,来自小程序本身的坑,来自保司上下游耦合的坑,在这样边踩坑边填坑的过程中,底层系统逐渐完善和稳定起来。经历6个月的内部迭代,11月2日,微保首款百万医疗险正式登录微信九宫格,迭代1.0正式发布。首款产品以流畅的投保体验和产品特色征服了用户,在保险行业引起了巨大的反响。9 F9 N n2 r. l# j& C7 @' x
' r5 A @" a3 f' e [* e& [# w2 C2)震荡期:/ }2 A5 R- o, b
( q7 ?& B$ J# A
随着业务的发展和团队的扩张,产品线迅速增加,项目开始出现资源争夺,资源匹配不均,不同项目间重复建设。这期间组织需要解决的问题是:找到适合多业务并行的项目管理方法,顶住业务压力,并解决因此产生的技术债务,确保资源投入在正确的项目上。9 ~1 O7 f+ W. @+ k# R! k
% I3 b- l% j" \) I7 t
研发管理方面,根据实际情况,做了多轮的研发流程优化,在优先级,评价标准,评价机制方面做了较多的优化和探索。在存量产品已经不少的情况下,新的项目的展开也受到集团审核的挑战。如何确保新业务与存量业务不冲突?新项目的长期用户价值是什么?长期赔付风险如何考虑?保险服务质量如何保障?产品战略布局如何思考?等等一系列问题,都有待解决。9 U& y& Y( j& @2 S
2 }* H' G7 Y- c# N6 b$ [
针对这些问题,我们有三个方面的经验:1 l9 A/ m1 x9 J6 i2 F' q4 F: m
在研发管理工作上,着眼于让有限的资源投入到更有价值的业务上,工作的重心由初期主抓进度和质量逐渐转变为聚焦产品价值,人力和成本上;: }6 f- I' s7 _% O7 T
在迭代节奏上,我们从最初的双周迭代,一步步转向现在单双周兼有的敏捷的迭代,并不断review不同项目特点,选取适合的迭代节奏;
, X: D4 S# w- q' _4 p v( B8 \" ^审核线流程优化,除了规范化审核材料以外,不断梳理审核要点,建立沟通机制和通道,建立高管内审的机制,保证了审核工作的顺利展开。& I* Z# i6 X; l/ y9 n
1 B/ _; E8 j7 P3)规范期:# D" h, @6 [% z4 O4 J) C* I- f+ x; @
& a9 b% O( {6 N& h5 b
形成期和震荡期的5个关键问题,从19年开始进入不断优化和完善的过程。尤其是在如何确保做正确的事情方面。* @; u: l0 m5 w) f1 `
" q7 i v6 O$ x, H- ]- Q早期研发管理工作仅关注封版后的过程,到规范期后,项目管理工作开始全流程管控,通过严格的立项准入机制,项目管理工作从最初特性封版到上线,转变为从idea产生即介入,全流程关注并透明进展,确保项目符合进度规划。" I! p3 ~6 I: T- O" ^; b& R
' H# D( R8 v& k. y4 {( t# u7 P$ M. e立项,成为研发项目管理初期的最关键环节。立项意义具体这里不赘述。实践中立项经常会被业务需求方抵触,这不可避免,因为立项工作会带来工作量。所以立项工作需要做好引导和机制配套,尽可能简化流程,完善立项checklist,帮助团队和组织做好立项。规范的立项让团队对齐项目价值,明确可能的风险和投入,确保团队最初的投入是正确的。
0 ]' R) b8 B7 n/ H5 W
+ {) F$ f9 O8 d" u2、敏捷闭环,环环相扣 B4 i7 Q3 S3 }8 Q) {
微保的敏捷工作一直是围绕两个闭环:需求环和研发环。
5 H/ P, ~2 C6 `: v8 Q9 J
) J$ f: T* q( A. r8 A! v
8 c1 |$ R! x4 y- ^$ T* t9 m9 l$ k( J! [- |6 K* `
1)需求环:做正确的事情
& c0 h# q9 Z# a3 \! v+ G1 v, |4 P7 X/ Z5 Q% |) ?8 E
主要解决需求问题,起点是需要:市场或用户的需要,业务布局的需要。需要往往是不清晰的,需要团队一起不断讨论,确定好目标。目标包含条款,保险费率,合规要求,投保条件,产品定位,保护目标人群等等。在确立了目标以后,才真正是产品的方案开发和形态确认,交付物是明晰的需求。需求进行一步经过评审获得大家一致的理解和确认,然后进入下一个研发环。; g4 Q5 i N! E
) [, Q+ E. { }: g( m
2)研发环:把事情做正确
; c, X( i; t2 \% q9 ~) F0 w7 v3 K
8 ?$ p* C. M( a% f进入研发环的需求是明确的,可以执行的。包含架构设计,编码开发,保司联调,功能及系统测试,性能测试,发布验证,体验验收。上线配套的监控和数据报表,为决策层提供决策支持。如有缺陷,则修复改进再发版或再迭代。如根据报表发现业务存在设计问题,或不符合用户需要,则进行特性调整,进入轻量级需求环。重复迭代,不断完善产品。
/ E" E) r) \0 n8 @9 O. H. k
, W$ Y5 y: ^# R. M" g0 x c在展开项目管理的时候,我们遵循敏捷(Agile)增量迭代,采用Prince2强调的原则和流程框架,再结合Scrum的实操,形成微保自己的敏捷套路。( b5 G+ @; ]( y9 h) {& k2 f4 I
* [( G4 }1 a! {
为保持需求信息一致性,我们使用TAPD来承载微保敏捷实践中需求的管理和实现。每个月有900+story通过Tapd来进行生产和流转,线上和线下问题的跟进也通过Tapd来进行跟进和管理。; z2 g& C0 V/ \6 g4 V; j
1 X& A" H J9 `
通过梳理,不断优化敏捷闭环中各个阶段的工作,微保C端产品发布频率从18年平均22次/月,提升到19年39次/月。效率提升了77%。
# q5 B8 Y7 O( G) Y! K7 f0 R9 T: O
9 N: E5 M7 T- o. S8 K& b4 Y( P! ?. |' }$ m
8 t# X0 u* H8 W7 o- F! g03增量迭代和关键环节管控
9 B. Y7 W9 }, q& r8 h! F
" K4 W; o( y& Q7 B: L& Q( m- j1、敏捷的核心
4 |# R5 I- M7 ]& d微保的敏捷核心:增量迭代交付,满足组织“需要”,关键环节管控,解决业务“问题”。2 Q3 w2 L/ q1 [
. e' ~# Y# |" S2 O0 O! M( w" J
短周期增量迭代指的是我们有单周迭代、双周迭代以及紧急发布;关键环节是指立项环节、启动流程、内审外审流程,还有封版等重要环节。
4 ^4 {; c, Q' @: {7 b
1 }) o2 F% T5 c i0 W0 v; `' ?# ?/ v/ I0 P$ |4 ~
/ n8 ?* |7 e* C G
我们的迭代和大多数互联网产品迭代一样,采用流水形式。这对团队配合要求极高,同一时间不同角色成员需要并行多个迭代。但流水让产品获得更快的交付,能够及时的调整,符合敏捷的思想,满足组织和业务的需要。
# ?& t' a* u9 q* j* }4 g9 E m7 }4 Z3 e [% U1 c' X# ]
2、组织的需要
5 o1 V! T( T' P回顾前文提到的5大类问题,其实就是组织对研发管理的5类需要:
/ ?' s7 @, q2 ` t3 H$ ^高效协作的需要:通过流程机制让互动更主动,更有效,需求质量更高。1 Z' K1 c! s' V" R; F2 ~1 o; j, g
顶住业务压力的需要:一开始即做测试环境,迭代环境建设,包括持续集成等。采用微服务,尽量复用,要考虑通用性,平台化。5 ], T& c1 u- |- j
做好风控的需要:除常规的法务,政策和业务安全检查机制外,要做好变更管理,确保变更的有效性,必要性和风险可控。: \* L0 S( U% E/ n7 }5 G b& e- J
线上服务质量的需要:解决技术债务,可测性,重复建设,监控不完善等问题,确保线上产品质量。2 F! ], ^ F {' J" V- y
做正确的事情:通过价值立项,审核,全链路把控,深度复盘。确保每个环节的交付质量和时效。确保在执行中不偏离正确目标,总体风险可控。
2 W; E7 E- Q, D5 p& O, b' @+ m- F2 s! ]
+ q8 _8 U( J# [+ e6 z. [3 K5 A2 O" t+ d2 G) k* E ]
这里选取5个典型且容易被忽视的关键点分享给大家:9 U5 c0 L' X% @& G' p% q- x. N
2 z5 C8 E7 ?* U" C+ C1 j5 }
1)团队协作:流程帮助团队更有效的沟通协作
+ V D% r* ~" D6 H E, s0 x4 Q+ D' g5 X
迭代初期因缺少流程迭代无法有效进行。我们围绕贯穿迭代的需求,制定了项目迭代的流程。用TAPD把整个需求管理支撑起来。反复推敲,为产品迭代过程规划7个关键状态,形成模板,机制,并明确了各角色的工作职责。! \! U/ ~. Y& Z* `
2 `+ t! e) O+ N) k5 U
! O8 a, i+ X$ O* F) {8 {+ C) Q' {( X1 A: t5 ~$ v$ s
针对需求的沟通漏损问题,我们强调双向沟通。除了产品同学向技术团队澄清需求以外,开发和测试同学也要进行需求反澄清。在多需求优先级无法判断的情况下,引入需求预审,排期会等关键会议,确保信息在初期能够充分的透明。! S8 l+ A5 k0 i, \
& D/ B3 g/ D9 l8 Q! o# _* `不要忽略体验的验收:验收工作非常重要,是产品与用户见面之前最后一次纠错机会。全面质量管理倡导全员参与,保障产品质量,完全依赖测试团队是不合理的。
! T% k( X# }0 U- e% G/ ^# J
7 p4 k2 I I- W5 h5 E有一个真实案例,某次开发把一个30万元保额的文案说明配成20万,在上线之前被一个经验丰富的保险同学发现,避免了问题被遗留到线上。
3 L3 C% q' V9 u$ V! O. O2 l9 q: N( t, U3 n
我们对类似的线上问题进行了复盘,建立了验收机制,让更多的角色参与到线上验收,形成了固化的验收机制,避免了类似问题的再次发生。
) L1 z9 R: t' Z! }0 s: d; b% l( e1 E* E0 T; s1 G, A) y
; Z0 s" y) Y% Y% \( H
4 h! q6 g0 e& n5 z: C' Q- c3 @2)需求质量低:尝试寻找深层原因0 T. a+ ^ ?4 v1 ]1 I" B* X1 {; W" T
$ X1 e# Y4 n( y1 G8 {# @3 e在一段时间内,需求质量成为引发技术和产品的矛盾点。我们尝试评价最好的需求和最差的需求。企图通过树立标杆,让需求都变得清晰,稳定,完备。虽然做了充分的推演,但当评选真正落地时,我们才发现评价成本非常高:除了心理障碍技术同学不愿意去评分以外,不同业务的技术评分标准也很难统一,导致评分最低的产品同学非常大的抵触,最终评分计划宣告失败。
! u' \. F5 n E- U- ?1 u5 N
& n. ?) d/ G- [6 W: n8 d0 u7 e
) [8 d/ G* A0 F, t" E9 f5 H6 e$ h4 J- Z& a1 ?% v
需求质量问题的本质是什么?考虑不完善,不充分。回归问题本身:以问题为导向,尝试去就事论事的改进,倡导大家进行迭代总结,不求需求清晰,稳定和完备,只求需求能够充分被理解。通过这样的措施,化解了需求质量问题带来的冲突和矛盾。3 F# b# L$ ?; Q- g1 i3 A" Q
1 ? a& t2 l0 t- [/ c# x, f( T
具体来讲,有三点:2 E) J4 I" Y6 m' i8 U% l2 s
①迭代复盘:发版之后,项目经理按需组织大家聚集在一起,互相吐吐槽,讲讲怎么改进。把问题摆在桌面上,很容易能够理解为什么出问题。当然,只吐槽治标不治本。需要引导大家一起思考,形成可落地的,达成一致的改进方案。: s' }# r- X' S7 p/ N3 Y- B1 K
9 j* }8 E0 T9 j: g②需求的澄清和反澄清:往往团队可能没有意识到要做这个事情的重要性,这就需要项目经理介入去推动。技术团队(开发和测试),要进行反澄清。开发同学要对story分解task,测试同学需要明确的组织用例评审过程,进行反澄清。以确保产品,开发,测试对需求理解的一致性和完整性。在澄清的过程中,也可以对未考虑到的问题进行识别。有效的减少进入迭代以后的变更。
. Q0 Y k" |5 q. U
2 q' ], \3 Q6 k' M( I③加强沟通:尝试去度量业务方面的需求质量是无意义的,更多要以目标为导向,和团队在一起互相沟通,解决需求一致性和需求完善的问题。需求质量低的根源也往往来自高层。常见原因是时间紧张导致需求考虑不完善。项目经理也需要和产品、技术团队一起,理清投入和产出,管理高层预期。) ]0 U1 l$ n9 x# c) A
' t) o* S3 I( U1 R
3)变更管理:推动变更的合理化+ G- c0 {4 m& a D8 ^
1 A8 p1 ?( t- U( o W5 W# X" }
/ `. V+ M( V# K5 G5 N8 }/ g* h- i0 I' O$ o; s) ]8 `' U
% V7 s6 o0 V) m5 W+ t
变化是客观存在的:业务复杂、时间短考虑不周、市场变化都会导致需求的变化。但有时变化可能是主观的:需求的提出者并没有想清楚为什么要变。甚至高层决策者可能自己也没有想清楚。团队需要给与决策者充分的决策依据也往往比较难。 e7 s0 L0 G+ o) k# s3 {1 K
6 X C5 Z; f$ }& H( [& I这时,变更管理就显得格外重要。为了确保信息的一致性,我们强调变更评审,这是非常重要的环节。变更记录需要同步到Tapd,以便未来维护。当团队内部认为变更会带来风险,就需要进行例外管理,上升问题,上升至研发总监、质量总监以及产品总监层面。如果这个层面还没法达成一致,可能还要继续上升。问题上升前,需要准备充分的变更决策依据,这也倒逼团队把问题考虑得更清晰。这样就可以尽量确保变更是有效并且是有意义的。这个过程很微妙,有时候大家在讨论如何上升的过程中,就已经达成一致的结论了。
- H a% n/ ~- B5 i1 @1 }' I; R
: O; B! Q& c# F j! n6 G变更中项目经理的角色如何扮演?在进行变更管理的时候,往往是产品和开发产生冲突的时候,需要进行一定的引导,我们实践中最有效的两个原则:( h, z$ Y& d. B- w$ @$ g+ e( n
帮产品争取合理的变更。
5 B T' Z$ U$ s1 w4 P5 J; b' a帮开发挡住不合理的变更; w6 ^* g4 N) o8 r6 y( T6 y+ J
合理的需求这里不再讨论,不合理的变更带来的风险和成本较高,要充分讨论,卷入有话语权的干系人,做正确的准确的决策。
2 U! Z9 k7 S% M7 E5 b8 n8 S- \. f5 }! T5 ^
4)产品可测性差:复杂上下游环境,多系统耦合
1 C6 p! l7 t7 t! T2 S& V; a
+ u& |8 Y7 g, @, a- d0 S可测性问题目前在行业里被提及的不够多,这一点有点遗憾。可测性低,测试场景就难以构造,测试就只能依赖于开发搭环境,造场景,测试效率低下。因此从一开始,测试团队在可测性方面就投入人力。当然,可测性的工作也离不开开发同学的支持和配合。 w) ~" M' f5 z" }/ B) h" l. q6 G
! K' _7 ]" `5 ?3 X8 b% }/ Y
车险案例:传统车险需要自己构造数据,然后数据流要到中保协系统走一圈,再提供给测试。测试数据就像火柴,要验证火柴能不能点燃,必须要划一下,但划一下火柴就没了,测试数据非常稀缺,严重阻碍测试进度。
2 G4 S' `( F8 ^: |1 _0 @$ x" e) [& _8 |8 D$ x; h
$ s4 B# h% K: {" n+ r+ A5 \2 }. a5 W9 _/ O1 R0 p8 ]6 Q, \
为了解耦保司,我们投入测试和开发人力联合做mock,梳理了测试数据流转的各过程,及可测性需求,在线上线下环境都支持了虚拟保险公司mock服务,并对业务数据做了逻辑隔离。处理了上下游环境,解决环境过于复杂的问题。测试数据构造变得非常简单,可以构造不同车型,不同价格,不同年限,不同责任的投保车辆。测试效率得到极大提高。100%覆盖到异常测试场景。线上的虚拟保司mock,也基本解决了线上验证需要找真实用户的问题。
5 h# ]( {: l8 m! j, e# l( I1 t4 J& d, ^
5)做正确的事:全链路管控2 ^; a5 D2 R9 p# P+ H( l1 o7 n
1 Y+ C% e' y0 g1 w
“这个需求很简单,怎么实现我不管,老板明天要看到”,这样的段子经常被技术同学拿来调侃产品。其实是业务侧顶不住老板压力的无奈写照。微保的产品从idea到上线过程中,也存在类似的问题。( \% u' c. n( R: ~0 K
1 m4 k+ v+ R* U7 S( J一款新的保险产品,要经历市场调研,保司合作,形态确认(费率,投保条件,保险责任,文案说明,风控设计),设计交互,需求细化等等环节才能真正进入开发阶段。而开发和测试阶段往往在整个产品生命周期中仅仅占很小一部分。
; Z8 T" D* I4 c3 C/ {" ]- N# C. k+ {6 p6 f1 g9 Q2 t
& @- I; H* U; \. E
% f* I; t4 i7 [如图所示,中间点是SFM(需求封版会议),往前即需求环,往后即研发环。需求环往往损耗时间较久,就会导致产品看起来迭代周期太长。我们初期在需求环的管控上做的不到位,业务侧同学也无法给出高层干系人合理的时间估计,这也是“需求排不上”、“研发效率低”背后的原因。 R/ t8 b' Z4 ?! S3 K
; l7 z( p1 B! g% e8 E% p& w
我们结合过去的项目经验,与业务侧深入分析,归纳整理出项目全周期中的关键节点。对各环节的合理时间进行预估,并将其整合成工具提供给业务同学。帮助业务同学更好的管理高层干系人的预期。也避免了产品开发中的反复和变更,让产品的生产过程更加可控。' A' |8 ~1 L4 U+ n9 z
' ^5 j. X( Y z6 D8 d( v" M3 t+ k3、小结" X3 m/ f1 }. G: o C8 J# U
微保的敏捷就是在不断的满足组织需要的过程中,让敏捷的各环节能够高效的运转,确保整体的高效交付。0 b6 f! u) h: ^- p6 _6 p" T
* d- c4 e5 h3 \6 a) q+ B5 A0 v& E& `! g! @5 ?6 L0 L* y2 B5 g
; J8 ]; k$ i$ T9 T通过定规范,做研发复盘,让团伙变成团队,组织高效协作起来。
. F! `5 {6 A& t; z! V( r: f+ q通过建平台,使用开源组组件开发通用框架,做好向上管理,顶住业务压力。
5 O# ?* A/ |' z. L$ D关键环节引入风控检查点,做好变更管理,整体上把控住了风险。& m% S- v) M; m
通过技术专项,持续集成,可测性等工作,技术债务未导致严重线上事故。# c, i5 X* }; P( n) K/ d
通过抓立项,全链路管控和业务复盘,确保项目一直是在做正确的事。
8 D/ j6 ]3 Z1 k" U" \0 D7 k1 y2 [ O04展望( N' ^, X1 ?5 D
& S: S1 ?* D# U8 f1 B6 X" Y& l9 y' V
回顾敏捷闭环,我们过去做的事情,和未来一直需要做下去的仍是两件事:做正确的事,把事情做正确。做正确的同时,还有一个隐含需求,就是快。具体来讲:& x$ B; t% P l! d& W
# O$ D" D2 V! i% W: v9 p4 j1)协助组织做正确的事,并且在过程中确保一直在做正确的事。
, ]" X m/ a+ L$ }0 e3 ~4 B
" e7 a) d2 s6 k. Z6 a价值立项:充分评估项目价值,确保项目值得做。- r, j3 f& C( L2 G6 N0 B
聚焦业务:减少业务重复建设,推动业务统一规划。
" }0 y' v B# f& N. R* u9 [! @. H深度复盘:传承经验教训,避免反复试错和高成本试错。. x# y8 {+ i- C
# M8 `1 F- @0 q4 Y9 W+ V9 `8 B2)推进业务需求的落地,并高效的快速交付和反馈,帮助组织实现业务价值。
# g Z5 j' B4 f Z' g. R1 b1 J/ I% B) ^7 n7 b
度量体系:过程结果透明,可控,问题得到优化等。3 r* {* p0 n# ?4 }6 i
持续交付:CI/CD成熟度、自动化,UT投入等。
6 x' z" r+ `0 ^2 T! R8 I/ x' f& o技术债务:监控,平台化,规范化,容灾降级等。
/ k! b1 \; ?: B0 o; q5 \1 R E* L+ ^/ ^& I7 ?, A* I
敏捷研发管理是一个很大的主题,今天的分享要讲透是不够的,只是简单分享了我们在这个过程中遇到的几个关键问题。微保是一个互联网保险行业的新兵,在实践中其实都在摸着石头过河。希望大家可以多交流。探索互联网保险敏捷研发的成功模式。4 `! L9 o) _/ h( W% w
" y m' R$ j1 y1 X
3 P' Z; }: ^7 ]! e$ |8 b ` |
|