谈谈需求变更跟踪

在实际研发的过程中，由于需求变更的缺乏跟踪，带来很多问题。需求变更跟踪分为两类，一类是项目开发期的需求跟踪；一类是系统上线后维护的跟踪，最难处理 的是上线后的需求变更跟踪管理。需求的跟踪过程，包括需求的审核，接受，分派，开发，测试，发布,部署及相应的配置管理跟踪等。

项目开发周期内的正常的需求变更,应该要跟踪控制相对容易点。新需求及需求变更均需通过需求申请单申请，经评审和批准后，产品经理将要素纳入需求跟踪矩阵以作跟进，并及时更新。填写需求跟踪矩阵表是很重要的,当然不同的阶段,也可以有不同的工具使用。

系统上线后维护期间的需求跟踪是最难处理的，因为维护期涉及到客户关系处理，流程制定需要公司的上层和客户的上层来共同推动。维护期的需求变更，有很多特 殊情况,比较客户要求很紧急，直接打电话给开发人员，开发人员接受，修改，发给客户。这不是规范的做法。有公司的项目基本没有做变更控制，或者说是客户在 做变更控制，他们说怎么变更就怎么变更，这是企业开发能力成熟度较低的表现。

研发人员是否直接面对客户修改问题？这个要根据企业的情况，具体决定。有些企业中间有产品部和需求规划部，或者运维部门来统一接口面对客户，有些是合理 的，比如研发人员是不能直接根据合同来做开发，有些需求是没有体现在合同里面的，产品化的需求需要根据市场的需求全面分析考虑而来的。有些小型公司小型项 目周期短，则是完全可以开发人员直接面对客户沟通的。上线后正式运行的系统，面对需求变更要慎重分析，尽量避免仓促的修改带来较大的风险。面对上线后客户提出的需求，有三种处理方式可以选择：一是快速修改完 成，打补丁等；二是推迟到下个版本；三是要变通实现，最小成本，替代解决，否决当前修改。因此面对客户提出的问题，沟通技巧，降低风险，优先级划分等都是 要考虑的因素。 

上线运行维护后需求变更规范的流程是什么呢？客户应该提出变更请求单,客户负责需求相关领导签字确认,提交项目组后应该进行风险评估,确定变更方案,评审 通过后,才可以得以实施。有些项目组人员说时间太短，按照流程很难做到，但是这些过程都必须要做，只是根据变更问题的重要程度和影响范围，投入的时间比例 不同，流程的东西，有时候忽略哪一块都不行，都可能会造成后面放大的风险和成本，否则后果责任你能承担得了吗？

关于上线后产品的需求变更如何降低呢？在早期产品规划方面就应该注意以后需求的可能变更，包括挖掘隐性的需求，在架构设计方面要考虑未来的适应性。如果能 深刻理解客户业务知识，找出规律、共性的公司就能规划做好产品。否则，只能跟着某些客户做项目，一个企业应该要有成长，初期发展的往往要以一两个重点项目 为主，但是公司发展壮大以后，就要转向产品的开发管理为主，只有这样才能创造更多的企业利润。另外在知识管理里面优化核心模块和建设共用平台，非常有利于 需求的快速实现，这些都是企业都需要重视的。虽然版本升级周期影响到客户满意度，其实也不是越频繁约好，健壮的版本，都可以通过灵活配置来实现。