产品经理的工作内容和职责文档格式.docx
《产品经理的工作内容和职责文档格式.docx》由会员分享，可在线阅读，更多相关《产品经理的工作内容和职责文档格式.docx（12页珍藏版）》请在冰豆网上搜索。
重点在宣传：
品牌的建立和推广、对企业等组织进行宣传合作、对终端消费者进行宣传合作、同时研究消费者心里
b）产品的市场拓展相关内容
重点在拓展市场：
具体到移动互联网上的客户端产品，就是通过投入资源与手机厂商，或者产业链其他环节进行合作帮助产品通过厂商内置、后置等渠道拓张市场份额;
c）产品的商务拓展相关内容
重点在商务：
根据产品形态的不同，不一定会有这样的部门。
作为接口，它连接产品项目组和外部的与我们有商务合作的组织或个人
d）产品的渠道推广相关内容
重点在推广：
动用各种渠道类资源，帮助产品扩张市场份额;
紧跟市场大盘，预测市场发展规模并制定相关策略
e）产品的内容运营相关内容
重点在运营：
根据产品形态的不同，紧跟社会热点进行内容类的运营，一般意义上而言，对于大多数半年以上的产品，内容运营至关重要。
（如何处理产品的可运营性和功能特性之间的关系也是PM要花时间细想的领域，这是后话）
以上，a～e的部分则一名PM或多或少要参与其中的工作。
所以小结一下，一个PM的工作范围是以上1～7和a～e的和，而主要的工作内容（也是花时间最多的部分）是1～7的部分。
第2节产品经理的工作方式和方法
第1节概要性的描述了PM要做什么，而这一节则主要描述PM会怎么做。
与上面1～7相对应的顺序。
一、需求撰写
1）需求从哪里来?
a.PM根据自己的专业素养（也就是感觉）体验自己产品和市场上其他产品时发现的问题或是灵感闪现出的关键点;
b.各级产品领导的直接反馈和建议
c.用户使用中遇到的问题、困惑、以及反馈非常需要的功能点
d.行业最新的动向
当然，以上仅仅说明了需求的来源，这大量的需求最终在前线PM这里汇总，PM根据自己的专业能力对需求进行筛选、优先级划分、推理权衡和细化，并时刻与产品核心路线进行对比校正，最终拿出产品下一步发展的方案;
2）怎么写?
a.主要工具
word、ecxel、ppt什么的、原型设计类的软件，这些都不重要。
所以你可以自由的选择自己需要的工具、软件、甚至系统，自己顺手就好，所以建议时不时的换一换工具换一换心情。
b.写作技巧
#1开始写之前，一定要在自己的脑子里完美的想好这个功能点的方方面面（或者至少想个80%），各种可能、各种异常处理都要想清楚;
#2写作的时候，要尽量清晰全面的把想好的东西写出来:
#2.1清晰是指逻辑清晰，一定要让交互、设计、开发、测试同学能很好的理解你想要传达的想法;
#2.2而全面是指详细，一定要详情，非常非常的详细，需求产生的背景、要怎么改善、为什么这么改善、这么改善后期望达到什么样的效果、触发条件呢（前置后置）、具体怎么改善呢（最大量的写作工作、事无巨细描述清楚你的逻辑、同时考虑所有的异常情况）、必要的流程图、适当的最终效果（这里后面还会有提及）等等等等
#2.1和2.2是一名PM专业程度的体现，一定要拿出逻辑清晰的文档，因为你是自己产品的上帝，你的每一处逻辑都会影响到千千万万在这种逻辑下生活着的终端用户，通过完美的逻辑，概念设计一个完美是世界是这个工作最有价值的部分之一，可是最快乐的部分，不要错过它。
#3写作之前和写作之后
#3.1真正动笔写作之前最好能先把你的想法和涉及的开发、交互沟通一下，初步判定一下可行性，否则天马星空的设计如果最终被开发判定实现不了，或者实现的成本高于你的预期，就要再斟酌斟酌了。
#3.2写作之后的流程
自己写出来的东西还不能直接拿给项目组开始开发的流程，还要至少组织一次会议请同为策划的同事、需求相关的同事和各级领导进对你写的东西进行一次评审，这样做的目的主要有3个：
a.帮助你检查需求的严谨性，找出错误和漏洞，讨论出更优的方案
b.知会到需求相关方，也就是这个需求会涉及到的项目组以外的其他组织的相关同学，在正式开工前听到他们的意见，一方面可以根据他们的现实情况对需求做一些调整，另一方面可以与他们约定好后续的合作方式、需要的资源，对方准备也需要一个时间
c.领导那里会有关于市场、产品今后发展方向的更多的信息，因此他们会帮助你评估这些需求是不是符合当前产品的发展方向、会不会/会如何影响到公司/部门在这一个点上的定位和布局、会不会比他们对这个产品的期望不符。
具体这一步的流程和在项目循环中的位置，在后面一节“项目相关的流程”那里会进一步说明。
二、开发过程
与上面1～7相对应相对应，现在我们开始讨论第2个部分：
开发过程。
开发过程是我们的产品从概念变成真正可贩卖的工业品中必不可少的神奇一步，是多种不同分工、不同专业背景的同学在一起协同工作的过程，很重要。
后面会以如下的一个目录方式逐步讲解这里的细节：
1）项目的概念
2）项目组
#1人（资源）
#2流程（人和人之间如何协同）
3）PM在开发过程各个阶段中的作用
#1需求阶段（需求方全体确认需求）
#2开发阶段（开发团队集中开发阶段）
#3测试阶段（质量检查的阶段）
#4发布阶段（内测、灰度、正式发布等逐级发布阶段）
#5发布后的阶段（效果跟踪的阶段）
下面会根据这样一个目录进行说明：
项目的概念相对简单，可以理解为一个话题或者主题，很多人为了同一个目标、同一个主题、同样的利益和愿景聚拢在一起形成了项目组。
这一点和公司等任何组织的形成类似。
项目组里有不同的人，一般来说，一个处于开发循环中的核心项目组包括了这样的一些人：
产品经理、视觉设计人员、交互设计人员、开发人员（前端开发、后台开发）、测试人员、项目经理等。
所谓的开发循环中的核心项目组是指一个形成一个产品所需要的最少（最标准）的人力配置结构，当然一个更宽泛意义上的项目组还包括了很多很多其他角色：
运营、渠道、运维等等等等;
这些角色在开发循环中（显然，不在循环中的时候某些角色还有自己的独立于项目组之外的工作）的主要职责是：
a.视觉设计人员（视觉设计，你看到的几乎每一个优美的图案）
b.交互设计人员（交互设计，你在使用产品过程中哪些举动可以获得反馈以及以什么形式获得什么样的反馈）
c.开发人员（前端开发同学的成果就是你拿到的最终安装包、后端开发同学的成果则是在服务器端的逻辑，离你看起来很远，但实际上息息相关）
d.测试人员（写过程序的同学都清楚，开发过程中难免会有各种各样的问题，有些很容易看出来，但有些要通过一定的测试手段和方式才能找出）
e.项目经理（成熟稳健的项目经理对一个团队来说非常重要，人力资源在项目中的保证和调配、确保项目中涉及的各流程的顺利运行，以及处理好项目组内成员及其分别的外部支援团队与项目组之间的关系，这些是项目经理工作的内容，所以你看到了与项目经理良好的互动和项目配合对PM的工作会有很大的帮助）
##题外话一下，项目经理的英文ProgramManager,产品经理的英文ProductManager，所以你看到两者如果英文缩写的话会很像，因此不同的公司都会想办法在英文名上对这两者进行区分，在腾讯，公司制度上项目经理缩写为PM，而产品经理缩写为PDM，但实际上不论是在行业内还是在公司内，大家还是总是喜欢叫产品经理为PM。
所以以下我会继续这样写。
#2流程
互联网产品的一个典型的项目组内环形开发流程是这样的：
需求的撰写和定稿–》交互设计和视觉设计–》开发–》测试–》发布–》新的需求的撰写和定稿……
##所以你看到了，需求阶段是整个环形开发的起点，因此当你综合考虑PM的职责和他在开发流程中这样特殊的位置时，就会明白他是很不容易的，有很多事情需要他来处理和承担责任（背黑锅而受到指责什么的……所以新手特别是毕业生产品经理是很艰难的，类比导演专业一毕业就带摄制组出去拍摄，艰难程度可想而知，因此对于新手，在你从业的前半年到一年的时间是需要准备好随时接受来自项目组内外的压力，这里冷暖自知了，最后第3部分心得体会和大家分享一点点）
那个循环开发流程只是说项目组内需要一同经历的流程，也就是说为了协调大家各种角色的时间、更好的进行协同工作所需要的循环流程，但实际上项目组内的部分同学，除了这个流程以外，在这里的项目组里每天每周都还有无数其他的流程要走。
与项目相关的，比如PM在自己的组内有需求评审的流程、比如交互设计师和视觉设计师分别在自己的视觉/交互组内都有各自的评审流程;
3）PM在开发过程中各个环节中的作用
#1需求阶段
#1.1加工从各个需求渠道过来的需求、撰写需求的部分就不说了，上面已经讲到了
#1.2带着写好的需求文档经过需求评审的流程，并根据评审的建议或意见进行修改，直到达成一个绝大多数人都能够认可的需求;
#1.3和交互设计师深入交流，不要只说你要什么效果，而要全面的讲讲为什么要这样做，你达成一个什么样的目的，这样可以更好的借助交互设计师的专业知识，可以提供给你和他更开放的思路一起想出可能原先想都想不到的更好的实现方案。
##题外话一下，如果你所在的公司和部门在你所在的项目中提供了专职的专业交互设计师，那么建议在写需求文档的时候可以使用一些低保真的原型工具（低保真!
），而不是Axure因为这样会限制你和交互设计师、以及在需求评审阶段的每一个人的思维，这绝对不是你想要的效果，所以，试试低保真的原型图吧
#1.4和视觉设计师深入交流，不要说你想到哪里用什么颜色，同样，尽量说说你想到达到什么样的效果，至于配色什么的交给视觉设计师吧
以上1.1～1.4的部分才是一个完整的需求方确定需求的部分。
#2开发阶段
#2.1在问题出现时权衡取舍、做出决策
开发过程中，随时会遇到概念设计阶段想不到的新状况，比如开发同学开发过程中发现有的地方不好处理、或者有的地方有两种以上的实现方案但是都有优缺点、或者某些地方要是真按照需求文档那样写会有一些潜在的风险，而以上的任何一种情况出现，都需要你，一个一线PM根据自己的经验和感觉、根据产品方向和核心价值进行权衡取舍后给出直接明确的答案：
做或者不做、选A方案或是B方案、哪些损失是值得的。
#2.2保证资源及时到位
#2.2.1及时与某些项目资源输出方沟通
保证资源的到位是项目经理的职责，但实际上产品经理也要深入的参与其中。
比如设计资源的到位情况，项目经理会保证在一个时间段内这个设计人力可以100%的属于这个项目组，但是在设计师动手之前你需要与之充分沟通，确保设计师与你向着相同的方向在努力;
而当设计师输出设计资源以后，还要根据设计资源的质量（也就是能否满足需要、是否契合PM希望达到的视觉气质等等）反复与设计师沟通，这个过程可长可短，而项目组后续的很多工作都有可能卡在这里，所以PM在这里也有责任保证资源的保质保量及时的输出。
（##题外话，所以如何保质保量及时也是一个问题，这里涉及到“信任”和“妥协”，在第3部分心得分享的模块，会做进一步说明）
#2.2.2在项目过程中随时与项目资源输出放沟通
既然如上所说，开发过程中随时都会有新的问题，都会有项目内外部各级的同事领导体验反馈出问题，那么相应到，很多资源上的新需求，也是在项目过程中随时产生的，当有此类场景出线时，及时与相应的资源输出方（一般是交互和设计）进行快速有效的沟通非常必要。
#2.2.3及时审核确认
每天项目都会有新的进展，每天都会有一些功能点完成、一些修复优化的点开发好，因此及时的审核确认也是PM工作的一部分，否则等到了测试阶段或者上线前的阶段再发现一些重大问题（或是与需求文档不一致的地方，你会发现这种事情时有发生）就会造成很大的修复成本，时间、人力、项目组的信心、PM被信任的指数等等等等都有可能受到不同程度的伤害，因此这也是一个很重要的部分。
#2.3下一个循环也在同步的进行
移动互联网市场正在日新月异的迅猛变化，当前行业里最雄厚的资本、最杰出的人力资源都在以极快的速度向这个领域内聚集，因此腾讯MIG去年常说的一句话就是“快比什么都重要”，所以具体到腾讯的模式下你会发现以两周或者三周为周期的项目组开发周期非常的普遍（记得一年多以前还有2个月多一个周期，那个时候PM还有喘口气的时间，这是题外话了），因此作为一个PM，在一个正在进行中的项目周期中，你除了要做到上面的#2.2.1~2.2.3之外，还在同时为下一个项目周期做好准备，开始进行需求的撰写、评审以及其他的需求方流程。
#3测试阶段
一般来说，在前期开发过程中，PM会进行高频率的产品自测，也就是上面的#2.2.3所描述的部分，而到了真正的专业测试阶段，PM介入的就比较少了，专业的测试人员测试出问题后大部分情况会直接反馈给开发同学，只有当有很多很多问题开发同学做不完需要PM排优先级的时候、或者是有些优化点优先级低但是可能意义非凡时，需要PM来做一些时间和效率上的取舍。
（关于质量与效率等问题，在第3部分心得体会那里也会有提及）
#4发布阶段
一般情况下，在经过了专业测试之后的产品差不多就可以发布了，以后的过程可能不同的公司/部门都会有所不同，但大致上还是比较相似的：
#4.1找一小撮玩家进行测试
可以找公司内的同事，也可以招募一些公司外部的玩家用户测试，这一阶段的目的是找出专业测试也没有发现的重大问题（比如安卓平台上由于机型和系统的严重碎片化，很容易发生程序在某个特定机型上出一点小状况的事情）以及听听用户对某一个新feature是否会有比较大的正向或是负面的反应;
#4.2灰度发布
还是基于万一出现问题时控制受众范围的考虑，一般我们会采用灰度发布的策略（当然这个策略的制定也是PM工作的一部分），灰度策略制订时一般考虑两部分受众：
新增用户、老版本用户。
新增用户如何处理、什么比例;
老版本用户如何处理、什么比例，这些问题一般通过PM的经验结合这款产品的用户规模、所在生命周期的某一特定阶段而制定。
#4.3全量发布
灰度发到100%就是全量了，也有不经过灰度发布直接全量的情况。
#4.4其他
当然，以上#4.1～4.3才不会是我们工作的全部，还有很多很多的事情需要你来做，比如提前一周左右输出发布计划给所有相关部门和人员、发布前的各种各样的资料准备、发布前和各宣传相关的渠道的交流（微博、软文、、）、发布前准备好客服公告、新版本发布时安装包里帮助文件的更新、发布后信息知会给所有相关部门和人员等等等等。
#5发布后的阶段
#5.1效果跟踪
可以通过很多渠道直接或间接的获得用户反馈，比如论坛、微博、Q群、帮助社区、新闻（腾讯的产品不论好坏一般都会有或多或少的行业评论）、甚至家人、朋友、同事、领导等等等等。
#5.2数据分析
毕竟只有血淋淋的数字才能直观的证明一项新功能/改动的正确性和效果，因此版本发布后的数据分析也是必不可少的工作。
数据分析这里至少将包括规模数据的分析、和各主要特性的分析两大部分，当然用户及市场反馈的部分也是一个重要的可选项。
以上1）～3）整体上概要性的描述了开发环节中PM的主要作用，而实际工作中一般要处理的事情会更多一些。
三、产品相关数据的监测和分析
这一部分讲到了数据，虽然在心里我倾向于认同PM（至少在需求的创造这一方面）实际上是一种（感性的）艺术，不应该以数据来作为唯一的判断标准进行衡量，但是醒醒吧阿宅，经济学常识告诉我们，在一个市场经济主导的经济社会里处于竞争环境中的企业内工作，这样的环境注定了用数字说话才更有力量，因为数据才代表了收入和金钱，所以艺术只能让位于商业，好吧，这么说有点冷酷，那么听听下面的说法：
另一方面，用户数据可以简单直观理性的证明给我们自己和各级相关同学：
我们在做的事情是正确的!
是有价值的!
是想着光明的方向的!
这些数据帮助你看到用户真实的想法，即使你在网上看到一堆人骂一个功能没用仅仅噱头，但看到数据显示92%的用户会频繁的使用该功能，你心里会不会踏实很多?
这里大概说一下吧，一般情况下我们更关注规模数据、操作数据和运营数据，其他的还好。
另一方面，以什么样的周期来关注数据也是一门学问了，根据公司/部分/产品/数据种类的不同而不同。
数据这里比较敏感就不细讲了，感兴趣的同学可以在网上找找书什么的，或者在工作中自行摸索。
四、行业、市场和竞争对手的监测和分析
#1行业与市场
行业和市场信息的阅读和了解其实没有必要进行制度性的要求，只要平时多看看行业新闻就好，主要是培养自己的产品sense（这一点多用多想别人的产品也有很大帮助）和行业敏感度，这一点对热心于这个行业的新同学来说从来都不是问题吧。
值得提的两点是：
#1.1兼容并蓄、海纳百川的心态
主观上不要轻视任何一种创意和市场行为，每一条科技新闻的形成背后都有一堆执着的人和一定的市场基础，多看多想，不要急于否定和排斥，可以多练习形成自己的观点和判断（这个阶段不一定要分享出来）。
#1.2行业敏感度的培养与验证
当你对一个产品一个功能一种趋势有了自己的判断，即使身边的人、项目组暂时不能接受，但市场终究会给出一个答案。
如果你的预见，总是能经过时间的证明（比如一段时间后在竞品的身上看到了自己原先的设计），对自己自信心的形成会有很好的正向激励作用。
#1.3工具、方式
一般来说，作为一个客户端PM白天你几乎是没有时间用来看网页看新闻的，所以你会比别人更需要一些移动智能终端设备比如iPhone、iPad什么的，便于你利用一些碎片时间update到最新的资讯，否则自己会很快过时，逐渐陷入到自己特定的领域内无法形成宏观的视野，也会容易缺乏自信，变得依赖于岗位。
#2竞争对手的监测和分析
维护一张表格，周期性的检查竞品的动态，挑出一些你关注的点进行持续性的分析，知己知彼才能更好的打败对手。
第3节心得体会
现在回头看，在前面的章节中大量的许了愿要在第三节中进行心得体会的分享，千万不要有过高的期望啊，只是felix自己在工作中的一些不完全的感悟和总结（怎么可能期待我在这样的大半夜1点半回忆完整个这1年的经验呢～呵呵），难免会有偏颇和不成熟的地方（毕竟才1年级嘛，不然以后靠什么吃饭），仅供参考。
1）服务意识
第一点并没有提MIG内部常说的“产品经理是火车头”的概念，因为如果以那个观点作为出发点，操作层面其实比较走弯路，特别是毫无管理经验的毕业生同学。
所以根据自己长期的摸索，认为以“服务意识”作为一个PM心态的原点会比较好的应对面临的问题。
这么想的原因是：
#1首先重新审视一下我们的工作实际上是要求面面俱到，在开发循环中的任何一个环节全权代表产品团队和项目组在做一个一线的决策，因此可想而知每天可能每个环节的同学，包括各级领导都有可能来找你确认、查询、解决、反馈一些问题。
确实会很忙很乱时间完全碎片化，有时也会因为总是被打断正在进行的事情，和接到很多临时性的任务而心烦意乱，所以这种时候如果认为别人的“打扰”干扰了你的“正常工作”，那你就输了，因为不断被“打扰”，不断被确认也是我们工作的一部分，因此这种时候如果能认识到“我的工作就是一种服务性的工作啊呵呵呵呵”基本上心理会比较容易摆正心态。
#2服务的心态可以更顺利的作为一种内驱力，在项目组正常运行时提供助推剂;
比如你不会独断的任务需求的产生是你一个人的事情（虽然你确实收到了比较专业的训练），而是会用一种开放的心态与项目组内成员充分的交流;
同理，很多事情，比如外部团队帮助下制定的产品宣传策略和品牌推广活动，作为一个接口人你也可以开放的分享的项目组的其他成员（当然虽然他们也许没有时间看，而你也不一定有时间这么做）
#3醒醒吧啊宅，不要被“Manager”两字蒙蔽了双眼，IT业内（传统行业那个就不提了）最早提出PM概念的微软在设立“PM”这个职位之初的定位：
为工程师端茶送水、预定会议室、与其他团队交流以及帮工程师团队承担来自外部的压力、并尽最大努力帮不善言辞的工程师们推销他们的想法。
so，看到了吗?
其实这个职位从设立之初就是个服务性岗位，so，我把这一点作为“服务意识很重要”的最重要理论基础了。
2）“产品经理是火车头”的理解
这一句话基本上在腾讯MIG内部经常被提及，你的各级leader、项目经理，甚至开发团队潜意识里都会反复提到这个词，所以作为这句话所涉及的主体行为人，PM会怎么理解这句话呢?
我的理解是：
#1执行力
输出需求的效力、保证需求尽快通过各种各样评审的效力、保证需求所涉及的各类资源的正常按时输出、保证对开发过程中出现的问题的及时解决、保证发布正常进行的效力、以及各种各样你主要处理的事情的执行力，因为一般情况下，对方的单线程和线性的，而PM会同时面对很多人很多件并发的事情需要解决，因此如果在某一个方面某一批人那里出现延误和没有处理好的情况，PM很容易被认为执行力差……所以执行力是一个很重要的要求。
#2积极的感染力
就是怎么看怎么觉得有精神，类比各类动漫中的热血小强型角色;
#3责任感
主人公的意识，积极的涉足、主导和解决不期而遇的问题，时刻从产品大局出发权衡取舍;
这里大家已经很熟了就不说了。
#4当然，还有黑锅
如上所述，既然很多很多人的很多事情都与你有关，那么进度卡在你这里、或者你没有说清楚、或者你没有提任务、或者你没有早说……就都是你的责任了，这种情况下一方面参考一下#1的解释调节调节，认真你就输了;
另一方面，可以通过一些制度性的行为为自己提供支持，比如及时邮件什么的。
3）信任、妥协、营造气氛
这条几乎上升到了方法论的层面，这两条其实说大很大说小很小，灵活应用的话效果会比较好。
#1信任与妥协
上面第二部分说了，PM所在的项目组中有各种各样的角色（项目组外也是），每个人都有自己的专业分工，所谓“术业有专攻”，其他角色顶着自己的帽子、带着自己的头衔，一定是在自己的专业领域内受到多年理论和实践打磨的，为什么你不相信别人的专业素养却要求别人相信你的眼光?
所以信任很重要。
所以毕业生PM来公司如果立马就开始背诵“产品经理是火车头”，并且希望自己在任何一个领域内的看法都被严格执行的话，基本上立马会躺枪，因为你的看法在某一个特定的领域内是不成熟考虑不全面的，所以在有些时候当你意识到在这个领域内有更专业的人可以贡献力量的时候，“妥协”吧!
因为大家的目标是一致的（妥协的理论基础）
#2营造氛围
如果能在一定时期里项目组内，特别是需求方内部（产品、交互、设计）大家都能比较好的做到信任和妥协，就有可能形成一个良性的循环，其结果是PM的工作
升级会员 