从应用环境中提取需求过程解密

       一直开发检查站android的远程检测系统，这个系统的需求不复杂却比较新鲜，系统主要是提供给我们平时不太熟悉的汽车检查站使用，做完了最基本的原型之后，上周放假前，在米老师的带领下，我们实际考察了检查站的总体操作流程。

         从软件制作角度考虑，考察过程中得到这样几个信号：

         软件展示界面一定要简单化：

        之所以这样说是因为平时我们一起沟通的大多都是内行人士，就比如说一个“什么东西可以唯一标识这一辆车”，甚至更简单一点说“用界面上的什么可以找到这一辆车”，这样的语言，业内人士就算不太懂软件的话也明白想要表达什么。但是对于检查站工作人员就不一样了，他们知道的是自己操作的原来的系统上面，点击哪个可以显示什么。这些东西感觉就是他们入职时候一些简单的培训了解的最基本的操作，至于让他去解释更详细的信息，最多他们能解释的就是通过自己的工作经验来告诉我们哪里还可以确定这个车的一些与其他车辆有别的地方。而对于其他不变化的信息或者说很少用到的信息，他们基本无法解释这是什么，所以相互之间更不能去探讨哪里能够进行简化和变化了。

        通过这样的沟通，我们不难想象到我们的用户对于软件的了解和使用水平，所以这就告诉我们，界面设计一定要能简化则简化，尽量让用户操作最少的数据而获得最大的信息。同时有任何一点歧义的地方一定要有提示功能，估计这是一个不错的软件特点之一。

        沟通方式最好用产品说明：

        鉴于以上介绍，可能用户的需求我们懂得如何在程序中实现，但是用户不明白我们想要提取什么信息。用户模糊的地方就可以直接给我们说“你们把***任务给我完成就好了”，“我也不懂具体怎么说”，“要不然你们自己去看就好了”。但是对于我们有实现上不太方便或者具体设计和用户需求不一定完全吻合的情况，我们却无法表达，因为我们要表达的他们一定是不懂的专业术语，鉴于此，我认为还是用产品向用户说明最有效了，只要用户用起来没有不方便的那就说明符合他们的方式，在这之前最好按照设计人员的理解去做。语言在这个过程中显得苍白无力。

        从用户的感受提取需求:

        通过现场考察和沟通，发现验车现场很多人在等待，据知情人士爆料，这些人在整个检查过程中就一直在等，不是说自己开车被检查完后可以直接领取结果，这个过程是等待检查站的工作人员对检查信息进行处理，换句话说，检查站的操作效率决定了用户的办事效率，而且是很多的用户。所以通过现场考察我们完全可以知道检查站最需要的是什么，最需要改进的是什么。他们急需把中间的每一个过程简化成自动化的，节省时间。

         同时跟检查站的老技术人员进行交流发现，他们对新技术是不认可的，他们宁可用一些纸质的材料也不愿意用一些电子产品。这正好告诉我们一个信号，新技术给他们带来的弊端和损失很大，让他们无法信任新的技术和新的产品。同时也说明他们急需一个安全可靠的产品来保障自己的工作。所以我们应该把我们的产品的重点放在可靠性上。

        当然了，从现场提取需求的信号还有很多，日后一一分享！