软件需求的本质

    先看看什么是需求，人要吃饭，要喝水，要娱乐。同样，软件也是因为人的某种需求而产生的。

 

    再来看看如何表达需求，人如果饿了，就会去做饭。这个过程，是不需要表达的，需求产生动机，动机支配他的手脚，最后需求得到满足。

 

    换一种方式，如果他不想做饭，或不会做饭，他可能会去外面的餐馆。这时候，他的需求是他的协作方来满足的。比如说他来到了一家兰州拉面馆，说“一碗牛肉刀削面”，很少有做兰州拉面不知道“牛肉刀削面”是什么的。这里准确表达依赖于客户方与供应方对概念有一致的理解。也就是说，对“牛肉刀削面”这个概念，客户方和供应方理解是一致的。在软件需求中，对核心概念的理解可能是以术语表来体现的，这是双方达成共识的基础。

 

   继续这个场景，看看还有哪些情况：

   1. 要了一碗牛肉刀削面，结果来了一碗牛肉拉面。可能客户普通话不标准，或者场所太嘈杂，服务员没听清楚，导致出现偏差。沟通不畅。

   2. 面做好了，来了。一吃，怎么这么淡阿，店家根本不知道客户的口味。需求遗漏。

   3. 来，给我加点香菜。来，给我加点蒜。需求变更。

   4. 正吃着呢，抬头一看，邻桌有人在吃羊肉串，其实他已经吃饱了，说，给我也来一串。典型的客户心态，别人有的我也要有。Feature envy.

   5. 服务员过来，你这面里怎么有虫子阿？ 软件有bug，迟迟不付钱，吃霸王餐，很多软件公司就是这么被拖死的。

   6. 要了一碗牛肉刀削面，结果来了一碗拉面。结果：“我发现这拉面比刀削面还好吃阿”。用户说出的需求并不是真正的需求。

 

   客户的需求是很难琢磨的，软件不是像刀削面这样，是标准的产品，每一个软件，在未开发完成前，用户是是不知道实际的体验的。不像刀削面，用户早就体验过了。

 

   使用明细的需求规格来定义需求。

 

   “你要拉面还是削面阿？” 削面

   “要不要加鸡蛋阿？”不要

   “牛肉还是羊肉阿？” 牛肉

   “有汤还是没汤阿？” 有汤

   “要不要加香菜阿？” 不要

   “口味重还是淡阿？” 咸点

  “大碗还是小碗阿？” 大碗

  “打包还是这里吃阿？” 这里吃

 

  使用严格的需求规格来定义需求，有几个前提：

第一：就是需求调查者／分析师对领域／产品有非常完整的理解，不能遗漏。

第二，对规格的定义无歧义。比如：上面的每一条，双方理解都是一致的,是明确的。

第三，依赖客户对自己的需求有相对比较准确的理解。如果用户从来没吃过什么牛肉面，不知其为何物，他表达的东西不具备准确性。

第四，时间允许，这种描述方式，耗时肯定是相当长的。用这种方式问客户，可能客户早就跑到旁边的那家快餐店去了。

第五, 用户没有体验。在整个调研过程中，用户根本就没尝到过面是什么滋味。

 

   使用迭代和紧密交流获取需求。

   第一次来，用户觉得有点淡，下次就加点盐。第二次，用户觉得应该加点醋，下次就加点醋。第三次，店里建议他加个鸡蛋，味道果然不错。

   。。。。。。

 

   经过几次迭代以后，用户来到店里，基本上小二已经知道这个客户喜欢吃什么样的面了。这里面有几点：

   第一. 用户尽早的获取到了真实的体验，无论是不好吃还是好吃。这也是敏捷软件开发方法所推从的尽早的发布可用的软件。

   第二. 用户补充了他想要的需求。在经过体验的基础上，用户表达了他的需求，需求更具备针对性。

   第三. 需求是一个交流的过程。完全可以引导用户的需求。

 

   总的来说，软件需求的本质是用户同服务供应者理解一致的过程。 写具的需求规格说明书文档只不过是一个媒介，它并不一定能使双方达成一致的理解。将真实需求转换成语言描述，本来就可能有失真。即使写了文档，也要和最终用户作频繁的沟通，才能确保双方一致理解。要想真正用户满足需求，必须让用户及早参与，多次迭代。

 

   腾讯产品的策略就是“用户体验，快速迭代 ”， 看它现在的发展就知道了，它找到了发展的本质。

 

   PS：很久没写博客了，思路不是很清晰，大家对付看吧，不妨谈谈你对需求本质的理解。