前几天Z同学若有所悟地说,原来产品和业务方跟你说的,不一定是他真的需要的,原原本本按他们说的做,很有可能最后并不解决他们的问题。

诚哉此言!和需求方打交道久了,大部分程序员都会有的感慨。然而这并不是他们故意或不用心,因为你描述的,你想要的确实不一定是你需要的。

乔老爷的遗训尤在耳边,“用户根本不懂他们想要什么,除非你秀给他看”。福特也说,“如果问人们想要什么,他们会说要一匹更快的马”。

受限于认知水平和环境约束,当事人往往对于可能的选项没有概念,用美国前国防部长拉姆斯菲尔德的话说,叫着未知的未知。比如,对于福特汽车发明前的年代,大众的字典里根本没有“汽车”这个词,自然打死也想不到,除了骑马还可以开车。

当然,最常见的要属对需求的描述不够本质。人的大脑更拿手具象思维,而不是抽象思维。这在大部分时候是没问题的,比如,口渴了,直接说想喝水,说我想解渴,反而会让人一脸疑惑。这里的关键点在于,是否具备准确描述解决方案的能力。如果很清楚这就是最优或唯一的对策,OK,直接把这个对策当成需求。如果不是很有把握,还是不要冒这个风险,至少可以在提供对策的同时,描述下原始需求或面对的问题,给对方一个考察更优对策的可能。在福特的例子里,可以这么说,我需要一匹快马,或者你有别的更快出行方式,也行。可惜的是,多数“上帝”都是甩手掌柜,并没有为“小二”考虑的意识。那么,小二们,尤其是有了这层认识的小二,比如Z同学,就得学会自己来挖掘,多提问,溯本求源。

程序员的另一大抱怨是,无休止的需求变更。虽为程序员,我想说,这可能是我们所做事情的固有特点。很多时候需求方只能战战兢兢地说,我认为这样能解决问题,实现目标,但没试过之前,我不敢保证实际就是这样。当事人自己的需求尚且如此,更别提广大用户的需求了。需求不是一次性把握住的,需求是逐步接近的,而且很可能是进两步退一步的螺旋式接近的。这是一门实践学科,需要观察,探索和试错。根据反馈及时做出调整是它的固有特点,不应该是负担。当然,没收到反馈就发起的变更,没有验证任何假设,确是要极力避免的。

防止变更成为沉重负担,首先要转变认知,拥抱变化。接着要切割,把大需求切割成小需求,降低每个需求失败的成本。对每个需求使用“PDCA”模型持续改善。用上个需求的检查结果调整下个需求的计划。

目前的普遍毛病是,光有计划-执行,检查和调整做的少,做的不够科学。必须通过测试让数据说话,表明设计的有效性,而不是一直用主观判断来说服人。少了后两个环节,就无法建立闭环,迭代将退化为重复。这是个足够大的话题,可以另开一篇了。

50年代,心理学家马斯洛提出了他的需求层次理论,把人的需求概括为,生理需求,安全需求,社交需求,尊重需求,和自我实现需求。前三者是基本需求,一旦被满足,人们不太会过多考虑,甚至不再意识到它们是种需求,进而当成是理所当然的。尊重需要,包括要求受到别人的尊重和自己内在的自尊心。自我实现需要,指通过努力,实现自己的理想和抱负。它们是近乎无止境的需求,永远无法被真正满足。

如果把马斯洛模型和“想要的,需要的”结合起来看,会发现一个有意思的现象,你最急切想要的反而是你最不需要的。