需求变更导致计划一团糟,谁之过

经常有人抱怨:需求老是变来变去,把我的计划都打乱了!!!

虽然我心里也很理解他的无奈,很是同情他的遭遇。可是一味地报怨并没有什么用,根本解决不了什么问题。有报怨的时间,还不如静下心来思考一下为什么会出现这样的情况?有没有什么应对措施可以缓解甚至避免这种情况再次发生?

需求所以会发生变更,一方面是客户造成的。比如:

  • 客户没有给出准确的需求描述

  • 客户没有理解软件人员的表述却以为软件人员和自己的理解一致

  • 客户没有履行对需求进行确认的职责,使得确认后的需求仍然有很多不正确的地方

  • 客户只是想增加新的功能

诸如此类。

虽然如此,但软件开发人员不能把责任都推给客户。反过来从自己这方面也要找找原因。

  1. 我们的需求分析做好了吗?

GJB5000A需求管理过程域第1条专用实践就是要求与客户达成一致理解。这句话说起来容易,做起来却很难。即使面对面地交流,你表达了自己对需求的理解,客户也可能听不明白;或者客户以为自己听懂了,实际上并没有听懂……这些情况都可能发生。所以要尽可能提高“一致”的几率,还是要注意沟通的方式和方法。比如:

  • 找对人。需求的确认者要具备一定能力和水平,真正熟悉业务流程,最好有一定的权威性。

  • 软件开发人员要使用客户熟悉的语言来表述自己对需求的理解。

  • 一图胜千言。必要时画个草图可能比说上半天要有效得多。

需求确认的时候也是一样。

如果软件开发人员把需求开发做得好一点,也许就没有那么多的需求变更,那么对计划的影响也不会太大。

  1. 架构的健壮性和可扩展性

有时候需求的不确定是事先知晓的。对于这种情况,软件开发人员在进行结构设计时,应考虑软件架构的可扩展性,应使得不确定的需求发生变更时,不会影响整体架构,只是局部的改动。这样的话,需求变更带来的影响就会很小了,如果在策划时给了一定的余量时间,可能就不需要调整计划!

  1. 项目管理的风险策划

除了以上技术上采取的措施外,在管理上也可以采取一些措施。比如运用好风险管理过程。如果对需求确认信心不足,就把需求变更识别为风险,应对这一风险的缓解措施就是在进度计划中留有一定的时间余量。如果需求变更有了事先设计的时间余量缓冲,那么就有可能有了变更也无需调整计划。

虽然需求变更会对软件的开发计划带来很大的影响,但只要分析其原因,采取有效措施,会使得这种影响降到最低。

需求变更导致计划一团糟,谁之过》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/3377.html