阿里产品岗需是技术出身？分享技术转型产品的成功经验

最新推荐文章于 2024-08-21 11:40:44 发布

csdn业界要闻

最新推荐文章于 2024-08-21 11:40:44 发布

阅读量1.4k

点赞数 2

戳蓝字“CSDN云计算”关注我们哦！

640?wx_fmt=jpeg

作者 |卡小基

本文转载自公众号：卡小基看世界

最近看了一个爆料：

640?wx_fmt=jpeg

不管这爆料是不是真的，至少在我9年的开发生涯中没遇到过几个靠谱的产品经理，究其原因就是大多非技术出身，非技术出身也就罢了，还不懂装懂，纸上谈兵。随着未来的互联网竞争压力骤增，也是时候把产品经理筛一筛了。

这篇文章不是我写的，而是我的知识星球的球友写的。他已经从程序员成功转型到了产品经理，在产品的道路上也是走的很顺畅，所以就把他的经验分享给大家，下面是正文。

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

比如出门时候我总是穿格子衫、牛仔裤，戴着黑框眼镜背个双肩包；

比如休闲时候我是个死宅，喜欢玩游戏和看小说；

比如一直到23岁时候我依然是“妹手软”，没谈过恋爱。

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

比如拥有还不错的逻辑思维能力；

比如我对新技术总是充满兴趣，愿意主动学习；

比如我对工作和生活充满热情，精力非常旺盛。

就这样波澜不惊的工作了几年以后，突然有一天我不想再天天对着电脑敲代码了，我想尝试一些和人打交道的事情。

正好这时候领导找我谈话，问我想不想做需求，于是我就顺理成章地从一名程序猿变成了产品汪。

就如自古以来所说的“商而优则仕”以及现在娱乐圈的“演而优则唱”一般，

有的人说程序员到了35岁就要考虑转型，转管理转产品或者转售前。

其实我觉得是否转行这个事情根本还是取决于个人，

取决于你自己的个人性格、爱好、特长，取决于这些“内因”，而不是所谓的年龄、发展前景、环境因素等“外因”。

简单地说，你自己觉得你最喜欢做什么，最擅长做什么，做什么事情让你最快乐、最能给自己带来成就感，那你就去做什么。

就比如Java之父，詹姆斯·高斯林今年63岁了还在写代码，并且去年还跳槽去了亚马逊继续做云计算的开发。

当然我这边文章主要不是谈程序员是否转产品经理的事情，所以对这个问题就此打住。

我从开发转做需求开始到现在也有一年多了，刚开始转的时候其实非常痛苦，特别不习惯，经常跟身边小伙伴抱怨。

但好在自己也是个不轻言放弃的人，不断自我反思坚持了下来，到现在终于感觉在产品的道路上初窥门径。

但总的来说，在这个行业里我依然属于新人，需要学习和掌握的东西还有很多，再次不敢高谈阔论，

只是把自己的一些经历和理解记录下来，一则作为自我总结的成果，二则分享给大家，希望能给刚从程序员转产品的人一些帮助。

产品知识体系

在这个信息爆炸的社会，知识是不值钱的。甭管你需不需要，知识就在那里，堆积如山，当你需要的时候，你只需在网上轻轻点几下，知识就出来了。

但是知识确实又很重要，因为有了知识你才能搭建出你的知识体系。

微信公众号“岛上十点”的乔治王在知识体系上举了个例子：

这有点像搭房子，每一块知识的碎片都是一块砖，有的人搭了一座尖顶的高塔，因为他可能对某一项知识专精，也有人搭了个四合院，占地大，什么都能聊个十块八块的，但是绝多数人只是守着一地的砖，它们东一块西一块，有的是砖而有的只是泡沫板，根本搭不起房子。

然后他举一个身边简单的例子就是：

我的同事们为了孩子能挤进一个好点儿的小学大费周章，同事不乏美院或者数学类专业出身，教个小学初中生绰绰有余，但是他们依然给孩子报画画和奥数班。老师往往有成体系的教育方式，怎么对话怎么引导怎么验证都有自己的方法，知识只是最基本的内容，而家长有的往往只有知识。所以虽说知识都是一样，但是帮助你打底子的人不一样，在如何系统的、多维度的传授知识上，人家才是专业的。

同样的，在产品岗位上，我们也有着数不清的知识，

无论是近几年出版的各式各样的有关产品经理的书籍，或者是“人人都是产品经理”、“产品经理社区”等网站平台，

相关的文章、观点、案例可谓是层出不穷、百花齐放，我们不愁找不到学习的内容。

然而在学习时候，我们就应当顺便搭建出自己的知识体系，

比如产品经理的职责主要可分为需求、设计和运营三大板块；

需求又包括需求调研、需求分析等，设计又包括系统分析、系统设计等，运营又包括市场推广、内容营销、活动策划等；

对于需求调研里又包括了解问题领域、做好涉众分析、规划业务范围、规划需求层次、进行客户访谈等，需要获取业务用例，进行业务建模，提炼业务规则、获取非功能性需求，然后得到业务需求报告、建立业务模型和领域模型；

而建立业务模型时候我们需要根据业务用例用活动图、时序图、协作图等描述业务用例场景，最后用包图进行分类......

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

640?wx_fmt=jpeg

而这个产品体系就是我们自己的房子，

具体怎么搭建，每个人都有一套适合自己的方式；而搭建成怎样的房子，符合自己的需求即可。

但重要的是一定要有一套自己的房子，这才是自己立足的根本。

产品思维

从程序员转产品，我们需要学习很多新的知识、新的技术还有新的软件工具，

但我觉得只要是一名合格的程序员，无论知识技术还是软件工具，短时间上手应该都不是问题。

真正最难转变的是思维方式，是将技术思维转变到产品思维上。

对于产品思维这个概念一直是众说纷纭，我对产品思维的理解就是如何做好一个产品的思维方式，

简单来说就是，我要做一个产品，这个产品的用户是谁，它解决了用户什么问题，它比其他类似产品的优势是什么，它的价值（盈利点）在哪。

也就是说作为产品经理思考时候，用户是第一位，一定要解决用户的“痛点”，让用户觉得好用，并能创造价值。

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

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

功能vs业务

作为程序员，当要做一个项目时候，我们最关心的是这个项目有哪些功能，然后考虑每个功能如何实现；

而作为产品经理，当要做一个项目时候，我们看重这个项目的业务场景是什么，解决用户什么问题。

两种思维方式做出来的产品，很可能就是以下结果：

技术思维做出的产品，柴米油盐食材一应俱全，但用户需要做什么菜都能实现，但是需要自己配各种佐料和食材；

产品思维做出的产品，就是已经把每种菜的食材佐料配好了，用户直接选择就可以。

就好比美图秀秀，它面向的用户是广大普通社会群众。

这些用户首要关心的是把自己的照片美化，所以有了一键美图。

假如它只提供了各种美图的方式，我想很多像我一样的直男或者非专业人士一定不会考虑去使用它了。

HOW vs WHY

有一种方法叫“5W1H”法，即分析问题时候思考下：

why：为什么做

when：什么时候去做

who：谁去做

what：做的目的是什么

where：从哪里入手

how：怎么做

从技术思维的角度关注一个需求时候，总是先关注一个需求如何去实现，即HOW；

而从产品思维上来关注一个需求时候，应该多问一下WHY，为什么需要这个需求，多思考为什么，从而找到需求或问题的本质。

引用人人都是产品经理社区作者@有趣的程序员的一个例子就是：

哈佛商学院教授西奥多.莱维特曾说过，”人们不想买一个四分之一英寸的钻头，而是想要一个四分之一英寸的孔。”

作为技术人员时，遇到这样的需求，你需要考虑的是How，如何提供给顾客四分之一英寸的钻头，钻头要多长多锋利等等。

而作为产品，你需要考虑的则是Why，你要思考或是询问为何顾客需要一个钻头呢，自然不是回家摆着，而一定是他需要打一个洞。

那么再问，为何要一个洞，可能答案是挂一副画，装饰一个墙面等等。

等你挖掘到客户的真正需求时，你的解决办法就不仅仅是给她一个钻头而已

像专家一样行动vs像小白一样思考

作为程序员，我们日常接触到最多的还是技术人员，这些人一般来说逻辑思维都较强，擅长使用和处理各种软件，所以总是将这种形象代入到客户身上。

但作为产品人员思考时候，将用户想得越“小白”越好，假设他们是不懂电脑，不太会玩手机，甚至不会打字的人。

比如我们在设计手机APP时候，其中一个原则就是简单，易上手，不需培训。

如果我们做的东西，给我父母年龄段的人使用也毫不费力的话，那就说明这个产品真的满足了简单、好用。

当然这点挺难的，尤其是对于一些功能性的软件，但我们在思考时候也得必须考虑到这点。

产品方法论

在各个行业和岗位上都有一定的原则和经验，归纳起来，就成了方法论。

产品和技术一样，需要通过不断的学习和积累加上不断的思考才能有所突破，

对于我来说，以下是我这一年多以来形成的自己的一些做产品的方法，算是抛砖引玉，给大家做做参考。

项目启动

任何产品启动都有其启动的源头，即其愿景。