这两天我一直在review之前作为产品运营（CMS后台的业务方）与产品经理（CMS后台系统的产品）之间“需求”沟通的一些工作。针对自己会想起来的一些场景，我主要思考了几个问题，第一个问题：作为产品经理取得业务的信任在后续产品的迭代中是不是很重要？第二个问题：作为业务方他的核心痛点是什么？第三个问题：如何站在业务的角度去看待提需求，如何站在产品的角度去分析业务所提出来的需求？在思考这些问题的时候，我主要是从业务角度和产品角度去切换去互相满足。

首先我先谈一下业务的“人性”，我记得自己在之前的文章里有提到过人性七尊罪，今天先不涉及那么多，因为我觉得自己现在对人性的理解还很片面。今天就根据业务（秒杀运营）的角度来简单聊一下人性，在之前收集其他的运营同学的需求的时候，我慢慢发现，业务人员（运营）提需求都有一些共同的特点，我简单举几个列子，第一：站的角度--运营人员都是站在它们自己所负责的模块来提需求，她们所站的角度就是她们日常的工作（举一个简单的例子，我记得有一个检索区新增检索条件，列表区新增一列“相关负责人”，这个需求的背景是：一个小姐姐，需要按照相关负责人来检索，进行统计相关的数据，最后这个需求被产品给拍回去了，我觉得对于该运营的工作而言，这个功能的优化是很有作用的，能够帮助他省下很多的时间，但是我和产品沟通完之后，我才了解，这个功能进行优化之后，使用的受众面比较少，并且还需要往数据库加字段，和BI同步相关负责人的数据，所以说这个功能在上一期没有做）。第二：需求--她们所提的需求都是在业务中可能会花费她们很多的时间，或者是让他们感到很麻烦，觉得这个事情可以交个系统去做，第四-省时间，早下班，所有的业务所提的需求就是能够让自己从一部分的工作中抽离出来，或者是能够让自己的工作效率变的更快，能够早点下班。

总结：业务的人性就是，产品设计策划的这个功能，能够帮祝业务节约时间，提高工作效率，用比较俗的话就是，能够在上班的时间，多有时间玩玩游戏，下楼逛一逛，喝喝茶，早点下班，这样业务就很认可这个功能，如果是你设计这个功能让一部分业务的工作量变大这样的情况下业务就会一致反对。

针对三个问题的思考：

1.作为产品经理取得业务的信任在后续产品的迭代中是不是很重要？

在我没周和运营同学收集需求的时候存在几种状态：第一：我没有什么需求，很冷漠的态度，第二：能不能先把我上次的需求给上线，第三，会提几个新的需求。但是我发现很多提出来的新需求，其实对与其他运营的同学而言，也可以减少她们的工作量，为什么她们不提呢，针对这个现象我去和我的老大聊了一下，才发现是我们的产品团队太不给力，很多时候前半年的需求后半年还没有上线，所以说让很多运营同学觉得提不提都一样，反正最后也不会上线。而造成这样的情况的原因是什么呢，我觉的就是运需求方（按照我们秒杀而言就是运营同学）已经对我们的产品团队失去了信任。我个人觉得这是一个恶性循环。我在想如果我是秒杀的产品我会如何去改变这种现状，第一：我会分析，目前运营同学所提的需求哪些是需求比较紧急，或者是上线一个功能能够解决一大部分的人的需求，然后进行充分的对需求进行优先级的排期，第二，我会更加多的让产品同学和业务同学多交流，能够促进更多的互相理解。所以说我觉得业务和产品之间的互相信任，在之后的产品迭代中作用很大。还有就是我有一个想法就是，如果我是产品的leader，肯定有很多功能没有办法去完成，但是我们可以用其他的方式去让业务信任我们，让业务能够明白，我们很努力的在做，但是因为很多外在原因，没办法及时完成，但是我们一致没有放弃去做去优化。

2.作为业务的核心痛点是什么？

我只能站在秒杀后台系统来分析，业务的核心痛点就是-怎么能够让业务花费最少的时间，最少的精力去完成每日的工作。省时间，省力就是业务最大的痛点。举个例子吧，例如，新的功能上线之后，业务使用该功能的时间，和平时业务不使用这个功能完成工作的时间是差不多的，那么对于业务而言，这个功能是没有提高“业务人员的价值的”，业务就会觉得没用。

3.如何站在业务的角度去看待提需求，如何站在产品的角度去分析业务所提出来的需求？

如何站在业务的角度去看待需求：我觉得吧，我们秒杀的产品对业务的了解太不深刻了，经常看见我们的leader和产品在那里撕逼，说你不了解就不要干涉我们，所以说，作为一个业务型的产品我觉得更应该深入了解业务，深入的业务去聊，才能站在业务的角度看待问题，才能给业务提供完美的解决方案。如果我是业务产品，当我拿到一个业务的需求我会如何分析：第一：我会首先会搞明白这个需求是谁提的，为什么会提，在那种场景下被用到，确认是个人需求还是业务需求，不优化，或者不实现这个需求可不可以，第二：搞清楚之后，我去设计解决方案