http://blog.csdn.net/yqmfly/article/details/7679781博客阅读笔记

阅读笔记

　　令作者印象深刻而难以忘怀的，是他亲眼目睹的、道听途说的一个又一个的软件项目，它们有的获得了成功，但更多的是令人沮丧的失败。幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。项目开发有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。

　　作者先列举啦4个故事更加形象地诠释软件开发时容易发生问题的几个方面：

　　

（1）不要被客户牵着鼻子走，要从专业角度去分析，客户为什么提出变更，找出更合理方式让双方都满意

　　一 。 我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。

（2）基于技术实现去引导客户的需求，使客户的需求可以用计算机实现

　　二。 不能客户怎么说软件就怎么做。客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟人家是非技术的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。

（3）真正要完成需求分析，应该是一个一个专门讨论各个领域的小会（除啦开始必要的动员大会），并且必须与专家建立联系，反复沟通。遵循一定的科学方法。

　　三。 从职能角色划分，有高层领导、财务人员、生产管理员、采购人员、销售人员，等等。在这样一个复杂场景中，不同人员对这个项目的需求是各自不同的。非常遗憾的是，我们在进行需求分析的时候没有认真分析清楚所有类型人员的需求。在进行需求调研的时候，总是集团领导带领我们到基层单位，然后基层单位将各方面的人员叫来开大会。这样的大会，各类型的人员七嘴八舌各说各自的需求，还有很多基层人员在大会上因为羞涩根本就没有提出自己的需求。这样经过数次开会，需求调研就草草收场。我们拿着一个不充分的需求分析结果就开始项目开发，最终的结果可想而知。直到项目上线以后，我们才发现许多更加细节的业务需求都没能分析到，系统根本没法运行，不得不宣告失败。一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。

（4）在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

　　四。我们的项目从需求分析到设计、开发、测试都十分顺利。但到了项目进行的后期，快到达最后期限时，我们将我们的开发成果提交给客户看，客户却对开发结果不满意，提出了一大堆修改，而且这些修改工作量还不小。怎么办呢？加班、赶工，测试时间被最大限度压缩。最后项目倒是如期上线了，但大家疲惫不堪，并且上线以后才发现许多的BUG。需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。以上这个事例，如果我们提早将开发成果给客户看，提早解决问题，后面的情况就将不再发生。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

　　　接下来作者就开始讲述如何做好需求调研，分析以及确认。要做好需求分析，调研是必不可少的过程，而需求确认则是需求分析的保障也是结果。所以需求分析离不开调研更不能没有需求确认。

　　　其中要做好需求调研则需要：　

　　一.初识：对客户提出的需求进行深入理解后，运用专业知识，提出比客户原始需求更加合理，可操作的解决方案。我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。万事开头难。如果在项目开始的时候总感觉千头万绪不知如何着手，这里有三个建议三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。

　　二.拜访：需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。按照现在的软件运作理念，软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务。按照这样的理念，软件供应商与客户建立的是长期共赢的战略协作关系，这更需要我们与客户建立长期友好的关系。

　　三.研讨会：需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。按照现在的软件运作理念，软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务。按照这样的理念，软件供应商与客户建立的是长期共赢的战略协作关系，这更需要我们与客户建立长期友好的关系。

　　四。需求调研：我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。

　　五。迭代：需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。

　　六。需求捕获：户业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识，站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求。当一个需求分析员能达到这样的水平，客户嘴中没有说出来的需求就会被源源不断地被发掘出来，最终做出来的需求分析才是完整的、准确的。