如何提高研发效能？

showmaker

为什么要提高研发效能，因为技术本身是为业务服务的，产品的价值体现在业务上，技术的所有价值最终都要通过业务结果来呈现，我们的根本目的是帮助业务成功，促进业务腾飞。
; t, G4 T% g* h) @/ D! p
3 L5 r+ h6 L3 j- j8 G+ W, ~- x& I那技术就不重要了吗！重要，因为所有的业务价值最终都要通过软件服务来变现，两者相辅相成，互相促进。
6 H/ S! b* [. D  G" ~4 `3 ]
那如何提高研发效能？

  ]. U; G9 S9 B9 ~9 k, R0 ?4 G0 S 一个项目从立项到上线涉及到角色包含客户、运营、客服、产品、技术、测试。
' Z7 h2 e, u' p4 _  w- u) z
涉及到关键流程如下。
4 D2 ^  |0 v& Q- Q
需求收集，运营/老板 -> 产品，关键产出：想法/idea/业务需求文档
3 B5 j" B5 u# z5 D2 F7 Z2 v
需求评审，产品 -> 运营/老板/技术，关键产出：产品需求文档
& W  w) I+ p3 T! g6 p" H. ^
需求内部评审，产品 -> 运营/老板/技术/若干项目负责人，关键产出：产品需求文档
" u* l# g8 l* D& f8 v
) H, E/ K/ c9 E+ }需求宣讲，产品 -> 研发/测试，关键产出：大家对于问题，目标，需求的理解达成一致
( y; ]! h" a& t
技术方案评审，研发 -> 产品/测试,关键产出：技术架构/代码
& S) {  V5 f, {, [: x
4 q7 i* f' ]" K3 U$ G/ _测试用例评审，测试 -> 研发/产品，关键产出：测试用例/需求逻辑测试case全覆盖
- M$ K, z$ L5 C: r& m! V; Y5 P  G
系统上线，产品/研发/测试 -> 客户

4 p1 }* s9 v' m2 }4 \% f7 ?1 |需求复盘，客户->运营/老板/产品/技术，关键产出：需求客户满意度
' x* {/ P5 S9 s3 X) e

Do things right还是Do right things？


! ^/ U- G7 G% T" ~接下来主要从需求管理，研发，测试三个维度描述，如何Do right things。
2 Z( Q) k& I$ @
- }) [5 \9 W' z" U1 l
5 H& j2 E& G. Y1.需求管理

( S' b( j$ {& x团队什么时候对需求的理解最充分、最多？项目结束的时候！但项目中的绝大部分决策是什么时间做出的呢？项目开始的时候，这就导致了一个悖论，我们在最无知的时刻，做出了最重要而且是绝大部分决策，并把它作为随后执行的依据。
% d- `0 }8 T9 w( m: }0 U
这个需求是运营提的，做！这个需求是老板提的，做！

" X8 w( V# x( a* @( b/ P为什么要提这个需求，这个需求的目的是什么，有什么价值，凭什么这样做可以达到目标，哪些数据可以证明，上线后如何衡量此需求真实效果。

: s/ k$ v8 w% r* S我们不是乙方外包公司，是和老板站在一条船上的人，有理由有义务搞清楚老板为什么要提这个需求，需求背景是什么，为了解决什么问题，达到什么既定目标，目标结果如何衡量，尝试下”5问法“。
) d7 {1 U: c% H; }8 ~: N* i; H

需求是泥沙俱下，如果不能正确的分析需求，把握需求的本质，就会沉浸在永无止境的接收需求状态，机械的干活却没有结果。
- q6 ~2 ]- Y0 h, \* {: V! }# a* S
# h+ X3 i; W3 b/ n' \* a我们是有思想的手艺人，不是等待老板投食的宠物。
/ b( y# R& L1 i% Y5 y; m

运营/老板讲解需求的时候，主要是和产品对接，研发、测试不知情不了解。这就会导致一定的信息误差，最后评审需求的时候，研发、测试是站在产品需求文档的角度考虑问题。如果这个文档自身就和业务的期望有差别呢？

; O: I" G  [# v# d. H/ N我们应该以终为始，聚焦目标，需求前置。在和运营/老板最终需求方案终版的过程中，就应该拉着技术进来，提前介入，预见未来。

  ]  @- r8 c' @ 在很多人的思维里，认为需求评审就是把需求跟开发详细过一遍，就进入开发阶段。
& H! E" K6 `; L& z. Y0 A
5 i" m4 w  R8 D+ z! K& X$ b严格来讲，这会导致挺多问题，需求逻辑有缺陷，打回重做，浪费大家时间，经常如此造成大家对你个人能力的质疑。
# {1 r, ^6 u  A- [% I9 W/ A
, H! D$ ~; y/ q# h9 \2 o所以内部评审是有必要也非常重要的一个环节，但是很多产品不重视这个环节，甚至还有很多产品经理并不知道有内部评审这个环节的存在。

9 ], e/ C* N8 F: O" o 产品不需要为单次故障负责，但全年故障数量纳入kpi考核之中，只有屁股在一起，大家才能在一个战壕里更好的思考问题。
7 ^" y0 P# {5 F& @1 r1 J1 R
9 E$ n. a( o- W8 s% t1 _. P7 } 2.研发环节
+ _6 c( d+ k: k+ M+ L
# `) |- }: q& j, q4 `9 ?. b根据二八定律，20%的需求决定了我们80%的业务价值，它决定了我们的成就，客户的直接反馈，市场竞争力。
! @# D$ t0 m+ B8 L; x( E6 j8 s% ?
  P+ [' j  F4 t' a% z  N“持续快速交付价值的能力“，这个价值指的是需求的多寡吗？
6 h. E, _; F( X) V, v+ l
我们应该聚焦于单位时间内创造价值的效率，这个价值指的是需求上线后对于用户的实际价值。用户价值的流动串起整个系统，促进整体优化的不二选择。为了提高价值的流动效率，组织就必须关注用户价值在系统中端到端的流动过程，改进整个系统，而不仅仅是局部环节。
; J: Y# V# L7 C2 f4 t( K/ s, V
所以对于大需求，批量性的需求，最好打散拆开，以2-4周作为研发周期，快速迭代，不断打磨优化上线，给予业务以反馈。
7 S9 z. H# X2 E' n
不要给业务surprise，要让业务感知到价值在流动，需求在流动，就像巴普洛夫的狗一样，这群人靠谱，值得信任。
  N) C  F5 C% c0 V9 F, M" v
3 c- x, G  U& m2 S
4 X8 G7 z' O$ ?/ ^  E5 ~' w) Y如何保障价值流动的过程质量呢，把交付质量内内建到开发过程中，而不是依赖最后环节的测试。

首先要保证基本的单元测试，其覆盖率至少到50%，覆盖主流程，保证冒烟case是ok的。

5 I) f( U2 ^# \- z- L( B代码改动提交触发集成测试，编译是否出错，代码静态分析，单元测试覆盖率报告。
( r; B5 g- @8 e  O9 e% `
, W( L* c: i3 V/ M8 o
每月度工程质量梳理，代码缺陷，产品逻辑缺陷梳理，要让光照亮了问题所在，把问题暴露出来，暴露出来的问题，惦记在心里的问题，就不能在叫问题了，叫待优化需求。
) i  M( s! m  H6 k. h4 `1 R
, _7 f. I: [2 a+ V/ z9 n; B" Q5 @, @ 研发对于需求要有一定的预见能力，做好适当的扩展。每半年各系统负责人串讲自己所负责系统设计架构，并提出系统最丑陋的三个地方，开发的时间久了，必然会有灰尘和垃圾，如果一个劲儿堆积需求，垃圾越级越厚，就会积重难返。打扫干净好接客。
6 y9 A# Z5 X1 P/ |

  N! [8 z: c) e6 }% U2 A' \5 z3.测试环节

测试用例评审前置，研发、产品一起参与，把所有的case全部覆盖一遍，对于流程逻辑，直接现场解决，开发在过case的时候，也会不断考虑如何编写更健壮的代码，毕竟我们的目标是提高服务质量，全年无故障，而不是为了给测试冲业绩，比拼bug数量多少。

8 o+ {# E* T* j6 h单元测试，集成测试，接口测试，开发环境，测试环境的搭建，上线前checklist检查点。

/ x( W4 v# V! U* ~  ?9 ^测试用例的评审，沉淀，积累，不同测试等级下需覆盖功能范围和测试用例。


综上
' F* ?0 k6 ]8 a$ Z
横截面主要主要聚焦于角色内，产品：搞清楚问题所在，明确的，清晰的，无歧义的，达成一致的需求；研发：代码的健壮性、可维护性、可扩展性；
8 t: y- \% @% k4 W- W, P! `4 D
4 i9 e4 Z) {5 I) r7 T1 h/ H* f测试：多维度的测试用例，测试系统的方方面面。
% g7 ?1 b1 [) r9 r6 v: ^
纵截面，共性就是组织与制度问题、能力问题、沟通问题、选用育留问题。
* h9 R) u& s9 ]. K! r. P, N
专业培训不足是导致研发效率未达预期的远因之一，既然如此，我们就要在平时加强员工各方面的培训。
' ~; h. f; a# z, P, r* v" X, l5 c+ m) A; N
, l5 u/ [5 F" n* }- i提升人员能力也是提升员工效率的一种方法，能够有效改善部门之间的沟通问题，减少矛盾。


: t5 C# h+ {/ _7 _8 E! r4 |8 O

damengshu

内部评审是有必要也非常重要的一个环节

CLBuu

如果不能正确的分析需求，把握需求的本质，就会沉浸在永无止境的接收需求状态，机械的干活却没有结果

hunterccc

学习学习  感谢分享

RNGxiaohu

单元测试，集成测试，接口测试，开发环境，测试环境的搭建，上线前checklist检查点

Blah

为什么要提高研发效能，因为技术本身是为业务服务的，产品的价值体现在业务上，技术的所有价值最终都要通过业务结果来呈现，我们的根本目的是帮助业务成功，促进业务腾飞