一、敬畏之心
为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围
为了节约项目成本（资源），就需要减少项目范围或延长项目时间
如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间
产品经理应该用一种“悲观”的视角看待项目，用乐观的途径去解决问题
二、产品&项目的异同
1.目标不同
产品对结果负责，项目经理对过程负责
2.关注点不同
产品经理的侧重点向外，关注用户和市场，解决的是最什么
3.交付物不同
产品经理交付的是产品成果，最终交付给用户的产品，关注产品的成本、质量和体验，以及产品通过运营后转化的企业效益。
项目经理交付的是管理成果，最终交付管理层的工作报告，关注团队的士气、效能、成本，以及企业整体的生产效率的提升。
三、项目环境决定成败
1.项目生命周期
谈产品和项目的时候有一个清晰的定义--项目一定要有开始和结束时间
不能实现的功能一定要拒绝，当前不能满足的需求一定要明确，能达成什么样的指标一定清晰。
2.项目治理环境
没有人可以逃过环境的影响，也没有一种项目管理的方式可以超脱于外
一个项目能否管好，不一定取决于你的努力，更多地是裁剪一个恰当的方式，符合这个环节的一种节制，和你所把控的那个节奏
有的人对项目有积极影响，有的是消极影响
每个人都有自己清晰的职责和权限，“按部就班”才可保平安
3.项目过程资产
这个资产，指的是一个项目在它整个生命周期里面所有产生的，使用到的全文文件文档，包括来自任何人，任何组织所涉及的知识，文件，记录
所以，写好一份文档极为关键，管理好这些文档是第二重要的
四、合适的人与靠谱的计划
实际上，项目之所以会扯皮，往往在前期就埋下了巨坑，随着项目的进程问题越来越严重，直到不能收场。
想做好一个项目，首先要搞清楚项目利益相关方，组建合适的项目团队，然后我们需要分解我们的项目任务，制定一个清晰的项目计划，才能指导和推动项目的进展。
找到一个最具有推动力的关键人，对内争取到更多资源，对外摆平各种关系
基于用户故事来分解这个项目的任务--构建一套以用户需求驱动的PBS，才能满足用户的需求，也才能真正估算一个可行的项目计划，双方才能在一致的目标下推进具体的功能。
搞不定人事，理不清边界，是项目失败的最关键因素，作为项目经理（有一些情况下是产品经理直接带项目）务必保持清醒的头脑
五、项目节奏和潜在的风险
在项目过程中，所有轻松的氛围下，极易容易带来错误的判断，低估项目复杂度，独孤项目的资源消耗，在商业行为上会演变为低估项目价值，从而埋下巨大的隐患。
1.合理制定计划，更需恰当的控制节奏
最好还是重新检查一遍项目的任务分解情况，其中往往暗藏风险，一定要让你的项目是根据结果导向来反推工作事项，才能真正估算每一个结果的产出所需要的工作量。
所以，最直接的方式是物尽其用。根据工作量估算直接安排项目计划，每个人的工作看上去都安排很饱和。
每一个关键节点（里程碑）上都有真正的成功输出，管理好每一个关键节点，并准备好下一个节点的资源投入，项目总体的进度会比较有序可控。
2.风险往往存在不经意之间，一定要头脑清晰
一定要能学会找出项目最重要的事情，而少去干紧急的事情
在项目的开始阶段列出一个风险清单，提醒相关的人员注意可能的状况，防患于未然
在项目过程有一项关键的节点，就是搞一个正式的仪式--召开一个项目启动会。讲清楚项目的价值、背景，需要的资源和进度，影响的范围以及可能的风险。把所有好的结果画一个大饼给所有人，把所有坏的局面讲清楚给所有人。
六、期望与权利
1.建立完整的流程变更机制并严格遵守
任何人都可以提出需求和变更，但你必须作为唯一的接口人和过滤器
为此，你应该有足够的心理准备，你需要面对N多方的压力和撕逼。甚至，为了项目交付的这一终极目标，你需要有不惜得罪人的思想准备。
程序员不直接接受任何非PM的需求，不接受任何非经过评审的需求--所有未经过评审的需求，只可讨论，不可执行，减少（避免）张嘴就来的非必要、非紧急、非合理的无效变更。
作为产品经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级
2.建立完善的文档管理机制并落实到位
一定要所有的文档，形成版本机制并同步到团队的所有人员，可以借助一些在线工具来帮助完成这些工作。
要知道，但凡失控的项目里面一定有一条是找不到需求的出路，不知道为什么要这么做，也不知道谁要求这么做吗，反正就是做了，然后谁也讲不清楚由来。
任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二部才是决定是否执行。一定要专人负责需求的梳理，跟踪和进度的反馈。
需求池统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。
3.张弛有度，控制项目的节奏
你得想方设法让你的项目，在你所能控制的范围内进行。一旦超过边界，你可能需要启动后背资源予以干预，而且是在苗头开始之际。
最后，一定要深刻的理解，需求是不断的演进和变化的，合理的规避不合理的变更方为上策。
