打字猴:1.704234037e+09
1704234037
1704234038 所有动作都是可以及时获得反馈的。比如在PC互联网时代,你的鼠标悬停在一个超链接上或单击一个超链接都会看到实时的视觉反馈。
1704234039
1704234040 原则二:对用户操作容错
1704234041
1704234042 帮助用户从错误中恢复,容许用户在操作后反悔。例如,在你误删除邮件后还可以做undo操作。
1704234043
1704234044 发布
1704234045
1704234046 发布相关的概念属于运维的范畴。因为有了丰富的云服务,现在互联网业务的运维工作轻松很多。在团队不大时,甚至可以交给开发工程师代劳,而等到产品发展壮大后,运维工作就非常关键了。运维工作要负责维护并确保整个服务的高可用性,还要不断优化系统架构、提升部署效率、优化资源利用率以提高整体的ROI(Return on Investment,投资回报率)。目前大规模集群已司空见惯,如何管理好成千上万台服务器上的服务,成为运维工程师面临的最大挑战。
1704234047
1704234048 移动互联网时代,发布的工作还包括“发包”。发包是把安装包提交给各种应用市场。俗话说,iOS怕审核,Android烦渠道。具体地说,iOS程序提交到苹果App Store审核之后,总会碰到奇奇怪怪的拒绝理由,关键是每次拒绝审核人员只提出一个问题,改好后再次审核时才提下一个,时间就这样一天天过去,效率非常低下。而Android程序,有太多各式各样的应用商店,发包工作不胜其烦。
1704234049
1704234050 以上提到的都是把产品“做出来”的岗位,但只列出一些线索。研发生产的过程中,还会有些其他岗位的人员也介入进来,比如客服要熟悉新产品、准备帮助文档,市场运营要准备商业上的发布方案等,这属于广义运营的内容,到第09章再说。
1704234051
1704234052 7.4.2  如何做一个让Ta们讨厌的人 本章的最后,继续聊聊在研发生产过程中与他人沟通和配合时的注意事项。下面以与技术人员沟通为例,分享一些简单易学、通俗易懂,能让产品经理在各种配合方眼中迅速变得很讨厌的做法。
1704234053
1704234054 开始实施之前
1704234055
1704234056 ►不说清需求价值。 技术问“为什么要做”时支支吾吾,或者说这是老板(运营)要的,假装自己是个传话筒,或者说“我接的是二手需求,什么都不知道”,而不是去追溯这个需求的初衷。相反,面对老板时,则一定不要有理有据地顶撞,那会让大家喜欢上你。
1704234057
1704234058 ►不去想功能细节。 技术问细节(当然,是涉及业务的细节,不是技术实现细节)时,装作自己之前完全没想过,需要现想:“那就这样做”、“可能那样做也可以”“要不你来定吧”……这时你能看到的是技术同学的白眼,听不到的是他们心里的三字经。
1704234059
1704234060 ►帮技术评估工作量。 特别是技术出身的产品经理,最容易这么干。他们的潜台词就是“希望加活”:“我评估过了,这些都能做掉的”、“不要偷懒,不要忽悠我,我都懂”。
1704234061
1704234062 ►逼着技术团队承诺。 任何时候只知道公事公办,技术承诺了却做不到,自己就没责任了。很多事情不像接力跑的交棒,更像踢足球的传球,一开始没人知道下一步该干什么,如果对方基于此对你说:“大家在一条船上,应该同舟共济”时,你只要回:“我不管,我不管,我不管”就好了。
1704234063
1704234064 我认为,“承诺”更适合传统的瀑布模型,开发任务明确,技术也成熟,可以提前计算好工作量。但在互联网的敏捷模式下,很多时候会做着做着发现坑,或做着做着需求不得已发生变化,所以产品经理应该和技术人员一起做“预测”,心里想着目标,一起面对变化。最核心的区别是:承诺是技术对产品的责任,预测是两边一起承担责任。
1704234065
1704234066 实施过程之中
1704234067
1704234068 ►做了一半改需求。 经常在某个迭代周期内做“非受迫的需求变更”,这招太狠了,技术同学肯定很难忍受,俗话说“没有变更就没有伤害”。如果是因为产品经理没想清楚而导致无谓劳动,碰到性子烈的技术就要直接干架了,这时候要注意保证自己的人身安全。
1704234069
1704234070 ►开发过程中消失。 你可以多安排点出差、多开开会,注意手机尽量关机,不要响应技术的问题,要不然,责任就回来了。让技术同学为了赶进度,按照他们自己的想法做下去,关键是要在验收的时候跳出来说“这不是我要的”,再次提醒注意人身安全。
1704234071
1704234072 ►过度关注实现细节。 帮技术决定技术方案,技术出身的产品经理最爱干的事儿就是变着法儿地越俎代庖。一定要把技术从积极主动的小伙子,打击成一个个纯打工心态的“资源”(这个词听起来就有杀伤力)。
1704234073
1704234074 产品发布之后
1704234075
1704234076 ►发布后没有反馈。 技术人员也需要从市场、用户那里获得反馈,从而对自己做的事情产生价值感和成就感。我们要做的就是,功能发布之后,好像石沉大海,不告诉大家任何结果,甚至庆功会都不叫他们,紧接着继续安排他们干活。
1704234077
1704234078 ►任务无节奏感。 让技术人员忙一阵闲一阵,发布之后再开始研究接下来做什么。一会儿让技术人员有着天天通宵的高强度,给deadline,下死命令,做完之后突然不知道做什么:“你们也一起来讨论一下业务”或者“出去培训培训(做做团建)吧”。
1704234079
1704234080 全程适用
1704234081
1704234082 ►优柔寡断无决断。 表现出这个品质很具杀伤力。比如,在事情讨论完毕后,大家说:“你定吧,你说往哪儿走我们就照办。”在所有人都等着你拍板的时候,你说:“啊……那个……方案各有利弊,我也不知道怎么办,你们有什么好想法……”
1704234083
1704234084 ►报喜不报忧。 藏着、掖着一些坏信息,比如“老板在考虑干掉这个项目”这类信息,从不主动公开,但通过其他小道消息让大家知道,这样很容易就把互信完全打破,这时候他们一定很讨厌你。
1704234085
1704234086 ►不要把他们当人。 这是必杀技——不关注人的成长,只关注事的结果,永远把合作伙伴当“资源”。
[ 上一页 ]  [ :1.704234037e+09 ]  [ 下一页 ]