以产品经理的视角看待项目以及如何管理项目上

　　对很多产品经理而言，特别是身处创业团队，往往都是一身挑几职，产品和项目，理不清理还乱。从本文开始，以产品经理的视角看待项目，以及如何管理项目。
　　不管你身处大公司大环境，还是小公司创业团队，相信你一定见过各种项目的问题，也见过很多失败的案例。所谓成功的项目，一定是在有限的条件下，达成预期的目的。
　　想要管理好一个项目，必须尊重基本的客观事实，对项目想要完成的功能范围、所需要消耗的资源和时间成本，必须有一个清醒的认识；一颗对产品、对技术、对用户的敬畏之心，是一个项目可能成功的基础。
　　一、敬畏之心
　　对任何项目项目而言：
　　时间紧迫，活儿就只能凑合了；
　　资源有限，人手不足，就往后拖吧；
　　东西做不完，就只能赶紧砍内容，别弄那么多。
　　范围、时间、成本、质量，环环相扣，任何一个环节都带来极大的挑战，都可能引发极大损失。
　　老板们都想项目完成的时间要快，完成的成本要低，完成后的质量要好。但能够完美做到以上三个要素的项目，少之又少，我基本没有见过。
　　反倒是，我见过最让人感到震惊的状况。
　　一种是多产品多项目的并行开发，最后发现没有一个产品可用。还有一种就是引发极大的质量问题，造成重大的损失。而事实上，这都是可以预计和预防的。
　　有的时候，真是人心不足蛇吞象，想法足够大胆，但投入捉襟见肘。要知道，任何罔顾基本规律的做法，必然遭受现实的打击，造成不可估量的损失。
　　作为PM（项目产品经理），一定要把这个金三角的关系牢记于心。
　　为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
　　为了节约项目成本（资源），就需要减少项目范围或延长项目时间；
　　如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间。
　　甚至，对质量的追求，都是一个度量的平衡。
　　不管你用什么管理的方法方式，都不能绕过这一基本原则。
　　因此，在做预算的时候，必须面对现实，而且一定要掌握一个原则：预留一定的弹性空间。
　　PM应该用一种悲观的视角看待项目，用乐观的途径去解决问题。
　　但事实上，PM们最容易犯的错误，就是在完工日期的预测上，为了讨好客户或者上司而过于乐观，或者依据简单的经验数据来做出决定。
　　鱼与熊掌之间，是一道三角难题。项目计划是一个多次反复的过程，也是一个不断修正的过程，一定要时刻保持基本的敬畏之心，重复考虑各种因素的相互协调。
　　想要在三角之间找到一个平衡点，一定要弄清楚什么是好，什么是快，什么是便宜。最忌讳的就是盲目的追求快，最可怕的是过于乐观承诺好。
　　所以，对于产品（项目）经理而言：
　　第一条规则是：让你的老板认可和接受金三角法则；
　　第二条原则是：你始终在受限的环境下管理你的产品（项目）。
　　二、产品amp；amp；项目的异同
　　项目这个概念，其实时刻都在我们身边发生，火箭上天是一个项目，家庭装修也是一个项目，他们共同的特性就是都有完全不同的开始、结束时间，也都产生完全不同的结果。
　　有的项目很长影响很大，甚至流芳百世，比如修建三峡。有的项目仅仅是你的私事，比如追求心中的女（男）神。
　　1。产品vs项目，两个世界的追求
　　随着互联网思维的遍地开花，我们看到一种现象，项目经理这一角色似乎越来越被削弱，产品经理大有取而代之的趋势，甚至很多互联网公司都没有专职项目经理。
　　这是错觉还是必然，两者之间是否必然会被过渡？
　　但两者其实是完全不应该有混淆和争议。
　　产品，是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西（百科定义）
　　项目，是为创造独特的产品、服务或成果，而进行的临时性工作（PMP定义）
　　这个定义已经很清晰的界定了一个产品是由N个项目组成的，产品输出实际的东西，而项目对应产生产品的过程。也就是，产品经理对结果负责，项目经理对过程负责。
　　对一个企业来说，产品经理强调的是做一个什么东西，通过什么方式可以卖给谁，赚到多少钱。
　　项目经理考虑的是：需要多少时间，投入多少资源把东西做出来。
　　比如对面有一个山头。
　　产品经理想的是：把旗帜插到对面山头上去。插一面大旗还是小旗，是一面绿旗还是红旗？是不是要用混凝土加固下，啥时候再发起下一个项目。
　　项目经理想的是：怎么去那个山头，谁抗旗，抗多久，扛不动怎么办？至于旗帜插上去下一步怎么办，会不会倒，项目经理并不关心。
　　2。1。1关注点不同：
　　产品经理的侧重点向外，关注用户和市场
　　市场机会和竞争格局
　　用户需求和用户沟通
　　解决的是做什么，卖给谁，赚谁的钱的问题。
　　项目经理的侧重点朝内，关注资源和进度
　　资源调配
　　资源效率
　　项目进度
　　解决的是如何用有限的资源在限定的时间内，按照质量要求把东西做出来。
　　2。1。2交付物不同
　　产品经理交付的是产品成果，最终交付给用户的产品，关注产品的成本、质量和体验，以及产品通过运营后转化的企业收益。
　　项目经理交付的是管理成果，最终交付管理层的工作报告，关注团队的士气、效能、成本，以及企业整体的生产效率的提升。
　　2。祸起萧墙，根源到底在哪
　　理论上来说，项目经理和产品经理是不应该存在争议的，但事与愿违。
　　为什么会出现我到底是产品经理还是项目经理的困惑呢？
　　首先，产品经理是抢着项目经理的饭碗而复兴的。
　　尽管产品经理很早就诞生了（来源于宝洁，故事可百度），但在IT领域并没有受到重视，在那个年代，对于看不见摸不着的软件，用户是没有概念的，只能是企业自己决定自己要做什么，以自己的技术推动用户往前走。
　　在2010年前后，技术的普及也带来了用户的觉醒，传统强调时间、进度的软件工程的思维越来越具有局限性，宝洁的故事事实上在重演，产品经理再次横空出世，一直到后面的人人都是产品经理，是一种彻底的思维转向。
　　也就是：产品经理试图分解和分担过去项目经理的职责和工作，把传统软件工程的项目概念，重新回归到产品本身来，从强调企业内的项目交付，转为面向用户的成果交付。
　　了解目前的甲乙方项目就能够感受得到，交付给甲方的成果，其中之一就是庞大的过程资产，甚至试图在尽可能的还原过程，我就是按照你的思路和要求一步步做出来，你就老老实实的签字画押吧。
　　所以，甲乙方项目、外包项目极容易脱离用户需求，因为面向管理过程。
　　第二，产品经理和项目经理存在难以逾越的鸿沟
　　事实上，对用户而言，一个产品是怎么做出来的，他完全不关心。加了多少班，熬了多少夜他也不感兴趣，他只关心这个产品是不是他想要的，有没有价值则直接决定他是否愿意付费。
　　你说你这个软件可以约妹子，他就试试能不能约到妹子？你说你这个app买东西便宜，他就试试比别人便宜多少？除此之外多说无益。
　　对用户来说，当物质丰富，用户有可选余地；他一定选择他喜欢的，满意的产品。只要他不开心，他除了卸载，还是卸载。
　　而传统软件工程思维，是与此相背离。
　　作为项目经理，如果一个东西，能够按质按量按时的生产出来，是难以评判它的失败。完美的过程管理，更是能带来企业管理效率和人员能力的提升。遗憾的是，这些对用户而言都是无效的。
　　产品经理来说，鸡飞狗跳都是次要的，用户开心比什么都重要，所以他首要解决的是用户、市场和竞争性的问题。而把内在的过程放在其次，需求很简单，怎么做我不管在一定程度上并没有错。
　　子非鱼，用户思维，和我们自己的思维是存在天然的鸿沟的。
　　站在地球上，我们始终看到的是太阳绕着我们转；而站在月球，站在太空呢？
　　这也是以用户为中心往往很难落地的一个原因用户思维是一种反向思维，反人性。
　　产品和项目在这个维度上存在对立关系。任何一个产品，越强悍越完美，越有可能让用户开心，但对企业来说就可能是灾难，项目过程必须采取折衷的办法。打造完美的产品，意味着投入更多的额外资源，形成事实上不必要的光环。
　　第三，产品经理和项目经理剪不断，理还乱
　　对一个将军来说，我只知道要拿不下这个山头，留多少血我不感兴趣。
　　但你并不能这么做。
　　软件开发过程中，就必须遵循基本的规则和规律，一个妈妈生一个宝宝要10个月，不能直接换算为10个妈妈生一个宝宝只要一个月。
　　当一个东西，决定要做的时候，就开始牵涉到复杂的资源、进度、质量和范围的问题，而这四个形成一个互相角力。比如范围扩大，就势必引发进度和资源问题：
　　很多时候常能听到并行，同步的字眼，多想想10个妈妈生宝宝的故事。
　　项目的过程有其复杂的机制和逻辑，同一个项目，在不同的模式下，极可能消耗的资源，进度，质量都会完全不一样，项目的过程管理有科学的依据和成熟的体系。比如工作任务的分解、关键路径的跟踪等等。
　　产品经理其实非常的依赖项目过程的管理，不管这个角色被定义为项目经理还是自身的兼顾，都会对产品的工作带来影响。
　　所以我们常常见到两种产品经理，一种是以市场、用户为天职的产品经理，看上去牛皮轰轰响，可东西没出来，还有一种是事无巨细过程很完美，但市场反馈差一点。
　　3。相辅相成，方能互相成就
　　项目经理和产品经理的争议严格来说并没有意义。
　　个人的主张是，理应各司其事，特别是更加复杂的竞争环境下，想要真正的以用户为中心，势必进一步加强用户的沟通和研发，把更多的精力放在对市场的灵敏反馈上。
　　同时，产品的过程管理也极为重要，它反过来反作用于用户。清晰的业务方向，准确的市场反馈，以及完善的项目过程管理，才是真正无望而不利的。
　　对企业来说，小团队可以产品经理兼任项目精力，在一定程度上需要分设不同的角色，应对更为激烈的市场竞争。
　　对产品经理和项目经理而言，彼此之间有清晰的定义，但从来都只有模糊的边界。
　　三、项目环境决定成败
　　作为一个产品经理，我们都曾心怀改变世界的梦想，期望一己之力为用户带来无上的价值。
　　现在的情况是，梦想谈完了，模式说清了，想要搞出一个什么东西也明白了，是要真正见到产品的时候了。
　　可是，你可能就那么几杆枪，怎么办？
　　磨刀不误砍柴工，在真正亲自下战场操刀之前，关于项目的几个核心概念一定要搞清楚。
　　你的身份现在应该切换到项目的角色。
　　不要再谈理想，也不要再说体验故事，先把东西做出来再说。
　　1。项目生命周期
　　谈产品和项目的时候有一个清晰的定义项目一定要有开始和结束的时间。
　　所以，任何一个项目一定都一个生命周期，或长或短。任何一个项目，规模、复杂度都不同，但无论大小，都一定具备一个通用的生命周期结构：
　　启动项目；
　　组织和准备；
　　推进具体的工作；
　　结束项目。
　　也就是任何一个项目，都有一个通用的项目阶段：
　　启动计划amp；amp；执行amp；amp；控制收尾
　　任何一个项目，最轻松的开始阶段，反正啥都好说；最难受的是推进的过程，不是甩锅就是撕逼，打架都正常；最尴尬的是收尾，对方不签字的时候想要跪下去叫爷爷，收了钱老子就是天下第一。
　　这是一句玩笑话，但在甲乙方的项目过程中，司空见惯。
　　所以，项目开始的时候，丑话要说在前头，开弓没有回头箭，开始没讲清楚的事情，到了后面就讲不清楚。先做恶人，才可能有机会做好人。
　　不能实现的功能一定要拒绝，当前不能满足的需求一定要明确，能达成什么样的指标一定清晰。
　　这个叫项目目标，所有后续的功能只能围绕这个目标来执行，任何要推翻目标的项目行为，都不能被直接接手，必须启动相应的机制和流程。
　　无数的项目证明，这是基本的定律。
　　项目目标和范围是两位一体的事情，只打30层楼的地基，就绝对不能去盖50层的楼。
　　想要修改目标和范围，一定要重启全新的项目。
　　项目的坑往往就是在这个时候挖下来而不自知。
　　而后期接手的人，根本没有任何办法理清楚过去的纠葛矛盾，它会演变成一出N角恋二手项目很容易烂尾。
　　失败在所难免。
　　也就是：项目在开始和执行以及收尾的过程中，一定会要投入不同的资源，并催生各种需要控制管理的风险。越是早前不确定性最高，甚至随时都可以关闭，但损失可能小，越后后期越难控制，损失往往无法估量。
　　在项目的早期，一定要尽可能的预知风险，比如做硬件的，一定要明白，可能结构不行，材料不能准时到位，做软件的也一定要知道技术的瓶颈在哪里，而且，软硬件要及时同步。
　　遗憾的是，我们常能见到硬件设备已经出来，软件工程师还没有入场，然后就发现各种货不对板，彼此埋怨。
　　而硬件项目是不能像软件一样快速迭代甚至推倒重来。
　　3。项目治理环境
　　项目早期的坑，最多是一个开胃菜，进入到项目之后，每个雷一旦引爆都可以逼停一个项目，这个环节最大的不可控因素就是人的因素项目的环节因素。
　　没有人可以逃过环境的影响，也没有一种项目管理的方式可以超脱于外。
　　一个项目能否管好，不一定取决于你的努力，更多的是裁剪一个恰当的方式，符合这个环节的一种节制，和你所把控的那个节奏。
　　这是非常难的一件事，越是大的项目越难，在这种大项目里面，对事不对人是绝对错的，搞不定人一定搞不定这个项目。
　　环境因为包括组织的文化、结构、区域位置、行业标准、人事制度、授权机制，甚至法律法规等，任何一个项目都受其中的一些因素所影响。
　　在其中最具有直接影响力（杀伤力）的就是人，在项目里面叫做干系人。
　　有的人对项目有积极影响，有的是消极影响。
　　比如拆迁经常会钉子户，也有的时候，只要张三同意，李四就一定反对，诸如此类的情况比比皆是，所以搞清楚一个项目会涉及倒那些人以及什么利益关系，比啥都重要，否则谁都可以是项目经理了，都可以发号施令了。
　　老实说，这个图一定用都没有，所谓分析项目干系人，其实就是找出那些对项目施加影响的人，特别是那些负面影响的人，背后捅刀子的人，得了便宜还卖乖的人，那些不按常理出牌的人，作为项目经理你可以给一个大家都可见的关系图，但自己私下还要再准备一个。
　　所有的人和事，往往都是利益的事情。
　　搞清楚了关系，就要真正开始组织团队了，这个叫项目团队。
　　组成一个项目的人，都是各有所长（各怀鬼胎）的，作为项目经理就一定要分清楚职责职权，这里面又会涉及团队内部人的沟通，分享问题，以及各种奖励惩罚机制。
　　这个图是不是看着很官僚的样子。
　　官僚就对了，这种结构的设计，就是为了保证项目组内的有序可控，对外有统一的出口，对内有稳定的次序。
　　不要随便夸海口，更不要随便瞎承诺，只有项目经理才可以享有足够的权力，才能保证团队内部的健康，和项目的健康，否则就变成一锅粥。
　　每个人都有自己清晰的职责和权限，按部就班才可保平安。
　　3。项目过程资产
　　说完了，人和事。下一步就是物了。
　　如果说项目的环境因素可以让一个项目万劫不复。一旦管不好过程资产，那就一定黄土加身了。
　　这个资产，指的是一个项目在它整个生命周期里面所有产生的，使用到的全文文件文档，包括来自任何人，任何组织所涉及到的知识，文件，记录的。
　　为什么常说项目里面那么坑，有一部分原因就是没有管理好这些资产，比如产品经理输出的原型，业务流程不清晰，还没有存档。所以，写好一份文档的极为关键的，管理好这些文档是第二重要的是，详见如何用Axure输出高质量的PRD？
　　在过程资产里面还有一些特殊的内容需要特别投入精力：项目本身的文档。
　　项目计划书、里程碑节点、变更控制流程、财务控制程序、缺陷管理程序等等，任何一个环节都足够展开一个宏大的篇幅细说它的故事。
　　从这里开始，热身运动做完，可以开始埋雷挖坑了。
　　具体内容，请听下回分解。