如何制定一个周密的项目计划，大概不是项目中的难点，但计划之外的情况，却是大家最头疼的地方。在项目具体推进的整个过程中，无 *** 控的需求变化通常会给项目带来沉重的压力和意想不到的风险。因此，一套合适的需求变更过程管理和设计方案标准对于项目和项目监理来说都是必要的。
问题分析首先对边肖的项目做一个简单详细的介绍:商品方面，我们都是C端商品，关键需求来自于管理和方案策划。就商品而言，我们正处于调整期，目前关键是探索新的角色。就项目而言，由于功能复杂庞大，激光切割室空不大，所以每个版本号的周期时间较长(每个版本号的产品准备周期时间为15~20个工作日)，从产品设计到产品开发发布的主要步骤如下:
定义小系列中的需求变更包括两个方面。第一，在产品的设计中:需求评审完成后，在PRD文本文档终稿后，对需求草案进行变更，定义为需求变更；第二，在产品R&D调度完成后，最终的软件开发测试和发布计划被最终确定，未来任何计划外的变更都被定义为需求变更。
在项目开始的时候，并没有明确定义需求变更的步骤和标准，所以在项目的具体推进的全过程中，会出现很多变更带来的问题。这里，联系实际问题来一一说明:
问题一:变更多:刚开始项目的大问题是需求变更多。如果只是一头扎进步骤，就会得过且过，所以大家都试着去分析这种变化的原因，看能不能从根源上堵住。经过辨析，发现有非常大一部分的变更是因为需求的设计方案不够强大或者需求的相互理解不及时，在后续的环节才发现，以至于需求的变更或者增加才刚刚开始。
问题二:变化不标准:变化是不可避免的问题。让我们坐下来聊一聊。如果你觉得很好，就做这个改动吧。这是我们以前的惯例。但是，由于缺乏基本步骤的既定标准，当事物被改变时，事物通常会丢失，从而导致以下问题:
变更需求明确提出人过多，不清楚听谁的变更明确提出的很晚，交给项目的時间很少了变更究竟做不做，何时做等信息内容，在每个人物角色间的信息内容不同歩第三，问题是有风险的:太少的项目关注于讨论变更本身和变更的实际意义，通常忽略了变更的实施通常会冲击原计划，缺乏详细的风险评估；在变更实施的情况下，没有相对固定的招数和技巧，整个实施过程非常松散，缺乏一些合理的监督，整个过程中的风险演变是未知的。
解决方法此外，我们注意到，如果项目管理中心所依赖的步骤和标准太强，项目运作就会很复杂，效率很低。但是太弱反而让项目懈怠，偷懒。因此，设计方案匹配方法时必须考虑各种规划方案，选择非常简单的方法完成标准化管理。
对于第一个问题，我们决定升级原来的主杆步骤，升级一个承前启后的环节，进行需求判定；对于第二个和第三个问题，我们已经标准化了如何审核更改以及如何实现两个完整的流程。方法建立监理项目，进行劳动力转移。
主杆业务流程优化在社会经验的基础上，该项目发现，单靠需求审查并不能完全确保需求方明确响应所有需求，其交互各方充分理解需求方的要求。本质原因是，PRD无法清晰详细地描述所有场景，很多关键点和一串串需求即使在需求审核后仍然很可能是不完整的。只有当交互式室内设计师将需求改进成精心构建的逻辑图和场景时，他们通常会发现需求设计方案在开始时并不及时。在版本号大的情况下，他们要等到所有的交互稿都拿出来了才会做修改，修改成本太高/体验不是很好。
所以针对复杂的设计方案，在互动评审之前，会拆分出一个阶段来做一个互动的主场景评审。根据增加的阶段，保证需求的完善和完善，减少后注环节的需求变化总量。
该方法适用于两种场景:方案规划中PRD频繁变更，功能过于复杂，潜在变更风险大。PRD的频繁变化往往是不完全的。功能数字逻辑存在系统性漏洞，也有可能是产品规划/业务数据分析讨论等外部步骤没有做好。在这样的情况下，仅仅提高一个主要场景的回顾是没有用的，读者必须具体分析。
对于这样一个交互式主场景的审查，具体步骤建议如下:
时段：这一阶段分配在需求评审完毕后，交互评审刚开始前，且提议在需求评审后尽早分配，大约两个工作中日内分配；內容：交互了解方案策划PRD表明后，基本制做交互稿，粒度分布做到遮盖关键的场景及详细的逻辑性步骤，随后举办主场景评审会与方案策划/需求方开展确定，保证需求了解恰当和需求的完善。参加人：需求明确提出方（如经营，销售市场等），方案策划，交互变更标准确立变更程序的标准包括两个关键级别。一是确立变革管理方法的基本核心思想；第二是建立一旦做出更改就必须依次实施的流程。
管理方法变更的核心思想>:>
变更管理的核心在于评估需求变更的使用价值，然后决定要不要做，在今天的版本号里要不要做。大家尽量从更多的方面去思考，包括商品的整体规划，需求的特点。
首先分析商品链接的特点:我们正处于一个商品转型发展的新旧交叉阶段(简单来说，一方面需要维持原有功能，另一方面需要探索设计方案的新功能)，因此这一阶段的需求变化可以分为四个层次:原有关键功能、原有附近功能、新关键功能、新附近功能；改动也是按照上面提到的级别分类，然后考虑版本号的发布时间和质量。需求变化按以下顺序考虑(边肖假设质量稳定，类别和进度为自变量，故优先考虑类别和进度):新角色关键角色变化>:原关键角色变化>:版本号发布日期>:新动作附近的动作变化>:原功能附近发生了变化。
另外，不建议因应急需求变化而延迟发布时间。就项目而言，发布时间是一件很严肃的事情，不是随便就能改变的。是大家互相守护的总目标。所以我们定义了需求变更的锁定期，一般情况下，锁定点之后所有的变更都不会被接受。关于如何设置需求锁定点，不同项目必须根据具体情况具体分析。比如大家的做法是:商品链接锁定期在互动场景审核后两天内；产品R&D的锁定期大约是测量点提出前的几天(如果设定的标准是版本号方案，开发设计会预估测量时间，确定展示期为锁定点，通常是测量点提出前的几天左右)。其实对于这两个锁点，大家会重点讨论后一个锁点的管理方法。
在解决变更的整体思路上，除了以上实践经验交流的理论基础外，也建议标准项目尽量固定产品开发的迭代更新时间，如果周期时间能在两个周一迭代更新是最理想的。大家也尽量每周迭代更新一次。当下，他们在解决需求变化方面明显更加冷静，但可用场景有限，零碎的升级需求是每周迭代更新解决方案的关键。
变更的实施过程>:>
实际上，对于如何实现更改，没有固定的技巧，但结构实际上是相同的。边肖在项目上画了一些实际活动，供大家参考:
需求方明确提出变更（提议同一个人物角色集中化由一个人来提变更，例如经营/销售市场必须各自特定唯一的輸出需求变更的插口人），方案策划评定变更重要性，制订变更的计划方案（提议变更统一由当今版本号承担的方案策划来统一搜集和輸出）；假如必须交互设计方案，必须和交互一起探讨完成计划方案。方案策划通告开发设计，开发设计同学们评定变更劳动量，一般状况下，开发设计和方案策划相互决策是不是在当今版本号完成变更，假如建议不可以一致，必须递交能够承担的干系人审核决策，但这类状况通常较少，绝大多数状况還是要靠商品和开发设计撕出一个结果。PK取得成功的变更将进到产品研发，站会众所周知，项目主管评定风险性；PK不成功的变更进到需求池，在养金鱼的鱼缸里重新排列优先。针对PK取得成功的变更，一般而言大家会摘掉一个优先较低的需求，确保迭代更新里劳动量相对性稳定；但，这仅仅正常情况下的作法，大家也会灵便的剖析当今剩下劳动量，来决策是不是能够立即加上变更，这类作法提议是尽可能要少。 在变更实行全过程中去监管情况和风险性：我们在项目全过程中运用jira的dashboard去监管每个开发设计变更劳动量和剩下的时间，运用每日站会去持续review确定序列中的变更，依照优先先后进行项目容许范畴内的变更。表明：项目上经常会出现那样的状况，大中型的需求变更通常较为宣布的走步骤，风险性比较好把控；针对碎碎的的小变更，在无法装包统一解决的状况下，单独开发者会相继承担一个一个而成的好几个小问题，而这种细微的难题你难以做去做時间服务承诺，只有大概的体会非常简单能够改，最后結果很有可能就这样：不经意间中，序列中的变更会渐渐地增加，一个个没经详尽估计的小一点聚集成很大的风险性。汇总综上所述，除了整理对策和步骤标准来管理方法变更和实施变更，还要选择合适的时机，正确引导精英团队总结变更原因，不断完善对策和步骤标准。要明确影响因素，高频换焦点，分析原因。总结除了应用的持续改进和生产步骤的闭环控制，还有利于精英团队对变更的原因和解决方案达成一致，提高团队配合变更和实施变更的能力。
如何改进变更管理方法，深度简化变更流程，还在探索和推进中。我们热烈欢迎大家和我交流。
创作者:于和，网易游戏航研项目服务部高级项目总监，先后在网易游戏GACHA、网易云音乐公共产品运营担任项目总监。关注敏捷和scrum在互联网运营的实践活动和精英团队的发展。网易一千零一夜重点编译之一。
文章作者为@网易游戏航研项目管理办法(微信公众平台:NetEasePM)，未经批准严禁拦截。
注:阅读相关网站基本建设方法的文章，请移至网站建设教程频道栏目。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）