测试某应用程序，有这样一个功能：
创建了一个任务，该任务下面包含了很多子任务，“开始”按钮之后，有一个进度状态监控窗口，该窗口中首先显示了一条不断向前跑的进度条，该进度条上内嵌了相应的完成百分比，在进度条后面，有两项时间相关的数字： 已用时间，剩余时间。
因为该程序是完全为windows平台所做，考虑到windows 界面风格提倡的进度条内不要嵌数字，于是测试人员报了BUG，让开发人员拿掉进度条内的百分比。
下面是双方的对话摘要：
开发： 为什么要拿掉百分比？这个就是为了让用户看的清楚的。
测试：首先windows界面风格不提倡进度条内嵌百分比，其次进度条后面不是还有两项时间相关的数字呢嘛，百分比是画蛇添足。
开发：进度条内的百分比是告诉你任务完成的进度，后面的两项时间数据是告诉你所花时间以及还需时间，这两个是两回事
测试：时间进度不就是我做这个任务的进度吗？
开发：你完全混淆概念了，时间进度是整个时间开销情况，任务进度是所有子任务的进行情况，不一样的概念
测试：但是我从用户的角度，我只关心我做这个任务用了多少时间还需要多少时间啊， 我不关心你做了几个任务或者说某个任务做到了百分之多少
开发：我觉得这个进度条内的百分比对用户是有用的，你完全混淆了时间进度和任务进度的概念
测试：我混淆了吗？
开发：举例来说，你造金字塔，预计100天完成，前99天你什么都不做，但是你的时间进度已经到了99％，而任务进度是0％，最后一天你做完了所有的使，于是你的任务进度从0％变为100％，而时间进度是从99％变为100％， 明白了吧？就是两个概念
测试：好吧，那么首先为什么要给用户这两个概念上的考量数据？不是更让人迷惑吗？ 其次也是最重要的，即使你进度条显示的是任务进度，那和将内嵌百分比数字拿掉也不矛盾啊
双方谁也不能说服对方，这个问题就这么一直悬着呢 （当然这不是一个会影响发布德大的功能或者稳定性方面的问题）
<——————我是分隔线——————>
这是个在现实中应该算常见的实例，开发和测试都一口一声叫着“用户”，似乎他们都是“用户”的化身，研究用户的“专家”。但事实上，并没有多少行为付诸于去验证用户的需求和想法。正如Kent.Zhu在这里所提到的：“这个年代，什么都缺，唯一不缺的就是专家！”我们不需要专家，我们不需要什么UED（EDU或DUE），我们真正需要的是请用户来，泡杯茶，然后听他说说他们到底要的是什么。
其实不想沙发的，你逼的！！！！
如果按照这个开发人员所说的，时间进度和任务进度是不同的，那一个进度条就无法表示出这两种不同的状态。就像金字塔的例子所说的，当时间剩下最后一天的时候，时间进度是99％，任务进度是0％，那进度条到底要显示99％还是0％，这已经矛盾了。
然而，应用程序中的进度可能是根据任务进度而估算时间的，所以两个量应该是一样的。应该说三个量都是一样的，一个进度条，两个数值。但时间那个值应该不是精确的值。
主要是要看这个进度条在程序里是根据什么量来确定进度的。根据任务数量，还是根据每个任务的权重，不同的方法表现出来的结果就不一样。只要计算对了，显示在哪里，要不要显示，就看所谓的需求了。
补充一下，进度条显示的就是百分比，这个百分比的数值不能表示剩余时间，也不能表示已经完成的或者剩余的任务数，它只能表示一个百分比（已用时间和剩余时间的百分比或者已完成任务和剩余任务的百分比）。我上面说的三个量是一样的，指的都是百分比。
如果要具体显示，百分数和进度条是重复的，而剩余任务数和估算的剩余时间是另外的参考，它们都是这个百分数的一个因子。
我同意开发说的百分比和时间不是一个概念，开发已经解释了区别。
我经常用迅雷，其实对于我来说我更关心的是百分比，他下载了多少了，是否已经下载完了，而且很多时候图片进度条很难用肉眼看清楚他是否下完，99.7的时候基本视觉上会误以为下完了。
时间是在当东西下的很慢的时候，或者我要离开关机的时候我才关心的。我真正关心的是这个东西是否能快速下完，如果速度快，我根本就不看时间，我也是以他的进度百分比来大概估计他的时间的，还剩时间不过是直观的把握心里的估算表示出来（目前的进度，大概还要多长时间，具体的都得以下载和加载时的网速为准）
无意中逛到……说两句吧 = =
其实偶觉得，对于进度条来说，直观的感觉是对当前执行的任务进度的反馈，所以应该是例子中的“金字塔造了多少层了”，这是首页需求。
然后偶大概还有多少时间能完成呢？就是预计剩余时间的显示，这是次要需求。至于已经用了多久了，要看需求了，普通任务的进度条不显示也罢。
然后，关于进度条，有一点个人认为比较关键，就是要让我感觉到它在动，只要程序真的在执行那么条就应该“动”，不是时间在动而已进度在动，尽管它可能真的没动，但要给我“任务还在进行、正在进行”的信心。
我倒是想知道windows界面风格为什么提倡进度条内不要嵌数字，到处找，没找到。。。
用户，呵呵~
我想知道这玩意一般执行任务需要多长时间？如果和前面楼上说的迅雷下载一样，时间由种子质量决定，那还是加上百分比吧。
“我们不需要什么UED”
这句话经典，其实我觉得应该根据这个产品的主要用户群体和用户使用习惯来去解决这个问题，假如是专业性比较高的的产品，使用者有较高的文化水平，有这个数字会比较好，这样会比较理性，感觉一切都是可控的。但如果是大众化的产品，那则应该考虑简化，减少容易令用户造成困扰的因素。
我感觉正是由于没有UED他们才会为这事争论。
“我们不需要什么UED”
难道请用户来访谈不是UED的方法么？
这么说吧，UED这玩意现在就连程序员也多多少少都懂点，但是能做好的人，能做系统的人不多，作者或许没有见过这样的人。
会画画的人太多了，但是大师没有天赋是不能称之为大师的。
我们公司的软件部门有个所谓的需求分析组，UED的方法用的溜溜的，形式做的美美的，但是做出来的东西简直不能看。
不是方法的问题，是人的问题。
在这个专家遍地的时代，真正的专家常有，但是真正的伯乐不常有。
太多无休止的争论源于：争论的各方都认为自己就是用户，自己能代表用户的立场。
解决方法很简单，一旦出现这种多次讨论未果的苗头，立马整理测试要点，做用户测试。只要用户测试有结果了，各方很容易达成一致。
其实把自己想象成一个用户很容易也很难
这么简单的道理，用户并不在乎你（系统）到底完成了多少任务多少线程，他唯一关心的只是大概还需要多少时间才能得到他想要得结果，所以精准的时间同步才是进度条最需要准确把握的关键。只是现在做不到而已，用户最讨厌的进度条是什么？明明还有很多时间却已经显示99%快要结束的样子，或者还有很多没有完成却在1秒钟之内刷的结束了的进度条，那等于没有…这个需要做用户访谈才能了解到么？触手可得的commen sense. 如果开发人员对于这点也要challenge,那只能说明UED人员太弱势，犯了太多错误而得不到信任。这时候可以求助项目经理，如果还是不行，那只有让用户说话了。
撇开这个具体的问题，其实这篇日志另外的意思是我们需要了解用户的真实需求或者被隐藏起来的需求本质。换句话就是不要仅仅理解“用户只想要一匹跑的更快的马”，而是需要从根本上去解决他的需求问题。回到具体的进度条问题，有些问题确实是commen sense，但是不是有比进度条更好的告诉用户程序进度的方式呢？这个才是需要从了解用户的角度去做的。
不同用户关注点不同，冗余显示只要没有歧义，标示清楚，总是好的。