关于项目需求变更的管理

      谈到项目需求变更，这个估计是所有项目经理都头痛的话题，需求变更直接影响到项目的成本，进度和复杂度。但是这个又是不得不面对的，这也是项目经理存在的价值，如何完美的解决这些问题呢，下面我们一起交流下

　　关于需求变更，分为外因和内因。

　　外因：

　　1.引导，搞明白客户的真正“需求”，有时候客户的需要可能并不是他们想要的，需要我方进行分析引导。

　　2.变更，确实需要变更的话，我们团队必须做的就是重新评估变更影响，是否需要延期，工作量等，是否影响质量标准等内容。然后重新安排优先级，并纳入下个迭代，确保变更内容得到执行，和客户确认好现在的需求是否需要继续完成，重新和客户确认里程碑和产品原型，他们其他的想法可能也关联性的发生变更。

　　3.反思，需求变更的原因，加强和客户对于产品的展示频次，及时获取客户的第一手信息。

　　4.书面和客户进行变更确认，看看变更成本，走变更流程保护乙方的利益。

　　5.最后就是验证变更结果，既然客户要变更需求，一定是很重要，最后通知客户变更完成，给他们信心。

　　内因：

　　1.范围没圈定就开始细化，需要控制用户的新需求。

　　2.没指定需求基线，需求分级优先级。

　　3.没有良好的软件结构适应变化。

　　关于制定项目计划：

　　这个应该是分阶段的，项目立项之前，应该尽量完善，项目计划其实就是项目预演。先说一下项目计划大概怎么做吧。

　　1.确认项目目标，只有项目目标和客户的一致项目才能成功。了解客户的需求，可以访谈，可以开会了解他们对项目的态度和期望，顺便也能了解干系人的一些情况。然后把需求排列优先级。

　　这样我们自己先理解一下客户到底想要什么。和客户的目标保持一致，后续方便进一步沟通。

　　2.确认项目交付物

　　目标确认了，后续就是做为了实现这个目标的拆解，我们是通过OKR把目标拆解成子目标，然后把每个子目标还原成比较大用户需求，方便和客户沟通。后续用户需求再拆成子需求，便于团队能落地。这个时候需要把每个需求怎么验收，需要什么指标，粗略的时间节点都要纳入进去，一般客户比较关心的就是时间和质量。

　　最后就是拿着用户需求和用户进行二次确认。我们这边用的是脑图和原型，原型不需要那么细，讲明白就行，有条件可以用高保真原型来确认，更直观。

　　比较重要的一点需要和客户确每一个需求的交付物，要如何提交，如何交付，必要的话可以把关键的人纳入到需求确认当中。

　　这样客户想要的产品基本清晰了。

　　3.制定时间表

      交付物确认了，我们基本上就知道用户想要一个什么的产品，以及一些可以量化的指标，质量期望或者进度，或者一些指标的期望，或者成本。

　　对于客户来说，已经确认的大的用户需求可能代表了一个里程碑，客户可能会持续关注。

　　这样我们就把大的用户需求向下继续拆解成能落地的用户需求，每个需求都要遵守敏捷的原则，这个就不展开说了。产品经理需要把用户需求排列优先级，里程碑和里程碑之间算一个时间盒，然后在和产品经理制定好每个里程碑时间盒内的迭代增量，这样就形成一个了产品增量的路线图。

　　每个产品增量其实都是一个用户需求，每个需求都有粗略的人员，验收标准，验收流程，如何测试，质量标准，也包含技术难点，风险等。

　　虽然没那么细致，但是这样也可以估算出一个相对准确的时间表。每个增量以及所需的资源，风险，验收标准等指标。

　　项目排期本质上其实算是我们内部进行一次粗略的项目预演。

　　我们拿着这个时间表和客户确认，基本上客户关心里程碑，对这个增量的时间表不是那么在意。

　　这样我们能得到干系人都有谁，如何沟通，沟通频次，沟通工具，建立一套沟通反馈机制。

      第一阶段的对外项目计划算是大概完成了

　　后续就是内部如何能敏捷起来了。

　　首先产品路线图以及有了，需求优先级也有了，接下来就是产品经理把大需求拆成小需求，并且把脑图和原型对团队进行宣讲，让团队也理解要做一个什么样的产品。这样研发可以对需求进行任务拆分，测试人员也可以着手测试用例和了解如何验收。

　　在团队理解需求的过程中，会遇见很多问题，这样我们再进一步把需求细化，例如补充这个需求对应的研发测试人员是谁，测试指标是什么，对外联系人是谁，风险有哪些，以及比较重要的如何沟通的呢。

　　这样就能明确干系人都有哪些，风险点是哪些，如何沟通。沟通频次，沟通渠道基本都能确认下来。

　　然后就是确认迭代频率了，每周交付哪些些需求，主要根据项目和团队的情况制定，动态调整。

　　这就是scrum的管理方式，不展开说了。

　　然后我们就能有一张产品分解pbs和任务分析wbs对应的表格，pbs对应客户，wbs对应团队。这个时候的时间点就基本比较准确了。

　　4.明确支持计划

　　形成几张表格，形式不局限于表格，有专门的管理工具

　　人力资源计划：

　　需要明确每个部门领导或者联系人，明确他们的角色和职责。

　　描述参与项目的人的数量和职能，每一个参与者清晰的开始时间，参与周期，以及人员来源

　　沟通计划

　　说明不同的干系人需要了解项目哪些信息，以及怎么获得，邮件，微信，还是周会，明确汇报项目状态，阶段性成果啥滴，争取让项目透明化。

　　风险管理计划

　　把我们制定计划过程中的风险记下来就形成一张表，预估各种风险以及解决方案，风险发生概率，责任人等指标。以及风险如何反馈。怎么变更之类的内容。

      一般的项目角色有3个，代表客户的产品或业务，代表团队的项目经理或技术leader，代表公司利益的乙方或者公司高层。

　　项目经理主要是协调这三方，3个角色找到了，协调好了，项目也就搞定一半了。