论调研需求时观摩用户实际工作流程重要性

来源：互联网发布：高端黑知乎编辑：程序博客网时间：2024/04/19 14:31

背景

昨天开会BOSS说调研讨论：弹性需求，利益最大化，今天上午需求调研结束后，我想试试昨天的理论，请求观摩对方使用XXX程序的人的操作流程，目的很简单：

是为了站在用户的角度思考问题，因为开发的角度会固化自己的思维，就像重构的时候发现自己之前的这段代码写的很差，但是当初写的时候就是没有感觉没有意识到；
是看能否挖掘更多需求，是用户没有想到的需求.

但是发现收获的远远不止这些：

结果

1.提供思路：

描述：基于要求你开发的功能，可以参考对方之前的做法，虽然做法不一定是最优最好，但毕竟是一条可以行得通的路子，举个今天的例子来说：

例子：判断某一个XXX
用户提出了这个需求，那回来以后肯定是要完成，但是最终发现XX并没有提供相应的方法，那如果说用户必须有这个功能，那我们肯定需要想法解决，当看到实际操作时询问后得知之前的做法是给XX，有一个属性没有值就是XX，有值就不是XX。

2.提供更多功能：

描述：有些功能可以想象的到用户是以后肯定需要的，但是现在没有提出来，像这样的功能，简单的可以顺手就做了，复杂点的呢，在闲暇时候就给做了，这样下次讨论的时候会让用户省心，让我们处于主动的地位。举今天两个例子来说：

例子1：打开数据库中的XX
当看到用户操作时直接打开数据库中的XX
例子2：设备拷贝功能
用户操作的时候习惯选中XX，按ctrl拖的方式复制一个该XX，拷贝的XXName属性为空，其他属性与源XX属性相同。

3.挖掘功能：

描述：有些细节，用户没有想到，但是你在观察用户操作的时候会发现有些是用户已经习惯的，举个今天的例子来说：

例子：今天用户提出XX高亮的需求，但是并没有指明说高亮的颜色是什么，但观察及询问的时候才知道，用户已经习惯若XX的XX端点处为红色，XX接则是绿色。

4.弹性功能：

描述：有些功能，用户A提出来了，但是A并非是真正使用该程序的人员，那需求必然会和实际出入，就像玩传话的游戏一样，A用户提出的功能是否是必须的呢，是否是真正使用该程序的人员所想要的呢，依据今天调研结果来看，这真的是有出入，造成的结果是有些功能你浪费时间和精力去开发，结果并不是人家真正想要的，那这个责任该怪谁呢，你能怪你的上帝用户吗，且加大你的工作量，不能让你的利益最大化，很被动的接受，所以弹性分析需求是很有必要的，举个今天的例子来说：

例子：用户A和我提出框选某一区域XX，可以罗列出该区域不同类型XX的共同属性，通过修改来达到批量修改的效果，但是当你问真正操作的人员这个功能时，得到的回答是不需要，没必要，因为我问完后也询问了使用该程序的人员有哪些类型，得到的是真正使用者代表的意见。

5.发现问题：

描述：这里指的是发现用户问题，有些需求用户提出来了，但是用户并没有完全告诉你，导致有些事情会让开发者自以为是xxx,或者说用户没有提供相应的数据，这个让人很恼火唉，举个今天的例子：

例子：今天之前已经调研三次了，涉及到XX的保存，我一直以为XX就是XXX提供的XX，当演示的时候我拉出XX，对方也无说明，但是看实际操作，我才知道原来XX是他们自己定义的XX，且之前提供的文件并没有提供该XX。

6.让自己更有信心：

描述：有些功能用户提出来的时候，你会有思路，但是并不可能现场完成来验证，但是如果你得知了对方之前的做法，和你的想法不谋而合，那让你心里有数，更有信心，举个今天的例子说：

例子：如何打开已保存在数据库中的XX，在用户提出这个功能后我的想法是先缓存到本地，然后打开，因为我没有试过将二进制数据在内存中转为特定格式文件，当看到实际操作时询问知道之前的做法也是缓存本地文件的做法，这样的好处在于验证了自己的想法是正确的，让自己更有信心。

7.其他：

描述：用过上面的分析和挖掘，感觉自己的身份并非只是个开发者，是对方的一员，知道了这个程序想要的最终版本是什么样子，心里也能预估到项目的进展，大概多长时间后该程序就可以让用户使用起来。

感慨：
从4月份5月份开始到现在11月了，按每两周调研一次的频率算，我也去的不少了，现在才感觉入门怎么去调研—2015-11-06

0 0