前几天Z同学若有所悟地说，原来产品和业务方跟你说的，不一定是他真的需要的，原原本本按他们说的做，很有可能最后并不解决他们的问题。
诚哉此言！和需求方打交道久了，大部分程序员都会有的感慨。然而这并不是他们故意或不用心，因为你描述的，你想要的确实不一定是你需要的。
乔老爷的遗训尤在耳边，“用户根本不懂他们想要什么，除非你秀给他看”。福特也说，“如果问人们想要什么，他们会说要一匹更快的马”。
受限于认知水平和环境约束，当事人往往对于可能的选项没有概念，用美国前国防部长拉姆斯菲尔德的话说，叫着未知的未知。比如，对于福特汽车发明前的年代，大众的字典里根本没有“汽车”这个词，自然打死也想不到，除了骑马还可以开车。
当然，最常见的要属对需求的描述不够本质。人的大脑更拿手具象思维，而不是抽象思维。这在大部分时候是没问题的，比如，口渴了，直接说想喝水，说我想解渴，反而会让人一脸疑惑。这里的关键点在于，是否具备准确描述解决方案的能力。如果很清楚这就是最优或唯一的对策，OK，直接把这个对策当成需求。如果不是很有把握，还是不要冒这个风险，至少可以在提供对策的同时，描述下原始需求或面对的问题，给对方一个考察更优对策的可能。在福特的例子里，可以这么说，我需要一匹快马，或者你有别的更快出行方式，也行。可惜的是，多数“上帝”都是甩手掌柜，并没有为“小二”考虑的意识。那么，小二们，尤其是有了这层认识的小二，比如Z同学，就得学会自己来挖掘，多提问，溯本求源。
程序员的另一大抱怨是，无休止的需求变更。虽为程序员，我想说，这可能是我们所做事情的固有特点。很多时候需求方只能战战兢兢地说，我认为这样能解决问题，实现目标，但没试过之前，我不敢保证实际就是这样。当事人自己的需求尚且如此，更别提广大用户的需求了。需求不是一次性把握住的，需求是逐步接近的，而且很可能是进两步退一步的螺旋式接近的。这是一门实践学科，需要观察，探索和试错。根据反馈及时做出调整是它的固有特点，不应该是负担。当然，没收到反馈就发起的变更，没有验证任何假设，确是要极力避免的。
防止变更成为沉重负担，首先要转变认知，拥抱变化。接着要切割，把大需求切割成小需求，降低每个需求失败的成本。对每个需求使用“PDCA”模型持续改善。用上个需求的检查结果调整下个需求的计划。
目前的普遍毛病是，光有计划-执行，检查和调整做的少，做的不够科学。必须通过测试让数据说话，表明设计的有效性，而不是一直用主观判断来说服人。少了后两个环节，就无法建立闭环，迭代将退化为重复。这是个足够大的话题，可以另开一篇了。
50年代，心理学家马斯洛提出了他的需求层次理论，把人的需求概括为，生理需求，安全需求，社交需求，尊重需求，和自我实现需求。前三者是基本需求，一旦被满足，人们不太会过多考虑，甚至不再意识到它们是种需求，进而当成是理所当然的。尊重需要，包括要求受到别人的尊重和自己内在的自尊心。自我实现需要，指通过努力，实现自己的理想和抱负。它们是近乎无止境的需求，永远无法被真正满足。
如果把马斯洛模型和“想要的，需要的”结合起来看，会发现一个有意思的现象，你最急切想要的反而是你最不需要的。
