互联网项目经理-大互联网公司项目经理做啥

一般来说架构师高点，但是你要分清楚2个概念架构师是技术上做到了很多的起点，项目经理偏向于管理了，现在中国写代码的超过35岁基本都是转行做管理的，道理我想你也明白，所以这2个不同的方向你选择那条道路都可以，关键是自己如何给自己的未来定位，相对来说项目经理比架构师好做，架构师需要做到技术的极致，项目经理主要是对一个项目的把控。希望这些建议对你有帮助。

产品经理岗位沉淀的核心能力与价值是什么？

1．是对产品经理个人专业能力的理解2．从系统分析员看产品经理工作的异同2无线互联网产品经理面临的更大要求和挑战  第一部分：对产品经理专业核心能力的理解 年，个人对SP行业产品经理的看法与认知：1）产品逻辑简单；感觉当时的那些WAP产品逻辑非常简单；有的是简单几个页面，放几个图铃就可以拿到移动梦网上收费；这里产品的主要工作还是在内容运营上；2）“面向运营商的产品策划”；那个阶段，SP的商务模式清晰暴利，移动绝对主导产业链，制定游戏规则，对产品模式，甚至连产品表现层都有限制，比如页面什么地方要加什么链接就要加；3）“面向渠道的产品运营”；运营商通过移动梦网把握营销渠道及计费渠道，产品经理更多的工作是以收入为中心进行渠道经营；对用户的行为分析做的比较少；回顾这个阶段，我想整个行业发展阶段就是如此，无所谓对错了；4）产品经理的进入门槛不高；要做开发至少要会写程序吧，但感觉产品经理门槛太低；BD内容维护，美工，很多角色都可以转岗到产品经理；据了解，当时很多SP公司招一些专科生，甚至高中生做产品经理，也一样紧锣密鼓的赚钱。

产品经理的工作内容琐碎而繁杂，但感觉不够系统和严谨，每天花用画几个页面就扔过来开发。

 我当时一直在考虑这种工作状态下，这个岗位沉淀的核心能力和价值是什么？但客观的说，这个也不全是我们的问题，当时的整个SP行业氛围就是如此浮躁；也幸亏这个时期无线业务的造血功能，才养活了游戏，互联网等各个业务；但人才的价值在哪里呢？随着后续SP行业泡沫的破灭，很多公司的SP产品经理下岗，求职也到处碰壁；原因在于他们并没有建立起自己的核心竞争力，甚至不具备成为一个互联网行业产品经理的能力。

 对产品经理专业核心能力的理解。

这里只谈专业领域方面的能力，对于商务谈判，沟通技巧，文档能力等方面暂时搁下；个人认为一个领域的产品经理的专业能力表现在以下三个方面：1      行业理解能力；                   行业分析师的素质；2      用户需求系统化分析能力；系统分析师的素质；3      用户体验细节把握的能力；交互设计师的素质；  首先：行业理解能力，是做这个行业产品经理的前提。

宏观方面，行业的视野对于产品战略定位，产品策划，商务模式等有必然意义；微观方面，对这个行业内用户需求，行为，习惯，交互行为的理解。都需要在这个行业里逐步积累；提升方式：获取行业信息，思考加工，提炼观点；个人认为这个本质上属于知识层面，经过靠年深日久的积累，逐步转化成能力要素和外化为直觉层面；要像一个行业分析师那样了解这个行业。 其次，用户需求系统化分析能力。

作为用户的代言人，产品经理左手是用户群，右手是技术人员；产品经理要在深刻理解用户需求的前提下，将他们系统整理，分析，转化成开发人员可理解的表达方式；用户需求分析的工作是系统，严谨的，而不是零散，琐碎，堆砌的；把产品看成一个系统，就可以理解各个功能之间的关系，而不是做简单的功能加法；需要的分析方法，进行业务建模；并能综合权衡用户需求度，可行性，方案成本的来评估需求的优先级；提升方式：掌握系统化分析的工具，比如业务建模，用例分析；习惯面向对象的思维方式；个人认为，这块能力需要比较严谨的逻辑思维；我们常见的问题是，产品经理一上来就画UI交互图，用户界面；其实这些在一个产品过程中属于最后的思考环节；会导致我们无法认知产品定位，产品全貌；在产品功能拓展过程中，没有方向感，容易做加法；个人认为，这个其实很适合系统分析师的工作特点和思维方式，在下面会讨论一下系统分析师和产品经理工作中的异同； 。

 再者，用户体验的细节把握能力；用户体验，这个名词姑且理解为使用者对产品的主观感受吧；这个感受可能是功能设计带来的，也可能是交互细节，或视觉设计方面带来的。

特别是在竞争市场功能趋同的环境下，决定体验的往往是细节层面；最了解用户的人，是产品经理，他既是用户代言人，同时有时对行业理解比较深入的人；因此，他需要有很强的“用户使用场景还原能力”；这个“使用场景”，是对人，时间，空间的综合考虑；就是要能模仿用户的心态和使用环境，来检验产品的工作流程是否顺畅，体验是否OK；这个如果是习惯于用例分析的系统分析师，做这个还是会有优势的；在有的产品构建构成中，是有“交互设计师”这一岗位细分出来的，比如WEB或软件交互设计师；这是一群掌握了互联网UI交互基本原则，对用户心理及行为分析有理论沉淀的专业人才；因为产品经理对产品负责，因为要有交互设计的理论素养；虽然在具体的工作中，产品经理不一定亲自做交互设计，但要有判断能力，知道为什么好，或者哪里不好；有一些领域，比如WAP交互产品设计，因为行业发展初期，这一岗位还没分化，只能由产品经理搞定。

  产品经理的“125”模型，只是换一种提法：对于以上三种能力，我在团队内部有一些包装和提炼：“1”：一种能力。系统化需求分析及业务建模的能力；“2”：两种视角。一是宏观的行业视角；深入理解互联网及无线行业，这对产品战略定位，用户群行为需求，交互习惯，及商务模式的衍生都有意义；二是微观的用户视角；作为最了解用户的人，必须对产品体验负责，具备很强的用户场景化分析能力（分析）。

 “5”：是一个普遍产品设计方法论；之前是：战略层，范围层，结构层，框架层，UI层；这个来自于用户体验的要素一书这里特别说明一下：1）产品定位；根据外部市场及内部资源状况，从用户需求及公司战略角度阐述发展此产品的可行性，并明确产品发展策略，两个视角：1用户视角；满足何种用户的何种需求（包含对目标用户群的锁定）；2公司视角；对公司利益价值何在；2）业务建模；通过分析，描述用户对产品的功能诉求；确定大致的服务范围；并识别需求的组织分类及优先级；通过这个工作输出业务模型描述，用户需求分析说明书；这个不涉及到细节交互及实现方案。

个人认为，产品经理的进入门槛虽然不高，但要成为很优秀很资深产品经理还是有比较大挑战的；从公司职业能力模型来看，素质的全面性是一方面；关键是要在专业能力上有深入的发展；个人认为要在以上3个能力点有突破的人，才称得上专业； 个人的一点想法与建议：1      产品经理专业能力的系统化培养机制产品经理的其他综合素质，比如项目，领导力，沟通。

等能力素质各人都可以在不同的岗位实践中获取；公司这个方面也有一系列的培训课程，比如沟通技巧，谈判技巧，项目管理。等。但在产品经理专业能力方面，比如需求分析的能力，这个培训还是比较少；比如用通用的面向对象的思想做需求分析，用做业务建模的方法，比如对于UML工具的了解；这个都比较少。

我们自己的产品经理写的需求说明书，要么是直接就画交互设计；要么是采用传统面向过程系统设计中的《功能规格需求说明书》，包含了输入，输出，处理过程这些内容；希望，公司或有做的比较好的团队，能进行这个方面的系统化培训；对于交互设计原则，还不错，设计中心有相关培训；对于行业理解力，这个几次培训可能无法解决问题，可能得靠产品经理自己的日常信息积累和思考。

  2      对于产品经理岗位人才的建议还是不得不说，要成为一般产品经理并不难，要在业务领域很资深，个人观点是还是因人而异；一个建议是从系统分析员中招聘产品经理；或从会系统分析的开发人员中找；因为系统分析师的思维方式和综合素质和产品经理类似，相信再加上行业的理解，进入角色应该不难；另外一种就是靠从新人开始培养了，个人觉得要在专业层面有突破，首先逻辑思维能力要强一些，有利于掌握系统化分析的方法；其次是有一定的内敛气质，善于观察总结，能在用户体验细节上沉得住气；还要有强的学习领悟能力，擅长对行业方向进行思考；至于创意及发散性思维，个人觉得有更好，没有也不是非常关键，可以通过发现和收集别人或用户的来完成，反而太发散和跳跃的思维会影响对系统整体的思考。

  第二部分：系统分析员和互联网产品经理工作的异同：从我之前系统分析员的工作经理，聊一下个人浅显的看法；前面几年包括读研时期做项目，做过一些系统分析角色，包括面向过程的系统分析及后来尝试学习面向对象的系统分析。

 首先，相同点；1）系统分析的思维方式类似产品构建过程我们可以把一个产品看作一个系统，其内部的功能架构不是简单堆砌的，而是有依赖从属的，符合一个系统的视角；在面向对象系统分析中，无非就是分析清楚系统人，事，物体，规则了；这个人，是系统的使用者，相当于产品的目标用户群；事，指使用者通过系统要完成的事情；相当于产品中的功能特性建设了；物，系统中用户完成事情中所产出的东西，比如数据实体对象等；产品中也有这些，比如日志。

一般的系统分析是系统目标界定，相当于产品定位了；然后是业务建模，用例分析，系统建模；前面相当于产品设计中的场景化分析，做功能化构建；而系统建模这个工作是用技术语言来描述系统模型，目前这个工作在产品工作中没有的，因为大多数的产品非技术背景，不考虑这些；但技术人员则应当输出完整的系统建模；但是可能很多团队省却掉这一步了。

 2用户视角系统分析师和产品经理都要非常强化用户视角；系统分析，特别是面向对象的系统分析都是以人为核心的，首先就是找到系统的使用者，再研究他的需求及想完成的事情；做分析，也必然以的参与为核心来进行描述；这一点，和产品经理的场景化分析是一致的。  3）分析和用户的场景化分析能力相通我们描述用户的需求，不能简单的止步于对目标用户群社会属性的认知年龄，职业，收入。

等，一个场景包含了对人，时间，空间等综合考虑，这种场景化的还原对分析用户的需求是有必要的。  4二者的职业素质模型类似综合素质要求都比较高，比如沟通能力，领导力，谈判能力。等。  其次，差异化：1）业务模型的复杂度一般系统分析师面对的商业系统设计的逻辑比较复杂，特别是涉及工作流环节；而互联网的产品相对比较轻量级，完成的功能简单；比如一个WPS的产品，OA系统比一个产品要简单一些。

2）目标用户群及其需求界定方面一般的信息管理系统的用户角色很好阶段，逐个找到并做深度CE，调研，是尅一挖掘出所有需求的；而互联网产品一般面临千万级用户，需求很难明确界定，只有通过敏捷的开发过程，不断试探和反馈。

3）业务模型上，互联网产品包含更多的创意文化系统分析师所面对的商业信息系统一般是解决现实工作中的问题，要客观忠实的反映符合传统工作规则；而互联网产品的更多是挖掘用户潜在需求，甚至通过创意来激发新的需求。

  再者，系统分析师的额外优势：系统化需求分析能力，及业务模型的建设能力；从业务模型推导出产品规划及版本节奏的时候，系统分析师一般有技术背景可以综合技术可行性，技术实施成本等进行综合考虑；  第三部分：无线互联网产品经理所面临的特殊挑战1产品经理系统分析能力和要求是一致的，业务模型的建设能力也是一致至于其他的领导力，项目能力，商务谈判，沟通技巧。

等产品模型方面都一致；甚至由于无线产品经理在某些能力上会更出色，比如商务谈判，沟通技巧。 2用户交互体验细节方面，由于移动终端的特性，这一块没有行业沉淀，需要自己摸索，自我沉淀 3行业理解能力上，无线产品经理面临更大挑战一方面需要了解当前有线互联网行业的业务形态，竞争状况，商务模式等；因为有线互联网向移动侧延伸和渗透，服务融合是趋势。 。

另一方面，由于无线互联网还具有自己的行业特点，比如运营主导的长产业链；移动终端，无线网络，运营商政策对上层应用产品的影响都要综合权衡；我划了一个图，简单说明一下无线互联网行业的各种要素。

这个得看这家互联网公司偏重哪一块。如果说门户型，内容型的互联网公司，那么项目经理可能更加偏重文案编辑，策划。如果这家是电商，那么更加偏重营销策划这方面。如果是技术服务性公司，那么可能偏重技术开发等等。但一个好的项目经理，最重要的还是敢于承担责任，公正之心

PMO基本概念如下。据我所了解PMO需要较深的行业经验，与人脉。还需要对项目有整体的把握，以及较好的流程控制、沟通能力。

如果你还是个年轻人的话，就要具体判断你想要从事的这个行业目前的状况。以IT业为例，大型ERP系统类的PMO身价不可限量，但是年轻人也极少，相对小型的项目的话还是有机会的，还是要看个人的了。

PMO即（项目管理办公室），是随着IT产业的潮流应运而生的产物，最初的目的是节约成本，提高项目成功率，以及实施标准流程，以应对越来越多的项目管理任务。虽然它在节约成本和提升项目管理质量上目前还很难有一个可量化的指标，但是越来越多的公司和企事业单位在它们的IT部门设立集中的PMO，统管所有IT项目。PMO（项目管理办公室）是负责对所辖各项目进行集中协调管理的一个组织部门。PMO的职责可涵盖从提供项目管理支持到直接管理项目。

PMO的一个主要职能是通过各种方式支持项目经理，包括（但不限于）：管理PMO所辖全部项目的共享资源；识别和开发项目管理方法，最佳实践和标准；指导、辅导、培训和监督；通过项目审计，监督对项目管理标准、政策、程序和模板的遵守程度；开发和管理项目政策、程序、模板和其他共享文件（组织过程资产）；协调项目之间的沟通。PMO的核心职能包括：1定义并推行可重用的项目管理流程；2集中控制项目进展和资源调配。

那么，就会有两种不同侧重点的PMO：一种是顾问型的，为项目经理提供培训、指导和最佳实践；另一种是集中式管理型，将项目经理集中到PMO，然后派往不同的项目，最终由PMO统一控制所有项目和资源。

国内很多公司应该是更倾向于后者，一方面，项目管理或者说软件工程本来就是一门艺术，很难有一个定式，就算有再多的“最佳实践”，根据项目具体情况的不同，也很难保证它们就一定适用，现实中要找到真正管理经验丰富，可以向别人提供理论指导的人才，并非那么容易；另一方面，后者能够更加直接的体现出PMO存在的价值，不光是直接的具体的项目管理，也有利于确定不同项目的类型和轻重缓急，合理分配资源。

项目经理与PMO的目标不同，所需遵守的要求也就不同，但他们的所有努力都必须符合组织的战略需求。

项目经理与PMO之间的角色差异可能包括：项目经理特定的项目目标，而PMO管理主要的项目集范围变更，这些变更可被视为能促进业务目标实现的潜在机会；项目经理控制分配给本项目的资源，以更好地实现项目目标，而PMO负责优化利用全部项目所共享的组织资源；项目经理管理单个项目的制约因素（范围、进度、成本和质量等），而PMO从企业层面管理方法论、标准、整体风险机会和项目间的依赖关系。

当然，如果一个PMO最终做成一个完全意义上的行政部门的话，它也不应该同公司的企业文化相冲突，它起到的作用也应该更多的体现在如何去将项目的失败和公司的亏损减到最低限度，如何提高公司的项目管理水平，而不是一味的、机械的通过所谓的“标准流程”处理项目的实际问题，或者仅仅是一个跟踪项目进度，通常以一种管理者的姿态去命令各个项目组的部门。

它应该同公司的各个相关部门：如CIO、CAO和QAO，以及具体的项目组、公司财务和高层管理部门共同协作，促进公司各个项目的顺利实施。一个比较常见的、直观的说法是，PMO需要保证所有其属下的PM具备管理当前项目的能力。而从长远来看，最理想的PMO能够给公司的IT部门带来持续不断的业绩提升。