从4个优势2个分析法拆解研发为什么要懂业务

研发人员为什么要懂业务呢？我们带着疑问继续往下面看。

举个栗子，产品提了一个需求，下单需要支持组合商品（多个SKU组合），
大部分情况下，当一个需求涉及改造全流程、影响范围广的时候，研发人员可能存在拒绝需求的情况，拒绝的理由也比较直接，比如是：影响稳定性、影响性能、改动大等，都是从技术角度出发。

其实有时候稍微转换下角度，我们可以从影响范围、工时、价值方面与产品、业务沟通该需求是否值得投入大量人力成本，毕竟任何创新的东西，都不是容易的事情。

研发、产品、运营思维对比

在日常的工作中，研发、产品、运营不乏存在相互吐槽的情况：

• 研发吐槽这需求改来改去，不切实际，天马行空…
• 产品运营吐槽这需求明明很简单，为啥开发周期需要那么长，为啥实现不了…

等等以上吐槽，抛开三方工作经验导致的问题以外，其实更多的是产品思维、运营思维、研发思维的碰撞，导致了大家对同一件事情的认知不同，从各自的角度出发表示难以理解。来看一组三方思维、工作内容的对比：

研发具备一定的业务思维，站在产品角度去思考问题，就容易和产品团队沟通协作培养更加融洽的工作关系、更有利于提升工作效率。

懂业务的优势

1、可以更好的理解需求

理想情况下，研发只需要按照产品经理的需求文档、详细规则编码就好，但现实中这样真的可行吗？这里打一个问号？

在敏捷的开发模式下，版本的节奏越来越快，对产品经理业务经验的要求也随着提升，面对经验欠缺、新手的产品经理时，研发完全依赖产品的需求文档，是会存在一定的风险，比如：频繁改动，还未上线就夭折的情况。

正确的做法是，研发结合产品给出的需求背景、用户场景去思考，该需求真正要解决的问题是什么？能达到治标又治本的效果吗？这个过程可以和产品经理保持紧密的沟通协作，尽量做到一起共创需求。

福特汽车公司的创始人亨利·福特就曾经说过：“如果我最初问消费者他们想要什么，他们会告诉我要一匹更快的马。”

2、更好的设计技术方案

小到需求任务拆分，大到中台化建设、微服务拆分。
在这些过程中，都离不开对业务的理解，需要将生硬的场景，按照面向对象的思维去进行理解设计。

设计方案过程中，除了考虑功能实现，还需要考虑性能、高可用、可扩展性、技术选型等。这些设计都不是凭空产生的，需要研发结合业务场景、业务特点去设计。

3、培养全局思维

作为一个开发负责人，想高质量的让团队完成开发，保障项目平稳上线。则需要把控整个项目的流程是否形成闭环，正向逆向流程考虑是否周全，风险的处理是否全面等。这些都需要我们熟悉业务的来龙去脉后，站在一个全局的角度去看待问题，不仅仅只是关注代码的实现。

4、为职业发展提供更多的可能性

研发的职业发展大致三条路，技术管理/CTO、业务技术架构/首席科学家、创业。无论哪一条路，越往上走，对业务能力的要求越高，高管每天谈论的都是公司战略、市场行情、如何盈利等相关业务的事情。

如何提升业务能力

1、5W1H8C1D分析法

一图胜千言，请看图：

2、用户生命周期漏斗模型分析法

① 获取
获取环节首先要做的就是触达用户，直白来说就是让用户知道我们的产品，触达的路径就是我们通常听到的“渠道”，比如广告、社交推广、老用户推荐、主播推荐等手段。

触达用户后，吸引用户进入产品是获取环节的关键。这个环节可通过新人优惠政策、现金红包奖励等福利留住用户。

② 激活
激活是第二个环节，我们需要把获取的用户转化为产品的真实用户。简单来说，就是用户下载了你的 App 后，至少要打开 App 体验一下核心的业务。

③ 留存
留存是第三个环节，我们需要把激活的用户转换为产品的长期用户，避免出现“用户来得快，走得也快”的现象。

④ 收益
收益是第四个环节，我们需要将留存的用户转换为收益，这样企业才能获取收入，毕竟绝大部分商业产品的最终目标是获得利润。

⑤ 推荐
推荐是最后一个环节，我们需要通过“以老带新”的方式来实现用户增长。

最后
技术只有通过业务才能实现价值，无论是业务开发还是架构组件开发都是一个道理，最本质的区别是直接与间接的关系，业务开发直接面向业务场景；架构组件开发，通过业务代码承上启下，间接关联。