需求是软件设计师永远的痛

无论是软件公司兴高采烈地拿到了项目，还是企事业内部电脑部（科技部）无奈地接收到了项目开发任务，两者都会面临“需求”问题。需求是定制软件的起点，也是定制软件的终点。在中国没有需求就没有软件，没有软件也就没有软件设计师，没有程序员了。但是，需求并不是一个天上的馅饼，现实中谁吃谁倒霉，谁就被其折磨至疯至死。越是大项目，需求就越多越复杂，越是大项目，需求就越会变化，这种对需求的掌控，对需求变化的应对就成了软件设计师把握项目最重要的基础。

作为软件设计师，他首先要面对需求，只有在对需求了解和懂得的基础上，才能对需求进行各种分析，分析透彻后，才能进行项目的总体设计；总体设计完成后，才能进入功能设计；功能设计后，才能进行功能的流程设计；流程设计后、才能对具体的功能实现技术算法进行设计；等等。因此，需求是设计各个环节之首，需求做不好，其他全乱了。

在现实工作中，软件设计师在需求方面往往会碰到以下问题：

1、 入门艰难

入门艰难是软件设计师，常遇到的问题，由于很多软件设计师只关心编程、只关心技术。对用户的业务基本上是不懂的，除非有项目了，他才会被迫地去学习需求中的相关业务。这种对业务先天的拒绝，说明软件设计师还没有进行很好的角色转变，忘记了其了解用户需求，进行需求分析是其首要的职能。究其个中原因是软件设计师对用户的业务和需求的恐惧，很多人对自己不懂的东西，往往抱有拒绝的态度，因为，自己怕不懂会给别人造成无能的形象。干脆就离自己不懂的东西远远的。软件设计师要想远离需求是在内心深处的，但是，现实中他必须要接受需求，否则，项目无法进行。所以，很多软件设计师在拿到用户的需求的时候，尤其是初次进入这个行业的时候，进入一个自己从未听说过的业务的时候，自信心几乎为0，十分担心项目最终能否进行下去。这种恐惧的折磨是非常明显的。当然随着对项目需求的逐步了解，这种恐惧心态才会逐步地平息下来。

我的建议是，软件设计师平时就要养成重点放在需求上的习惯，根据公司和单位未来可能开发的软件和方向，主动地去学习各种用户的业务知识，作为今后项目设计的积累。例如，今后可能进行银行业应用系统的开发，那就要早早学习各种银行业务知识。有了这些知识积累后，软件设计师的自信就不会为0了。

我特别反对现学现卖的工作作风。有的人等到项目落实了，一点准备都没有，就来听用户的需求讲解了。明明听不懂还一个劲地点头，留了一大堆自己不明白也搞不明白的东西，浪费时间、浪费效率。对项目开发的时间影响很大。常言道“机会是留给有准备的人的”。这种人可恨有可怜。

2、 沟通吃力

要了解和理解需求，就必须要和用户进行沟通，要沟通就要有共同语言。现实中软件设计师和用户沟通并不融洽。主要的原因在于：

1） 用户讲述的需求的时侯，往往感觉需求非常简单，所以讲起来行云流水，简单中包含了无数的业务名词和业务做法。而且内容大都是发散的，不经过严密推敲的。而软件设计师往往准备不足，听不懂，但是又不会中途打断用户的讲话，即使是进行需求讨论的时候，由于问题太多，而提不出问题来。

2） 有的软件设计师更喜欢看需求书，喜欢通过自己精通的看书的方式了解需求，以避免和人打交道的尴尬。但是，很少需求书能把需求说清楚的，大多数需求书，往往比较简单、漏洞百出。软件设计师看这样的需求书能懂得需求那才怪呢。另外，用户需求书，往往需求更多的业务知识的支持，而这些业务知识一般是很难附在需求中的。从某种意义上来说，和人沟通是正道，和书沟通只能是一个补充。

3） 在很多应用项目中，用户的要开发的系统并不是自己企业自身的要求，而是外部监管的要求。例如，银监会要求各商业银行在规定时间内报送某种报表。银行在开发这个报表的时候，对这个报表本身就不很理解，往往会把银监会下发的文件作为需求提供给开发者，自己却说不出所以然来。

对于一些跨部门跨业务的应用系统开发来说，有的用户只对自己熟悉的部门和业务比较懂，但是对其他的部门和业务并不太懂，这个时候软件设计师就很难从他的口中得到自己想要的东西了。软件设计师千万不要认为用户是什么都懂的。有的用户甚至说的都可能是错的。

4） 在后期的交流之中，软件设计师往往不自觉地会用计算机语言和用户进行交流和解释，这个时候，就轮到了用户听不懂了。例如：用户发现查询一个交易，需求等待十分钟，就问软件设计师为啥这样慢。软件设计师经过检查后，告诉用户是因为数据库中表索引忘记加了，所以慢了，现在已经改好。用户根本听不懂数据库和索引这些词义。但是只能认为软件设计师讲的都是高科技的。

3、 交流不便

无论在需求阶段还是在设计阶段，还是在编码阶段、测试阶段、投产阶段、软件设计师都要和用户进行交流和沟通。只有交流软件设计师才能知道项目要做什么，只有交流才能知道项目做的对不对。在现实中，往往很难找到一个完全脱产的用户跟着软件设计师跑完全程的，一个设计师往往要和许多用户打交道进行沟通。因此，软件设计师往往会遇到找不到用户的情况，或者用户对他说工作太忙没有时间和他交流的情况。“你急他不急。”到“你不急他急”各种情况都有。由于用户是上帝，软件设计师是上帝的臣民，所以只能再急也只能等了。

我要建议的时候，当要和用户进行交流的时候：

1） 尽量在交流前，把所有的问题及在本子上，千万不要遇到一个问题，就去问一个问题，这样会大大增加交流次数，影响用户的自身工作。

2） 要学会预约用户，当用户经常说没有时间的时候，要先期进行交流确定交流时间。不要自己想要去问问题就去问。这样被拒绝的概率会小一些。

3） 对待需要不同岗位进行交流的用户，建议由其部门领导牵头开一个联席会议，在会上进行集中交流。

4、 变化频繁

软件设计师好不容易才把需求搞懂，进入了开发阶段，常常会遇到需求需要变更的情况，有些变更比较小，比较早，影响不大，软件设计师往往只好忍了。但有些情况，例如需求分析并不充分，到了开发阶段，甚至到测试阶段发现了功能重要遗漏、重要功能变更，发现数据库设计要大的变化这些需求的变更，往往让程序员想死的心都有了。更崩溃的是，这种情况决不是出现一次。当用户信誓旦旦决不再变的时候，用户还会找出各种理由进行第二次、第三次变更。当然最终的胜利是属于甲方的（用户的）。更更崩溃的是需求改动后，程序编好了，需求又改回来了。开发人员做了一会无用功呀。

面对不断变化的需求，我们很难通过合同形式强制需求不变。因为变是硬道理。我建议：

1）              在讨论需求的时候，多向用户提出可能变化的功能、流程、信息、报表的可能在哪里。把可能的变化范围控制在自己的手中。千万不要要求用户这个不能变那个不能变。恰恰相反，你要不停地问，那个要变，那个为啥不变。把“变”从暗处拉到明处。

2）              需求变化的主要原因一个是业务本身不成熟，所以会产生变化；另一个原因是用户本身的业务知识掌握程度有差异，产生了需求变化。所以，要多找几个用户交流，采众家之言，不要认一个用户说话。这样需求变化的可能性就会大大减少。要特别找那些业务知识强、表达能力强、逻辑性强的用户作为需求提出的主要人员。多听听他们的意见和建议。就能减少需求的变化。

3）              要从技术层面解决需求变化问题，例如，将整个项目的构架变成一个可扩展性的构架，对信息设计也采用扩展的设计，最大限度采用参数化，采用接口技术。

我深知做项目的不易和艰难，我深知需求是软件设计师永远的痛。一个软件设计师只有在这个行业，这个类型系统不停地设计开发，才能积累这个行业的业务知识，积累这类系统的开发经验，才能将这种痛逐步地减轻。当我们有一天比用户更懂业务的时候，我们这种痛才会消失，我们才会把原来的痛转化成享受。

   

软件行业出现“需求驱动”开发模式，必然会造成软件设计师的永远的痛，无论怎么医治这种痛始终存在，无法只是大痛和小痛之分吧了。只有跳出现有思维的圈子，对这种开发模式的彻底反思，我们才能找到根治这种疼痛的良方。

 

 

转载自：http://www.cnblogs.com/n216/archive/2010/05/14/1735092.html