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

[员工激励] 如何提高研发效能?

[复制链接]

该用户从未签到

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

EDA365欢迎您登录!

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

x
为什么要提高研发效能,因为技术本身是为业务服务的,产品的价值体现在业务上,技术的所有价值最终都要通过业务结果来呈现,我们的根本目的是帮助业务成功,促进业务腾飞。
& j, n) d! i( L7 X3 e# Y  N+ ~& Z9 ~3 V  f0 a
那技术就不重要了吗!重要,因为所有的业务价值最终都要通过软件服务来变现,两者相辅相成,互相促进。6 X7 x2 E2 k4 ^% @

7 m) L. f5 p9 p6 r 那如何提高研发效能?
4 V$ U# H" E+ _7 }+ T, V3 z$ c/ m! ?; u1 H# G2 F% c2 F# X3 b3 z
一个项目从立项到上线涉及到角色包含客户、运营、客服、产品、技术、测试。
7 |8 q* d6 n# }
) M- ~3 m* y8 p 涉及到关键流程如下。1 u% Q/ K' B' S; s* t5 V

& P1 q8 u  U* b+ v' c- {需求收集,运营/老板 -> 产品,关键产出:想法/idea/业务需求文档9 @4 F. e. W) A' y+ K/ j+ `

6 h+ g" r: A; i" R+ B* W6 T需求评审,产品 -> 运营/老板/技术,关键产出:产品需求文档& ~0 I6 @* B/ M  s2 x  Z

9 k# v& F1 {' |& j' A) Z4 t1 n) Z! D7 ~需求内部评审,产品 -> 运营/老板/技术/若干项目负责人,关键产出:产品需求文档, |1 |: ^4 s+ B0 h

) G5 b# O7 P; O/ U需求宣讲,产品 -> 研发/测试,关键产出:大家对于问题,目标,需求的理解达成一致
! S+ M1 h- X% S% ~; n1 O1 F9 i
2 E" }, c. _( D技术方案评审,研发 -> 产品/测试,关键产出:技术架构/代码
$ j" P8 J) r0 J$ X: l! l: I/ B: k: {0 V) V# v: Y) t6 d/ j  N6 I
测试用例评审,测试 -> 研发/产品,关键产出:测试用例/需求逻辑测试case全覆盖
+ W$ v" l- M9 l- U
* N; |' L9 g, p# F系统上线,产品/研发/测试 -> 客户
; K" x3 Y) ?1 Q. e& @' K, l8 D/ `  P  R8 G" G
需求复盘,客户->运营/老板/产品/技术,关键产出:需求客户满意度! Q$ }: \) p9 S7 j+ b  I/ |* O
% c- g9 y% \# |( o+ o5 h, Q

4 Q  t: A  o+ }0 }! e& TDo things right还是Do right things?
0 W7 S* ?; M* `2 J9 A' q
% i. V% z" l8 {6 q: g7 ~ & O! }4 n  g7 [6 V  r$ w4 D' z1 Y
接下来主要从需求管理,研发,测试三个维度描述,如何Do right things。
3 M9 c: T% u. t% L
! a0 C$ W! a0 T8 g: e
$ B9 S' f5 _% ~/ j6 n( j# b1.需求管理
; e! o0 D$ \/ u
7 n" M7 M# b( H% _2 T. s% r7 n% H) J团队什么时候对需求的理解最充分、最多?项目结束的时候!但项目中的绝大部分决策是什么时间做出的呢?项目开始的时候,这就导致了一个悖论,我们在最无知的时刻,做出了最重要而且是绝大部分决策,并把它作为随后执行的依据。9 z8 C! v, H' Q. C/ z
6 J4 N4 n8 P" _3 z; G1 t6 o
这个需求是运营提的,做!这个需求是老板提的,做!
; O$ ]" K/ j7 W8 Z. |* H" Q) Y7 }1 c  _0 @
为什么要提这个需求,这个需求的目的是什么,有什么价值,凭什么这样做可以达到目标,哪些数据可以证明,上线后如何衡量此需求真实效果。: p0 X' ?$ l3 Y. Q, Y

: q/ |$ y  M& J2 i% N! R我们不是乙方外包公司,是和老板站在一条船上的人,有理由有义务搞清楚老板为什么要提这个需求,需求背景是什么,为了解决什么问题,达到什么既定目标,目标结果如何衡量,尝试下”5问法“。6 V; ~# O6 k- [+ T# A( O" v: _& V
9 G6 b" }+ Q7 [$ K4 {$ {

3 d& m) b" i& C% U- q+ M+ |! d: c需求是泥沙俱下,如果不能正确的分析需求,把握需求的本质,就会沉浸在永无止境的接收需求状态,机械的干活却没有结果。
9 A$ B6 k. }! G$ G+ t' K' J5 y- M5 T: T/ U+ p  ~2 Q* a- [
我们是有思想的手艺人,不是等待老板投食的宠物。! q! G/ L: C' j

6 O" u. V3 h, X! K" u- d2 u3 P
. n  t. B: q5 D; V9 e运营/老板讲解需求的时候,主要是和产品对接,研发、测试不知情不了解。这就会导致一定的信息误差,最后评审需求的时候,研发、测试是站在产品需求文档的角度考虑问题。如果这个文档自身就和业务的期望有差别呢?# A: n# C1 x% s6 U$ \

1 F' r6 P* t% ~* |9 r0 o1 }8 c' K9 M我们应该以终为始,聚焦目标,需求前置。在和运营/老板最终需求方案终版的过程中,就应该拉着技术进来,提前介入,预见未来。
" m. ?" v5 t! g7 E9 d5 ~* V+ A$ S! ~! N7 E+ L. o
在很多人的思维里,认为需求评审就是把需求跟开发详细过一遍,就进入开发阶段。
; u  T8 \" D0 W+ q6 n) F( |" l
1 g9 ~5 @( o1 }( e; y$ _7 k9 ~严格来讲,这会导致挺多问题,需求逻辑有缺陷,打回重做,浪费大家时间,经常如此造成大家对你个人能力的质疑。
' }: S! L6 i+ I% H$ c
: }" {: @& r% }6 y' f! i所以内部评审是有必要也非常重要的一个环节,但是很多产品不重视这个环节,甚至还有很多产品经理并不知道有内部评审这个环节的存在。
4 a4 b$ a/ J* b- d. F% x
5 e5 N: o. j, x/ x! h4 Y 产品不需要为单次故障负责,但全年故障数量纳入kpi考核之中,只有屁股在一起,大家才能在一个战壕里更好的思考问题。
. Y0 [# y' y  y/ N  V( w, W& {7 {2 b0 {6 j. d" c
2.研发环节3 {8 e5 x3 o. K

4 ?+ X; s* @& A4 r- b根据二八定律,20%的需求决定了我们80%的业务价值,它决定了我们的成就,客户的直接反馈,市场竞争力。+ Z# P1 T$ R- I- k. N
4 U4 I2 v- a* t( \. Q3 i
“持续快速交付价值的能力“,这个价值指的是需求的多寡吗?( e& H0 r3 Y& H
" d1 ^0 H' F4 l' i* t
我们应该聚焦于单位时间内创造价值的效率,这个价值指的是需求上线后对于用户的实际价值。用户价值的流动串起整个系统,促进整体优化的不二选择。为了提高价值的流动效率,组织就必须关注用户价值在系统中端到端的流动过程,改进整个系统,而不仅仅是局部环节。0 K" Q) V) Z2 o- w1 r; w. s: Y6 `

: V' H1 a1 L' o# ]: S! k6 G所以对于大需求,批量性的需求,最好打散拆开,以2-4周作为研发周期,快速迭代,不断打磨优化上线,给予业务以反馈。
  k! E( _3 M8 Q1 J( m6 }# a! Y% W- \$ k, r/ X* U9 V) y
不要给业务surprise,要让业务感知到价值在流动,需求在流动,就像巴普洛夫的狗一样,这群人靠谱,值得信任。
. }' j- T7 j8 f" m1 O! t) Z& E' X( y, R$ @
8 C9 P1 ?6 K, W7 A: l' T
如何保障价值流动的过程质量呢,把交付质量内内建到开发过程中,而不是依赖最后环节的测试。
5 i; V/ n! b/ t; }. `6 Q
& \  h# N, v) Y  [$ R首先要保证基本的单元测试,其覆盖率至少到50%,覆盖主流程,保证冒烟case是ok的。. h6 w* B7 T: R4 y; G

% R) |& {9 c! L5 n" W: g) k1 _代码改动提交触发集成测试,编译是否出错,代码静态分析,单元测试覆盖率报告。2 o+ ~+ L, b% x6 g
$ o0 t3 w! b% I) X) W
( V, G- b- F0 f) I# _9 `, q
每月度工程质量梳理,代码缺陷,产品逻辑缺陷梳理,要让光照亮了问题所在,把问题暴露出来,暴露出来的问题,惦记在心里的问题,就不能在叫问题了,叫待优化需求。7 f5 ^9 Q, b1 j+ y+ r. H2 d

; ^/ Q2 W. s% D. H3 R, W% ^ 研发对于需求要有一定的预见能力,做好适当的扩展。每半年各系统负责人串讲自己所负责系统设计架构,并提出系统最丑陋的三个地方,开发的时间久了,必然会有灰尘和垃圾,如果一个劲儿堆积需求,垃圾越级越厚,就会积重难返。打扫干净好接客。
6 A/ I" L( B5 k  I* t* T1 i0 W  \! j4 C& q0 S( x

5 v6 g7 i' n& u3.测试环节0 c% D+ u! A+ {+ s" q) L* ]

4 K! F' Z$ U' O; W+ C/ R测试用例评审前置,研发、产品一起参与,把所有的case全部覆盖一遍,对于流程逻辑,直接现场解决,开发在过case的时候,也会不断考虑如何编写更健壮的代码,毕竟我们的目标是提高服务质量,全年无故障,而不是为了给测试冲业绩,比拼bug数量多少。
! j/ ^; [4 k  [- z/ n# {- M5 m- |  e0 ~  U3 Y& {, }
单元测试,集成测试,接口测试,开发环境,测试环境的搭建,上线前checklist检查点。
- u7 r& w% c+ z( D; ^8 k  ]$ w, m' W( j2 y
测试用例的评审,沉淀,积累,不同测试等级下需覆盖功能范围和测试用例。
/ W& }& t8 E  v. s( a
4 z( j3 i- A4 _( H9 V) J' k
( D* B" ^: h* _& u综上  T# @3 W! k; b  c
: t0 j3 J% {4 E3 Y# T# O
横截面主要主要聚焦于角色内,产品:搞清楚问题所在,明确的,清晰的,无歧义的,达成一致的需求;研发:代码的健壮性、可维护性、可扩展性;; b  S4 h3 a/ ~; w

# r8 K' A/ }4 Z; x& D测试:多维度的测试用例,测试系统的方方面面。! m1 I5 f( }6 i2 f7 W

# C" `, u# r* I' W纵截面,共性就是组织与制度问题、能力问题、沟通问题、选用育留问题。7 _6 ?* \' C% \

% x7 {; F$ M  L专业培训不足是导致研发效率未达预期的远因之一,既然如此,我们就要在平时加强员工各方面的培训。! C& v. g0 \; ]3 W. K& ?
$ G- y1 T% _. s" e. C) |
提升人员能力也是提升员工效率的一种方法,能够有效改善部门之间的沟通问题,减少矛盾。
$ E' _+ w* B4 v1 r/ C0 M
. V% m8 E* W8 p) L) I$ Y" }6 n: z: h( S

该用户从未签到

2#
发表于 2021-9-13 13:38 | 只看该作者
内部评审是有必要也非常重要的一个环节
# e6 I: H; S& L$ }

该用户从未签到

3#
发表于 2021-9-13 13:53 | 只看该作者
如果不能正确的分析需求,把握需求的本质,就会沉浸在永无止境的接收需求状态,机械的干活却没有结果

该用户从未签到

4#
发表于 2021-9-13 16:43 | 只看该作者
学习学习  感谢分享

该用户从未签到

5#
发表于 2021-9-14 16:43 | 只看该作者
单元测试,集成测试,接口测试,开发环境,测试环境的搭建,上线前checklist检查点
  • TA的每日心情
    开心
    2023-6-2 15:15
  • 签到天数: 1 天

    [LV.1]初来乍到

    6#
    发表于 2021-9-23 18:20 | 只看该作者
    为什么要提高研发效能,因为技术本身是为业务服务的,产品的价值体现在业务上,技术的所有价值最终都要通过业务结果来呈现,我们的根本目的是帮助业务成功,促进业务腾飞
    , S: I# D) R1 j) `
    您需要登录后才可以回帖 登录 | 注册

    本版积分规则

    关闭

    推荐内容上一条 /1 下一条

    EDA365公众号

    关于我们|手机版|EDA365电子论坛网 ( 粤ICP备18020198号-1 )

    GMT+8, 2025-6-9 14:36 , Processed in 0.078125 second(s), 23 queries , Gzip On.

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

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

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