对于产品经理们而言，日常需要对接各种各样的业务们所提的需求。这件看似简单的事其实并不简单，这其中有以下几个点需要注意。
1、业务方通常都没有互联网之类的经验，提的都是比较直接的需求。
例：我要在App的群聊中，增加一个发红包的功能。他们既不考虑发红包的钱，从哪里来，也不会考虑抢到红包的钱存到哪里去。直来直去的甚是可爱。
2、业务方不会把需求提干净，通常都需要产品经理去慢慢引导他们。
例：我要做一个内部用的CRM，只需要有销售线索池，分配销售线索，然后每一员工跟进线索池的记录，就可以了很简单。但是他们可能不会考虑到每一条销售线索的状态流转，哪些操作会造成状态的变更等，这些都需要产品去引导他们，告诉他们需要有这些基础功能。
3、业务方通常是不会提出关于产品基础架构的需求的，这些都是需要产品经理规划好，如有需要他们参与及输出的内容，需要及时提出，不然会造成基础架构有问题，业务无法正常开展的情况。
例：比如职业编程在线教育，其产品的基础架构就有课程结构，一门课程是如何组成的（章、节、视频、练习如何组合），课程与课程之间是否有联系，课程是如何收费的（整体收费还是月/年卡模式），这些都需要产品经理规划好之后，和业务方沟通，达成一致后，由业务方出一份课程清单，什么时候提供哪几门的课程。
下面让我们来看一个简单的实际案例来了解，产品经理应该如何对接业务提出的各类需求。
背景：公司一款产品上线后，业务部门需要有一个内部使用的CRM，对已有、新建的销售线索进行分配、跟踪等操作，功能比较简单，但是麻雀虽小也要五脏俱全。
业务方提出的需求如下：
- 线索池列表：所有销售线索都在此显示
- 线索分配：有分配权限的账号，可以把线索分配给他人
- 线索跟进记录：每一条线索的下方都可以记录对线索的跟进记录（线索跟进者和他人都能输入跟进记录）
业务提的需求规划
产品对接后需求分析如下：
产品对接后的需求规划
我们可以看到，当产品经理对接到业务方提出的需求后，如果事先使用思维导图整理后，再去和业务方确认。这样就方便很多了，看着导图的内容，大家心中大致知道需要做什么，到底有哪些功能。
产品会事先把相应的系统功能添加进去，顺便加入一些体验上的功能。业务方也能知道最终做出来的东西有哪些功能，是否满足自己的诉求。如果双方在功能上有分歧，也可以在第一时间沟通。
有了明确的内容后，再设计PRD就方便很多了，不会出现产品设计出来的东西和业务的需求不符，也不会出现对业务提的需求理解不清楚的情况。
网友评论