研发效率破局之道-学习思考

最近公司研发效率有下降的趋势，在学习了极客时间 《研发效率破局之道》之后
有一些思考

效率

站在公司业务领导，或者老板角度看，效率就是最少的人干最多的活，如果领导外行，那么下属就会增加工时，陷入了无尽循环。

目前大家的工作流程基本上 是业务提出需求，产品设计方案，开发根据产品设计逻辑方案实现逻辑，测试组进行功能测试，之后上线验收。

业务方缺少参与

业务方会提出各种各样的需求，但很少参与全流程，基本上是把想法告诉产品之后，就准备验收。
这种情况下，信息的传递会产生缺失，会导致上线之后功能并不是业务方想要的结果。
这种情况下基本上是产品没有把控需求，把自己当做传声筒。
这种情况很普遍。

产品缺少规划

产品部门为了完成KPI ,对业务部门的需求来着不拒，导致系统业务逻辑混乱，很多时候领导发话，就直接提需求，没有长远规划。
后期导致产品业务逻辑不通，很多功能需要找开发了解信息。

对于简单的业务，或许可以依靠团队协作把控产品，一旦涉及复杂的ToB 业务，整个团队效率越来越低

开发 不理解业务

开发不理解业务需求，一味复用接口，前后端 配合不一致，导致 产品细节不一致

开发过程中，一旦提供基础的接口的人员不给力，拖延整个团队。

对于跨组协作，没有提前规划好接口细节，导致联调的时候跟中异常。

服务不做治理，技术架构不更新。老旧技术阻碍效率。

测试较真

测试按照自己的理解，刻意制造测试bug ,对于正常业务无法触发的场景，人为制造。

测试对于业务不理解，在测试阶段针对功能缺失提出bug.

导致产品和开发从新梳理逻辑，

经常发生的场景是 测试阶段、产品、测试、开发 在一起去对需求。

团队协作

团队协作，需要一个负责的领导，如果领导要求各个团队各司其职，那么基本上就是大家都不管。

软件开发的生命周期，很难做到责任边界清晰，产品设计的业务逻辑如果有缺陷 开发应不应该指出，

开发的工时评估很大程度上受到产品细节的影响，谁来决定细节，产品设计逻辑的时候 和现在的业务逻辑有冲突，开发写不写代码，要不要需求重新评审。

开发不理解产品的业务逻辑 ，算 产品没有讲清楚还是开发理解不到位。

测试提出的bug 到底是产品没有考虑到 还是 开发代码有问题，或者是环境不稳定导致。

开发效率

开发效率的本质还是人的问题，如果一个优秀的团队，大家积极主动 一切问题都会被解决。

但是如果大家能力不济，那么团队中优秀的人会承担更多的思考。

越平庸的团队管理成本越高，公司开发团队的能力基本上和薪资成正比。

破局之道

在学习了极客时间的课程之后， 发现国外的国内的差异巨大，很多世界级别的优秀公司基本上重视工程师文化，

国内则是 侧重产品，产品往往比技术更加接近核心

对于管理本质是权责明确对等。