|
2.2 来自开发部门的问题blog.mypm.net
(1) 对需求理解不准确。经过需求分析之后产生的《软件需求规格说明书》是软件产品开发的依据，也是业务部门最后验收的依据。原则上说，《软件需求规格说明书》是开发者和用户之间的一份事实上的技术合同。项目管理者联盟
然而，由于以下几方面的原因，开发人员对《软件需求规格说明书》理解不准确，使得软件开发过程中和交付使用之后不断出现用户不期望出现的问题，软件产品不能准确地按用户的期望工作。项目管理者联盟
(2) 不严格按需求开发，自以为是。业务人员和技术人员由于知识背景各异，长期受到的训练不同，有很多差别。业务人员在描述问题时常常根据当前的实际做法简略描述，许多细节被忽略。项目经理圈子
在实际开发中，个别开发人员可能对业务需求中的一些提法和做法不愿接受，觉得从技术角度看，换一种处理方式可能更合理、更简单。因此，有时个别开发人员可能会在某些处理中按自己“更为合理”的理解去做，其结果是开发的产品不符合业务需求。
(3)不坚持原则，根据个别人的要求变动需求。业务需求是一个业务处理的全面约定，对需求的确认和修改是严肃的事情，不能随意变动需求。在金融软件开发实践中，开发人员有时不能坚持这项原则，对业务人员的一些个别要求不经过管理程序就随意答应。项目管理者联盟
结果是，最终提交的产品不符合《软件需求规格说明书》的要求，其中变动部分有时连需求提出者和相关管理部门也不掌握。项目经理博客
3、解决的办法项目管理者联盟文章
多换位思考，注意沟通的技巧项目管理者联盟
需求的复杂性是固有的，是无法避免的。每个人的知识都是有限的，所以不要苛求业务人员对IT技术非常精通，交流时尽量使用通俗用语而不是IT术语。在规定时间内，用有限的资源来保质保量地完成项目，让业务部门满意是开发部门的职责。项目管理者联盟
开发部门应当想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。在与业务人员的沟通中，应当更多地从业务人员的角度考虑问题，应当尽量避免正面冲突，耐心倾听意见，多问一问“您还有什么想法?”，项目管理者联盟
等业务人员把他的想法都表述清楚以后，开发人员可以迅速评估一下他们的建议，如果实现起来太困难，可以给业务人员一些更加中肯的提议，多用“您看这样行不行?”、“这样也可以达到同样的目的”之类的语言。club.mypm.net
当业务人员提出需求变更时，可以站在业务人员的角度来说明需求对整个项目的重要性，比如对项目进度的影响、对系统架构的影响、对系统稳定性的影响以及对系统用户的操作习惯的影响等。项目管理者联盟
当与业务人员的争议不可避免时，项目经理一定要坚持原则。如果遇到争议不下的问题，可以提交双方部门领导进行裁决。项目管理者联盟
(1)业务培训。由于金融领域的业务知识专业性非常强，因此完全有必要在项目初期，聘请既懂技术又懂业务的专家，组织开发人员进行有针对性的业务知识培训，避免出现因不熟悉业务知识，而导致需求理解上的失误。项目管理者联盟
(2)需求调研。需求调研有几种方式，常见的有需求讨论会和跟班作业。跟班作业是最有效的方式，但消耗资源较多，且受项目成本和项目时间的约束，很少有项目采用。召开需求讨论会，是需求调研的常见做法。项目管理者联盟
会前应做好充分的准备，起草需求调查问题表，将调查重点锁定在该问题表内，否则讨论将会变得漫无边际。在讨论会上要耐心聆听，同时要善于提问，并且要主导讨论内容，否则将无法保证讨论进度。问题表可以有多份，随着调查的深入，问题表将不断地被细化。项目管理者联盟
根据经验，业务人员通常没有耐心回答复杂的论述题，所以问题表应当以选择题、是非题和简答题为主。项目管理者联盟
(3) 需求评审。在需求整理完毕形成文档以后，开发人员最好把自己总结的需求，向业务人员比较详细地讲解一遍。这种做法不仅能够大大减少技术人员与业务人员在业务层面的歧义，还可以及时准确地发现潜在的问题。项目管理者联盟
开发部门和业务部门共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有一定的约束力。即便因为业务变化，不得不对项目需求进行大的调整，以至于项目延期，那也不是开发部门的原因，甚至可以以此为依据来拒绝不必要的需求变更。项目管理者联盟
而对于业务人员来说，通过审查这些详细的需求内容，对将要设计的系统也能做到心里有数，消除不必要的疑虑。签字确认后的需求文档可以作为今后产品交付的依据，对双方具有同等的约束力。据统计，需求设计阶段的评审，发现缺陷的有效性，最高达到75%，比测试有效20倍以上。项目经理圈子
(4) 加强需求跟踪。将系统设计、编码、测试等阶段的工作成果(如设计文档、代码、测试用例等)与需求文档进行比较，建立与维护“需求文档—设计文档—代码—测试用例”之间的一致性，确保软件依据需求文档开发。项目管理者联盟
(5) 需求变更控制。需求的变化问题是每个开发人员、每个项目经理都经常遇到的，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等，还必须对需求变更的影响进行评估。唯一的办法是使需求在受控的状态下发生变化，项目管理者联盟
而不是随意变化，依据“需求变更申请———审批需求变更申请———更改需求文档———重新进行需求确认”的流程处理需求的变更，确保需求变更不会失去控制而导致项目发生混乱，每一个小的变化都要严格按照变更管理流程来管理。项目管理者联盟
4、结语项目管理论坛
|
