加入收藏 | 设为首页 | 会员中心 | 我要投稿 宣城站长网 (https://www.0563zz.cn/)- 数据湖、行业智能、边缘计算、开发、备份!
当前位置: 首页 > 站长资讯 > 动态 > 正文

他是这样从程序员转型做产品经理的

发布时间:2020-11-21 14:17:08 所属栏目:动态 来源:互联网
导读:为什么?因为结局是圆满的,至少这个奖项足以证明那次选择的正确,但毕竟人生不能一帆风顺,工作也不会事事如意。 有人会说:你看上他,不就因为他准备的够充分吗? 说实话,在面对一个完全未知的岗位的时候,不可能有准备,也没办法准备。 只有亲身经历,才会

为什么?因为结局是圆满的,至少这个奖项足以证明那次选择的正确,但毕竟人生不能一帆风顺,工作也不会事事如意。

有人会说:“你看上他,不就因为他准备的够充分吗?”

说实话,在面对一个完全未知的岗位的时候,不可能有准备,也没办法准备。

“只有亲身经历,才会感同身受”,这是我常挂在嘴边的话,无论工作还是生活。

别人无比娴熟的操作和风骚的走位使你拍案叫绝,但是你真正自己去玩的时候才发现,APM不够啊,意识跟不上。

那咋办?好吧,我们看看攻略。

所谓攻略,无非是问下前辈,读一读那些过期的文档,但在实际的工作中,你面临的是各种意想不到,千奇百怪的局面,想通过攻略来解决是完全不现实的。

所以对年轻人来说,鼓起勇气,迈出第一步,敢于说出 “我愿意”,还是很被欣赏的。

别人不说,至少我很欣赏。

有人会说:“嘚瑟啥?他不就因为契机凑巧了吗?”

嗯,有一定道理,咱们来掰扯掰扯。

回想当时,在我认为 “还行” 的那几个程序员中,有两位当面就拒绝了我,因为他们不考虑转型,也不想转型。

的确,在职业发展上,程序员要比产品经理的路线更清晰,投入与产出比更稳定,而产品经理这种岗位,在很多程序员心里是个 “靠脸吃饭” 的活。

在他们心里,这个职业的发展路线不仅不够清晰,而且受人文类影响太大,又强依赖沟通、表达能力。

至于小张为什么愿意尝试转型?

我和他聊过,他的说法是:“我不喜欢每天重复做翻来覆去Copy+Paste的工作,而且对技术也没有狂热的追求。”

“再加上,我喜欢跟人打交道,喜欢非计划性,带有潜规则性质的事情。”

“你不是常说,哪里强,哪里弱,自己内心要有点逼数吗?你瞧,我解读得够清楚吧?”

你们看看,当老大的,在兄弟们面前还是要多说一些正确、务实且有意义的话,也许这些话不能给你立刻带来财富和幸福,但是一定会改变你看待事物的方式。

“另外,我才26岁,就算转型失败,对我也是一次历练,你不是说不要害怕失败吗?”

嗯,平时的唠叨太有用了,继续。
 

没事,空降这条路走不通,那就内部 “提拔”。

当时,我在团队内找了几个 “我觉得还行” 的程序员,从意愿、发展、潜力与能力等多个角度与他们沟通。

有意思的是,小张并不在这几个人之中。

就在沟通进行到第二天的时候,小张突然找我,并主动提出想转型做DevOps产品经理的想法。

说实话,我听完之后心里不太舒服,觉得这小伙子有点不自量力,所以就反问他:“你?你知道啥叫产品经理吗?具体职责又是什么?”

“嗯,我大致知道一些……”

我瞟了他一眼,不屑一顾地说:“你还知道些?来,给我说说,咱们对DevOps产品经理的职责要求都是啥?”

他耸了耸肩,拉了把椅子坐下,随后就开始叙述。

需求的挖掘和分析

作为产品经理,首先要明确自己的用户是谁?感知用户,明确目标群体。

很显然,我们的用户是技术前台团队中的FeatureTeam(积分、会员、交易等),而产品经理要做的,就是挖掘和分析开发与测试人员在构建、测试、发布和部署工作中的痛点和需求,并通过系统工程化的能力将产品开发的效率进行提升。

另外,在和用户交流需求的时候,并不是说发现了什么就做什么,应该要清楚的了解用户是否真的要这个需求,什么情况下要,否则忙个半天,用户和开发很可能在背后骂你傻逼。

我记得去年年底,咱们业务线的产品经理不是还 “对需求的挖掘和分析能力” 作为绩效的评判标准吗?

所以我觉得这点是非常重要的,而且里面学问很深。

推动产品目标的实现

作为产品经理,除了需求,更重要的就是推动。

说直白点,就是利用各方资源把这个事情推动下去从而实现,而不是停留在黑板上,纸面上。

当然,这需要有很强的心理素质、抗压能力、沟通能力,还要有和稀泥的水平。

我记得去年年底,那位获奖的产品经理不是还调侃自己是 “没有实权的CEO” 吗?我挺认可这句话的。

所以,务实才是硬道理,少扯什么产品战略,那不是产品经理该去想的东西,踏踏实实的解决问题,给用户带来提升和价值。
 

今天在这里,可以借此做一个简短的总结。

两年前,当我们决定将组织向敏捷转型的时候,至少我们这些团队负责人在理念上是非常接受 “产品制” 的,但等到落地时,我们却被 “到底怎样算是一个产品” 给难住了?

比如,一个系统对应一个产品吗?还是一个团队对应一堆产品?如果是,那么产品与产品之间的边界又在哪里呢?

的确,像我们这种习惯于以确定性(IT要解决的问题是确定的)为基础,注重计划、预算、执行效率(人力利用率)的人来说,一下子要转变成不断挖掘客(用)户的真正需要,持续迭代更新解决方案,一切以提供给客(用)户的价值为目标。

说实话,太难了,甚至不知道从何下手。

(编辑:宣城站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读