项目相关败因分析3
一、 需求变更频繁
说到需求变更频繁，相信所有做过需求分析的开发人员都有过这样的经历，用户每次变更需求之后，用户尽力的去满足用户的需求，可是每次开发人员修改完成之后，往往用户又会提出新的需求。在之前的分析过程中已经提到了需求变更的部分原因。但是不论如何，需求频繁变更这个阶段是不可避免的，要想将项目开发的尽可能完美，满足用户的需求，只有不断的修改。虽然需求变更这个阶段不可避免，但是很多人都没怎么在意，只是不断地修改，而不会去总结这些需求变更的类型。就作者的统计，目前在国内的软件行业中，对变更进行分类、统计的做法仍然不是很普遍。但如果只是简单地将所有的需求变更当做一个问题来看待，那么是无法有效的找出问题的根源。也无法有针对性的改进需求过程，提高设计的弹性。
二、 提供了不再需要的功能
对于谁才是知道用户最需要什么功能的人？产品经理，开发人员，还是用户代表？其实最了解用户需求的是软件本身，越经常被使用的功能，就是越重要的功能，那些没几次访问量的功能模块，一定是那些不再需要的。
作者曾经尝试过在每个功能模块的入口页暗藏了一个计数器功能，一段时间之后根据日志的记录，一看就知道哪些功能是不再需要的，哪些功能是不在需要的。当然，通过这个技巧，只能起到“马后炮”的效果，并不能在需求分析阶段进行防范。
三、 沟通失真
曾经看过一个漫画，客户向项目经理描述要做一秋千，项目经理向需求分析员描述自己的理解的用户描述，然后需求分析员进行设计。开发人员对需求分析员的设计进行实现。可是到了最后成了一个四不像，这幅漫画给人印象最深刻是沟通严重失真。虽然跟客户说的一样有两根绳子，一块木板，都是系在树上。可是功能却千差万别。究竟是什么原因造成这样的情况呢。其实从客户的描述到项目经理的理解，分析员的设计，程序员的编码的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工，从而导致信息内容有很大的改变。因此，对于软件需求分析而言，克服沟通失真就成了一个要点。
然而解决这个问题最关键，最有效的方式就是及时复述。通过复述，确定自己的理解，也可以将自己的理解描述出来，让对方进行确认。
