论如何提高研发效能

架构 专栏收录该内容
15 篇文章 0 订阅

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

那技术就不重要了吗!重要,因为所有的业务价值最终都要通过软件服务来变现,两者相辅相成,互相促进。

 

那如何提高研发效能?

 

一个项目从立项到上线涉及到角色包含客户、运营、客服、产品、技术、测试。

 

涉及到关键流程如下。

需求收集,运营/老板 -> 产品,关键产出:想法/idea/业务需求文档

需求评审,产品 -> 运营/老板/技术,关键产出:产品需求文档

需求内部评审,产品 -> 运营/老板/技术/若干项目负责人,关键产出:产品需求文档

需求宣讲,产品 -> 研发/测试,关键产出:大家对于问题,目标,需求的理解达成一致

技术方案评审,研发 -> 产品/测试,关键产出:技术架构/代码

测试用例评审,测试 -> 研发/产品,关键产出:测试用例/需求逻辑测试case全覆盖

系统上线,产品/研发/测试 -> 客户

需求复盘,客户->运营/老板/产品/技术,关键产出:需求客户满意度

 

Do things right还是Do right things?

 

接下来主要从需求管理,研发,测试三个维度描述,如何Do right things。

 

1.需求管理

团队什么时候对需求的理解最充分、最多?项目结束的时候!但项目中的绝大部分决策是什么时间做出的呢?项目开始的时候,这就导致了一个悖论,我们在最无知的时刻,做出了最重要而且是绝大部分决策,并把它作为随后执行的依据。

这个需求是运营提的,做!这个需求是老板提的,做!

为什么要提这个需求,这个需求的目的是什么,有什么价值,凭什么这样做可以达到目标,哪些数据可以证明,上线后如何衡量此需求真实效果。

我们不是乙方外包公司,是和老板站在一条船上的人,有理由有义务搞清楚老板为什么要提这个需求,需求背景是什么,为了解决什么问题,达到什么既定目标,目标结果如何衡量,尝试下”5问法“。

 

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

我们是有思想的手艺人,不是等待老板投食的宠物。

 

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

我们应该以终为始,聚焦目标,需求前置。在和运营/老板最终需求方案终版的过程中,就应该拉着技术进来,提前介入,预见未来。

 

在很多人的思维里,认为需求评审就是把需求跟开发详细过一遍,就进入开发阶段。

严格来讲,这会导致挺多问题,需求逻辑有缺陷,打回重做,浪费大家时间,经常如此造成大家对你个人能力的质疑。

所以内部评审是有必要也非常重要的一个环节,但是很多产品不重视这个环节,甚至还有很多产品经理并不知道有内部评审这个环节的存在。

 

产品不需要为单次故障负责,但全年故障数量纳入kpi考核之中,只有屁股在一起,大家才能在一个战壕里更好的思考问题。

 

2.研发环节

根据二八定律,20%的需求决定了我们80%的业务价值,它决定了我们的成就,客户的直接反馈,市场竞争力。

“持续快速交付价值的能力“,这个价值指的是需求的多寡吗?

我们应该聚焦于单位时间内创造价值的效率,这个价值指的是需求上线后对于用户的实际价值。用户价值的流动串起整个系统,促进整体优化的不二选择。为了提高价值的流动效率,组织就必须关注用户价值在系统中端到端的流动过程,改进整个系统,而不仅仅是局部环节。

所以对于大需求,批量性的需求,最好打散拆开,以2-4周作为研发周期,快速迭代,不断打磨优化上线,给予业务以反馈。

不要给业务surprise,要让业务感知到价值在流动,需求在流动,就像巴普洛夫的狗一样,这群人靠谱,值得信任。

 

如何保障价值流动的过程质量呢,把交付质量内内建到开发过程中,而不是依赖最后环节的测试。

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

代码改动提交触发集成测试,编译是否出错,代码静态分析,单元测试覆盖率报告。

 

每月度工程质量梳理,代码缺陷,产品逻辑缺陷梳理,要让光照亮了问题所在,把问题暴露出来,暴露出来的问题,惦记在心里的问题,就不能在叫问题了,叫待优化需求。

 

研发对于需求要有一定的预见能力,做好适当的扩展。每半年各系统负责人串讲自己所负责系统设计架构,并提出系统最丑陋的三个地方,开发的时间久了,必然会有灰尘和垃圾,如果一个劲儿堆积需求,垃圾越级越厚,就会积重难返。打扫干净好接客。

 

3.测试环节

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

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

测试用例的评审,沉淀,积累,不同测试等级下需覆盖功能范围和测试用例。

 

 

综上

横截面主要主要聚焦于角色内,产品:搞清楚问题所在,明确的,清晰的,无歧义的,达成一致的需求;研发:代码的健壮性、可维护性、可扩展性;

测试:多维度的测试用例,测试系统的方方面面。

纵截面,共性就是组织与制度问题、能力问题、沟通问题、选用育留问题。

专业培训不足是导致研发效率未达预期的远因之一,既然如此,我们就要在平时加强员工各方面的培训。

提升人员能力也是提升员工效率的一种方法,能够有效改善部门之间的沟通问题,减少矛盾。

 

说了那么多,我也只是个瞎逼逼的看客一个,欢迎吐糟。

 

欢迎关注我的微信公众号沐于清明一起交流

  • 2
    点赞
  • 0
    评论
  • 8
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

扫大街的程序员

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值