作为产品经理，如何做好项目管理？
source link: https://mp.weixin.qq.com/s/vBj1Qrw-79xR-i0Dta_iCA
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
本文为平台特约稿件，未经许可，禁止转载
全文共 12786 字 16 图，阅读超过 30 分钟
———— / BEGIN / ————
不管你身处大公司大环境，还是小公司创业团队，相信你一定见过各种项目的问题，也见过很多失败的案例。
所谓成功的项目，一定是在有限的条件下，达成预期的目的。
想要管理好一个项目，必须尊重基本的客观事实，对项目想要完成的功能范围、所需要消耗的资源和时间成本，必须有一个清醒的认识；一颗对产品、对技术、对用户的敬畏之心，是一个项目可能成功的基础。
一、敬畏之心
对任何项目项目而言：
时间紧迫，活儿就只能凑合了；
资源有限，人手不足，就往后拖吧；
东西做不完，就只能赶紧砍内容，别弄那么多。
范围、时间、成本、质量，环环相扣，任何一个环节都带来极大的挑战，都可能引发极大损失。
老板们都想项目完成的时间要快，完成的成本要低，完成后的质量要好。
但能够完美做到以上三个要素的项目，少之又少，我基本没有见过。
反倒是，我见过最让人感到震惊的状况。
一种是多产品多项目的并行开发，最后发现没有一个产品可用。还有一种就是引发极大的质量问题，造成重大的损失。
而事实上，这都是可以预计和预防的。
有的时候，真是人心不足蛇吞象，想法足够大胆，但投入捉襟见肘。
要知道：任何罔顾基本规律的做法，必然遭受现实的打击，造成不可估量的损失。
作为PM（项目/产品经理），一定要把这个金三角的关系牢记于心。
为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
为了节约项目成本（资源），就需要减少项目范围或延长项目时间；
如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间。
甚至，对质量的追求，都是一个度量的平衡。
不管你用什么管理的方法方式，都不能绕过这一基本原则。
因此，在做预算的时候，必须面对现实，而且一定要掌握一个原则：预留一定的弹性空间。
产品经理应该用一种“悲观”的视角看待项目，用乐观的途径去解决问题。
但事实上，产品经理们最容易犯的错误，就是在完工日期的预测上，为了讨好客户或者上司而过于乐观，或者依据简单的经验数据来做出决定。
鱼与熊掌之间，是一道三角难题。
项目计划是一个多次反复的过程，也是一个不断修正的过程，一定要时刻保持基本的敬畏之心，重复考虑各种因素的相互协调。
想要在三角之间找到一个平衡点，一定要弄清楚什么是“好”，什么是“快”，什么是“便宜”。
最忌讳的就是盲目的追求“快”，最可怕的是过于乐观承诺“好”。
所以，对于产品（项目）经理而言：
第一条规则是：让你的老板认可和接受金三角法则；
第二条原则是：你始终在受限的环境下管理你的产品（项目）。
二、产品&项目的异同
“项目”这个概念，其实时刻都在我们身边发生，火箭上天是一个项目，家庭装修也是一个项目，他们共同的特性就是都有完全不同的开始、结束时间，也都产生完全不同的结果。
有的项目很长影响很大，甚至流芳百世，比如修建三峡。
有的项目仅仅是你的私事，比如追求心中的女（男）神。
1. 产品 vs 项目，两个世界的追求
随着“互联网思维”的遍地开花，我们看到一种现象，项目经理这一角色似乎越来越被削弱，产品经理大有取而代之的趋势，甚至很多互联网公司都没有专职项目经理。
这是错觉还是必然，两者之间是否必然会被过渡？
但两者其实是完全不应该有混淆和争议。
产品，是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西（百科定义）
项目，是为创造独特的产品、服务或成果，而进行的临时性工作（PMP定义）
这个定义已经很清晰的界定了一个产品是由N个项目组成的，产品输出实际的东西，而项目对应产生产品的过程。
也就是：产品经理对结果负责，项目经理对过程负责。
对一个企业来说：
产品经理强调的是：做一个什么东西，通过什么方式可以卖给谁，赚到多少钱。
项目经理考虑的是：需要多少时间，投入多少资源把东西做出来。
比如对面有一个山头。
产品经理想的是：把旗帜插到对面山头上去。插一面大旗还是小旗，是一面绿旗还是红旗？是不是要用混凝土加固下，啥时候再发起下一个项目。
项目经理想的是：怎么去那个山头，谁抗旗，抗多久，扛不动怎么办？至于旗帜插上去下一步怎么办，会不会倒，项目经理并不关心。
2.1.1 关注点不同
产品经理的侧重点向外，关注用户和市场
市场机会和竞争格局
用户需求和用户沟通
解决的是做什么，卖给谁，赚谁的钱的问题。
项目经理的侧重点朝内，关注资源和进度
资源调配
资源效率
项目进度
解决的是如何用有限的资源在限定的时间内，按照质量要求把东西做出来。
2.1.2 交付物不同
产品经理交付的是产品成果，最终交付给用户的产品，关注产品的成本、质量和体验，以及产品通过运营后转化的企业收益。
项目经理交付的是管理成果，最终交付管理层的工作报告， 关注团队的士气、效能、成本，以及企业整体的生产效率的提升。
2. 祸起萧墙，根源到底在哪
理论上来说，项目经理和产品经理是不应该存在争议的，但事与愿违。
为什么会出现“我到底是「产品经理」还是「项目经理」”的困惑呢？
首先，产品经理是抢着项目经理的饭碗而复兴的。
尽管产品经理很早就诞生了（来源于宝洁，故事可百度），但在IT领域并没有受到重视，在那个年代，对于看不见摸不着的软件，用户是没有概念的，只能是企业自己决定自己要做什么，以自己的技术推动用户往前走。
在2010年前后，技术的普及也带来了用户的觉醒，传统强调时间、进度的软件工程的思维越来越具有局限性，“宝洁的故事”事实上在重演，产品经理再次“横空出世”，一直到后面的“人人都是产品经理”，是一种彻底的思维转向。
也就是：产品经理试图分解和分担过去项目经理的职责和工作，把传统软件工程的项目概念，重新回归到产品本身来，从强调企业内的项目交付，转为面向用户的成果交付。
了解目前的“甲乙方项目”就能够感受得到，交付给甲方的成果，其中之一就是庞大的过程资产，甚至试图在尽可能的还原过程，“我就是按照你的思路和要求一步步做出来，你就老老实实的签字画押”吧。
所以，“甲乙方项目”、“外包项目”极容易脱离用户需求，因为面向管理过程。
第二，产品经理和项目经理存在难以逾越的鸿沟
事实上，对用户而言，一个产品是怎么做出来的，他完全不关心。加了多少班，熬了多少夜他也不感兴趣，他只关心这个产品是不是他想要的，有没有价值则直接决定他是否愿意付费。
你说你这个软件可以约妹子，他就试试能不能约到妹子？你说你这个app买东西便宜，他就试试比别人便宜多少？除此之外“多说无益”。
对用户来说，当物质丰富，用户有可选余地；他一定选择他喜欢的，满意的产品。只要他不开心，他除了卸载，还是卸载。
而传统软件工程思维，是与此相背离。
作为项目经理，如果一个东西，能够按质按量按时的生产出来，是难以评判它的失败。完美的过程管理，更是能带来企业管理效率和人员能力的提升。
遗憾的是，这些对用户而言都是无效的。
产品经理来说，“鸡飞狗跳”都是次要的，用户开心比什么都重要，所以他首要解决的是用户、市场和竞争性的问题。而把内在的过程放在其次，“需求很简单，怎么做我不管”在一定程度上并没有错。
子非鱼，用户思维，和我们自己的思维是存在天然的鸿沟的。
站在地球上，我们始终看到的是太阳绕着我们转；而站在月球，站在太空呢？
这也是以用户为中心往往很难落地的一个原因——用户思维是一种反向思维，反人性。
产品和项目在这个维度上存在对立关系。
任何一个产品，越强悍越完美，越有可能让用户开心，但对企业来说就可能是灾难，项目过程必须采取折衷的办法。打造完美的产品，意味着投入更多的额外资源，形成事实上不必要的光环。
第三，产品经理和项目经理剪不断，理还乱
对一个将军来说，我只知道要拿不下这个山头，留多少血我不感兴趣。
但你并不能这么做。
软件开发过程中，就必须遵循基本的规则和规律，一个妈妈生一个宝宝要10个月，不能直接换算为10个妈妈生一个宝宝只要一个月。
当一个东西，决定要做的时候，就开始牵涉到复杂的资源、进度、质量和范围的问题，而这四个形成一个互相角力。
比如范围扩大，就势必引发进度和资源问题：
很多时候常能听到并行，同步的字眼，多想想10个妈妈生宝宝的故事。
项目的过程有其复杂的机制和逻辑，同一个项目，在不同的模式下，极可能消耗的资源，进度，质量都会完全不一样，项目的过程管理有科学的依据和成熟的体系。
比如工作任务的分解、关键路径的跟踪等等。
产品经理其实非常的依赖项目过程的管理，不管这个角色被定义为项目经理还是自身的兼顾，都会对产品的工作带来影响。
所以我们常常见到两种产品经理，一种是以市场、用户为天职的产品经理，看上去牛皮轰轰响，可东西没出来，还有一种是事无巨细过程很完美，但市场反馈差一点。
3. 相辅相成，方能互相成就
项目经理和产品经理的争议严格来说并没有意义。
个人的主张是，理应各司其事，特别是更加复杂的竞争环境下，想要真正的以用户为中心，势必进一步加强用户的沟通和研发，把更多的精力放在对市场的灵敏反馈上。
同时，产品的过程管理也极为重要，它反过来反作用于用户。
清晰的业务方向，准确的市场反馈，以及完善的项目过程管理，才是真正无望而不利的。
对企业来说，小团队可以产品经理兼任项目精力，在一定程度上需要分设不同的角色，应对更为激烈的市场竞争。
对产品经理和项目经理而言，彼此之间有清晰的定义，但从来都只有模糊的边界。
三、项目环境决定成败
作为一个产品经理，我们都曾心怀改变世界的梦想，期望一己之力为用户带来“无上”的价值。
现在的情况是，梦想谈完了，模式说清了，想要搞出一个什么东西也明白了，是要真正见到“产品”的时候了。
可是，你可能就那么几杆枪，怎么办？
磨刀不误砍柴工，在真正亲自下战场操刀之前，关于项目的几个核心概念一定要搞清楚。
你的身份现在应该切换到项目的角色。
不要再谈理想，也不要再说体验故事，先把东西做出来再说。
1. 项目生命周期
谈产品和项目的时候有一个清晰的定义——项目一定要有开始和结束的时间。
所以，任何一个项目一定都一个生命周期，或长或短。
任何一个项目，规模、复杂度都不同，但无论大小，都一定具备一个通用的生命周期结构：
启动项目；
组织和准备；
推进具体的工作；
结束项目。
也就是任何一个项目，都有一个通用的项目阶段：
启动——计划&执行&控制——收尾
任何一个项目，最轻松的开始阶段，反正啥都好说；最难受的是推进的过程，不是甩锅就是撕逼，打架都正常；最尴尬的是收尾，对方不签字的时候想要跪下去叫爷爷，收了钱老子就是天下第一。
这是一句玩笑话，但在“甲乙方”的项目过程中，司空见惯。
所以，项目开始的时候，丑话要说在前头，开弓没有回头箭，开始没讲清楚的事情，到了后面就讲不清楚。先做恶人，才可能有机会做好人。
不能实现的功能一定要拒绝，当前不能满足的需求一定要明确，能达成什么样的指标一定清晰。
这个叫项目目标，所有后续的功能只能围绕这个目标来执行，任何要推翻目标的项目行为，都不能被直接接手，必须启动相应的机制和流程。
无数的项目证明，这是基本的定律。
项目目标和范围是两位一体的事情，只打30层楼的地基，就绝对不能去盖50层的楼。
想要修改目标和范围，一定要“重启全新”的项目。
项目的坑往往就是在这个时候挖下来而不自知。
而后期接手的人，根本没有任何办法理清楚过去的纠葛矛盾，它会演变成一出N角恋——二手项目很容易烂尾。
失败在所难免。
也就是：项目在开始和执行以及收尾的过程中，一定会要投入不同的资源，并催生各种需要控制管理的风险。
越是早前不确定性最高，甚至随时都可以关闭，但损失可能小，越后后期越难控制，损失往往无法估量。
在项目的早期，一定要尽可能的预知风险，比如做硬件的，一定要明白，可能结构不行，材料不能准时到位，做软件的也一定要知道技术的瓶颈在哪里，而且，软硬件要及时同步。
遗憾的是，我们常能见到硬件设备已经出来，软件工程师还没有入场，然后就发现各种“货不对板”，彼此埋怨。
而硬件项目是不能像软件一样快速迭代甚至推倒重来。
3. 项目治理环境
项目早期的坑，最多是一个开胃菜，进入到项目之后，每个雷一旦引爆都可以逼停一个项目，这个环节最大的不可控因素就是人的因素——项目的环节因素。
没有人可以逃过环境的影响，也没有一种项目管理的方式可以超脱于外。
一个项目能否管好，不一定取决于你的努力，更多的是裁剪一个恰当的方式，符合这个环节的一种节制，和你所把控的那个节奏。
这是非常难的一件事，越是大的项目越难，在这种大项目里面，对事不对人是绝对错的，搞不定人一定搞不定这个项目。
环境因为包括组织的文化、结构、区域位置、行业标准、人事制度、授权机制，甚至法律法规等，任何一个项目都受其中的一些因素所影响。
在其中最具有直接影响力（杀伤力）的就是人，在项目里面叫做干系人。
有的人对项目有积极影响，有的是消极影响。
比如拆迁经常会钉子户，也有的时候，只要张三同意，李四就一定反对，诸如此类的情况比比皆是，所以搞清楚一个项目会涉及倒那些人以及什么利益关系，比啥都重要，否则谁都可以是项目经理了，都可以发号施令了。
老实说，这个图一定用都没有，所谓分析项目干系人，其实就是找出那些对项目施加影响的人，特别是那些负面影响的人，背后捅刀子的人，得了便宜还卖乖的人，那些不按常理出牌的人，作为项目经理你可以给一个大家都可见的关系图，但自己私下还要再准备一个。
所有的人和事，往往都是利益的事情。
搞清楚了关系，就要真正开始组织团队了，这个叫项目团队。
组成一个项目的人，都是各有所长（各怀鬼胎）的，作为项目经理就一定要分清楚职责职权，这里面又会涉及团队内部人的沟通，分享问题，以及各种奖励惩罚机制。
这个图是不是看着很官僚的样子。
官僚就对了，这种结构的设计，就是为了保证项目组内的有序可控，对外有统一的出口，对内有稳定的次序。
不要随便夸海口，更不要随便瞎承诺，只有项目经理才可以享有足够的权力，才能保证团队内部的健康，和项目的健康，否则就变成一锅粥。
每个人都有自己清晰的职责和权限，“按部就班才可保平安”。
3. 项目过程资产
说完了，人和事。下一步就是物了。
如果说项目的环境因素可以让一个项目万劫不复。一旦管不好过程资产，那就一定黄土加身了。
这个资产，指的是一个项目在它整个生命周期里面所有产生的，使用到的全文文件文档，包括来自任何人，任何组织所涉及到的知识，文件，记录的。
为什么常说项目里面那么坑，有一部分原因就是没有管理好这些“资产”，比如产品经理输出的原型，业务流程不清晰，还没有存档。
所以，写好一份文档的极为关键的，管理好这些文档是第二重要的是。
在过程资产里面还有一些特殊的内容需要特别投入精力：项目本身的文档。
项目计划书、里程碑节点、变更控制流程、财务控制程序、缺陷管理程序等等，任何一个环节都足够展开一个宏大的篇幅细说它的故事。
从这里开始，热身运动做完，可以开始埋雷挖坑了。
四、合适的人与靠谱的计划
几乎每个项目都有人吐槽，太坑太扯淡。
实际上，项目之所以会扯皮，往往在前期就埋了下巨坑，随着项目的进程问题越来越严重，直到不能收场。
在上文我们已经厘清了项目的几个核心概念 ，我们知道要想做好一个项目首先要搞清楚项目利益相关方，组建合适的项目团队，然后我们需要分解我们的项目任务，制定一个清晰的项目计划，才能指导和推动项目的进展。
我们现在从案例来还原项目前期的挖下的坑：
A公司目前正在为一个医院开发一套系统，现在项目按时间开发完成了，也做好了相关的培训工作，但始终无法验收，医生说不好用，而且还有三个需求要变更，开发工程师下个月要离职了，各种问题层出不穷……
假设你是这个项目的项目经理，我们一起来看看你踩的雷。
1. 项目第一坑：“人”才是最坑的
你从销售经理那里获悉，这个项目是内科的科长最开始发起的，副院长也很支持。
你很开心，感觉这个项目牵涉的人比较少，就开始了这个项目，并且定期发送相关的进度报告：
随着在医院的了解越来越多，你发现医院的关系越来越复杂，各种不配合扯皮的现象——很多没必要的需要变更，培训的效果也没有看上去理想。
你认为这是院长负责的项目，一定大家都会支持；你以为给内科做了一次培训，大家都会使用；没想到培训完之后他们还是反馈说系统不太好用。
这些问题，本质上就是项目开始阶段想得太简单，没有能搞清楚相关方的利益关系。
这是项目的第一步，也是项目的关键一步。
多数情况下，一个项目有支持者，往往就有反对者；项目的支持者能让项目锦上添花，但反对者往往决定成败。
如果在项目开始阶段，没有找出那项目能够施加积极和消极影响力的人，注定整个项目会很艰难。
同时，你还需要找到一个最具有推动力的关键人，对内争取更多资源，对外摆平各种关系。
所以，这个项目的干系人需要更完整：
越是大型的项目，人的因素影响越大，也越难以把控。
那些决定项目成败的，能出力的人，都应该是你的项目组成员，还有一些人，你需要TA挂一个虚职，并告诉及时告诉TA进展。
我们常常见到一个项目进行了一半，才临时通知或者征调其他部分的人参与，带来的问题就是沟通成本非常的高，过程完全不可控。
2. 项目第二坑：只有任务，没有成果
项目的第二步，是要分解项目的具体工作任务，也就是要分配张三、李四分别要完成的工作。
在PMP体系中这个叫WBS，在Prince2的体系中则强调的是PBS。
最直接的做法，通常都是根据“事项”来分解；毕竟我们需要把任务分配给不同的人来执行，并根据这个任务来估算时间，确定进度。
所以最常见的分解方法就变成这个样子：
但为什么这种分解方式会导致项目做到一半就会人员流失，士气低下呢？
根源在于这种任务分解只关注了过程，没有确定到底要做成什么样，没有边界和具体的目标。
没有验收的标准，没有衡量的指标，所有的人都在忙，忙到最后发现客户不买账。
比如项目计划里面UI设计的是10天，为什么不是9天或者11天呢？要输出多少个页面？
科室培训是培训一天就可以了吗？还是1小时就可以结束而且所有人都能熟练掌握？用户向要在用户登录模块里面添加一个找回用户名的功能，要不要增加？
诸如此类的问题，随时可能发生。
因为这种结构是没有办法落实到具体一个功能需要的耗时，所以会不会打乱整个计划就说不太清楚。
仅仅知道什么时候做什么，对项目的成败而言是没有意义的，关键是结果是什么，没有成果的努力，都是一种自嗨。
回顾前文“如何用Axure输出高质量的PRD？”，为什么会强调“故事”呢?
基于“用户故事”来分解这个项目的任务——构建一套以用户需求驱动的PBS，才能满足用户的需求，也才能真正估算一个可行的项目计划，双方也才能在一直的目标下推进具体的功能。
这是一个项目成果的护身符，当任意发起与PBS相违背的变更都会影响到项目的进度，界定了项目的边界，为日后的项目进度规避了许多不必要的障碍。
因为在这种结构下，任何的变更都可能导致整个路径的紊乱，从而项目失控。
或者为了项目进度，投入更多的资源，或者友好协商推迟项目的进度。
搞不定人事，理不清边界，是项目失败的最关键因素，作为项目经理（有一些情况下是产品经理直接带项目）务必保持清醒的头脑。
五、项目节奏和潜在的风险
我们搞清楚了项目的利益相关方，理清楚了项目的范围，要做什么工作也已经妥当的安排好了专人负责，然而项目依然还会失控。
原因何在？
展开话题之前，先回顾一下我曾经的一个项目。
大概在12~13年左右，我有幸参与了一个大型的项目，负责整个平台的搭建，这是一个从0到1的过程，公司和客户都没有过类似的项目实践。
这个项目，看上去“没有想象中的复杂”，关于是接单、派单、回单的过程，所有人都很乐观，整个项目氛围特别的轻松，3个月拿下完全没有问题。
然而，随着项目的推进，直到整个项目真正上线，前后耗时8个月。
项目开始前，当你能描绘一个美好蓝图的时候，所有人都会被感染，然后所有人都很乐观，被这种情绪感染的时候，每个人都会高估自己的产出，并且“有意识的”低估项目的复杂度。
甚至直到项目被彻底拖垮后，人们并不愿意承认这种盲目自大的情绪最终会给项目造成危害。
在项目过程中，所有轻松的氛围下，极其容易带来错误的判断，低估项目复杂度，低估项目的资源消耗，在商业行为上会演变为低估项目价值，从而埋下巨大的隐患。
所以，对PM来说，关注和把握好团队的氛围非常的重要，深刻的发现和传递项目价值，争取相对于的资源是极为重要的。
1. 合理制定计划，更需恰当的控制节奏
路易十四把你抓为俘虏，要求你替他做一个计划，为他的城堡添加三个新地牢：
小的地牢很难设计（最快要12周），但是容易建 成（1周）
中等的地牢是典型的，设计（5周），施工（6周）
大的地牢容易设计（1周），但是很难建造（9周）
你是这个项目的项目经理，你有一个设计师和一个建筑师，但你的设计师不会建造而建造师不会设计。
你会怎么制定项目计划？
在做这个计划前，根据我的经验，最好还是重新检查一遍项目的任务分解情况，其中往往暗藏风险，一定要让你的项目是根据结果导向来反推工作事项，才能真正估算每一个结果的产出所需要的工作量。
正确的工作量预估，才能带来可行的项目计划。
所以，最直接的方式就是“物尽其用”，根据工作量估算直接安排项目计划，每个人的工作看上去都安排很饱和。
但实际上，整个工程工期太长，资源消耗过多。
既然老板们不同意，那我们就必须寻找更好的办法来压缩工期。
1.加班。
在项目范围不变的情况下，加班是一个压缩项目周期的途径，但很容易导致项目团队的氛围下降，进而引发质量的下降。
对于加班，我们先不去做过多的讨论，但我想强调的是：项目中要把握好节奏，只加有意义的班，而不以加班为乐。
2.加人。
加人这个办法只适合项目早期，而且是越早越好——这其实意味着要在项目的早期争取到更多的资源。
而在项目过程中，团队稳定才是关键的，往往不等于加人就可以压缩周期，甚至只会适得其反。
把新人直接塞进项目，多少情况下不是好的选择。
还有一种办法，就是通过关键路径法。
既然造房子要先做好设计，那就可以把设计和建造的工作进行“分离”，先排出项目事项的优先级，说白了就是资源的投入顺序。
再找到一条完成整个项目最短可行的任务路径，这个叫做“关键路径”。
这个表，就很清晰的知道整个项目需要耗费的时间和资源，也很清晰的看到，什么时候什么资源应该投入项目。
也就是这每一个关键节点（里程碑）上都有真正的成功输出，管理好每一个关键节点，并准备好下一个节点的资源投入，项目总体的进度会比较有序可控。
而且，这里有一个非常重要的工作——项目计划一定要实时更新。
一个过时的计划表，等于项目没有计划。
2. 风险往往存在于不经意之间，一定要头脑清晰
假设一个公司有多个项目并行在展开，意味着全公司的资源能够交叉的完成的不同的项目，看上去多个项目在并行开展。
效率很高。
但这种方法却是最难管理的，而且还带来额外的管理风险。因为我们难以准确的估算每一个工作环节的工作量，也难以确保项目进度没有其他因素的占用时间——比如某一个技术难点带来的某个节点的时间延期。
在这种交叉的项目环境下，项目非常容易失控。
很多时候，我们常能听到说并行开发，实际上是对整个资源的过度自信和对项目的认识不足。看上去项目都启动了，但质量、进度难以保障。
同时干几件事情的美好愿望最终导致一系列的糟糕局面。
四处救火的局面，应该尽可能的少发生。
一定要能学会找出项目最重要的事情，而少去干紧急的事情。
理论上来说，在项目进入到整个阶段，作为项目经理只需要定期检查里程碑的节点输出即可。
在路易十四的项目中，如果你仔细再看这个表，你一定发现建筑工人有两周的空闲时间。
两周的时间，建筑工人无所事事，整天游手好闲——某一天路易十四巡视工地发现建筑工人睡大觉，还引起设计师的极大不满。路易十四认为你的计划有问题，浪费资源。
所以他直接把资源调走，理由是：建筑师并没有完全被使用或者没有全情投入。
你怎么办？
这个就叫项目风险。
所谓风险，就是不确定的事情。你不能完全的规避风险，有些时候你还需要把一些风险利用起来推动项目的进展。
通常的做法是：在项目的开始阶段列出一个风险清单，提醒相关的人员注意可能的状况，防患于未然。
也就是：在项目过程有一项关键的节点，就是搞一个正式的仪式——召开一个项目启动会。
讲清楚项目的价值、背景，需要的资源和进度，影响的范围以及可能的风险。
把所有好的结果画一个大饼给所有人，把所有坏的局面讲清楚给所有人。
这个会上，不仅仅是传递信息，也是争取资源和权力的关键时刻。那些资源是必须保障的，那些事情是需要经过审批的，那些事情是需要注意，都需要讲清楚。
必须确保整个项目有一个完整的可行的规则。
如果你只想做个老好人，没有通过一个正式的仪式来获得相应的权限，这个项目会变成非常的难以推进。
首当其冲的就是需求的变更。
要知道牵一发而动全身，一个小小的变更，甚至会引发整个项目的范围、进度、质量、成本的大调整，甚至可能让整个项目处于一个分崩离析的状况。
六、期望与权力
任何项目都有一个特色，那就是项目之前群情激昂，至于过程和结果，有的怨声载道，有的劫后余生，万象丛生都很正常，越大的项目故事往往越多。
在前述的文章里面，我从项目的环境，复杂的各方利益，项目的任务分解和任务进度的制定，多个角度分析和阐述了根本原因，这些诱因最终会在项目过程中成为无休止的变更，从而让整个项目陷入不可救药的局面。
所以，需求的变动那是家常便饭，没有变更往往不正常，而变更的管理和文档的确实会进一步加剧这种现状。
变更，分为两种类型，其一是完全不可控因素，既是未知的，也是不能改变的。
比如，公司的经营方向发生了改变，导致项目的预算被削减（增加），从而影响项目的进度。特别是在创业型团队，老板临时改变注意，发现某个方向可能更有潜力，调转枪头也未可知。
作为一个项目的负责人（执行者），在项目启动之后，唯一的使命就是促使项目成果，或者结束项目。对未知和不可控的任何局面，都无需过多的投入精力。
你能做的，就是管理那些可以被管理的内容。
那些内容是可以被管理的？（如何管理）
可控的需求变更，无非三大类：
没有细化清晰的项目需求
没有明确清楚的项目边界
存在设计缺陷的软件结构
深究起来会发现，在项目已经启动后，真正与客户直接相关的就是第二条，由于没有明确的项目边界，从而导致用户无休止的提出各种需求和变更。
而对需求本身的理解和软件的设计，则考验产品经理和整个团队对业务的理解、把握和产品设计能力。
这也是为什么我一再强调“用户故事”的原因，而这种变更则需要团队具备极强的消化能力。
1. 建立完整的流程变更机制并严格遵守
项目管理，本质就是对过程的管理，也就是要有完备的流程和坚决的执行，通过流程来规避可能的风险。
所以，项目的第一件就是设立一个需求变更机制（如果你还记得之前谈到的项目启动会，项目经理一定要借助这个会议让项目的所有相关方知悉这个流程）。
这个流程有两个核心观念，也是你一定要能争取到的权力：
所有人都可以提出需求变更的请求，但只有一个需求的入口——这个入口必须是你，如果你争取不到这个权力，那整个项目一定会失控。
任何都可以提出需求和变更，但你必须作为唯一的接口人和过滤器。
为此，你应该有足够的心里准备，你需要面对N多方的压力和“撕逼”。甚至，为了项目交付的这一终极目标，你需要有不惜得罪人的思想准备。
越是大项目，越是牵涉多方的项目，风险和协调都会是指数级的放大。
只有当你具备这个权力的时候，你才能确保项目在预设的轨道上进行，也只有你才可以清晰的回答当前要做什么，能做什么，以及不能做什么。
只有评审过的需求才可以被执行。
“不要接到需求就直接动手”，这是项目的至理名言。
你需要让整个项目团队，包括上至老板、直到程序员，也包括外部的客户，都认同、理解并遵守一个基本原则，那就是程序员不直接接受任何非PM的需求，不接收任何非经过评审的需求——所有未经过评审的需求，只可讨论，不可执行，减少（避免）张嘴就来的非必要、非紧急、非合理的无效变更。
切记：不是所有的需求都要接受，也不是所有变更都要立刻修改，一定要能敢于拒绝需求。
作为产品经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级。
但最终一定要你拍板，这是你需要争取到的第二个权力。你不能最终决定一个需求的价值，对你而言，项目已经离失控不远了。
当然，你可以适当根据需求的范围大小，决定评审的范围，甚至可以决定需要告知的对象，这没有标准，需要灵活把握。
这里其实是有一个例外，那就是技术本身驱动的变更；比如有更好的实现方案可以带来性能的提升，这个情况，需要根据整体项目状况，结合技术本身的能力判断。
一定要争取到合适的权限范围，才可能有序的推进项目进程。
2. 建立完善的文档管理机制并落实到位
俗话说“好记性不如烂笔头”。
项目过程中，文档是极为重要的工具，虽然管理文档费时费力。对于产品经理（创业团队还是兼任项目经理）而言，一定要持续的追踪项目的所有需求文档，变更记录。
一定要所有的文档，形成版本机制并同步到到团队的没有给成员，你可以借助一些在线工具来帮助你完成这项功能。
要知道，但凡失控的项目里面一定有一条就是找不到需求的出路，不知道为什么要这么做，也不知道谁要求这么做，反正就是做了，然后谁也讲不清楚由来。
任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。一定要专人负责需求的梳理，跟踪和进度的反馈。
完整的需求变更记录文档将有助于你了解整个项目情况，包括执行的需求，被拒绝的需求，你需要一个“需求池”统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。
3. 张弛有度，控制项目的节奏
你确定了规则，梳理好了边界，甚至也形成了流程。
下一步，你得控制好整个产品的推进节奏，合理的控制和调节需求、变更的优先级，以及资源的投放力度：什么时候该投入多少资源，什么时候该做什么事情，什么是关键路径，什么是关键角色，你必须门儿清。
你得想方设法让你的项目，在你所能控制的范围内进行，一旦超过边界，你可能需要启动后备资源予以干预，而且是在苗头开始之际。
你所有的干预手段，预防机制，都是为了确保项目按照一定的规则和秩序推进；也只有基于可控的节奏，你才能确保整个过程的质量，以及最终交付的质量。当过程不可控的时候，往往结果会很糟糕。
最后，一定要深刻的理解，需求是不断的演进和变化的，合理的规避不合理的变更方为上策。
有些时候，无论你怎样控制，由于市场的压力，总会碰到各种“无理”要求，如何看待这样的问题，就不是简单的控制问题了，这就需要更高的层面去权衡利弊，如果确实不值得，也只能放弃。
写在系列收尾处
产品经理作为引路人，就是尽可能的让不确定性的因素，变为确定的，可被执行的流程、方案。
不管你是否兼任“项目经理”的角色，在一个产品从0到1的过程里面，产品经理必须深刻的理解整个过程的艰巨，要能与团队一起致力于整个项目的成功。
至此，本系列从项目和产品的概念出发，到项目环境的分析，以及对项目过程的几大巨坑一一做了阐述，也许你还需要一些工具，或者模板来提高项目过程管理的效率。
———— / END / ————
———— / 推荐阅读 / ————
———— / 活动推荐 / ————
来自网易、洋葱集团等名企的7位实战派专家
300家企业、600位互联网精英齐聚
8月26日，2018中国产品运营大会 · 武汉站即将开幕！
扫码入群，了解大会详情
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK