先看看什么是需求,人要吃饭,要喝水,要娱乐。同样,软件也是因为人的某种需求而产生的。
再来看看如何表达需求,人如果饿了,就会去做饭。这个过程,是不需要表达的,需求产生动机,动机支配他的手脚,最后需求得到满足。
换一种方式,如果他不想做饭,或不会做饭,他可能会去外面的餐馆。这时候,他的需求是他的协作方来满足的。比如说他来到了一家兰州拉面馆,说“一碗牛肉刀削面”,很少有做兰州拉面不知道“牛肉刀削面”是什么的。这里准确表达依赖于客户方与供应方对概念有一致的理解。也就是说,对“牛肉刀削面”这个概念,客户方和供应方理解是一致的。在软件需求中,对核心概念的理解可能是以术语表来体现的,这是双方达成共识的基础。
继续这个场景,看看还有哪些情况:
1. 要了一碗牛肉刀削面,结果来了一碗牛肉拉面。可能客户普通话不标准,或者场所太嘈杂,服务员没听清楚,导致出现偏差。沟通不畅。
2. 面做好了,来了。一吃,怎么这么淡阿,店家根本不知道客户的口味。需求遗漏。
3. 来,给我加点香菜。来,给我加点蒜。需求变更。
4. 正吃着呢,抬头一看,邻桌有人在吃羊肉串,其实他已经吃饱了,说,给我也来一串。典型的客户心态,别人有的我也要有。Feature envy.
5. 服务员过来,你这面里怎么有虫子阿? 软件有bug,迟迟不付钱,吃霸王餐,很多软件公司就是这么被拖死的。
6. 要了一碗牛肉刀削面,结果来了一碗拉面。结果:“我发现这拉面比刀削面还好吃阿”。用户说出的需求并不是真正的需求。
客户的需求是很难琢磨的,软件不是像刀削面这样,是标准的产品,每一个软件,在未开发完成前,用户是是不知道实际的体验的。不像刀削面,用户早就体验过了。
使用明细的需求规格来定义需求。
“你要拉面还是削面阿?” 削面
“要不要加鸡蛋阿?”不要
“牛肉还是羊肉阿?” 牛肉
“有汤还是没汤阿?” 有汤
“要不要加香菜阿?” 不要
“口味重还是淡阿?” 咸点
“大碗还是小碗阿?” 大碗
“打包还是这里吃阿?” 这里吃
使用严格的需求规格来定义需求,有几个前提:
第一:就是需求调查者/分析师对领域/产品有非常完整的理解,不能遗漏。
第二,对规格的定义无歧义。比如:上面的每一条,双方理解都是一致的,是明确的。
第三,依赖客户对自己的需求有相对比较准确的理解。如果用户从来没吃过什么牛肉面,不知其为何物,他表达的东西不具备准确性。
第四,时间允许,这种描述方式,耗时肯定是相当长的。用这种方式问客户,可能客户早就跑到旁边的那家快餐店去了。
第五, 用户没有体验。在整个调研过程中,用户根本就没尝到过面是什么滋味。
使用迭代和紧密交流获取需求。
第一次来,用户觉得有点淡,下次就加点盐。第二次,用户觉得应该加点醋,下次就加点醋。第三次,店里建议他加个鸡蛋,味道果然不错。
。。。。。。
经过几次迭代以后,用户来到店里,基本上小二已经知道这个客户喜欢吃什么样的面了。这里面有几点:
第一. 用户尽早的获取到了真实的体验,无论是不好吃还是好吃。这也是敏捷软件开发方法所推从的尽早的发布可用的软件。
第二. 用户补充了他想要的需求。在经过体验的基础上,用户表达了他的需求,需求更具备针对性。
第三. 需求是一个交流的过程。完全可以引导用户的需求。
总的来说,软件需求的本质是用户同服务供应者理解一致的过程。 写具的需求规格说明书文档只不过是一个媒介,它并不一定能使双方达成一致的理解。将真实需求转换成语言描述,本来就可能有失真。即使写了文档,也要和最终用户作频繁的沟通,才能确保双方一致理解。要想真正用户满足需求,必须让用户及早参与,多次迭代。
腾讯产品的策略就是“用户体验,快速迭代 ”, 看它现在的发展就知道了,它找到了发展的本质。
PS:很久没写博客了,思路不是很清晰,大家对付看吧,不妨谈谈你对需求本质的理解。