在需求获取过程中后台产品的需求有什么不同

　　后台产品和前台产品因面对的用户不同，在需求上也有比较明显的区别，前台产品又可以称为用户产品，主要面向的是C端或B端用户，在进行产品规划、设计时更多的考虑的是用户需求、用户体验。而后台产品则有些不同，后台产品主要为内部用户使用，或者与内部其他业务系统之间发生交互以实现某种功能。
　　所以对于后台产品来说，在需求获取过程中大致可分为两种类型的需求：产品类需求、交互类需求。
　　（1）产品类需求
　　这类需求往往是针对于公司内部业务人员使用的产品，如一个资讯类产品，内容运营人员需要使用一个后台系统对内容进行整理、编辑，并发布到前端让用户可见。这样的一个业务系统就是后台产品，那么这类产品的需求一般由其他部门业务人员提出，产品的设计就要满足业务人员的需求。
　　（2）交互类需求
　　对于大公司或者较大的业务平台，从前端到后台，涉及多个系统或多个业务模块，业务模块之间根据流程或者功能进行区分，每个模块由不同团队负责，这种情况下，当一个业务模块需要进行需求优化时，可能就会依赖流程上下游其他模块的支持。如对于大型电商平台来说，用户选择产品下单支付的这样一个行为，后端系统就涉及到前端、订单、支付平台之间的交互，那么如果前端对于支付方式或者支付流程进行了更改，后台的订单模块、支付模块也需要进行相应的更改，这就涉及到业务模块之间的交互，更多的是交互流程和数据之间的需求。
　　1. 需求来源
　　基于上面提到的需求类型，后台产品的需求来源主要会分为三大类：业务人员、其他业务系统的产品经理、老板。
　　（1）业务人员
　　业务人员的需求往往针对于后台产品经理负责的产品或业务系统，这类业务系统为支撑业务人员实现某些业务场景而设计，对于业务场景的变更或者业务的发展，业务人员往往会对现有业务系统提出新的需求。
　　（2）其他业务系统的产品经理
　　对于大型业务平台来说，多个业务系统之间是上下游关系，在业务流程、数据交互上都会有所关联，那么其他业务系统的产品经理当需要进行系统重构、系统需求迭代时，也会提出需要配合的需求。
　　（3）老板
　　之所以把老板这个需求来源放在最后，主要是因为他既可能提出业务人员的需求、也有可能提出其他业务系统产品经理的需求。老板的视角通常是站在整个业务线甚至是事业群的视角去看待产品的迭代或优化，所以他提出的需求可能是只针对一个业务模块，也有可能针对整个业务流程，所以对于老板提出的需求需要具体问题具体分析。
　　2. 需求沟通
　　对于后台产品来说，需求的获取方式比前端或者用户产品更容易，不用通过用户访谈、问卷调查这些方式去获取需求。后台产品涉及到的＂用户＂通常都是公司内部人员，通过组织需求沟通会即可，然而，需求容易获取并不代表可以容易的明确需求。
　　组织需求沟通会，对于后台产品来说是基本功之一：
　　首先要明确需求涉及的相关干系人，通过会前通知、会议邀请等方式，在需求沟通会上将需求相关干系人全部组织到一起。
　　其次，在需求沟通的过程中，不要被带入误区，一定要明确需求的背景，即为什么要做这个需求吗，做这个需求可以解决什么问题。很多时候业务人员会在提出需求后紧接着提出解决方案，但是这种方式一定是有问题的。业务人员可以提出自己的业务解决方案，但是产品的解决方案一定是产品经理去思考的，不能被业务人员带到沟里，往往业务人员提出的方案会有一定的局限性，也许是局部最优，但一定不是全局最优。
　　最后，如果需求涉及多个角色或多个业务系统，一定要在沟通需求的时候让各方达成共识，否则后期一旦有一方产生意见不一致，很容易造成需求的delay。
　　3. 需求分析
　　经过需求沟通会明确需求内容后，下一步就是要对需求进行分析，分析的目标主要有两个：如何做以及什么时候做，分析的方法这里介绍三种比较接地气的：
　　（1）重要紧急程度分析
　　重要紧急程度四象限分析法比较常见，主要思想即对一个需求从重要和紧急两个维度进行分析，排序需求的优先级。
　　对于重要紧急的需求要优先做，比如老板说XX日前必须实现某某功能。
　　对于重要不紧急的工作可以排期到迭代中，比如某业务线说，这个功能不着急，在这个季度结束前能用就好。
　　对于紧急不重要的需求，要进行一定辨析，紧急但不重要的原因是什么，是否可以选择简单的解决方案优先排期。
　　对于不紧急且不重要的需求来说，可以与需求提出人进行沟通，争取将需求砍掉。
　　（2）依赖性原则
　　上文中提到后台需求中，有部分需求的完成是需要依赖于业务上下游其他业务系统的，那么对于这类需求的排期和解决方案，就需要与有依赖的业务系统模块进行确认，确认对方什么时候做，对方的排期与自己排期之间是否有时间上冲突。此外还要确认自己的解决方案与对法解决方案是否有冲突，保证双方可以完美适配。
　　（3）全局性思维
　　全局性思维其实上面也提到过，就是不要沉浸在自己负责的独立业务系统当中，要跳出这个小圈，从整个业务流程的视角去思考问题，去设计解决方案。
　　以前端或用户产品为例，这类产品经理在产品设计时就经常会忽略全局性思维，他们往往考虑更多的是用户体验，是某一个功能应该在哪一个页面展现给用户，但是他们却不会思考，当用户点下某一个按钮或者完成某一个操作后，后台的业务是如何流转的，后台的业务系统之间数据是如何交互的。这就是后台产品需要具备的全局性思维，不仅要考虑前端用户的操作，又要考虑到后台系统之间的交互以及流程。
　　上面三种接地气的需求分析方法中，前两种解决的是需求什么时间做的问题，而最后一种思维方法则解决的是需求如何做的问题。
　　4. 需求排期
　　需求排期即将明确的需求排进产品迭代周期中，保证研发、测试明确需求内容，且需求可以正常进入开发、测试、上线流程。按照需求明确、开发、测试三个环节进行一一解析：
　　（1）需求明确
　　在每一个迭代周期开始之前，组织需求会以及冲刺会。需求会即组织所有开发同学，就需求背景、需求内容与开发进行沟通，确认开发明确需求做什么，然后由开发同学将需求拆分成具体的可落地任务项。冲刺会即组织所有开发以及测试同学，就需求会确认过的需求，由开发反讲给测试，这样做的目的是保证开发正确理解了产品经理的需求内容，同时测试同学也会就疑问提出质疑，在产品、开发、测试三方同时在场的情况下，保证需求明确，不会在开发、测试过程中再产生撕逼的情况出现。
　　（2）开发
　　在开发过程中，每天通过站立会了解需求的进度，如果遇到需求的变更或者开发、测试同学的疑问，可以及时进行沟通，避免出现重大的delay。
　　（3）测试
　　对于产品内部的功能，由组内的开发与测试沟通测试事项即可，但是对于涉及多业务模块之间的联调测试，就需要提前沟通所有相关的负责人进行确认。
　　如果你是需求的发起人，那么在需求进入开发尾声，就需要协调不同团队的产品、开发、测试负责人组会沟通开发联调、测试联调的时间点，保证各团队之间可以在产品上线时保证统一。
　　如果你不是需求的发起人，那么也需要明确与你的业务模块有依赖关系的业务模块的测试时间，需要提前确认联调时间，保证不会因为自己负责的模块出现问题而导致整体需求的delay。