|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
为什么要提高研发效能,因为技术本身是为业务服务的,产品的价值体现在业务上,技术的所有价值最终都要通过业务结果来呈现,我们的根本目的是帮助业务成功,促进业务腾飞。9 O8 [0 r' I/ `" Y _4 `" o
7 T" L4 w N/ t6 D/ i
那技术就不重要了吗!重要,因为所有的业务价值最终都要通过软件服务来变现,两者相辅相成,互相促进。
; v8 ?+ r' N" a. M8 ]: n那如何提高研发效能?- y' T: V: |' b( V
一个项目从立项到上线涉及到角色包含客户、运营、客服、产品、技术、测试。
% ], I( Q) _$ a b) {" B% b4 K涉及到关键流程如下。
/ V- k/ m# b" b4 Y, z' c: g9 u3 e
' M I' F: Y8 L& F' T: b3 [% G需求收集,运营/老板 -> 产品,关键产出:想法/idea/业务需求文档5 I, B, G0 M6 @" I. o& N
2 c2 q- ]4 _; q' R# w" B$ i需求评审,产品 -> 运营/老板/技术,关键产出:产品需求文档
: t1 i' J/ G. C5 |- _* Y! y" @0 d# n7 r( N
需求内部评审,产品 -> 运营/老板/技术/若干项目负责人,关键产出:产品需求文档7 ^+ ]% A- \" J, k% E- n4 C
$ O- {' I2 Y6 P' p* e需求宣讲,产品 -> 研发/测试,关键产出:大家对于问题,目标,需求的理解达成一致
: Q/ E- a% J$ b# s8 x2 r' u
+ T! N( i3 n- U% y5 u* L; _5 t# @技术方案评审,研发 -> 产品/测试,关键产出:技术架构/代码' W, }1 k6 g8 z% G4 w" V
/ m1 O a: T: A/ b+ P, j7 ?$ R
测试用例评审,测试 -> 研发/产品,关键产出:测试用例/需求逻辑测试case全覆盖& |* h# G: J7 H$ q: A9 {
9 B2 X9 H4 h% ]9 |# Y! `; @3 F系统上线,产品/研发/测试 -> 客户1 M( X. p2 E' q! Y- r, ^# G
需求复盘,客户->运营/老板/产品/技术,关键产出:需求客户满意度/ e0 h/ J7 e2 _# V$ u/ T* d
Do things right还是Do right things?# l; L3 j* K$ y% r- u
接下来主要从需求管理,研发,测试三个维度描述,如何Do right things。) [/ s8 [7 ~) h9 y3 j
1.需求管理
; z- b3 A7 L$ Y
+ i; |) z, ?/ f团队什么时候对需求的理解最充分、最多?项目结束的时候!但项目中的绝大部分决策是什么时间做出的呢?项目开始的时候,这就导致了一个悖论,我们在最无知的时刻,做出了最重要而且是绝大部分决策,并把它作为随后执行的依据。$ Z7 s% r q; A/ D
6 b8 X0 Y# w; W0 ?5 L8 F: h8 J这个需求是运营提的,做!这个需求是老板提的,做!$ r' V+ e0 Y }
+ i \( P. H" P: k8 C( E为什么要提这个需求,这个需求的目的是什么,有什么价值,凭什么这样做可以达到目标,哪些数据可以证明,上线后如何衡量此需求真实效果。# }5 U5 w- V5 K# S' c1 B/ h/ j
3 W6 E2 i7 p& {6 D
我们不是乙方外包公司,是和老板站在一条船上的人,有理由有义务搞清楚老板为什么要提这个需求,需求背景是什么,为了解决什么问题,达到什么既定目标,目标结果如何衡量,尝试下”5问法“。( w7 r3 b3 Z6 V# _
需求是泥沙俱下,如果不能正确的分析需求,把握需求的本质,就会沉浸在永无止境的接收需求状态,机械的干活却没有结果。: l5 z# H4 Q' E
[' ]& F- F7 X9 f& J/ C
我们是有思想的手艺人,不是等待老板投食的宠物。* V" a/ c% `) U& X/ n
运营/老板讲解需求的时候,主要是和产品对接,研发、测试不知情不了解。这就会导致一定的信息误差,最后评审需求的时候,研发、测试是站在产品需求文档的角度考虑问题。如果这个文档自身就和业务的期望有差别呢?: ^- E" m; {6 p- D
) g8 O' X o5 j* P我们应该以终为始,聚焦目标,需求前置。在和运营/老板最终需求方案终版的过程中,就应该拉着技术进来,提前介入,预见未来。% h) @. E7 _ @: O. o
在很多人的思维里,认为需求评审就是把需求跟开发详细过一遍,就进入开发阶段。2 _+ z9 d/ k% s0 t+ g# ^6 p9 R
严格来讲,这会导致挺多问题,需求逻辑有缺陷,打回重做,浪费大家时间,经常如此造成大家对你个人能力的质疑。
) r, i3 B0 [+ T所以内部评审是有必要也非常重要的一个环节,但是很多产品不重视这个环节,甚至还有很多产品经理并不知道有内部评审这个环节的存在。
. L( O0 n8 c- Y0 q$ j# K' ]& o产品不需要为单次故障负责,但全年故障数量纳入kpi考核之中,只有屁股在一起,大家才能在一个战壕里更好的思考问题。+ I+ ]; Y: |/ o6 r/ m7 N
2.研发环节# J4 \$ i( t& T7 N2 }* q
) {8 H% V9 ~+ N: N
根据二八定律,20%的需求决定了我们80%的业务价值,它决定了我们的成就,客户的直接反馈,市场竞争力。; {/ C n+ [8 U" i% \
' k5 I) f* A1 R7 b
“持续快速交付价值的能力“,这个价值指的是需求的多寡吗?- d, o1 i8 k! \ C4 V8 O# v
% b- q* c& Q# ~% }# A% L
我们应该聚焦于单位时间内创造价值的效率,这个价值指的是需求上线后对于用户的实际价值。用户价值的流动串起整个系统,促进整体优化的不二选择。为了提高价值的流动效率,组织就必须关注用户价值在系统中端到端的流动过程,改进整个系统,而不仅仅是局部环节。. y( {2 B; |' j4 `5 p; P4 G
# S! i* Z, m8 o/ v' _! T
所以对于大需求,批量性的需求,最好打散拆开,以2-4周作为研发周期,快速迭代,不断打磨优化上线,给予业务以反馈。
0 ?; u/ u) e" A5 X4 V* x1 c" N. q& G; z5 D- v' `# n9 ?
不要给业务surprise,要让业务感知到价值在流动,需求在流动,就像巴普洛夫的狗一样,这群人靠谱,值得信任。. _" v' k& V3 s @5 h
如何保障价值流动的过程质量呢,把交付质量内内建到开发过程中,而不是依赖最后环节的测试。' w! B) ^! ]: c; a8 t
首先要保证基本的单元测试,其覆盖率至少到50%,覆盖主流程,保证冒烟case是ok的。* o3 _. L. r! K+ q/ w) G& s
8 N, n2 b' ^, n
代码改动提交触发集成测试,编译是否出错,代码静态分析,单元测试覆盖率报告。
% _4 y, s" k: Q X. `每月度工程质量梳理,代码缺陷,产品逻辑缺陷梳理,要让光照亮了问题所在,把问题暴露出来,暴露出来的问题,惦记在心里的问题,就不能在叫问题了,叫待优化需求。5 V9 t+ ^& E9 Y* [8 m d
研发对于需求要有一定的预见能力,做好适当的扩展。每半年各系统负责人串讲自己所负责系统设计架构,并提出系统最丑陋的三个地方,开发的时间久了,必然会有灰尘和垃圾,如果一个劲儿堆积需求,垃圾越级越厚,就会积重难返。打扫干净好接客。
. m9 e! b5 r! W' L5 w; ]9 c4 c4 H3.测试环节# \5 ^+ d& s u! a
+ I2 s4 {, p" x' X; D
测试用例评审前置,研发、产品一起参与,把所有的case全部覆盖一遍,对于流程逻辑,直接现场解决,开发在过case的时候,也会不断考虑如何编写更健壮的代码,毕竟我们的目标是提高服务质量,全年无故障,而不是为了给测试冲业绩,比拼bug数量多少。
( S1 F" O1 i- C" W
7 C* a7 p% [! u# `4 Z; v单元测试,集成测试,接口测试,开发环境,测试环境的搭建,上线前checklist检查点。
% s5 @# ^. k. \, |) o; e* L4 t6 h
测试用例的评审,沉淀,积累,不同测试等级下需覆盖功能范围和测试用例。
8 a9 d) K6 A# M7 j: Q3 l% t1 j( }& O1 _
综上$ X& ?" w6 S* B% A
: l3 Z" q. Q$ |$ V0 G. i8 }
横截面主要主要聚焦于角色内,产品:搞清楚问题所在,明确的,清晰的,无歧义的,达成一致的需求;研发:代码的健壮性、可维护性、可扩展性;
0 o% B, O2 Y+ r( J1 Q0 R5 g# s2 @3 q/ ^5 F5 m
测试:多维度的测试用例,测试系统的方方面面。
& i/ ^2 E9 p& |5 t& {4 ], z. b8 C# c5 [4 J7 H7 D- R: h
纵截面,共性就是组织与制度问题、能力问题、沟通问题、选用育留问题。9 c7 m6 C3 x6 G2 [0 w7 g. O# \" u
) v( @- v2 T5 w% W9 }; W9 g, W' o
专业培训不足是导致研发效率未达预期的远因之一,既然如此,我们就要在平时加强员工各方面的培训。1 H5 D+ o) l, i' ]
! j, R: `" u" |6 k0 J& i4 P! |提升人员能力也是提升员工效率的一种方法,能够有效改善部门之间的沟通问题,减少矛盾。# L2 Z* l$ k' S# _) K' V
# @ ~3 }7 s t* p: _* S
, K" `; V# f3 k! j$ K3 Z3 k2 U# k |
|