研发团队应该怎样提升业务能力?

大小的小

一天下午，测试提了一个Bug给我。测试反馈说列表展示结果与需求不符，我便再重新去核对最新版的需求。这块需求有订单模块的处理，涉及到同事的逻辑处理。 我便与同事进行沟通，可我们之间的业务对接有歧义。我们便找来产品经理，产品经理与我们讲解了两个模块之间的业务关系，然后又发现两个模块之间的业务改变涉及到的改动非常大.....

+ f0 w6 t8 q% u4 P! N
7 b1 V0 E* R- }" V7 O% O

: s- q9 B3 |7 ~8 j8 q* g. ~

这件事以后，我就开始思考，研发团队一起开发项目，每个人根据Leader分配的模块进行开发，各自负责各自的模块。而对于其他人负责的模块的业务逻辑不是很清楚，等开发到涉及到其他模块的功能或逻辑，再与其他人进行沟通，有问题才找产品经理进行确认。没有人统筹整个业务逻辑，完全根据产品文档进行开发，一旦产品某一处逻辑改变，涉及到相关业务无法预估风险。

研发人员拿到需求文档，可能就直接上手写代码。并没有想清楚之间的业务逻辑，没有进行编写文档就进行开发。开发完成后，只能等待测试人员测试，才能知道功能模块的业务逻辑是否与产品文档一致。

" Y2 a' y: O. t) D( m3 k

怎么解决研发人员对业务理解不透彻？研发人员业务感不强的问题？

第一，优化组织架构。研发人员分成几个小组，每个小组有一个专属的项目负责人，进行项目实施，各项目负责人对这些重点项目，一竿子管到底，确保项目彻底执行。以产品线进行划分，快速迭代开发出产品，符合市场的规划。比如，研发人员分成2~3组，每组保留2~3个主力开发，其他人都是在各项目组任意调配。

1 b) z- ^4 B$ E; w) _) t

第二，培养懂业务的技术专家，指的是产品设计人员，研发人员，测试人员都要懂业务，研究业务模式，知道生意的痛点是什么。大部分的用户往往不知道自己想要什么，所以很难提出准确真实的需求，技术人员学习业务知识，用软件工程的方法，将各种想法变成产品让用户使用，收集反馈并且快速改进，越来越接近用户的真实需求。鼓励整个开发团队学习业务，成为业务专家，也是互联网产品开发对技术团队的要求，技术团队越来越角色模糊化，其目的是减少沟通成本，提高协作效率，团队成熟度提升更快，以最佳的状态投入到激烈的市场竞争当中去。

3 P! m' F6 d7 X6 N2 @7 U
, z) K0 y# ~  R. j" v: E
" X& \6 ^  q8 {+ Y9 q- m1 O5 \5 K

培养懂业务的技术专家，方法多种多样，包括到业务部门轮岗、倾听顾客声音、用户深度访谈、业务知识培训等，只有持之以恒地努力，才能够增强对业务的敏感度，积累解决业务问题的经验。

研发人员的“业务感”普遍比较弱，认为业务需求是业务方的事情，我只管去实现就好，这种想法，使得技术人员失去了应有的价值。技术人员是一群具备系统性思维的聪明人，应该用系统性思维去解决业务上碰到的共性的问题，有效地提高业务各个环节的效率，最终实现技术驱动业务的发展，为企业创造更大的价值。

研发人员增强业务感，还需要去前线听“炮声”。 要避免“闭门造车”、“与业务脱节”、“不懂顾客”等现象，最有效的解决办法是，倾听用户的声音，只有这样才能更接近用户的真实需求，具备独立思考产品的能力。倾听用户的声音，可以结合调查问卷、用户深度访谈等方法，这都是一些比较成熟的方法。

$ i" J, j) i; C. a7 k

以下是几个行之有效的方法：

第一，成为产品的深度用户。如果产品的用户是公司内部的同事，轮岗是一个比较好的方式，比如1号店有个不成文的规定，技术骨干每个月必须到业务部门轮岗，跟业务部同事一起操作系统，强制自己换位思考，这种方式对研发人员培养业务感也是有帮助的。

第二，整理产品需求列表。通过用户访谈、用户意见反馈、业务人员提交的需求、同行的竞品分析报告等，进行需求的分类汇总，统计哪一类需求是有共性的问题、被用户诟病最多的问题，结合内部讨论来制定需求的优先级。

lupkpu9