阿里产品岗需是技术出身？分享技术转型产品的成功经验
戳蓝字“CSDN云计算”关注我们哦！
作者 |卡小基
本文转载自公众号： 卡小基看世界
最近看了一个爆料：
不管这爆料是不是真的，至少在我9年的开发生涯中没遇到过几个靠谱的产品经理，究其原因就是大多非技术出身，非技术出身也就罢了，还不懂装懂，纸上谈兵。随着未来的互联网竞争压力骤增，也是时候把产品经理筛一筛了。
这篇文章不是我写的，而是我的知识星球的球友写的。他已经从程序员成功转型到了产品经理，在产品的道路上也是走的很顺畅，所以就把他的经验分享给大家，下面是正文。
一直以来我都觉得自己是个典型性程序员。
比如出门时候我总是穿格子衫、牛仔裤，戴着黑框眼镜背个双肩包；
比如休闲时候我是个死宅，喜欢玩游戏和看小说；
比如一直到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效果交给美工就行了，但我觉得产品经理一定要参与视觉设计，
首先优秀的视觉效果一定是和业务挂钩的，
比如某个按钮图标，其图标内容就应该让客户知道这个按钮大概是做啥的，
或者界面的整体风格配色，也应该是和业务背景挂钩的。
而这些业务和功能，产品经理应该是最熟悉的，所以他也是必须参与的。
当然进行这些设计时候还有很多原则，比如主页面一定要清晰、尽量避免繁琐的操作，尽量将数据可视化展示等。
其他注意事项
产品经理作为承接用户和技术人员角色，沟通能力是非常关键的；
产品经理需要控制整个产品的进度，包括事情的优先级和整体资源的协调；
产品经理一定要有责任心，敢于担当，敢于背锅；
产品经理要和各个部门打交道，所以最好培养出良好的人际关系。
最后再说点啥
我觉得程序员是最适合转产品的岗位了：
一则是程序员大都有较强的逻辑思维能力，可以很好地完成分析和设计工作；
二则是程序员懂技术，转产品以后和技术人员交流更协调；
三则是程序员出身的产品经理设计的产品，产品开发往往根据可行性更高。
当然是做程序员还是做产品经理，主要还是看自己的内心，
没有最好的岗位，只有最适合自己的岗位。
如果你决心要进入这个领域，别懈怠，别放弃，持续努力下去吧，去迎接更好的自己！
福利
扫描添加小编微信，备注“姓名+公司职位”，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！
推荐阅读：
2019年中国IT市场趋势热点
2019年最值得关注的五大微服务发展趋势
叫你一声“孙悟空”，敢答应么？
骚操作！代码写情诗 | 程序员有话说
30 秒？！Chrome 插件带你速成编程学习 | 程序员硬核评测
翟天临之后，大连博士细数区块链博士圈那些事……
50个最有价值的数据可视化图表（推荐收藏）
微服务、Kubernetes和无服务器之后，即将发生的……
为了完成月入三万的目标，我都做了哪些准备？
喜欢就点击“好看”吧