&人参与 | 时间：日 23:28
编辑注：对于产品经理和程序开发一职，在业内有一个生动的举例&产品经理好比打车的人，知道要去哪儿，并且知道哪条路最短；哪条路绕一点但是最顺畅；如果哪条路限行了，该走另外一条路。那么，程序开发团队就相当于是司机。打车的可以不会开车，但是要到目的地，知道上面的东西，可以省钱，省时间。司机可以接不同的人，不同的路线，只要能走到目的地就行。&那么司机如何变为那个打车的人呢？知乎上一群专业人士展开了精彩的讨论：我是一名程序员，想转做产品经理，一方面觉得自己这方面更有天赋，另一方面我不想做只是面对机器的工作，热衷于做交流沟通性强的工作，对于转行谋职 产品经理难度大吗？修改由于不清楚现在公司对产品经理的需求是怎么样的，感觉大多只有大公司对产品经理职位需求比较突出，小公司需求不明显。朱佳祺：可能每一个搞程序的人，除了对编程有一种油然而生的爱的那种，恐怕有一个阶段都会觉得产品经理是一个自然而然的出路，无外乎几点：1，做技术太累， 太枯燥（因为没有爱，编程和其他艺术或者技术一样，没有若干年的重复劳作和积淀是不会有大成的）2，觉得做技术比较卑微。3，做技术不容易找对象 （nerdy look， 肥胖，其他各种不招人喜欢的因素，不潮。）4，虚荣心（产品经理好歹是个经历，有名片什么的。程序员就是民工等等）&&所以想变成产品经理，多牛逼啊！可 以使唤程序员，可算报仇了！有自己主导的项目了，可以和高层直接对话了。说了一堆废话，我想说，这不光是我的想法，我身边有好多人都是这样从一开始就放弃了做一个技术。现在我的想法是，做一个技术其实比做产品经理幸福很多。首先，你只需要关心你自己的东西，没有那么多杂七杂八的东西。第二，做技术的人比较单纯，更 有利于思考。第三，其实产品经理的地位还不如你。你可以罢工，如果你的技术足够nb.但是他不可以，因为他上头有老板，下面有你。第四，产品经理一点也不 比写程序轻松，有时候甚至比写程序要费劲的多。因为程序这个东西是一通百通，要搞出一个靠谱的产品可不是把一套模式复制就可以了。第五： 产品经理也是跟程序员一起混，因为圈子的影响，他们也可以看起来像nerd，肥胖，穿的很邋遢&&所以如果说只是觉得做程序太辛苦，想去当产品经理，那估计这个选择挺要命的。等于是用自己的短处在去搏别人的长处。但是如果是做程序做到一定境界 了，想要更一步的努力，那么我想说这个转变还是很巨大的，对人也很锻炼。一般来说，最终产品经理想要完全不去写代码，那除非：你的公司极其的庞大，产品经 理的团队可以组一个足球队。或者是你已经有了一个非常牛逼的团队和一个非常好的boss。其实上面一大堆东西都可以总结为一句话：因为小时候被老师各种虐，所以长大了也想成为老师去虐老师的娃。跟这种想法是一样一样的。最后祝各位想当产品经理的程序员能够让自己手下的it民工们都死心塌地的为你服务。陈湛翀：你不是一个好的程序员，可能是你没有发现程序之美，没有发现编程的魅力，没有真正爱上程序员这个工作，没有真正成为一个程序员。一个真正的程序员不会感觉到自己面对的是冷冰冰的机器，他面对的是一个可以实现他想法的朋友。又或者是中国的这种环境导致你产生这类想法。你的兴趣并不在程序员里，我觉得人就应该跟着兴趣走，应该毫无顾忌地转型去当产品经理。一个成功的产品经理确实需要有一定的技术功底，这样去判断一 个项目一个功能是否有需要去实现，实现起来是否技术成本太大。同时，也可以避免受到下属的忽悠，你的技术功底足以判断出&这个功能实现起来很有难度&这类 话的真伪。最后，产品经理需要技术来实现自己的想法，程序员就可以自己去实现自己的想法了。不是产品经理才有创造力的，程序员同样有。我是认为，程序员是幸福的。flamingtop：&觉得自己这方面更有天赋&我以前也觉得自己做产品有天赋，而且我发现不少技术人员觉得自己做产品有天赋，所以或者可以反观一下，如果真的是&天赋&的话，不会有这么多人都不 约而同地这么认为；我觉得这实在不是什么天赋，只是你从事技术工作一段时间以后，开始有一些认识了而已；很多人都能对所谓产品说出个三五六来，就像一个画 画画久的人，会自然而然的觉得自己对&艺术&有了&天赋&一样，不是很可靠的；&不想做只是面对机器的工作，热衷于做交流沟通性强的工作&这可能只能说明你不喜欢当前的技术工作，并不意味着你&适合&做交流沟通性强的工作，技术工作不总是有趣的，难免有厌倦的时候，但因为这个想去做产品是不太合适的，因为做产品也有和做技术类似的问题。下面是我的看法：我感觉国内的公司基本还没有这样的意识，能够真的让一个产品经理当起实职，对一个东西提纲挈领，有真正的职权去&负责&，因为不太可能被赋予这种 职权；平时看到的所谓产品经理应该叫产品&专员&更加合适，但比其他的&专员&更虚；这个职位现在已经越来越像其他行业的各种经理了，比如保险行业人人都 是经理，地产行业卖房子的都是经理，产品&经理&的语义差不多就是这个。我认为如果其他职位的人转产品，技术职位的人应该是比较合适的，因为技术人员天天工作在产品的方方面面，对产品的需求和实现知根知底，信息的不对 称问题在这里最小；另外一方面是市场人员，也很合适，也是技术人员转产品职位的最主要缺点，对市场的认知真的不够；很多情况下，技术人员转产品在管理层看 来更难接受一点，因为一般管理人员不太懂技术人员的工作内容，习惯于自上而下的思考方式，觉得市场人员可能是更high level的工作，所以呢，&把握&起来更好，事实当然不一定是这样，但这是一个现实的难度。和纯技术工作相比，产品工作在不同的abstract level上，需要的知识结构更宽广，单一的职位挺难获得这些需要的知识（和经验），所以就像一本书上说的那样&人人都是产品经理&，因为确实需要这样； 产品是团队的高级目标，团队通常会在下意识的情况下一起完成对产品本身的认知和管理；这意味着其实无论是开发人员或者市场运营人员，实际上大家天天都在一 起做产品，站高一点看，你做技术，不只是写代码，它还会确实地决定产品最后的工作方式，体验和面貌；来自市场和运营的工作同样最终体现在产品的最终形态 里；所以产品就像是一个同时受内外（多方）环境决定的生命体，没有单一方面决定产品，但任何一方面都有重要影响；所以你从技术转产品可能是从&实际&在做 产品到&看起来&在做产品。我觉得再积累积累也是不错的选择，真的作为技术人员，把技术做好，未尝没有做产品的&实&。另外，说的直白一点，要有真正的职权，真正地对结果和决定负责，要有把控方向的权力，仍然和团队一起做产品，但产品经理的决定不能够轻易地被 override，这才叫产品经理。没有实权的产品经理，是没有做头的，会非常纠结的，技术人员转到这种角色，成本非常大，所以要看看你转到的职位是不 是&实职&，还是只是&虚招&，我个人的经历，这个词现在很火，小心泡沫。王宇鹏：我是一名产品经理，我想转行成为程序员。 为什么呢？产品经理没有实权，基本上很多小公司产品经理就是一个人，要与设计，程序，市场，销售，客服，各个部门沟通，而且如果产品没做好肯定产品经理是责 任第一人。如果有一个好老板撑腰还可以，否则很难混下去。所以这也是很多国外ceo就是直接就管产品的原因，否则根本没有执行力， 同级别如何管？ 这也是国内很多企业产品做的烂的重要原因， 产品经理实际就是打杂的。技能要求高。 技术肯定要， 设计其实也要， 否则无法做原型设计。还有就是细节要求， 最重要的就是大方向要把握好。否则一个完美的产品没有市场也不行。word ppt excel 精通更是家常便饭、思维导图、原型工具/还要不停的研究新产品。如果遇到思维活跃经常变化的领导， 做PPT做到吐， 本来如果写程序写的多还有点用。 PPT做那么多根本没用。浪费脑细胞产品经理前途渺茫， 除非你自己想， 否则产品经理实际没有太多升职空间， 国内的产品总监很多都是市场或运营的人来管的。 做产品的很少会做到总监级别。 当然国内腾讯还是很看重产品这个职位的， 但其他的公司基本没有看重产品的。产品经理加班的确比程序员少， 但是产品发布测试的时候，也是忙死， 否则自己设计的产品非功能技术性问题其他人测不出来问题在哪。程序员的优势程序员以前的地位不行，但现在很多公司已经意识到技术的重要性， 程序员的薪资范围实际上限比产品高很多， 60万年薪不算什么， 国外公司年薪100万也是有可能的。 产品职位基本没可能。现在世界已经不同了，程序员不再是苦力了，以前国内是渠道，销售、市场为王，产品、程序、设计都是苦力。现在产品做不好根本没人用，销售在忽悠也 不行了。最后实现都是技术问题。而且现在例如 apple store 发行渠道成本很低，只要能做出来好产品不愁卖不出去，微博上一传就一大堆用户。程序员自己创业不是梦想，程序员一个配合一个设计产品就能做出来，产品经理 就不行，毕竟自己不会技术就做不出来。不创业也可以靠编程序活一辈子， 一个团队可能只有一个产品经理或没有，但程序员肯定要有两三个，程序员市场需求比产品大很多。 随着年龄提高程序员的经验壁垒比产品高很多。程序员可以对产品经理说 &这个因为技术问题做不出来& 但产品经理无法对老板说&这个ppt因为我能力不行做不出来&。最后还有程序员可以靠自己想做的技术，例如NB的技术 到达人生梦想， 而产品实际上都是从抄袭，在抄袭，最后创新也是技术创新带来的产品。子陶我觉得你的未来很无限。你又懂技术，又有产品天赋，还善于沟通，很好的技能结合。干不干产品这事，我真觉得不重要，生活之中皆是产品机会。无论你是哪种开发工程师，你都可以按照自己的意愿去做一个自己的产品。何必非当产品经理呢？而且，按自己所想制作的产品，更专一，更有意思，更容易成功。产品人员的郁闷你不清楚。很少有公司给产品人员极大的权利，你要被各种声音左右。同时，你又必须具有大量产品的深入的使用体验，并了解其然和所以然。这都是你长期积累的结果。现在去做一个产品执行者，有什么意思呢？莫如以产品经理的心态，去做一款自己想做的产品出来，这才是你最对的路。白云飞先回答提问的问题：我觉得你最好还是先查清楚什么产品经理和产品再考虑不迟。另外如果你已经了解了，你管别人说啥，大胆努力去促成转变就行。打击你的，劝你别转的，一般是根本没经验或者转失败的，要深入问问他们理由，要问的；鼓励你的，劝你转的，可能是忽悠你的或者识货的，自己要小心求证。呵呵，通过提高程序员level达到贬低产品经理之目的，实在搞笑至极。产品经理=产品+经理，前一个词描述范围，后一个词描述职责（经理并不专指职位）。任何程序员写的代码，都是为了解决一个或者多个问题，我们统称产品。而一个产品的诞生，不管耗费时间长短，必然有调研，需分，规划设计，驱动实施的过程，而这个过程，每个参与的人都应该全程参与，为了高效走完这个过 程，必然会有所分工，每个人的任务也有所侧重。分工里面为了确保大家认知一致，委派产品经理全程负责文档和信息的传达，协调各个人的关系，以其按期按质完 成任务。而团队每个人并没有因此失去充分表达的机会。当然现实的情况未必有那么理想。但平心而论，程序员可以傲慢，但是不要认为自己一直耕种就以为自己最懂行情，今年收成不代表今年收入。产品经理可以傲慢，但是不要认为自己知道的东西多就一定会有人替你卖命耕种，那些东西不一定是真理，也有可能是谬论。人就如围城反复，做或者不做，自己觉得值就行。听多数人的，和少数人商量，自己做决定！本文系站长之家整理自，转载请注明出处链接。顶: 1踩: 1 来源：，欢迎分享，（QQ/微信：） 原文地址：
相关文章阅读更多：&&&&&&
(window.slotbydup=window.slotbydup || []).push({
id: '2398785',
container: s,
size: '760,90',
display: 'inlay-fix'
名 称 必填
邮 箱 选填
网 址 选填
◎已有人评论，微信搜：QQ
1楼&& 08:25:19 有些话，真不像一个程序员说的，老板发话，谁不改，产品只是改需求，程序员要改代码，能一样么，改需求，有时候代码变更很大，框架都会变，你以为像吃饭这么简单，产品狗产品狗，现在看来，也只会献媚讨好的一条狗，怪不得现在的风气这么差顶: <ins data-digg="踩: <ins data-digg="
2楼&& 04:37:35 我和小伙伴们都惊呆了顶: <ins data-digg="踩: <ins data-digg="
3楼&& 15:57:38 累觉不爱顶: <ins data-digg="踩: <ins data-digg="
4楼&& 17:27:56 什么是气场？顶: <ins data-digg="踩: <ins data-digg="
5楼&& 16:21:11 不喜欢动漫头像和真实头像的是什么？？？顶: <ins data-digg="踩: <ins data-digg="
6楼&& 06:27:10 技术可以积淀，其实技术不仅仅可以做一两年，可以做很久很久，而且技术也能为你带来很多机遇。在国内这种环境下，有一技之长非常重要。顶: <ins data-digg="踩: <ins data-digg="
7楼&& 10:02:20 技术可以积淀，其实技术不仅仅可以做一两年，可以做很久很久，而且技术也能为你带来很多机遇。在国内这种环境下，有一技之长非常重要。顶: <ins data-digg="踩: <ins data-digg="
8楼&& 10:00:56 确实如此，从技术转过来，觉得网站那点程序太简单了，很多概念很容易理解。但是网站架设却并非技术人员就厉害，很多完全不懂技术的，一样做的很好。顶: <ins data-digg="踩: <ins data-digg="
9楼&& 14:29:33 这个不错的……呵呵……技术需要长时间磨合……顶: <ins data-digg="踩: <ins data-digg="
10楼&& 10:36:09 很多做技术的都是技术狂！顶: <ins data-digg="踩: <ins data-digg="
11楼&& 16:48:16 这个要看爱好了，不能因为什么头衔而浪费了自己的才能顶: <ins data-digg="踩: <ins data-digg="
12楼&& 15:50:08 国内做技术的人，好多好多都想过转行的，认为无法提升，无法往上爬。希望能逐渐有更好的国内环境高技术！顶: <ins data-digg="踩: <ins data-digg="
13楼&& 10:03:30 产品经理是不可能转技术的，技术队延续性、专业性，还有经验要求极高，很难从其他岗位转过来。顶: <ins data-digg="踩: <ins data-digg="
14楼&& 22:34:03 最羡慕公司技术部的同事，能让所有部门都被他们的垃圾框架牵制！嘿嘿，不能让技术总监听到…顶: <ins data-digg="踩: <ins data-digg="
15楼&& 14:42:30 技术还是不错的。顶: <ins data-digg="踩: <ins data-digg="
16楼&& 13:09:18 有技术的比没技术的好很多。顶: <ins data-digg="踩: <ins data-digg="
17楼&& 12:37:29 不同的公司，产品经理的定位是不一样的顶: <ins data-digg="踩: <ins data-digg="
18楼&& 11:38:42 技术还有机遇密不可分顶: <ins data-digg="踩: <ins data-digg="
19楼&& 10:38:08 我也看到了这个问题。各家之言都很对，想做是一回事，另外也要找对公司才行。顶: <ins data-digg="踩: <ins data-digg="
20楼&& 09:44:36 有了技术才不会被淘汰……顶: <ins data-digg="踩: <ins data-digg="
21楼&& 09:43:16 中国大部分技术员都是走转型路线的顶: <ins data-digg="踩: <ins data-digg="
22楼&& 09:19:55 有时候很羡慕那些会技术的人，做网络这行，懂点技术还是要好些顶: <ins data-digg="踩: <ins data-digg="
23楼&& 08:30:26 不要放弃技术顶: <ins data-digg="踩: <ins data-digg="
顶的最多文章&&
22971134797672572557
(window.slotbydup=window.slotbydup || []).push({
id: '2398769',
container: s,
size: '300,250',
display: 'inlay-fix'
最牛评论 219156146797472
最近活动 福利投票烧烤会活动花絮如何做一个软件需求分析师？优秀的需求分析师有什么样的品质？
如何做一个软件需求分析师？优秀的需求分析师有什么样的品质？
这个问题很大，这篇不想再去重复一个软件需求分析员的知识体系结构，而是挑重点来谈下成为一个合格的软件需求分析人员的关键点。我原来对
软件需求的定义或描述更多是偏于对现实世界的定义，而对软件架构的描述为现实到实现之间的第一层抽象。在这里纠正一下即：用户需求是对现实世界的定义，而
软件系统需求是现实到实现的第一层抽象，即业务建模和软件系统用例建模。在原来的软件工程里面我们更多谈到的一个词是系统分析员，我现在将其拆分为了软件
需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。从软件需求在整个软件生命周期中的定位来看，其上接业务，下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。对
于业务，首先要解决的是对业务的理解，然后才是在理解后业务的形式化表达和业务建模能力。而对业务如何理解，最核心的仍然是顶层的流程建模和分析能力，底
层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力，业务单据和对象的抽取和定义能力，业务规则的清晰阐述能力，和流程配套的相关的
岗位角色，交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识，更多的是对业务的熟悉，对流程管理和分析方法的了解。上
面一步的业务更多的是属于顶层方面的内容，而第二个层面往往会过渡到系统软件需求层面的内容，在这里我们更加强调的是类似面向对象的用例分析和建模的方
法，这包含了业务用例和系统用例分析和建模，是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例，单个具体的用例分析和建模，每
个用例详细的基本流，扩展流，业务规则，参与角色，界面原型，业务对象和对象属性等各个方面内容的描述，要知道我们做用例建模的目的是能够按用例驱动的核
心，平滑的转入到架构设计中去，因此用例分析建模已经不是简单的描述现实世界的问题，已经涉及到业务或用户需求到系统需求的第一层抽象转换。要
做好需求的第二步的事情，那么单纯的只有业务背景就不足够的，必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开
发，但是只是是做过，通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始，最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑
用例建模，去认识到为何要采用这种方式去用例建模，真正理解用例中每个描述点如何影响到最终业务系统的实现。没有技术背景很难真正成为一个优秀的软件需求分析师，最多也就是一个业务需求分析师。要
知道，当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉
及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容，或者
说软件需求已经会兼顾部分软件架构设计的内容，因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要
去了解涉及到UCD，交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入。一个优秀的软件需求人员既不应该因为具备技
术和开发背景而导致在需求分析和建模中的各种程序员思维，也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。软件需求人员衔接了最终用户和内部的设
计开发，是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧，各种软技能的要求更是必不可少的，在此不再展开去描述。一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题，因为最终真正有用的需求分析的方法论和模式，去理解和熟悉业务和快速形式化描述和建模的方法，有不断的实践总结出来的快速理解业务的能力。
顶层建模：如何将业务实体元素适配进系统逻辑模型中
谢邀，先做1年测试，再做2年开发，再开始做产品，需求分析刚刚的。
首先得明白软件需求分析师在软件过程中所处的位置。我们知道软件过程大概可以分为启动、需求、设计、开发、测试、部署和维护。很明显，需求分析员是在需求阶段上启到承上启下的作用。其次，软件需求分析师在需求阶段需要做哪些事。接收需求定义，捕获客户的需求、分析建模、编写规格书和确认。最终的目的就是提供一份完整的，无错误的、无二义性的、可测试的软件需求规格书做为下一阶段即启动设计的输入。最后，软件需求分析师在整个实施过程中还需要做哪些事。在软件需求规格书给到一阶段后，必不可少的要进行需求讲解，让技术、开发、测试更好地工作。（题外话，有人说要进行需求讲解的话，这个规格说明书肯定有问题。这种说法不太赞同）在测试阶段需要做需求验证，接收分析用户反馈的问题并有目的的修改。很显然，从上文我们可以看出来软件需求分析师要具备的品质有：1、沟通能力；2、文档编写能力；3、软件分析建模能力；4、团队精神……
已有帐号？
无法登录？
社交帐号登录转型产品经理必看 | 我是如何从程序员一步一步走向产品经理
招聘信息：
我是@老曹，人人都是产品经理大家长，今天小编妹妹们都休息了，为了坚持给大家推荐干货，没办法啦，只能亲自来审稿了。>这是一篇长文，我花了差不多30分钟才看完，也是我见过有史以来最长最完整的一篇关于程序员转型产品经理的文章。创办人人都是产品经理以来，每天都有很多人问我如何转型做产品经理、转型产品经理会遇到哪些问题，其实我一直没能回答好这个问题，因为我从运营转型产品经理的过程太顺利，并且转型的过程也没有做太多的思考和总结。直到看到这篇文章...作者完整记录了自己一路来从对产品的认知到接触产品到转型产品整个过程，以及对产品的理解、意识的转变、心态的转变，非常完整，由衷佩服作者。今天推荐这篇文章给大家，尤其是准备转型以及在转型路上的小伙伴们，希望对你们有帮助，文章比较长，但是值得一看。放下，是一种修行拿起，是一种历练写在前面过去一年，我完成了角色和身份的转变，从最熟悉的开发跨越到陌生的产品，从最初的好奇到中途的迷茫到最近的有一点开悟，一路经历着、成长着，抬笔记录下我这一年心态、意识、思维的转变，算是对过去的一段总结，对未来的一份期许，我因技术而入门，因产品而出门。我理解的产品说起产品，或者说互联网产品，我第一次明确的知道这个概念的含义应该是在2011年，那一年智能手机开始兴起，印象很深刻，那一年的Android系统还是在1.x到2.x的升级中，那一年的iPhone对我来说还是个遥远的奢侈品。也是在那一年，我开始学习Android开发到后来学习iOS开发，走上了移动开发的道路，也就是在那时候，我开始做移动App项目，那时候，我把项目当做了产品。那时候对产品的理解是浅层的，更多的是看得到的界面、用的到的功能，相信很多初入产品的同学都会有这个阶段，设计出漂亮的界面和酷炫的功能就以为是一款成功的产品。也就是从那个时候开始，我边开发项目，边发现自己对所谓的项目设计有了自己的见解，并时常给项目负责人，也就是产品经理提自己的建议，我想那就是我最早的产品感觉了，从此，发现自己对这个创造、设计一个好用东西的过程充满了兴趣，埋下伏笔，在开发的过程中，我开始有意识的去了解这个过程，在做好开发之余，我开始“不务正业”的去学习、去了解什么是设计、什么是产品。我开始从网络、一些行业会议去学习、了解这方面的内容，从此，我开始对这个过程越发感兴趣，从此，我知道，这个过程叫做产品设计，主导这个过程的角色叫做产品经理，也就是PM（Product Manager）。产品经理，听起来是多么高端的一个词，但此经理非彼经理，产品经理没有行政权力，没有主导商业战略的权力，产品经理负责商业战略的落地实施，负责定义产品、设计产品，协调各方资源在一定的条件下完成产品的研发和上线以及上线后的运营和维护。如果把产品比喻成一个孩子，那产品经理就是孩子他妈。现实中，产品经理的工作远没有本身称呼那么高端，产品经理需要处理每一个跟产品相关的问题，产品经理需要与各方沟通取得共识，需要去现场解决问题，需要处理大大小小的杂事，忙碌奔波于跟产品相关的每一个场景中，所以，在互联网，伟大的产品经理们自嘲为产品汪或产品狗。在我看来，产品狗是一个褒义词，它忠诚，对自己的产品忠诚，它勤奋，对产品每一个问题都努力解决，它乐观，每一个小小的进步能让它高兴，每一个不足都是它前进的动力。细数全世界优秀的产品经理，群星璀璨，乔布斯是极致的代言人，他定义并设计的苹果系列产品改变了一个时代，引领了潮流。他的苛刻、极致、改变世界的初心影响着互联网所有领域的产品经理们，奉为经典。张小龙，微信之父，深谙人性，理解潮流，能把一款产品做到人们的生活中，几亿人都为之买单，实属境界。相信每一个产品经理都有改变世界的梦想，也都在这条不归路上蹒跚前行，改变世界的毕竟是少数，能改变的只有自己，在产品之路上修炼自己、完善自己，不经意间也许就会发现自己已经做了一件了不起的事，脚踏实地，仰望星空，有宇宙的胸怀，同时也要有蝼蚁的勤奋。我转行做产品到现在正好一年，我所在的是一家创业公司，从技术转行产品也实属巧合，这一年，从产品角度来看，我的产品之路总共经历的三个阶段，也是截然不同的三个阶段，这一路，我的心态、意识、思维都在经历着变革，或者说蜕变，伴随的是艰辛和一路不放弃的韧性，总的来说，在思维意识上我经历了工程思维、功能思维、产品思维三个阶段。思维决定心态和行动，记录下我的转变。阶段一：工程思维我从2014年10月份开始正式做产品，从那个阶段开始的三个月左右，我做产品的思维更多的是以技术和系统角度出发，我定义这个阶段为工程思维阶段。为什么这么说，因为我在设计产品的时候，第一出发点是技术实现层面的，通过实现的难易程度和系统角度去定义产品和设计产品。这么做有一个最大的弊端，就是脱离“实际”，我说的这个实际并不是技术实现的“实际”，而是需求和实际场景。容易变成为了设计而设计，相信做技术的同学都会有一种感觉，当接到一个需求的时候，首先是从现有工程架构的角度和扩展角度去考虑，一个需求或者一个功能的实现与否第一考虑要素是对现有系统的兼容性以及扩展难易程度。这是一种很正常的思维，因为我也是这样。但从另一个角度考虑，一个需求的价值不在于它本身的技术难易，而在于是否解决了产品用户的问题，如果把一个需求定义为技术产物，那我们是在做一个科研任务，相反，产品做的是商业任务。所以，我在一开始从技术模式切换到产品模式时，相当一段时间都是在通过技术定义和设计产品，这个时候的产品脱离现实场景，远离用户需求，我开始反思。工程思维下的产品产出更像是一个工业品，而不是一个能站在人的角度解决现实问题的产出。它是技术产物或者说是科研成果，远离实际需求和场景，最后会发现，这样的产品投入市场后几乎处于不可用状态，这是非常严重的问题。工程思维模式下，缺乏用户意识，当然就更谈不上用户体验了。有问题不是坏事，可怕的是发现不了问题，发现问题后我开始解决问题，于是，我逐渐进入第二阶段。阶段二：功能思维发现工程思维下的产品工作不尽如人意，于是我开始有意识的思考，如何去分析和理解需求，如何通过技术手段将一个需求转化为一个给用户使用的功能。这是我的第二阶段，即功能思维，这个阶段维持了近半年，这时候我开始意识到，产品最终是交付给用户使用的，所有的设计过程都是将一个业务需求转化为一个具体场景下的特定功能。而每一个功能都具备完整的业务逻辑和功能体验。好在的是，这时候我开始站在用户的角度去设计产品，将一个业务需求转化为一个技术能实现的功能，于是我开始围绕功能而思考，每一个需求或者优化我都首先从功能角度入手，如何让用户更好用，应该展现哪些信息等等，我将注意力集中在功能体验和视觉体验上，开始学习市场上各种优秀的产品设计，于是我在解决产品可用性的前提下陷入了一个功能设计怪圈。会为了完成一个需求开始考虑功能体验上的各种可能性，重点都是关注产品功能本身，而忽略了其业务目标和业务价值。而且，这时候我发现，一个产品从商业战略到最后的落地产品上线，期间不仅仅是一个技术产品，还包括业务定义、全业务流程设计等等，产品始终与业务并行发展，真正好的产品应该做到产品驱动业务，在产品设计过程中我忽视了与业务的互动，包括产品上线后产品运营和业务运营，这些环环相扣构成一套整体来支撑一个产品的运转。而且做产品的都知道，与各方的沟通和达成一致实际占到了产品工作的很大一部分。我的思路再一次被打开，开始关注业务、关于产品战略和定义、关注产品需要实现的业务目标，在保证实现一个正确功能的前提下更多的思考这个功能的业务目标是什么，不以结婚为目的的谈恋爱都是耍流氓，不以实现业务目标为目的的产品设计都是扯淡。功能思维下的产品产出具备了一定的可行性，因为它结合实际需求，在功能思维下我对整个移动App的产品功能设计有了深刻的认识，从信息架构到产品交互设计和部分视觉设计都形成了自己的思维模式。同时，我开始站在业务角度去思考产品问题，产品究竟实现了什么业务目标，与产品相关的各环节究竟该如何定义和设计才能保证最终产品产出是具备可用性的，于是，我逐渐进入第三阶段。阶段三：产品思维产品思维，也是我目前所处的阶段，这个阶段我关注的更多的是业务价值和业务目标，在充分理解商业战略的前提下来完成产品定义和产品设计，通过充分了解产品所围绕的业务场景去提升产品的可用性和易用性，改善业务体验和产品体验，提升整体的用户体验。返璞归真，回归产品的本质。在产品思维下，我理解产品的过程超出工程和功能，但又涵盖工程和功能，正是因为有了前两个阶段，才让我对产品整个过程和每一个细节有了更进一步的了解和认识。在产品意识和产品思维的驱使下，我在前期定义产品的阶段会充分了解业务并清晰定义业务目标，衡量在目前的产品环境和可用资源下如何快速实现。期间需要完成大量的沟通工作，与业务、运营、设计、技术和公司其他相关职能部门等等。在共识和可行性的基础上再开始进一步的详细设计工作。产品思维其实可以大大简化产品工作，在思路梳理和分工协作上相比之前有了效率的极大提高。整个产品体系从下到上分为战略层、范围层、结构层、框架层、表现层。最下层的战略层决定了业务和产品需要实现什么目标，为什么人和什么场景服务，范围层需要定义清楚在既有战略的基础上做哪些东西来实现战略目标，结构层需要基于范围层的内容完成基础信息架构和交互设计，框架层完成我们能看的到的界面设计，表现层则是视觉表现设计，让产品看起来更友好。一个完整的产品定义和设计过程都需要经历从下到上的每个阶段，缺失某一个阶段都会导致产品的不完整，重点关注某一个阶段也会导致产品的不平衡，所以需要产品经理找到其中的平衡点。但就重要性来说，越往下，重要程度越高。产品思维还有一个非常重要的环节就是对业务流程的设计，产品经理为最终的产品质量和用户体验负责，在设计前期就需要考虑产品从设计到开发到最终投入使用需要经历哪些环节，需要与哪些人进行合作。比如需要数据准备的产品，在产品设计阶段就需要与数据提供方达成一致，保证产品上线时数据准备是ok的，比如需要运营介入的产品设计，需要在前期沟通阶段就邀请运营人员加入，确保其对整体业务流程和产品环节是足够清晰而且理解一致的，才能在最后产品上线时大家集体发力保证产品能高效运转，而不是产品单方面思考和定义然后交付给下游配合方，这样会导致产品与业务脱节。所以，产品思维需要在考虑整体性的同时顾全细节，心里要装下业务、运营、设计、研发，这个过程很累，但也足以让人成长。做好产品的同时，也做好了自己。我的产品方法论在整个互联网产品行业里，我属于产品新人，需要学习和掌握的东西还有很多，在此不敢高谈阔论，只把自己的理解记录下来。在这一年的修炼过程中，我慢慢形成了自己的一套做产品的方法，分享出来，算是接受批评建议和与大家讨论。产品和技术一样，需要通过不断的学习和积累加上不断的思考才能突破才能破局，所以对我来说，这是一次重新学习和突破的旅程，好比当初学习技术一样，学习、理解、掌握、整理、思考、突破。以下五点是我做产品过程中的五个关键步骤：定义产品战略定义产品战略需要基于商业战略，我理解的商业战略和产品战略还是略有不同的，商业战略的目标是实现组织利益最大化，而产品战略的目标是实现用户利益的最大化，在确保围绕商业战略的前提下落实到产品战略。所以，对于产品战略的定义需要建立在对商业战略的充分理解上。这就需要从组织高层也就是组织商业战略制定者那获取到一手信息，以最完整的状态将商业战略的定义做到充分理解。接下来就根据完整的商业战略定义来制定产品战略。一个组织或者公司可能有多条产品线，这时就会有个产品战略，但是商业战略只有一个，所有的产品战略都是为了实现这一个商业战略而制定的。定义产品战略需要分析清楚产品的目标用户是谁，使用场景在哪，关键资源是什么，当然最重要的一点是产品解决了用户什么问题，如果要用一句话来回答什么是产品战略，我总结就是：“我们用什么方法为谁解决了一个什么问题”。这里的“我们”就是组织，是团队，“什么方法”是指我们的核心业务，是服务，“谁”是指我们的目标用户，是客户，“什么问题”是指核心需求，是场景。这个过程不需要用到什么工具或特别的方法，只需要做到组织和团队的理解共识，通过文字记录下来即可，关键是思考清楚。通过对关键问题定义，回答清晰后就可以进入下一步，对业务流程进行完整的梳理了。梳理业务流程梳理业务流程需要基于对产品战略的清晰定义。业务流程围绕产品战略目标而设计，需要明确业务目标，流程围绕目标进行最简化设计。在这个过程中最关键的是定义好业务目标，明确清晰业务目标即要达到什么目的后再进行进一步的流程设计。梳理业务流程的过程中需要考虑整个业务流程中涉及哪些关键角色，这些角色的关键动作是什么，业务流程中包括哪些关键信息，同时要定义清楚各角色间信息流动的方式。完成对业务目标、关键角色及动作、关键信息的定义后，可以使用流程图将设计好的业务流程通过图的方式表达出来。流程图的画法就不赘述了，有很多方法，关键是明确业务流程设计中的三个关键环节。在梳理业务流程的过程中，需要定义清楚哪些是需要人去参与和处理的，哪些是需要技术处理的，这样一个完整的业务流程梳理下来后就已经很明确，技术产品的边界在哪，而边界之外的需要协调各方资源来完成。同时，整个过程中需要与组织各方进行充分的沟通，确保设计的业务流程在现有资源环境下是可行的，也要与研发团队就技术产品在业务流程中所扮演的角色和定义进行充分沟通，确保在现有技术上是可行的。总的来说，梳理业务流程的过程就是产品经理在现有资源下为实现产品战略目标而设计的一套可行的业务操作流程。产品原型设计业务流程梳理清晰后，就可以开始产品原型的设计了。产品原型设计包括信息架构设计、功能设计、交互设计和视觉设计。产品经理首先需要对产品信息架构进行定义，产出完整的产品信息结构图，接下来基于对业务流程的理解开始进行功能设计，功能设计的目的是为了满足业务流程的设计，所以是先有业务流程设计后有功能设计。产品功能设计时确保采用最小化原则，我们采用的是最小化可行性原则，也就是MVP（Minimum Viable Product）原则，这是精益创业中的一个概念，关于什么是MVP什么是精益创业大家可以去了解一下，我觉得这是一套非常好的业务和产品设计实践。功能定义完后就是交互设计和视觉设计了，在大公司可能有专门的交互设计师和视觉设计师，但我认为，产品经理还是需要有比较强的交互设计能力和视觉审美能力的，之说以说需要具备交互设计能力，是因为前期的业务流程定义和功能定义都是产品经理直接参与的，而最能理解并将其直接转化为一个技术产品的非产品经理最合适不过，这是我认为的一种比较高效的方式，当然，用什么方式取决于其所在组织的实际情况，像大公司就是人多工种细，但弊端就是效率低。而我们作为创业公司来说，我是极力倡导产品经理需要进行功能和交互设计，最后产出产品功能交互图，这个过程称之为低保真设计。当然这个过程可以和设计师一起沟通进行，吸取专业建议。之所以说产品经理需要视觉审美能力，就是最后由视觉设计师完善高保真设计，但是一个好的产品经理我认为是能分辨出什么是好的设计和不好的设计，而且用户的第一感是从表现层开始，也就是看的见的界面和用的着的功能。产品原型设计过程中可以用到的工具有很多，我常用的有苹果的keynote，用它来制作产品界面原型快速而且美观，交互设计逻辑用简单的文字加上连线标示来标示跳转关系即可，当然还有很多的工具可以选择和使用，就不赘述了。这一步完成后应该就能产出一个所谓的PRD了，之所以说所谓的PRD是因为我认为创业公司最好不要去弄一大套文档来各种说明，PRD的目的是用来记录整个设计产出，同时作为业务各方和研发团队的输入材料，做到描述清晰、利于业务和技术理解即可。这也是精益创业的核心所在，不要做多余的东西，简单直接、达到目标。沟通协调资源完成产品战略定义、业务流程梳理、产品原型设计后，就进入设计实施落地阶段了，这个阶段主要是沟通和资源协调工作。同时需要对设计产出进行微调和优先级处理。这个阶段是考验产品经理优先级处理和沟通协调能力的阶段。团队里每个人的思维方式和角度不同，如何使大家在理解上达成一致本来就是一个浩大的工程，沟通技巧在中间就起到了非常关键的作用。与业务的沟通不能完全用产品技术思维，与技术沟通不能完全用业务思维，所以，产品经理起到承上启下进行信息传递的关键作用。在确保业务目标的前提下保证技术产品能在有限的资源和时间内完成。沟通讲究的是找对人，同时注意沟通顺序。明确沟通目的然后找到能解决这个问题的那个最关键的角色，如果找错人付出的就是时间和精力然后还得不到结果。找对人后接下来就得确定沟通顺序，要确保事情顺利开展和问题的快速解决，定义一个沟通顺序很重要，一般来说，我按照问题阶段来确定沟通顺序，比如处于问题定义阶段，需要和问题提出人和相关决策定义人完成问题的定义，问题定义清楚后针对具体的解决方案，再和与这个解决方案相匹配的资源各方进行充分沟通，然后确保在解决方案的执行过程中执行各方的理解是一致的。全程确保沟通的直接、高效，避免出现重复沟通和沟通不到位的情况。在沟通协调这个环节中，产品经理千万不能怕麻烦，重要的事说三遍，沟通、沟通、沟通，很重要！验证改进产品经历以上四步后，产品能按期上线了，这时候需要监测业务和产品的实际运转情况，深入现场了解问题，回来后及时总结并制定改进方案。这是精益创业中的验证环节，前期的设计在某种程度上都可以说是先验的设计，上线后就需要根据实际运转情况来反向验证业务和产品，这也是之前为什么要做MVP设计的原因，因为前期设计越简单后期验证改进的成本就越小，好产品是在不断验证和改进的过程中打磨出来的，没有一次性完整的设计。在验证和改进产品的过程中，我认为最重要的一个环节就是去现场，去到业务发生的地方，去到用户中间，在实际场景中体验产品，发现问题并制定解决方案。避免接收二手信息，这样会误导产品经理做出判断。改进产品的时候，可以结合业务流程中的每个节点，找到现场很重要，去现场，在现场定义问题，回来制定解决方案，快速验证、快速试错、快速改进。写在最后过去这一年，我完成了一次转型，从一个专业技术人员转型到产品人员，技术让我入门，看到这个行业的细节，产品让我出门，让我看到更广阔的空间。这个过程中没少走过弯路，经历过开始的好奇、憧憬，到中途的迷茫、自我否定，过度到现在的慢慢开悟和真正理解产品。人的成长本来就是一个过程，春天播种秋天才能收获，回想这个过程感受到更多的是收获和成长。我的产品生涯才刚刚开始，路还很长，我会坚持在这条路上走下去，走好，走漂亮！以上说的这些都是我个人的一些总结，不代表任何观点。放下，是一种修行，对过去的珍重和告别，拿起，是一种历练，是对未来的信心和期待。就写到这，我所说的不一定都是对的！本文由 @唐韧_Ryan 原创首发于人人都是产品经理 ，转载请保留作者信息并注明来自人人都是产品经理（微信号：woshipm）。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量10616点击量8409点击量5425点击量5297点击量5051点击量4921点击量4437点击量4380点击量4103
关注微信 每日推荐
扫一扫 浏览移动版
&2015 Chukong Technologies,Inc.
京公网安备89}