域名频道资讯站上一篇我分享了一个初阶产品经理所具备的“软实力”，下面我为大家介绍下必备的“硬实力”是哪些？
之前有人比喻说，产品经理就是一个团队的小CEO，需求怎么做，得由产品经理定。
其实这倒不是因为产品经理权利有多大，而是因为产品经理所代表的是业务的诉求，所以任何逻辑、功能点、权限的设计问题一定是要产品同学来（背）拍（锅）板的。
研发同事们在开发过程中经常在群里艾特我：“是PM让这么干的”“PM给个逻辑吧”“PM你们决定到底怎么做吧。”
每次遇到这种等着我拍板的情况，真让我瑟瑟发抖……
俗话说的好，背不好锅的PM不是一个优秀的PM，那作为一个优秀的初阶PM，需要具备哪些的专业能力呢？要想回答这个问题，就得要知道，产品经理每天都在干些啥？
首先我们同步一个流程，产品同学要完成一个完整的功能迭代需要经过以下这些环节：
- 需求沟通 → 沟通能力
- PRD输出&原型绘制 → 需求文档撰写能力、原型基本功
- 产品组内需求评审 → 沟通能力、抗压能力
- 开发评审&排期 → 沟通能力、抗压能力
- 测试用例评审 → 逻辑能力
- 开发&提测&测试 → 项目推动能力
- 验收 → 细心
- 效果回归 → 数据分析能力
这么总结下来，一目了然，一个小白产品所具备的核心硬实力大致分为四个模块，即PRD撰写能力、AXURE绘制能力、项目管理能力以及数据分析能力。
01 PRD撰写的能力
PRD（Product Requirement Document）即产品需求文档，要想了解，PRD到底是个什么东西，就要问问自己这几个问题：
问：PRD给谁看？
答：PRD是产品提供给开发、测试同学看的
问：PRD用来干嘛
答：PRD是产品用来告诉开发这次需求是要实现什么功能、怎么实现、实现效果
问：PRD写的时候有什么要求吗？
答：没有特殊的规定，本着“把话说清楚”的原则，把这次需求的背景、目前的现状、以及实现的方案写下来即可。
个人方法论分享
写文档的时候围绕“谁要用”，“为什么要用”，“怎么实现”这三个维度去写，这样就确保这个需求的前因后果是清晰的了。
围绕着系统去写
在写实现方案的时候，要通过在系统上触发的场景去写对应的交互过程或者后续的流程，必要的时候可以通过流程图展示出来。B端的产品要注意需求中所涉及到的数据的流转、存储等；而C端的产品则要注意功能中涉及到的交互、跳转逻辑等要描述清楚。
考虑界面、系统的关联性
比如是一个很简单的加字段的需求，也要考虑到这个字段是否支持删、改、查等操作，包括他的输入规则、取值逻辑以及对其他系统的影响，比如说，如果我是在订单系统加了这个字段，那退费系统也需要展示吗？等等等等
数据埋点需求
如果这个功能后需要进行效果评估的话，就需要在文档里说明埋点的场景以及埋点的规则。
考虑各种边界值以及异常情况
正向的流程我们每个人都能想得到，但是一旦流程中任何一个环节发生了问题，系统又该如何处理呢？
举一个很简单的例子，微信支付我们都使用过：用户扫码–手动输入金额–输入密码–支付成功。
可是这其中几乎每个节点都有可能终止操作：扫码失败、不展示二维码怎么办？金额输入过大是否有限制？限制规则是什么？密码校验失败后系统会怎么提示用户呢？密码输入正常但是没有调起微信的支付接口该怎么办？接口响应延迟导致重复支付了怎么办等等等等。
这些问题以及应对办法，就是产品经理必须来做决策的，一个好的文档一定是各种正向流程、逆向流程、每个边界值都考虑周全，把开发安排的明明白白~
但是毕竟产品同学也没有那么多时间去把每个正向、负向场景的用例梳理出来，如果之后在技术评审或者在开发的过程中被指出来的话，就用小本本记录下来，之后再做类似的功能的时候不要再犯相同的错误就好啦。
再多说一句：写完文档之后自己要review一遍，把自己想象成一个门外汉，看下能不能读懂，文档的逻辑有没有漏洞，这个方法亲测很有效哦。
02 Axure绘制的能力
Axure是画原型的一个工具，也有很多人用Sketch。原型就是指你所做的功能的一个设计demo。
如果是B端产品的话，对原型能力要求没那么高，基本就是一个打辅助的作用，来解释需求文档（以前我都是画个demo后直接找UI小姐姐~）；C端的产品更重交互，所有对原型能力要求高一些，有的公司会要求产品画高保真设计图。
个人方法论分享
现在网上也有很多教程，我最早看的是小楼写的，比较显而易懂。当时还作死用了Axure全英版，查单词就要花好久……（答应我一定要汉化好吗）
入门的话可以先模仿下画Baidu首页，这个时候一般自己是没啥设计思路的，可以画画喜欢的APP/PC界面，或者可以参考下antdesign的设计，现在还蛮多的互联网公司用的都是蚂蚁那一套，提前熟悉了的话正式工作以后也有帮助。
（画外音：Axure也可以用来简单的P图，我前几天还用Axure把同事的照片和易烊千玺的P在一起了你敢信吗）
03 项目管理能力
项目管理能力=跟进+推动力。
推动力，从字面上解释就是推着走，工作中也就是把这个项目逐步推的上线，一般在遇到瓶颈或者由于临时的问题而影响进度的时候，产品同学就要通过不断地沟通、解决问题去推动项目上线。
跟进则主要是在开发、测试阶段，通过跟进开发进度、解决开发过程中的问题点，或者提前暴露风险从而避免项目delay等等。
个人方法论分享
说话一定要tough！不要不好意思扭扭捏捏，这点对于刚入行的小白同学十分重要，要有底气把自己的需求点、期望结果和同事讲明白，不要随便讲一句话就脸红（去年我实习的时候第一次评审时声音都在颤，更别提推动了），组织会议的时候、评审的时候、其他一切场合都不要方，你要记住你是这个项目的owner，要适当的硬气一些。（悄悄告诉你，这个也是面试官会考察的一个能力点噢）。
和开发也好、业务也好，双方确认完某个事情后，一定要在对应的时间的节点下再去跟进确认，每个阶段都要保证是在自己的可控范围内的、无风险的。写到这里的时候突然想到我之前的mentor和我说：产品经理做的就是一个操心的活。现在想想，真是深有体会。
04 数据分析能力
你以为需求上线了这个项目就算结束了吗？too young too simple！
功能是给业务做了，那业务用的好不好，有没有解决他们的问题，他们的反馈如何？这些产品同学也要关注呀！
工作以后最大的一个感悟就是：一切都要以数据说话。
上学的时候那种主观的说辞“我觉得不错”“挺有用的”“确实提高了效率”，在职场上完全是行不通的。
如果你说这个功能解决了你的问题，那你得靠数据去证明：做这个功能前，人均耗时多久，扑多少人力，上了这个功能后，人均耗时多少，大约提高了多少工效？等等等等。
个人方法论分享
带着目的去做需求，比如：我这次这个功能就是想要把某某部门的工效提升20%，那在PRD中就要把涉及到工效的触发点进行埋点处理，上线后请开发小哥哥跑一下数据自己算一下，看看有没有达到期望指标，没有达成的话，就要考虑功能上哪些地方还有不足。用这次的分析结果作为下个功能迭代的依据，逐步优化。
最重要的是，在这个过程中你十分清晰自己在这个过程中做了什么事，取得了什么效果，解决了什么问题。诶？等下，这些问题听着好熟悉，对啦！这就是你下次跳槽的时候面试官会问的问题呀~ 如果这些你都了然于胸，那offer不就是你的了吗？
作者：小仙贝；公众号：闫秀儿
本文素材来自互联网
