2015年终总结·工作篇

2015年,工作方面发生了许多的变化。

首先是年初从用户研究员转岗成为产品经理。

做了2年用研,我也不知道自己算不算一个好用研。或许是因为从毕业进入互联网行业开始,就一直想做产品,不知不觉中我努力的方式就是做一个产品经理眼中的好用研。用dota来比喻的话,类似于辅助位,插眼(市场分析、用户访谈)、反眼(体验走查)、游走gank(提供研究证据、推动产品改进)。而我老大带领用研团队努力的方向是在更大范围内发挥研究的力量。用dota比喻的话,就算不是一号位至少也是二号位,经常来个宙斯大招全屏闪电(用户体验考核),再NB一点儿的直接开启大局观、飞鞋全场带节奏(市场调研、向公司决策层输出战略决策)。

我一直觉得,我老大是一个非常牛逼的用研,更是一个非常牛逼的老大。当年整个团队学习氛围非常浓厚,经常组织内部专业分享,跟他的2年里收获很多。

2015年,老大去做了B2B产品。希望有朝一日能以PM的身份再次相逢。

然后的变化就是9月份换了一家公司。

在前东家做产品的半年时间里,一大半时间是在用SQL跑数,分析数据做调研,一小半时间是在开会、撕逼。真正做设计和推动方案落地的机会并不多,几个月下来除了把老大们交付的几件事按部就班的做完,别的就啥也没做了。有自身的原因,比如产品经验不足,心态不够自信等等。更多是组织层面的因素:开发资源比较少并且效率略低下,设计部门较为强势、规范已经相当成熟、留给PM发挥主观能动性的地方已经很少了。

新东家的情况完全不同,产品尚处在快速发展期,PM对产品管控权力很大,从需求发起、交互设计乃至视觉设计,都是PM说了算,开发也都非常给力,有时还会自己做个方案出来找我们PK(笑)。前些日子写试用转正总结才发现2个多月做过的项目比之前半年的还多,现在再想起当初那些撕逼也好、纠结也好,根本不算啥,心态上也自信了许多。

不知该不该感到庆幸,如果不是因为情变,说不定就会如同温水煮青蛙一样沉沦下去了。等到某一天互联网严冬的大锅盖盖下来、才发现自己弱小得根本跳不出去。

最后就是从社交领域到电商/金融领域的转换。

领域上的转换,感受到最大的差异是每个人的卷入度。社交领域里,用户和产品都没有特别强的卷入度,能玩就玩、不能玩拉倒,用户反馈每周整理一次,但其实只有高管投诉会得到重视,普通用户根本没人管。电商行业不一样,用户反馈每天整理一次,不管什么用户投诉,会要求第一时间响应到位,一些特殊问题产品会直接打电话给用户询问情况。另外每年三次电商节如同打仗,不拼个你死我活誓不罢休,竞争颇为激烈。

这种高卷入度也会渗透进产品设计中。转化率成了一个特别现实的问题。由于漏斗模型几乎是个不可挑战的铁律,每一步多余操作、每一步新增操作,都会受到设计上的质疑。 那么最后就来说说转岗之后都踩过哪些坑、收获了哪些经验吧。

1、产品设计方面

做过2个非常业余的烂设计。

第一个是白条收银台的分期选择和优惠券的交互设计。分期选择是原先就有的,新增了优惠券。优惠券有可能会限定适用分期,当用户分期不适用时,有些优惠券是不可用的。二者存在着联动关系。但分期和优惠各自都折叠在二级页面里,并且因为沿用了老版本的设计入口离得比较远,用户很难在二者之间建立起联系。

新功能上线后,负责运营的同学试用了一下,跑过来猛烈吐槽。我一边给她用美图秀秀当场做简易教程,一边很沮丧很心塞:卧槽我特么做了个需要看说明才能用的设计。。于是下决心之后一定要重构。

新版本在交互逻辑上重新做了设计:1)分拆了下单页和支付弹层,减少接口反复调用;2)分期和优惠统一放到支付弹层里解决,并且在一个操作闭环里解决分期和优惠冲突的问题,当用户选择了有限制分期的优惠,就紧接着引导用户再选分期。

经验:

1)设计要遵循就近原则。如果两个选项之间有依赖关系,那么它们要么得在空间上离得很近,要么得在时间上前后衔接。

2)最好设计前期拉运营同学一起review方案。运营、市场同学的『大脑结构』和用户更为接近,PM的大脑有时候太跳跃了。

第二个比较业余的设计是优惠的初始化状态。电商结算页初始化的时候如果没有默认优惠,这个位置就会是『未选择』。我当时觉得应该有一个状态区别于用户自主确认过的『未选择』,于是将初始化的状态设计为『请选择』,当用户手动确定『不使用优惠』时,这个才会变成『不使用优惠』。其实这种小细节的区分是没有什么必要的,却让代码逻辑变得很复杂。

经验:

1)要克制。合理的简化设计是很有必要的。当RD抱怨:『这块的逻辑太复杂了,我们hold不住』,也许是有道理的。请一定要想到发版前夜大家一起熬夜加班改bug、梳理逻辑的情景;

2)要去看行业通用设计。因为它有可能是比较合理的做法,至少,它会是用户最习惯的做法;

3)通过增加逻辑判断提升的用户体验可能会由于复杂而被抵消掉,或者提升压根可以忽略不计。要知道对体验影响最大的那块短板在哪儿,而不是盲目加高其他木板的长度。

2、异常情况处理

从社交转行做支付后最大的感受就是:90%的时间和精力都用在处理各种异常流程,只有不到10%的时间花在正常流程和用户界面上。很多逻辑一开始没有想通透,常常是一边开发一边遇到之前没有考虑到的异常情况,也就是『踩坑』。坑踩多了,会逐渐掌握异常情况的全集,从而得以预判哪里有坑。

47a53314jw1eynqw0mtqhj20cs0an405

经验:

1)预先准备业务流程图,或者在需求宣讲时和RD一起梳理绘制,一些复杂的前端逻辑或许用伪代码来说明会更好(不过我还没写过,不知道会不会伤害到RD的自尊233);

2)和QA一起review测试用例,好QA可以帮忙预警很多坑;

3)各种追加的处理,随时补充到文档里、随时讨论组里沟通以免RD遗漏(尤其是当团队成员有分散办公的情况);

3、降低上线风险

还遇到过两次上线失误。

一次是服务端『少上了一个依赖』(开发原话,具体啥意思我也不是很懂),代码回滚,收银台挂了34分钟;另一次是H5前端少处理了一种情况,挂了30分钟左右,和我变更过需求有关系,QA同学没有回归测试到这个用例,也是个小失误。这两次上线问题,RDQA当时都是处于多个项目同时进行的状态。

作为PM,同时跟进2-3个项目是一件很正常很合理的节奏,每天的工作非常充实饱满,工作狂倾向的我还觉得略爽。但写代码是一个要求认知资源高度卷入的活动,多个项目并行RD会有较高的失误率。

经验:

1)测试用例QA一定要写、一定要写、一定要写,写完还要一起review,这是最简单的管理风险的方法;

2)关键环节最好在业务非高峰上线(不过没人愿意熬夜加班上线,落实起来有点困难);

3)尽可能不要在开发中途变更需求,如果变更需求,尽量帮RDQA回顾逻辑依赖。

4、大局观

谁没被砍过需求呢。

需求起因是老大说要『搞搞消费』,但现在的产品框架容纳不了太多导购内容,于是需要先扩展产品架构。扩展需求列出来之后,最先跳出来反对的是客户端RD,因为安卓内存控制做得不好,架构扩展后可能会提高低端安卓机崩溃率,吵来吵去最后争论焦点回到了这个事情有没有必要做,老大想了想,拍板砍掉了(他自己提的)需求。所以你们看,其实一切都赖老大,对不?哈哈

有想法、出方案、说服开发开搞、然后搞到一半需求被砍,这是小PM比较容易遇到的情况。作为一线PM,要努力提升大局观,老大『拍脑门』的时候自己要心里有数,对于那些逻辑上不成立、不符合战略重点的需求,缓缓再搞。把宝贵的资源专注在战略重点上。

2016年计划

16年目测又是很忙的一年。战略重点涉及公司机密就不多说了,自己比较感兴趣的事目前有以下几件。

1、支付SDK:上半年希望用来了解支付类SDK的实现原理:包括支付路由、如何具有业务通用性、安全性等。

2H5设计:在承接业务需求和开发基础功能的中间,也希望能穿插着做几次运营活动,所以需要平时多看看H5案例,了解H5页面的实现原理。

3、混圈子:多走出去,参加一些产品经理论坛。如果有可能,希望可以自己组织几次内部小工作坊,和小伙伴们一起成长。

加油,2016

Comments are closed.