需求管理，管的是期望，要的是权力。
文 | 杜松，公众号 | 产品微言
任何项目都有一个特色，那就是项目之前群情激昂，至于过程和结果，有的怨声载道，有的劫后余生，万象丛生都很正常，越大的项目故事往往越多。
在前述的文章里面，我从项目的环境，复杂的各方利益，项目的任务分解和任务进度的制定，多个角度分析和阐述了根本原因，这些诱因最终会在项目过程中成为无休止的变更，从而让整个项目陷入不可救药的局面。
所以，需求的变动那是家常便饭，没有变更往往不正常，而变更的管理和文档的缺失会进一步加剧这种现状。
变更，分为两种类型，其一是完全不可控因素，既是未知的，也是不能改变的。
比如，公司的经营方向发生了改变，导致项目的预算被削减（增加），从而影响项目的进度。特别是在创业型团队，老板临时改变注意，发现某个方向可能更有潜力，调转枪头也未可知。
作为一个项目的负责人（执行者），在项目启动之后，唯一的使命就是促使项目成果，或者结束项目。对未知和不可控的任何局面，都无需过多的投入精力。你能做的，就是管理那些可以被管理的内容。
那些内容是可以被管理的？（如何管理）
可控的需求变更，无非三大类：
没有细化清晰的项目需求
没有明确清楚的项目边界
存在设计缺陷的软件结构
深究起来会发现，在项目已经启动后，真正与客户直接相关的就是第二条，由于没有明确的项目边界，从而导致用户无休止的提出各种需求和变更。
而对需求本身的理解和软件的设计，则考验产品经理和整个团队对业务的理解、把握和产品设计能力。这也是为什么我一再强调“用户故事”的原因，而这种变更则需要团队具备极强的消化能力。
1、建立完整的流程变更机制并严格遵守
项目管理，本质就是对过程的管理，也就是要有完备的流程和坚决的执行，通过流程来规避可能的风险。
所以，项目的第一件就是设立一个需求变更机制。（如果你还记得之前谈到的项目启动会，项目经理一定要借助这个会议让项目的所有相关方知悉这个流程。）
这个流程有两个核心观念，也是你一定要能争取到的权力：
1、所有人都可以提出需求变更的请求，但只有一个需求的入口
这个入口必须是你，如果你争取不到这个权力，那整个项目一定会失控。任何都可以提出需求和变更，但你必须作为唯一的接口人和过滤器。
为此，你应该有足够的心里准备，你需要面对N多方的压力和“撕逼”。甚至，为了项目交付的这一终极目标，你需要有不惜得罪人的思想准备。越是大项目，越是牵涉多方的项目，风险和协调都会是指数级的放大。
只有当你具备这个权力的时候，你才能确保项目在预设的轨道上进行，也只有你才可以清晰的回答当前要做什么，能做什么，以及不能做什么。
2、只有评审过的需求才可以被执行
“不要接到需求就直接动手”。这是项目的至理名言。
你需要让整个项目团队，包括上至老板、直到程序员，也包括外部的客户，都认同、理解并遵守一个基本原则，那就是程序员不直接接受任何非PM的需求，不接收任何非经过评审的需求——所有未经过评审的需求，只可讨论，不可执行，减少（避免）张嘴就来的非必要、非紧急、非合理的无效变更。
切记：不是所有的需求都要接受，也不是所有变更都要立刻修改，一定要能敢于拒绝需求。
作为产品经理，在需求变更收集上来之后，根据需求提出方的业务进行分析后，邀请需求方、技术、设计和测试多个环节进行分析，从而判定需求对于项目的影响如何，确定是否接受变更并将变更排列优先级。
但最终一定要你拍板，这是你需要争取到的第二个权力。你不能最终决定一个需求的价值，对你而言，项目已经离失控不远了。
当然，你可以适当根据需求的范围大小，决定评审的范围，甚至可以决定需要告知的对象，这没有标准，需要灵活把握。
这里其实是有一个例外，那就是技术本身驱动的变更，比如有更好的实现方案可以带来性能的提升，这个情况，需要根据整体项目状况，结合技术本身的能力判断。
2、建立完善的文档管理机制并落实到位
俗话说“好记性不如烂笔头”。
项目过程中，文档是极为重要的工具，虽然管理文档费时费力。对于产品经理（创业团队还是兼任项目经理）而言，一定要持续的追踪项目的所有需求文档，变更记录。
一定要所有的文档，形成版本机制并同步到到团队的没有给成员，你可以借助一些在线工具来帮助你完成这项功能。
要知道，但凡失控的项目里面一定有一条就是找不到需求的出路，不知道为什么要这么做，也不知道谁要求这么做，反正就是做了，然后谁也讲不清楚由来。
任何需求，都必须记录在案，甭管是否执行，需求的第一个动作就是备忘，第二步才是决定是否执行。一定要专人负责需求的梳理，跟踪和进度的反馈。
完整的需求变更记录文档将有助于你了解整个项目情况，包括执行的需求，被拒绝的需求，你需要一个“需求池”统一管理来自业务端、技术端的需求，并针对项目中出现的资源、时间等因素可以合理的进行调配。
3、张弛有度，控制项目的节奏
你确定了规则，梳理好了边界，甚至也形成了流程。
下一步，你得控制好整个产品的推进节奏，合理的控制和调节需求、变更的优先级，以及资源的投放力度，什么事情该投入多少资源，什么时候该做什么事情，什么是关键路径，什么是关键角色，你必须门儿清。
你得想方设法让你的项目，在你所能控制的范围内进行，一旦超过边界，你可能需要启动后备资源予以干预，而且是在苗头开始之际。
你所有的干预手段，预防机制，都是为了确保项目按照一定的规则和秩序推进，也只有基于可控的节奏，你才能确保整个过程的质量，以及最终交付的质量。当过程不可控的时候，往往结果会很糟糕。
最后，一定要深刻的理解，需求是不断的演进和变化的，合理的规避不合理的变更方为上策。
有些时候，无论你怎样控制，由于市场的压力，总会碰到各种“无理”要求，如何看待这样的问题，就不是简单的控制问题了，这就需要更高的层面去权衡利弊，如果确实不值得，也只能放弃。
产品经理作为引路人，就是尽可能的让不确定性的因素，变为确定的，可被执行的流程、方案。
不管你是否兼任“项目经理”的角色，在一个产品从0到1的过程里面，产品经理必须深刻的理解整个过程的艰巨，要能与团队一起致力于整个项目的成功。
至此，本系列从项目和产品的概念出发，到项目环境的分析，以及对项目过程的几大巨坑一一做了阐述，也许你还需要一些工具，或者模板来提高项目过程管理的效率。
在下一个章节，隆重推出项目管理过程的工具包，希望能对你提高项目成功率有所帮助。
<未完待续>
关注公众号 产品微言，回复“ 项目 ”，即可下载本系列完整 PPT
