从程序员到产品经理

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/bit_kaki/article/details/81033327

一直以来我都觉得自己是个典型性程序员。

比如出门时候我总是穿格子衫、牛仔裤,戴着黑框眼镜背个双肩包;
比如休闲时候我是个死宅,喜欢玩游戏和看小说;
比如一直到23岁时候我依然是“妹手软”,没谈过恋爱。

当然可能也有些其他方面的特征

比如拥有还不错的逻辑思维能力;
比如我对新技术总是充满兴趣,愿意主动学习;
比如我对工作和生活充满热情,精力非常旺盛。

就这样波澜不惊的工作了几年以后,突然有一天我不想再天天对着电脑敲代码了,我想尝试一些和人打交道的事情。
正好这时候领导找我谈话,问我想不想做需求,于是我就顺理成章地从一名程序猿变成了产品汪。

就如自古以来所说的“商而优则仕”以及现在娱乐圈的“演而优则唱”一般,
有的人说程序员到了35岁就要考虑转型,转管理转产品或者转售前。
其实我觉得是否转行这个事情根本还是取决于个人,
取决于你自己的个人性格、爱好、特长,取决于这些“内因”,而不是所谓的年龄、发展前景、环境因素等“外因”。
简单地说,你自己觉得你最喜欢做什么,最擅长做什么,做什么事情让你最快乐、最能给自己带来成就感,那你就去做什么。
就比如Java之父,詹姆斯·高斯林今年63岁了还在写代码,并且去年还跳槽去了亚马逊继续做云计算的开发。

当然我这边文章主要不是谈程序员是否转产品经理的事情,所以对这个问题就此打住。
我从开发转做需求开始到现在也有一年多了,刚开始转的时候其实非常痛苦,特别不习惯,经常跟身边小伙伴抱怨。
但好在自己也是个不轻言放弃的人,不断自我反思坚持了下来,到现在终于感觉在产品的道路上初窥门径。
但总的来说,在这个行业里我依然属于新人,需要学习和掌握的东西还有很多,再次不敢高谈阔论,
只是把自己的一些经历和理解记录下来,一则作为自我总结的成果,二则分享给大家,希望能给刚从程序员转产品的人一些帮助。
 

产品知识体系


在这个信息爆炸的社会,知识是不值钱的。甭管你需不需要,知识就在那里,堆积如山,当你需要的时候,你只需在网上轻轻点几下,知识就出来了。
但是知识确实又很重要,因为有了知识你才能搭建出你的知识体系。
微信公众号“岛上十点”的乔治王在知识体系上举了个例子:

这有点像搭房子,每一块知识的碎片都是一块砖,有的人搭了一座尖顶的高塔,因为他可能对某一项知识专精,也有人搭了个四合院,占地大,什么都能聊个十块八块的,但是绝多数人只是守着一地的砖,它们东一块西一块,有的是砖而有的只是泡沫板,根本搭不起房子。
然后他举一个身边简单的例子就是:
我的同事们为了孩子能挤进一个好点儿的小学大费周章,同事不乏美院或者数学类专业出身,教个小学初中生绰绰有余,但是他们依然给孩子报画画和奥数班。
老师往往有成体系的教育方式,怎么对话怎么引导怎么验证都有自己的方法,知识只是最基本的内容,而家长有的往往只有知识。
所以虽说知识都是一样,但是帮助你打底子的人不一样,在如何系统的、多维度的传授知识上,人家才是专业的。


同样的,在产品岗位上,我们也有着数不清的知识,
无论是近几年出版的各式各样的有关产品经理的书籍,或者是“人人都是产品经理”、“产品经理社区”等网站平台,
相关的文章、观点、案例可谓是层出不穷、百花齐放,我们不愁找不到学习的内容。
然而在学习时候,我们就应当顺便搭建出自己的知识体系,
比如产品经理的职责主要可分为需求、设计和运营三大板块;
需求又包括需求调研、需求分析等,设计又包括系统分析、系统设计等,运营又包括市场推广、内容营销、活动策划等;
对于需求调研里又包括了解问题领域、做好涉众分析、规划业务范围、规划需求层次、进行客户访谈等,需要获取业务用例,进行业务建模,提炼业务规则、获取非功能性需求,然后得到业务需求报告、建立业务模型和领域模型;
而建立业务模型时候我们需要根据业务用例用活动图、时序图、协作图等描述业务用例场景,最后用包图进行分类......

就这样一步一步,从职能从上往下的进行划分,将零碎的知识从下往上的进行聚合,最后最好再用思维导图画出来,就构成了一个属于我们自己的产品知识体系。


而这个产品体系就是我们自己的房子,
具体怎么搭建,每个人都有一套适合自己的方式;而搭建成怎样的房子,符合自己的需求即可。
但重要的是一定要有一套自己的房子,这才是自己立足的根本。

 

产品思维


从程序员转产品,我们需要学习很多新的知识、新的技术还有新的软件工具,
但我觉得只要是一名合格的程序员,无论知识技术还是软件工具,短时间上手应该都不是问题。
真正最难转变的是思维方式,是将技术思维转变到产品思维上。

对于产品思维这个概念一直是众说纷纭,我对产品思维的理解就是如何做好一个产品的思维方式,
简单来说就是,我要做一个产品,这个产品的用户是谁,它解决了用户什么问题,它比其他类似产品的优势是什么,它的价值(盈利点)在哪。
也就是说作为产品经理思考时候,用户是第一位,一定要解决用户的“痛点”,让用户觉得好用,并能创造价值。

而对于技术思维和产品思维比较,用下面表格来说比较直接:

 

技术思维 产品思维
功能 业务
HOW WHY
像专家一样行动 像小白一样思考


功能vs业务
作为程序员,当要做一个项目时候,我们最关心的是这个项目有哪些功能,然后考虑每个功能如何实现;
而作为产品经理,当要做一个项目时候,我们看重这个项目的业务场景是什么,解决用户什么问题。
两种思维方式做出来的产品,很可能就是以下结果:
技术思维做出的产品,柴米油盐食材一应俱全,但用户需要做什么菜都能实现,但是需要自己配各种佐料和食材;
产品思维做出的产品,就是已经把每种菜的食材佐料配好了,用户直接选择就可以。
就好比美图秀秀,它面向的用户是广大普通社会群众。
这些用户首要关心的是把自己的照片美化,所以有了一键美图。
假如它只提供了各种美图的方式,我想很多像我一样的直男或者非专业人士一定不会考虑去使用它了。

HOW vs WHY
有一种方法叫“5W1H”法,即分析问题时候思考下: 
why:为什么做
when:什么时候去做
who:谁去做
what:做的目的是什么
where:从哪里入手
HOW:怎么做
从技术思维的角度关注一个需求时候,总是先关注一个需求如何去实现,即HOW;
而从产品思维上来关注一个需求时候,应该多问一下WHY,为什么需要这个需求,多思考为什么,从而找到需求或问题的本质。
引用人人都是产品经理社区作者@有趣的程序员的一个例子就是:

哈佛商学院教授西奥多.莱维特曾说过,”人们不想买一个四分之一英寸的钻头,而是想要一个四分之一英寸的孔。”
作为技术人员时,遇到这样的需求,你需要考虑的是How,如何提供给顾客四分之一英寸的钻头,钻头要多长多锋利等等。
而作为产品,你需要考虑的则是Why,你要思考或是询问为何顾客需要一个钻头呢,自然不是回家摆着,而一定是他需要打一个洞。
那么再问,为何要一个洞,可能答案是挂一副画,装饰一个墙面等等。
等你挖掘到客户的真正需求时,你的解决办法就不仅仅是给她一个钻头而已


像专家一样行动vs像小白一样思考
作为程序员,我们日常接触到最多的还是技术人员,这些人一般来说逻辑思维都较强,擅长使用和处理各种软件,所以总是将这种形象代入到客户身上。
但作为产品人员思考时候,将用户想得越“小白”越好,假设他们是不懂电脑,不太会玩手机,甚至不会打字的人。
比如我们在设计手机APP时候,其中一个原则就是简单,易上手,不需培训。
如果我们做的东西,给我父母年龄段的人使用也毫不费力的话,那就说明这个产品真的满足了简单、好用。
当然这点挺难的,尤其是对于一些功能性的软件,但我们在思考时候也得必须考虑到这点。

 

产品方法论


在各个行业和岗位上都有一定的原则和经验,归纳起来,就成了方法论。
产品和技术一样,需要通过不断的学习和积累加上不断的思考才能有所突破,
对于我来说,以下是我这一年多以来形成的自己的一些做产品的方法,算是抛砖引玉,给大家做做参考。

项目启动
任何产品启动都有其启动的源头,即其愿景。
了解愿景的方式有很多,可能是招标文件,可能是相关业务调研,也可能是公司的商业战略。
具体的方式跟行业或者产品类型相关,但在项目启动时候一定要搞清楚这个问题:
为什么要开发这个系统?我们用这个系统能解决什么问题?
接下来是进行涉众分析,搞清楚这个问题:
谁关心这个系统?会涉及到他的什么利益?
然后就是投入和风险:
这个系统愿意花多少钱?允许多少时间?
客户参与度如何?有没有度量方式?技术上是否存在风险?是否有重要人物反对?以前是否被取消过?
在项目启动前对项目进行提前摸底,才能顺利进行接下来的工作,避免返工以及尽可能避免风险。

需求分析
在项目启动时候我们了解了项目的愿景后就可以开始梳理业务流程,进行需求调研了。
业务流程是和现实挂钩,客观存在的,进行业务流程梳理时候需要抛开计算机的概念,这样才能彻底搞清楚客户的业务。
根据项目的愿景我们可以把项目按照法律法规、岗位手册、职务说明等或者直接的客户访谈拆分为一个个的业务,
并确定每个业务的范围、目标、流程和涉众期望,从而获取业务用例。
然后用文字、活动图、时序图等方式将其表示出来,即形成一个个业务模型。
需求调研是一件很繁琐的事,其难点在于用户的需求难捕获、易变。这时候我们可以把自己想想成用户,然后问这几个问题:
对系统有什么期望?打算在这个系统里做些什么事情?
做这件事的目的是什么?做完这件事希望有一个什么样的结果?
当每个需求我们自己都能回答好这几个问题时候,自然做出来的业务模型就是合理可用的模型了。

系统设计
根据我们需求分析的结果,就可以进行系统设计了。
将业务用例抽象为系统用例,即考虑如何用系统实现这个业务,为完成这个业务我需要哪些功能?
确定完功能以后,接下来考虑的是交互设计和视觉设计。
交互设计即系统如何和用户进行交互,用户如何一步步操作系统以完成对应业务;
视觉设计即系统的UI效果。
有的人可能觉得UI效果交给美工就行了,但我觉得产品经理一定要参与视觉设计,
首先优秀的视觉效果一定是和业务挂钩的,
比如某个按钮图标,其图标内容就应该让客户知道这个按钮大概是做啥的,
或者界面的整体风格配色,也应该是和业务背景挂钩的。
而这些业务和功能,产品经理应该是最熟悉的,所以他也是必须参与的。
当然进行这些设计时候还有很多原则,比如主页面一定要清晰、尽量避免繁琐的操作,尽量将数据可视化展示等。

其他注意事项
产品经理作为承接用户和技术人员角色,沟通能力是非常关键的;
产品经理需要控制整个产品的进度,包括事情的优先级和整体资源的协调;
产品经理一定要有责任心,敢于担当,敢于背锅;
产品经理要和各个部门打交道,所以最好培养出良好的人际关系。

 

最后再说点什么


我觉得程序员是最适合转产品的岗位了:
一则是程序员大都有较强的逻辑思维能力,可以很好地完成分析和设计工作;
二则是程序员懂技术,转产品以后和技术人员交流更协调;
三则是程序员出身的产品经理设计的产品,产品开发往往根据可行性更高。
当然是做程序员还是做产品经理,主要还是看自己的内心,
没有最好的岗位,只有最适合自己的岗位。
如果你决心要进入这个领域,别懈怠,别放弃,持续努力下去吧,去迎接更好的自己!


 

 

 

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试