2018-12-10 需求分析相关之二

上次作者的文章没有更新，因此又找了一篇其他的来看，例行贴链接[需求分析方法论-四层五步五清法]（http://www.woshipm.com/pmd/979525.html）

囫囵吞枣

-这篇文章里讲到的业务与我之前接触的完全不同，初读有一种陌生感，但是仔细阅读的话发现自己也可以将讲到的一些知识在脑海里具象化。
-四层第一层：梳理各部门的职能
看到梳理各部门职能的时候我想到的是前几天看的供应链方向的泳道图，泳道图就清晰的展示了在每个业务流程之中涉及到了哪几个部门，每个部门需要处理的事情是什么，虽然不是对每个部门的详细梳理，但是把所有业务中各部门的任务结合起来，每个部门的整体职能也就清晰了。梳理清楚每个部门的职能，既能在设计业务逻辑的时候条理清晰，也能够在涉及到部门交叉业务的时候迅速的做出判断，比如作者提到的权限分配问题，如果不是清楚风控部的整体监控属性和固收部的单一业务属性，很有可能导致风控部数据掌握不全面，做出有失准确的判断。
-四层第二层：梳理业务
产品经理普遍上来说只是某一个业务甚至某一个功能模块的产品规划者，不太可能理解所有部门的业务，因此简单但是全面的了解相关部门业务在需求逻辑梳理的时候是非常必要的。这里我还是感觉如果业务允许的话，泳道图是一个非常好的工具来帮助我们梳理业务，部门内部也非常好用。
-四层第三层：梳理信息
这里的信息实际上是各种底层数据，在我实习的时候，需要用到MySQL来实时查询数据，当时的公司只是一个创业公司，仅我的权限能够看到的就有四个数据库，更遑论每个数据库里成百的表格，每个表格里多则几十条的字段。当时在提取数据的时候，已经需要跨数据库跨表格来查询了。那是别人梳理好的数据我来用，但是如果是我自己梳理呢，我能否把每个表归到对应的数据库中去，能不能对每张表给出最合适的字段呢？这都是对能力的考验（另外，数据库与表格的规范命名也是一个很重要的部分）。
-四层第四层：梳理支撑环境
一般来说的互联网产品，支撑环境只需要考虑安卓或者iOS系统差别就可以了，服务器是否够用，那就请系统工程师去测算吧。
除了这四层以外，还有五步和五清，但是那是相对来说比较细的东西了，根据业务内容和相关的业务部门要做具体的设计。而且，这篇文章讲的方法算是最大的需求才会用到的最多的步骤，实际的工作中，我们可能需要的只是其中一部分就足够支持我们去完成手头的需求，而且有时需求紧急，容不得我们自己去一步步的做完这些步骤，所以，灵活使用咯

每日乱想

-像我这样的初级产品经理其实还是应该去大厂里锻炼几年，学习规范的项目制作流程，清楚每个部门的作用，不然很影响以后的职业规划。当然由于实习公司是58赶集旗下的，当时的产品流程沿用了58赶集的，可以说是比较规范了，像我现在的公司，是没有UE的，没有专业的UE，做出来的产品真的觉得交互有点说不过去啊。
-还是想着努力的自我提升，以更加专业的能力去应对更繁重的工作（我希望自己有繁重的工作啊）