week4——产品与用户接触的方案
基于以前是偏中台现在是后台产品的实际现实，这里会说一下后端产品的用户接触方案。
我们一般把“B端产品”分为“大B”和“小B”，以淘宝举例，在淘宝上开店的卖家们所使用的操作后台我会称之为“小B”产品，而阿里员工自身操作的系统称之为“大B产品”，我现在主要负责的模块更倾向于“大B”平台产品。大B产品的和用户接触的便利就是用户就是自己的同事，对于小创业公司而言（譬如我现在），很有可能我的用户就坐在我对面的工位上（经常和需求方怼的天翻地覆~~~）
以我当前的工作经验来看，主要是两种形式的接触：日常工作吐槽和特定的会议
两种方式大多数情况下已经涵盖了我作为B端产品需求的来源方式，当然对于两种方式的需求形式和质量不太一样。
首先是日常工作吐槽的模式，这样的需求往往都是你在和业务方沟通的时候，对方比较不经意吐槽发现的，譬如说你和同事交流过程中，对方会吐槽某个UI很难看，某些功能找不到的时候，作为产品，就要好好思考下了~是否对方说的诉求是否合理？他的诉求通常是为了解决什么问题？如果判定对方所言合理，那其实可以按照需求的紧急程度和优先级进行后续的迭代规划。
这种用户提供的需求好处显而易见，由于用户是一线的同事，所以很多时候会发现很多产品在设计之初未曾发现的漏洞，并进行完整的补全。问题的话在于当产品思考这个问题的时候，切忌忽视了其他，我就层经历过自己上线了某功能之后结果影响其余产品的一项功能，导致整个页面挂掉了~~~~~惨不忍睹~~~
其次是大型的需求会议，这种通常是项目部的客服同事或运营同事发起，当出现某些状况，仅仅依靠客服人员无法解决需要从功能层面去解决的时候，这样的会议便应运而生，通常这样的需求沟通会比较正式，会前需求方会发需求草案，会后会发会议纪要，这时候作为产品需要细致的和我们的用户——客服or运营沟通，为什么需要这个需求，实际场景是什么（这点尤其重要），当前的功能为什么无法满足他，如果有必要的话，对于这样的会议我建议录音。等需求会议开完之后，别急着说什么时候能上线之类的，应该仔细在会后重新梳理需求，需求是否合理，是否有更好的解决方案，这些都是需要会后自己甚至组内沟通的（保证你向其他组员转述需求时需求的完整性）。
最后，切忌，B端需求上线前 请千万记住发需求上线通知及操作文档。
