初级产品经理的职场复盘(2):专业能力篇

之前有人比喻说,产品经理就是一个团队的小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不就是你的了吗?

 

作者:小仙贝;公众号:闫秀儿

本文作者 @小仙贝

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部