|
产品经理的职责有哪些，这和两个因素有关——公司规模和职位级别，先丢结论，看图。 做调研、画原型、写文档、跟进开发以及收集用户反馈等，这些我们可以视之为产品经理技能树的枝丫与树叶，是一个个零散的点，如果最初我们没有搭建好树木主干，不知道这么做的目的，为什么这么做，其技能本身也就没有意义了。 好，我们来看看主干是什么，一个产品经理的职责到底有哪些呢，我们以国内一线大厂为例。 下图是产品设计流程中各角色的职责。 用流程化、结构化的思维来看问题就比较明晰了，需求分析——产品设计——交互设计——视觉设计——开发实现，我们一步一步来看。 一。需求分析这一块是一位产品经理需要掌握的核心技能。如果一位产品经理谈到需求，只会说“老板给的”、“用户提的”、“竞品抄的”，那应该好好重新认识一下“需求分析”。 需求分析可以拆解为：需求获取、需求研究、需求编写、需求验证 需求获取的要素有两点，一是业务相关方，二是获取方法；业务相关方也就是需求信息来源，包括用户、行业专家、内部职员、数据、历史文档等；获取方法主要采用用户研究（桌面研究、定性研究、定量研究等），这又是另外一大块内容了。 获取了ABCDEFG……这么多需求之后，怎么办呢，全部都进入需求池排期开发吗，还远着呢。 下一步是需求研究,先评估后排序。评估是将不合理的、无法实现的、不符合当下阶段目标的需求剔除或延期。排序是对进入需求池的需求进行优先级排序——场景分析法（人数／频率／满意度），用户等级分析法（核心用户、重要用户、边缘客户），马斯洛需求分析法（可用／易用／好用） 对进入需求池的需求我们需要进行需求编写。有人要问需求不就是需求嘛，一句话就说清楚了，还怎么编写，并不是这样。在项目成功的所有因素中，统计结果表明排在前三位的分别是“用户参与”、“清晰的需求描述”、“现实可行的客户期望”。所以需求的编写很重要，必须要采用严格的编写规约。通用的有Volore需求白雪卡 完成需求的编写之后，一般情况下我们需要进行需求评审。召集业务相关人员（运营、销售、市场等）来综合评定是否满足了最初提出的用户需求和业务需求。某些时候，白雪卡所表达的需求信息无法供大家评审得出结论，这个时候我们需要将需求进一步转化为原型，通过原型来验证是否符合预期解决方案。 以上就是需求分析的基本内容，脑图如下 我们回顾下，测试下你是否较好的掌握了需求分析 1.你在需求获取（挖掘）阶段是否调研过了所有或大部分的干系人——包括用户、行业专家、运营部、销售部、市场部等——而不是闭眼拍脑门自己想的？ 2.获取需求后你是否进行了需求的合理性评估，筛选和剔除？是否进行了优先级排序？ 3.需求的编写是否采用了标准的编写规格，而不是来自于上级的一句描述乃至口头需求？ 4.需求编写完成后，是否召集了大家进行需求评审，确认？还是直接进入设计研发？ 二。产品设计好了，完成了需求分析过程后，接下来是产品设计。产品设计可以由产品经理完成，也可以由交互设计师完成。产品设计的含义可以做如下理解——为用户需求所提供的解决方案就是我们进行的产品设计。通常表现形式为草图原型、或功能列表（feature list）。 三。交互设计在一线公司，基本都会配备交互设计师，所以交互设计的工作由交互设计师完成，但是还有绝大部分的中小型公司是不会配备交互设计师的，其职责由产品经理承担，也就是进行的原型设计。请掌握好Axure／sketch等工具 四。视觉设计这一块由UI设计师完成，产品经理即时跟进，确保呈现的功能、视觉效果、层级表现等符合预期。 五。开发实现产品经理不断跟踪项目进度、推动项目有序进行，在预定周期内完成。其中涉及到项目管理、资源协调、风险管控、需求变更等。 所以总结一下，产品经理的工作就是需求分析和项目管理（推动项目高质量按时完成、业务相关方包括交互、视觉、研发等），部分包括原型设计。 最后，上面介绍的都是产品经理的术和法，也就是技巧和方法，是基础底层的东西，用古人的话说是“达下乘也”，是属于下乘的东西。而如果自己能进行抽象提炼总结方法，也就是提炼而得，是“达上乘也”，属于上层的道理思维。到底应该是从下而上，先不问缘由掌握技巧和方法，还是从上至下先理解透彻产品经理一职的核心精髓，我觉得并没有孰好孰坏，只有哪种方法更合适。如果你目前仍处于初中级阶段，我的建议是从下而上。 |
|
|
