上帝的需求是什么？--谈软件的需求设计

前段时间到沃尔玛买冰箱，去的时候就已经打算好了要买海尔的，价位定在了1500元左右，感觉已经很不错了。到那里以后，经过比较，看中了一款2200多的，功能多，性能好，看得眼馋，同时又看到了其它品牌也有几款很不错的，价格也不算很高，功能比海尔的这款还要多，相比似互更划算，有点作难，但是后来还是选择了海尔的这一款，为什么?理由如下：

一是：这是我能接受的范围；

二是：海尔的产品质量可靠；

三是：功能多，性能好；

四是：海尔的售后服务好，一旦出现故障能得到及时的维护；

五是：海尔的信誉好，买了放心。

其实，我想这四条中，起到关键作用的还是第一条，第二条和第五条。比如：TCL的，功能其实也很多，但是我就不买它的，为什么？二哥的朋友结婚时买了个TCL的彩电，不到一周就出问题了，到商家换了一台后，不到一个月就又抱回去维修了，结果等了一周时间也没修好。这件事情对我的印象很深刻，后来不但我们家没买过TCL的产品，我们的很多亲朋好友也失去了对TCL其它产品的兴趣。我不知道朋友的朋友知道这件事情后会怎样，也不知道朋友的朋友的朋友或是朋友的朋友的朋友的朋友怎样，但是我却知道，TCL失去了一个比较大的原本属于它的客户群。

其实钱付了以后，心里并不像原先那样的平静，毕竟2000多，这不是一个小数目，后来等到送货上门，用了一段时间后感觉还可以，就慢慢放下心来。突然，前两天接到了奥尔玛商场的电话，询问商场送货员送货的服务态度以及冰箱的使用情况，并一再叮嘱如出现问题一定及时告知，技术员将会尽快上门维修。电话放下后，留下的不仅仅是感动和欣慰。后来碰到熟识的朋友，我不断的提到这件事，他们也深表认同，他们给我说的一句话，让我尤为惊讶：以后再买家电，我们也买海尔的，再贵也无所谓。我突然从中悟到：产品的销售其实并不是一场简单的交易，它还有巨大的宣传作用，而且这个宣传是免费的但又是最令他人接受和信服的。


我想海尔的成功也就是在于它把握住了客户们的需求，不光是物质的，最主要的还是心理上的！
    回想我们搞软件开发的，有几个项目是经过认真调研的？我们在开发过程中是否同用户进行过密切的交流？换句话说，我们是否真的知道我们的客户最终的需求是什么？客户是我们的上帝，我们是否了解他，了解他们的需求？开发初期，我们是否尊重过他们的意见？是否和他们进行过认真详细的沟通？下面仅软件行业的需求分析同大家做一番探讨。

不知道其它公司是怎样处理的，但我所经历的几家公司却惊人的相识：需求是凭以前的业务人员的经验制定的，没有同客户进行开发前的交流，开发过程中，随意性很大，跟着感觉走的次数非常之多，不断地临时更改一些需求，据说是为了某些客户可能的需要。这些缺点不再说了，笔者的另一篇随笔已经写的比较详细了。所谓幸福的家庭都相差无几，不幸的家庭却有着各自的不幸，然而这个却是不幸的项目也有着相同的不幸！

然而，好的也不是没有,一个朋友自己搞的一个项目，只有两个人，其中一个就是专门为了了解客户的需求，然后依据自己在本行业的经验，详细制定出一份需求，同时根据需求制定出一份功能需求说明书，同客户继续沟通，当客户提出一些变更后再重新设计重新交流，然后由这个朋友根据这份功能需求说明书进行开发。据说，他们这套软件已经卖了好几套，客户都是赞不绝口，偶尔一些小的需求，只需要作很小的变动。朋友说，三年了，这套软件还是非常的时髦，数据结构还是以前的结构，几乎没有改动过。

那么我们能不能从中借鉴一些经验呢？开发初期，我们最好让客户介入到我们的需求分析中来，认真听取客户的意见，在这一方面不要同客户有争执，当然了也可以提建议。我们要把客户当作业务方面的专家，我们就是小学生，要向专家们学习业务知识。客户既然是我们的上帝，如果我们在开发前期不尊重上帝，那么开发后期就会受到上帝的惩罚！

下面总结一下自己的看法：

1．  总结公司以前相同软件的得失；根据以前的经验制定出一套自己的需求说明

2．  根据这套需求展开讨论，分析不足之处以及较好的地方，重新设计

3．  客户介入，请客户提建议，以及客户的要求和可能的需求

4．  如果客户没有问题就执行下一步，否则回到2

5．  根据需求说明制定出一套功能要求说明书，一定要详细

6．  客户介入，听取客户的意见，重新探讨，重新更改功能要求说明书

7．  美工介入，根据制定出的功能要求说明书，迅速画出一套相应的图形界面，注意是画而不是做

8．  客户介入，根据这套画面重新进行功能需求讨论

9．  如果没问题执行下一步，有问题回到6

10．              根据画面设计表结构，不求最灵活，但求实现完整的功能

11．              客户介入，根据制定的表结构，向客户描述能实现的功能，请用户提建议

12．              如果没问题执行下一步，有问题回到8

13．              根据制定的表结构和美工作的画面设计功能函数，同时美工开始真正作业

14．              分配工作任务，开始施工。

注意：

1．  当客户介入时一定要求客户签名留档，提示客户如有其它重大改动，其要负重大责任，这是为了避免某些客户敷衍应付之举，因为我们的项目一旦实施，用户的需求更改会很大的影响我们的项目进度。

2．  在功能设计上尽可能做到灵活，意思是：我们可以根据我们的需要随意去掉某些功能，这样我们面对不同的客户将有更多的选择。就好比冰箱，客户的价钱不同享受到的功能也应有所不同。

3．  文档一定要详细，并且保证与项目同步更新。

4．  要有规范的项目开发规范，确保大家遵守。

5．  项目经理要随时了解项目的进度，以便及时处理一些异常情况（算了，这些还是留待下一篇文章再说吧）。



当然了，对于一个项目的需求设计我想也就是这样了，以后想到再进行更改吧，但总之，我们的目的就是要了解用户的真正需求，只有这样我们才能得到上帝的称赞，否则，上帝的惩罚将是非常的严重！

楼上的仁兄，说得不错，客户就是我们的上帝.
但是我觉得你的那种方式并不适合所有的项目
客户需求固然重要,但是不同的软件种类,它的地位就不一样.在一个比较大的软件项目里,用户的需求就会有众口难调的问题.你虽然认真耐心的做客户需求,但是客户有时候对软件的概念还很模糊,他只能从数据和界面上提供需求,而对于软件的骨架,他们的需求往往提供不了帮助,
在这里就像你买海尔一样,首先有个品牌效应,然后再去做细致的工作.可能更省力一些.在软件里边的品牌效应不一定像买电器,其实首先应该给他们灌输一些软件的思路,这会给你以后的需求调研带来很大帮助,这样的软件才能比较成熟,就像sap一样,人家给你提供的不仅仅是一套软件,而是建立在软件上的先进的管理思想,使得客户不服都不行,其实我觉得我们做软件项目也是要朝着这个方向来做

同一楼上的。楼主的方法并不适用于所有的情况。

例如敏捷需求分析，最重要的是相应变化。所以，一切需求并不是一开始就搞得很详细，将详细的需求分析推迟到开发这个需求的迭代前夕来完成。一旦客户有更改的要求，可以避免因为提前作了大量工作带来的浪费。而且敏捷需求分析主要是把握软件的商业价值，找到某个功能背后的商业目的，从而选择更低廉或更合适的方式来完成此功能。

质量和价值是敏捷开发的目标。就像楼主说的，造出高质量的冰箱，哪怕比别人的贵，也会有人欣赏，而且会因此得到口碑。实现高价值和高质量的一个方式，就是按照需求的商业价值优先级来安排开发。保证用户每次迭代得到的都是最有价值的那部分。

敏捷方法也不是什么场合都适用。最适用的情形莫过于互联网项目开发。大家都要抢占市场，快鱼吃慢鱼，这时候，需求可能还不是很明确，谁的软件快，谁的软件好，就成了成功的主导因素。

互联网项目开发怎么就不能用敏捷开发叻？要看你怎么用。。。能说说具体原因吗？对这个狠感兴趣。

同学，请看清楚俺写的。。。是最适用

这是个人看法。因为互联网项目的特性（快速，需求变化，交付有价值的部分）正好是敏捷开发所提倡的。据说，产生于2000年前后的敏捷开发，也是在互联网第一次热潮的时候磨炼过的那批人。敏捷确实适合于类似的商业项目。对政府项目之类的嘛，还有待俺亲自实践才知道。不过据我的经验，政府的一些人对于每2周能够看到项目的进展很兴奋，在同时其他公司非敏捷的项目对比下，敏捷就显得很出众

sorry...sorry...看走眼叻。。。。

其实，我倒感觉，越是比较大的软件项目，客户越多，我们越应该详细的做调研，诚然众口难调，但一般的行业性软件业都有自己的行规，偏差的只是客户自己的习惯而已，如果我们的需求做的到位的话，我们的系统才能更灵活。
这一点，我不同意冰云的看法，我认为专业是灵活的灵魂。敏捷开发它也是有针对性的，它并不是说一开始不需要搞很详细的需求分析，只是说在没有完全明确客户的某些需求时，不应该浪费太多时间继续做调研。如果你对某一行业根本就不是非常的清楚，单纯的依赖用户的需求变化来进行迭代，小项目尤可，大项目累也要累个半死。所以我认为，敏捷是基于对客户需求达到专业化后的一种思想沉淀。
客户是对软件不了解，有时他们对自己需要什么东西都不了解，这就需要我们引导他们明确自己想要的东西，就像冰箱，他们知道天热食品容易发嗅变质，但是他们并不需要去向厂家订制自己需要的冰箱的模式，如果让一个从没接触过冰箱的人凭空想象，它也很难想象出如今多种多样的冰箱。这时候，我们做的就是按照我们的设计画出一个样图，告诉用户形状，让他来感觉使用时的情况，我们不可能先造出一台冰箱让用户来真正体验，然后再根据用户的需求来对这个冰箱进行改造！这样用户就会有一中感性的意识，来修正我们的做法，当然我们不会仅根据一个客户的意见就修改我们全盘的方案，但是客户的意见还是很有必要参考的。我们要根据众多用户的意见制定出适合大众习性的冰箱，如果某些客户实在难伺候，那我们给他定做，当然这个收费就不一样了，我们要给用户适当的选择，不要根据用户的选择改变我们自己产品的构造！当然前提就是，你的东西必须要达到专业，不过这还是通过认真详细的调研获得的！

敏捷方法不是像你说的这样形式化的，那个用造冰箱类比制作软件的例子也感觉不太恰当，我们恰恰就是先造出来让客户看了再改进的。事实上，我自己都还不能完全说清楚敏捷方法到底是什么样子。我在 ThoughtWorks 经历了两个项目了，无论是需求分析项目管理还是开发过程，每个项目都有自己不同的做法。我只是根据自己的经验来说明，在某些特定场合的特定敏捷过程。想要让敏捷适用于各种不同的项目，就需要根据该项目的实际情况制定特殊的办法。而不是定制一系列最佳实践去遵循就一定能够成功的。

如果市场还是产品驱动的,敏捷就不是很适合,在这种卖方市场,产品提供者只需要定位好客户群,然后抽样做有效的业务用例分析,接着产品实现就好了,顶多做一下概念验证来和用户交互,其它的事情由市场推广来搞定.
这样减少了和用户交互的成本啊,因为有时候和用户交互的成本比较高,第一如果要得到有效的样本的话,需要很多人,第二,可能单纯一两个客户也不能代表整个目标市场的需求.

其实我自己也知道，这个例子不太合适，有点极端化了。如果我们不熟悉业务，并不是不能做软件，但肯定做不出优秀的软件。我认为迭代只是优化设计的一种方式，而不应该在项目开发之初就把它作为一种导向。如果我们能够精通业务，熟悉客户的种种需求，即使我们没有做出某些满足某些用户的功能，但最起码能够适应用户需求在某一程度上的改变，况且一旦软件真的被用户使用起来后，真正的改变是很少的，也许敏捷设计就是为了避免过度设计，但是灵活并不是过度，软件上功能的灵活不但能够适应更多的客户，同时也能给用户带来意外的惊喜，也许有些功能他可能以后永远都不会用，但当他知道同类价格下，你的软件没有而其他人的有，我想他选择你的可能性很小，除非另有其他的原因！