菜鸟级产品经理的深刻反思录。我果然弱爆了…

用户头像
武汉/UI设计师/12年前/8705浏览
菜鸟级产品经理的深刻反思录。我果然弱爆了…

产品经理好当,当好就不容易了。你得会技术,更得会装!

千万不能在技术人员面前表现出一丝胆怯;在需求方面前更不能表现出“哈巴狗”的姿态,你太听话他们不信你的。

同事们吐槽你,不要在意,就想着产品好就好,产品不好那就期待下次产品好!

内详

  真正变身为产品经理之前,在公司title是交互设计,实际干得是设计下新产品,画画原型,写写产品文档、偶尔担当下ui设计,日子不咸不淡的快速飞过。
  在某一个机缘巧合下被公司任命产品经理!开始负责某公司级别项目中的某个app产品,考虑到我是这方面的新手,所以产品不是很难,功能也在我“睿智”的决定下砍掉很多。总之就这样当上了传说中的产品经理……
  初当pm,实在是不习惯身份的转换啊,直接和老大们、客户们沟通。好在我各种大世面都见过,他们如“凡人”一般在我眼前。姐目空这一切的发生,开始了最开始的需求分析阶段。
  从开始到现在,几个月时间我越加了解这里面的门路,但是更多的是对产品经理的反思。主要是想想几个月中产品的问题,细节的更多(因为是女生的原因么?)
  技术类的问题实在是太深奥了,而我却没怎么用心学习!基本浮于表层的基本流程。该打。
  另外,文案方面不怎么被大家重视,但急要的关键时刻却难以想出好文字。好在我本身就是个心思缜密的好姑娘(吐),文案之恋的在功能确定后我就会慢慢考虑。
  现在就目前项目中遇到了几个比较突出的问题,写出来好好记录下,偶尔反思下。
 随便给比我更菜鸟的看看和比我牛的大碗们吐吐槽,勾起他们一丝曾经痛苦的回忆。

1、im的对象区分
  因为项目中有2种不同的用户群体,他们要做出区分的。这种想当然的需求,似乎有人偷懒还是其他原因,竟然一直没有区分,后来导致了im时消息会发不到指定人。
  eg:用户a和用户b是不同种类的人群,但是后台代号是一样的。没区分后,用户x给用户a发im!如果用户a不在线,就会发到用户b那里!!这不是乱套了吗?
  造成这种问题后,只能是修改客户端来区分,这就不得不让用户更新app了…(更新app后才能解决im这个问题!)

  让用户更新实在是太困难了,也很麻烦。之前项目里gps的问题就让用户更新过,后来又因为修改了bug让用户更新……发个稳定的包就经历了3次发包,这次im的问题必须得第四次了。


2、im自动回复的本地存储相关
  自动回复…这个远古来的功能还有人用!有的有的,是必须要的哦。
  最简单的就是本地存储,别人发了消息就即使回一条。但是这不是非常万能的,比如发送自动回复的用户的手机不再运行这个app,那对方也收不到了。ios的home键出去不一会儿就没了,安卓的好点…
  另外,我非常希望这个能人性化点,比如“用户a给用户b发消息后的5分钟内,用户b都没回,这个时候系统来回一条自动回复”。
  这样可以避免a和b交谈中,即时回复的“自动回复”带来的刷屏!

如果是 即时回复“自动回复” ↓
------------------- 情况① -------------------
a:在吗?
                 自动回复[不在啊]:b
a:哦
                 自动回复[不在啊]:b
------------------- 情况② -------------------
a:在吗?
                 自动回复[不在啊]:b
                           我来啦:b
a:请问***商品还有165的吗?
                 自动回复[不在啊]:b
                         有的有的:b
a:白色的也有?
                 自动回复[不在啊]:b
                             嗯嗯:b
a:麻烦关掉自动回复吧,神烦(#‵′)凸
                 自动回复[不在啊]:b
                             好…:b



如果是 5分钟无动静在回复“自动回复” ↓
------------------- 情况① -------------------
a:在吗?
                  5分钟后
                 自动回复[不在啊]:b
a:哦
                 5分钟后
                 自动回复[不在啊]:b
------------------- 情况② -------------------
a:在吗?
                           我来啦:b
a:请问***商品还有165的吗?
                         有的有的:b
a:白色的也有?
                             嗯嗯:b
a:好耶
                             呵呵:b

不过这个很复杂,还要判断,所以就没有然后了……

另外,还有走Server端的自动回复,因为变成了超级复杂,所以毫无疑问的就没有然后了……


3、push(push什么内容,怎么push,什么样的文案)
  这个是不起眼的东西,但是确很影响用户体验!
  push多了不好;不考虑重不重要就push也不好;push写什么;push的时间段怎么安排等等。
  下面是我目前负责过的2个产品的push相关的表格。

  主要分为6个类,备注也是必须的。





  文案很官方语言,因为产品所决定的。

  如果是sns相关的,我一定会让文案变得有趣


  下面就纯属话痨般的给“开发工程师”看,额,说不定会被默默吐槽吧。

  不过鉴于我很菜鸟,就得明确指出“我想要什么效果”。



4、后台返回的图片大小
  在ios的640*960下,我在ui规范说了头像都是88*88的大小,前端也ok,但是到了安卓…真是什么尺寸都有。比如会出现140*140的大小…后来才知道是后台返回数据就是这么大的。
  后台都是busy man&大爷,所以这个优先级为3的bug一直躺在tfs里,他们不改,我也不提。

  * 这属于很不起眼的问题,90的情况下都是没问题的,和安卓各种手机的奇葩分辨率有关。


5、不同账号代表不同权限,有些h5页面要区分显示
  最烦账号权限的,不过没办法,需求就是这样!
  在产品前期,大家都没提过权限,后来开发到一半了才说“啊,这个产品xx用户也要用,和xx、xx显示的某个页面会不一样哦”。。。
  后台不干了,说“就初定用户显示xx页面,其他新来的用户就看不到那xx页面”
→→ 然后新增的用户在打开xx页面时,后台就给了个提示语“你不能看哦”解决了…
至于后期会不会改,看客户反馈了。
  截止第一个发布,客户都没把这问题列到新的需求list,更别说提到buglist了。呵呵。
  跌莫!!下一个新产品时,我一定会从需求角度考虑这个问题!!

  从头就搞好,不要事后兴师动众的补救。


6、扫描二维码的整个流程和内在
  这个我先搬下百科的科普:二维码百科
  二维码(2-dimensional bar code),又称二维条码,最早起源于日本。每种码制有其特定的字符集;每个字符占有一定的宽度;具有一定的校验功能等。同时还具有对不同行的信息自动识别功能及处理图形旋转变化等特点。
  具体的生成和显示都是后台完成,而且完成的很好,所以我就放心的不管了。哈哈。

  我关心的是什么情况下要二维码,什么样的二维码更有吸引力等。


7、分享到微信、微博是什么样的板式、文案和流程
  借鉴下其他主流app的流程和样式(流程基本一样啊亲)。
  排版就是自我思考了(这你也借鉴,鄙视)。

  文案得根据产品来想,定位、需求什么的。(这如果也借鉴,你可以闪了,笨蛋)


8、版本更新怎么提醒更好(打开后还是打开前,怎么展示)
  看产品定位及需求了。
  个人觉得打开app后第一时间提醒最好,然后写些惹人侧目的文案。比如知乎就利用“爱”的调调让人去打分or更新。再比如些小众app挺acg的傲娇语气让你去打分or更新。

  那种干巴巴的“版本更新,加了***,改了***,请更新”类的官(非)方(常)语(严)气(肃)的文案……我只会默默想“额,好无趣”


9、产品介绍文档怎么写的易懂(培训手册)
  这个真的很不“互联网”啊!还要写手册去教…产品决定的,决定,的…
  我用了非常通俗的白话写的,菜场大妈都能读得懂。因为客户当时很严肃的说,越简单越好,这个产品的用户没受过很多的教育(小、初、高这样),接触智能手机的时间不长,年纪也比较大。
  关于这点,我想得更多的是“为什么要用图标按钮,应该用文字按钮的,但是设计时候被客户引导到用图案了”

  呐,培训手册节选↓




10、版本更新的记录
  我是按照给客户用的安装包来记录,记录的是功能点的变更。
  当然,发包前的bug修改等等,都是测试人员来把控版本号。
  最后就是xxxx102-852(测试环境)(1).ipa/xxxx1034(测试环境)(1).apk等等,总感觉哪里不对。
  他们会把后缀数字当版本号发到市场吗?

  * 市场更新这块是客户来主导,我负责给他们写版本更新文案和替换旧的效果图。


11、需求分析、实现
  这些激动人心且把握产品命脉的工作,对不起,是老板决定的。
  产品经理说的好听,其实就是老板手头下可怜巴巴的执行者,属于唱黑脸的角色,被后台、前端、测试骂的,产品失败还能当炮灰使的。
  既然有了以上觉悟,对“需求收集、分析、实现等等”,我的理解和行动是这样的:
  完全听从boss们的,但是为了增加存在感,必须创新2个方便用户且boss没考虑到的功能;及若干个不疼不痒,其他主流app都有的。后者属于等待boss、开发砍的,但前者一定要坚持保留一个。(这样,存在感就有了,撒花)
  如果产品经理懂ui,那恭喜,存在感升级的时候到了!
和客户一起热火朝天的看啊改啊,很能拉近彼此关系,说不定可以交换个名片,后面…不说了。
  →→ 如果产品经理自己做ui,呵呵,必须懂的说“这样就非常漂亮了,如果再不确定,开发进度会耽误哦!市场上慢了,用户会有异议的”
  如果产品经理不懂技术,那就闭嘴吧。无论说什么,犀利的开发工程师们总会对你哦哦哦的应付。有时候他们也会坏心眼的按照最简单的来,导致测试时候会发现很多不可逆转的bug,谁叫你不懂、心不细、他们不乖~
  但是我遇到的99%的工程师都非常不错,尽心尽责,我觉得这属于rp上的幸运。

  当然害群之马的也有,然后会被组织默默淘汰…耶。


12、灵魂般的启动页
  太虐人了…
  我在公司部门项目的app产品中被虐出阴影了,好在后来给客户做产品时,幸运的2吃通过了。
这方面我的经验是:如果非常精准的理解老板思维,请自由发挥,通常启动页做好了,老板也会对你各种秀恩爱。“太漂亮了,你太有才了”(容我扶墙吐一下…)
  如果不了解老板思维,请一定避开,能避开就避开。不能就随便做一张,给优秀的ui设计师当衬托和炮灰。而且下次老板不会让你做了,奸笑。(真是的,谁说懂ui的pm就得做ui了!!)

13、ui界面的细节
  功能能跑通的产品,60分及格;和效果图一致的才能得高分……
  大家都知道界面好才有好体验,但是我负责的产品中,时间是个不得不提的痛点。
  每次老大们都指定了一个不太科学的时间点,加班加点的做,最关键是每次迭代都希望给产品大改造,时间不够,先保证功能!于是界面就真的很“挫”。
  用户很挑剔,不好看就能卸载。
  ui设计师很愁,产品拿不出手去推荐。
  产品经理更愁啊…拿不出手+被领导鄙视。“这么挫,60分差评啦”

  我都恨不得自己会开发了!!


14、更好用的app……这个太无奈了
  我有限的脑容量里想到以下几个点,这些点能让我觉得这个app很好用!
  ·黑夜模式!黑底灰字,晚上关灯躺床上看很舒服(人人ios/天涯 做的挺好)
  ·可调文字大小
  ·禁止push时间段
  ·换皮肤
  ·标题栏/标签栏可随滑动隐藏
  ·浮在顶层的更新按钮(人人ios/贴吧 做的挺好,直接方便)
  ·提示语有新意
  ·提供离线阅读功能(天涯安卓版可以下载实在是太美好了!)
  ·im里有表情
  ·更多的分享类型

  ·没什么高端大气的隐藏型手势…(安卓长按我都是无意发现的…)


  以上错别字可能很多,也有错句。基本阅读还是没问题的。
  写了这么多,其实想想如果再来一次,自己肯定能做的更好,至于这个机会,就得看未来发展。
产品经理好当,当好就不容易了。你得会技术,更得会装,千万不能在技术人员面前表现出一丝丝的胆怯,在需求方面前不能表现出“哈巴狗”的姿态,你太听话他们不信你的。
  同事们吐槽你,不要在意,就想着产品好就好,产品不好那就期待下次产品好,毕竟产品好不好真不是你一个人说了算。
  实在当得很艰难的说,心就想想“起码这个月的工资,公司还是发了”…
  最后,祝各位产品经理好运。
35
举报
|
58
分享
相关推荐
评论
用户头像
评论你的想法~
表情
喜欢TA的作品吗?喜欢就快来夸夸TA吧!
推荐素材
水蜜桃和李子的平面水果图案
牛奶乳液层次梯田平铺平面
空的平台平面和自然景观
牛奶乳液层次平面平铺平面
中国传统纹样创新图案设计
平面风格黄绿色系花朵装饰
海底世界插画
城阙凡花
城市园林平面布局航拍
平面人物插画
城市园林平面布局航拍
平面男孩喝咖啡插画设计
金色颗粒质地的平面
古风平面仕女与瓷器
金色颗粒质地的平面
原创UIUX交互橙红渐变炫酷视觉平面设计作品集模板PSD
玄关入门地毯印花图案红地毯
倒计时,海报,平面
金色颗粒质地的平面
平面花卉图案扁平简约无缝拼接插画
城市园林平面布局航拍
金色颗粒质地的平面
金色颗粒质地的平面
空的平台平面和自然景观
平面书法字手写
你可能喜欢
相关收藏夹
大家都在看
登录注册