随便说说

    什么是需求，这个需求是根据什么来制订的？需求的内容是否就是完整的需求者所需的一切描述？很多时候，软件需求者自己都弄不清楚自己究竟需要一个什么样的软件。
    以游戏为例，从很抽象的概念来说，游戏玩家需要的是一个好玩的，能够打发时间的，可以从中得到乐趣的游戏，而游戏玩家往往只是有这样一个模糊的概念，具体如果细化，需要一个什么类的游戏，需要的游戏是什么样子的，需要的游戏有哪些功能，需要的游戏有什么具体的内容，需要的游戏有什么具体情节等等。
    从这里我们会惊讶地发现一个有趣的事实：游戏的乐趣有一部分来源于游戏需求者对游戏的大量部分的未知度，如果游戏有足够让游戏需求者未知的特性，能够激发游戏者的兴趣，从而更有乐趣地在游戏上花费时间。当需求者不知道一些细节时，反而会促使需求者对该游戏的评价上升。
    这个事实说明一个问题：软件的需求者，未必要对软件本身了如指掌。在某些情况上，用户的一些需求的完成需要通过用户对需求的模糊性定义。这是一个看起来自身矛盾的概念，实际上，在平时的软件工作时，经常会有公司发布的产品或开发项目中，提供一些新特性，从而吸引用户，从而增加用户的满意感。
    还有一些时候，甚至一些软件创造者自己都难以预料的结果或是设计上带来的未知结果，也能给用户更有趣的体验。仍以游戏为例，不少打斗性质游戏中，提供了自定义连招系统或是技能组合面板，使得不同搭配会有不同的效果，个性化的搭配可以配合出更有效率的或是更没有效率的招式组合。这就是一种典型的连开发者或设计者都难以预计最后会形成什么样有特色的组合，而这种更好的体验就来源于没有人能够完全掌握的前提之下的。
    这些设计，都来源于用户的最高需求宗旨：可玩性。而这样的需求可以说是模糊之极，这样的好处是设计与开发在有了足够大的发挥空间，但坏处就是要承担更大的用户不满意结果的风险。
    游戏是一个相对特殊的软件体系，那么在一般的项目或产品中，有类似的体现没有？当然有，比如在类似于销售管理系统中，不同的人对快捷键的需求是不一样的，举个小例子是，在输入单据时，有一些人乐意用TAB键来控件间跳跃，有一些人乐意直接用Enter键在控件间跳跃，还有一些人可能会喜欢一些更古怪的方式来控制。为了足够的灵活性，一些软件中，会提供快捷键设置的功能，这样的功能虽然不一定会人人用得上，但是这样的功能大大地适应了更多的用户习惯。
    现在有一个具体的问题：用户是否有这些灵活性的需求，如果是真实的开发中，我们是否值得花费时间去设计这样一个功能。这是一个令人有点头痛的问题，如果一个一个去问用户的快捷键设置的话，对方未必有这样的耐心，如果不这样去弄的话，最后设计出来的软件，可能会因为不符合用户的需要而重新修改而投入更多的时间。
    极端的办法是采用反复合订文件的手法，从软件的界面到软件的功能，全部都从用户那里进行需求获取，要求签定文件，哪怕是修改任何一个微小的软件功能，也要求签订正式文件，这样可以有效地逃避最后的交付时用户的不满，同时还有一个好处是会让用户觉得麻烦，而让你少改许多功能。但这种办法的副作用是会增加用户对软件系统的厌恶度，在签订文件的反复的折磨之中，同样会疲惫不堪，浪费的时间一样多，唯一不同的是，这可以把用户一起拖下水，共同享受折磨的乐趣。
    办法如果不想那么极端，打算少签订一些文件的话，就必须要有承担更多风险的心理准备，有时候，完成一个主要的功能并不复杂，但是在细节上用户的反覆无常是最可怕的，不改不能体现好的服务，改了也只是浪费时间，有时候，未必要对用户提供什么更好的服务，考虑利用培训的方法强行扭转用户习惯，并对某些功能的不修改寻找一些听起来不牵强而又似乎有点道理的办法是很有效的。举个例子来说，如果打算强行扭转用户习惯时，必须要找到一把手或是对方项目的负责者，告诉对统一操作的习惯，是效率性管理的有效体现，而且可以避免许多潜在隐患，比如某个人习惯的快捷键是添加，而另一个人相同的键却是删除或修改的时候，一不小心就会导致数据出错。如果对方说这个地方可以设置提醒呀，你可以说，这样会影响工作效率，然后可以忽悠说这是根据你们的多年经验而得出的结论等云云。
    由于很多时候，在现实中我们就会发现软件的需求制订，实际上不可能精细到用户满意的，如果用户能够提供一个完全令他自己满意而又详细得可怕的设计方案，这样的项目还是不接为好，因为这是基本上神话，其最终风险未必是你能承担的了的。
    有人认为，这个有什么，需求是对方提出来的，那么照做了收钱就是。这样的想法是最幼稚的，因为软件开发只是做项目中一个小小的必要环节而已。最关键的环节还是在于对方的付款，只要对方肯付款，又不会散播谣言的前提下，项目完没完成，软件能不能用，这些对于公司来说都不是问题，公司关注的目标只有收益，而公司的名声，只是为了扩大收益才需要的罢了。
   
    软件的满意度，一般来说，光是严格按照用户需求文档上确认的来做，不加入任何其它功能，是不可能让客户满意的。只有你加入了需求文件中没有严格指出的但又必需的功能，并形成一个列表完整展示给客户，即便是一个仅仅完成了基本上的功能运作而没有什么特色的系统，客户在得知“你为他加入了许多功能”，这也可以极大提高意度。
    大街上买东西时，经常会遇到类似的情况，大家可以回想一下，比如买个什么小玩意，一问价 格回答20块，再问能不少点，对方就来一句，这个不好少，唉，算了，你的话，18块给你吧。其实在此之前，你跟这个小贩根本就不认识，对方这样说，你一听 就知道很假，但是另一方面从心理上来说，有一种对方对你较特别的感觉。
    所以，有一个技巧是，不要告诉客户这是什么赠送的功能，由于赠送的功能人人都有，不搞特殊化，客户会认为那是他应当得到的，你已经算入款项了。而应该与客户假意熟悉一些后，大拍胸脯告诉客户某个什么功能可以单独为他开发，不增收费用，顺便还可以说如果是其它公司，一定会增收款项等云云，然后为功能加上些好听的名字，比如仅仅只是支持一个smtp发送就可以说是提供了邮件服务系统......具体可以自行发挥。
    这种技巧几乎没有副作用，即使客户知道你是睁着眼睛说瞎话，也能够“理解与支持”你，因为话听起来好听嘛。其实技巧的核心就是一个“他”字，让对方有一种你是围着他转的感觉，即使是要求加钱，也是“实在没有办法才要求加的”，只要能培养客户的这种错觉，事情就好办。