如何制定一份缜密的网站建设计划可能并不是网站建设中最难的事情，要应对计划之外的情况，才是最令大家头痛的地方。在网站建设实际推进过程中，不加控制的需求改进往往给网站建设带来沉重的负担和无法预料的风险。因此，设计一套合适的需求改进管理流程和规范，对网站建设而言都是不可或缺的。
一开始网站建设上并没有对需求改进的流程规范做清晰的定义，因此网站建设实际推进过程中会出现诸多由改进引发的问题，下面为你们详细说明：
一：改进多：一开始，网站建设最大的问题是需求改进很多，如果只是猛的一头扎进流程中去，反而浪费时间，所以我们尝试去分析这些改进的原因，看看是否能在源头堵住改进。经过判断，发现相当一部分改进是因为需求设计不够健壮或者交互对需求的理解不到位，在后续的阶段发现，进而才开始修改或新增需求。
三：问题带来风险：网站建设过多关注于讨论改进本身以及改进的意义，往往忽略了实施改进往往会冲击原有计划，缺乏完整的风险分析；在改进执行的时候，没有相对固定的套路和章法，执行过程很松散，缺乏一些有效的监控，过程风险演变不得而知。
二：改进不规范：改进是在所难免的问题，大家坐下来聊一聊，如果感觉不错那就把这个改进做了吧，这是我们之前的做法。但，由于缺乏一个明确的基本流程规范，一到改进的时候，处理事情往往丢三落四，进而会出现以下问题：改进需求提出人太多，不知道听谁的改进提出的太晚，留给网站建设的时间不多了改进到底做不做，什么时候做等信息，在各个角色间的信息不同步。
定义需求改进包含两个层面，一是在产品设计阶段：需求评审结束，PRD文档定稿后再对需求稿进行更改，定义为需求改进；二是研发排期结束，定稿开发测试上线计划，之后凡是计划外的变化都定义为需求改进。
解决方案
我们在给出解法的同时还需注意到，网站建设管理所依赖的流程和规范若太强则使网站建设运转繁琐低效；但过弱则又使网站建设松弛散漫。因此，设计对应办法的时候需要充分考虑各种方案，选取最简单的方式来实现规范管理。
针对‘一’，可以优化原有的主干流程
网站建设上根据实践经验发现仅靠需求评审无法完全保证需求方清楚的澄清所有需求，以及交互方充分的理解需求方的要求，其本质原因在于PRD并不能完整的描述清楚整个场景，许多需求层面的细节和串联即便在需求评审结束后依然可能覆盖不全；只有随着交互设计师把需求完善成结构严谨的逻辑图和场景说明，往往才会发现一开始需求设计不到位的情况，在大版本的情况下，等到整个交互稿都拿出来了再去做改进，改进代价过大/感受也不好。
针对‘二’可以改进如何执行
改进流程的规范涵盖两个主要方面，一是明确改进管理的基本理念；二是明确一旦要做改进，需要依序执行的步骤。改进管理的核心在于评估需求改进的价值，然后决定做不做以及是否在当前版本做，我们尝试从更多角度去思考，包括说产品的规划，需求的特点。
首先分析产品阶段特点：我们处在产品转型这样一个新旧交叉时期（简单说就是一方面要维护原有功能，另一方面更需探索设计新的功能），因此这个时期的需求改进可以划分成四个维度：原有核心功能，原有周边功能，新功能核心功能，新功能周边功能；改进也按上述维度进行分类，再考虑版本上线时间和质量，按照顺序去考虑需求。
同时，十分不建议因为紧急需求改进去延迟既定的上线时间，对于网站建设而言，上线时间是一个很严肃的事情，不能轻易的去改变，是大家共同守护的目标。因此，我们定义需求改进冻结时点，原则上在冻结点后不接受任何改进。关于需求冻结点如何设置，不同的网站建设需要根据实际情况做分析。
针对‘三’可以改进如何审批
对于较为复杂的设计，在交互评审之前会拆分一个环节出来，做一个交互主场景的评审。通过新增的环节，确保需求的健全和完善，减少流入后续阶段的需求改进数量。
这个做法适用于策划改进PRD频繁，以及功能过于复杂伴随较大的潜在改进风险两个场景。PRD频繁改进频繁并不完全因为功能逻辑设计有漏洞，还有可能是产品规划/商业分析论证等前置流程没做好，这种背景下光是增加一个主场景的评审是没用的，读者需要仔细分析。
其实改进如何执行，并没有一个一成不变的套路，但结构上其实还是大同小异，笔者给出网站建设上的参考只是一部分经验总结。想了解更多经验请到深圳网站建设一度互联网站留言区留言。
