日志
再谈Want和Need
||
前面我们讲了如何去“理解需求”，但需要谨记的是，由于每个人并不能代表所有用户，在需求领域，我们要了解两个概念：Want和Need。
1 需求首先是学习过程
通过前面小节，我们重新梳理了需求和测试需求的概念，现在我们再来看看本章最初的那个问题了－“需求变更是个筐？”。
事实上，需求的过程是学习的过程，一方面，自始至终团队成员都需要持续的学习领域业务知识、用户的习惯和思维方式，在这个过程中，从初识到熟悉，从误解到澄清，是一个螺旋上升的通道，速度快慢取决于个人学习经验。
而另一方面，对于客户、用户，或者是产品投资者来说，同样是一个学习过程，在通过和产品团队沟通、评估各个迭代版本的过程中，逐渐学习利用工程语言、工程思维来阐述他们的想法。
从学习的角度看，做错练习题总是难免的，同理，希望需求不出现变更就好像希望所有题目都一次性找到正确答案一样，愿望是好的，但却是不切实际的。
需求变更的本质是知识从认识、到记忆、到理解、到熟练运用的过程。而事实上，没有完全一模一样的产品或项目，每一次新产品新版本都是不断学习的结果，自然可以得出这样的结论：需求变更的钥匙不在于“控制”，而在于“理解和接纳”。
无论需求将会发生怎么样的变化，本着学习的态度，测试人员应该先需求变化背后的一些信息；
- 变化的层次，不要太笼统，搞清楚是什么层次的变化，是业务需求、用户需求、系统需求，或者是软件需求，是否存在同步的变化；
- 变化的轨迹，不仅仅要知道原来怎么样，现在变成怎么样，更需要了解变更的轨迹，测试工程师尽量要让每一次需求变更都是趋向更清晰的方向。
很多测试人员自觉属于弱势群体，以下是常常被提及的证据
1、 在人力资源上投入不足，技术力量较开发部门更弱。
2、 很多缺陷开发人员甚至产品经理都不认同，有些缺陷最终都不能得到修改。
3、 测试人员会因为遗漏的缺陷受到指责，尽管他们发现了绝大部分缺陷
4、 好产品是开发出来的，不是测试出来的，测试人员缺乏成就感
当我们把测试看作一个独立的角色来观察，这些证据很充分，足以证明在这种合作环境下，测试是弱势的。
但是，当我和产品经理、设计师，以及其它产品开发领域的同仁们沟通的时候，我经常听到的抱怨是“我们有个强势的测试组长”。
在我从事测试工作时，我比较喜欢听到这样的评价，强势意味着受到重视，工作能力被认可，更多的成就感，这些抱怨对我来说感觉更像是一种赞誉。
随着我的工作范围转向为过程改进方面，我渐渐开始学习倾听所有人的意见、抱怨、期待，尝试尽可能不带偏见地观察整个产品团队中彼此的沟通与协作。我发现，关于“强势的测试”的抱怨在很多组织中都存在。
当我请倾诉者试着举出一些例子的时候，我得到如下一些信息：
“需求评审中，测试人员总会找到一些看起来不是那么清楚的东西，这很好，但是测试人员总是坚持从客户这边得到答案，有时候要满足他们的要求看起来比较困难。”
“他们的确是完美主义者，他们要求软件需求更详细，而我觉得再详细的话几乎就可以哪来当用户手册用了。”
“测试人员会直接找到负责具体编码的工程师，不断地催他承认这是一个缺陷，而且应该被修改掉，测试人员习惯对工程师发出指令。”
“如果我告诉他们我不打算改这个缺陷，他会马上找到我的主管，或者把他的主管请到我这边来，直到我答应改为止”
“测试人员会直截了当地指出UI设计不好看，会误导用户，有时候会直接出他们认为更好的UI设计”
“如果测试人员的不同意见最终未被采纳，他们会抱怨得自己是弱势群体，没有得到应有地重视”
……
“追求完美，并努力地驱动团队去实现完美的产品”，拥有这样的合作者无疑是令人放心的，越是具有责任心的测试人员越能够得到这样的赞誉。
出发点是好的，但让人感到“强势”，作为测试人员，应该可以适当的思考下
从一个倾听者的角度，我关注到以上评价中频繁出现两个字――“他们”。
这不是一个好信号，在沟通中大量使用人称代词是个糟糕的现象，人称代词出现的频度和角色对立的程度是相当的。（当然，如果习惯与把“我们”这个词的范围扩大，并大量使用，则是很好的现象。）
从职业要求来说，测试工程师们习惯站在客户或用户的立场来体验产品，这是一种职业化的思维方式，从客户或用户的角度来提出需求、改进产品质量，他们有这样的自我定位，是非常专业的表现。
但必须承认，用户是多样的，影响用户判断的因素极多，我们充其量只能代表一部分用着相同经验、文化或偏好的用户，而不是所有用户。
这里，我们得到了一个小结论：从用户的角度体验产品≠代表所有的用户
用了这么多篇幅来得到这个结论，为了引出后面关于 “Want”和“Need”的话题。
题外话：测试人员如何改变“强势”的观感？ 如果我们尝试改变传统软件研发的角色定位，去掉“测试工程师”的定义，改用这样的定义： 没有“独立的”测试人员，所有团队成员都一样，一起工作，一起讨论需求、设计，当然也讨论缺陷。 这样的工作应该有助于改变测试人员“强势”的形象，也许有读者会说，这取决于企业文化，不是测试人员能改变的，我认同这个说法，我们先做自己能够做到的，至于企业文化和团队建设方面，本书后面会有更多阐述。
3 关于“Want”和“Need”
3.1 展开饼图的案例
在“理解需求”这一小节中，提到了一个需求“将各产品利润汇总数据生成饼图”,有四个方案来实现这个需求。
一、 以产品排序
二、 以百分比排序
三、 合并最小项
四、 利用复合饼图展示最小项
假设我们面对这样一个需求“将各产品利润汇总数据生成饼图”，我们会考虑用哪个方案，考虑的重点是什么？
我猜选择三号方案的人会比较多，上面的需求中隐含了众所周知的信息，完整的描述应该是这样。之所以选择第三号方案是因为大家都能认识到第一、二号方案是有局限的，而这些局限恰恰是不复合完整的需求描述。
“将产品利润汇总数据生成饼图，能够清晰、直观地展示各产品对公司的利润贡献”
因为清晰、直观是图表存在的价值，所以，后半句通常情况下不会被如此叙述。有经验的团队自然了解要这样做，而经验不足的团队只看到了半句需求，就实现了，更多的就要等待测试发现了。
那为什么不选择用第四号复合饼图的方案呢？在实际工作中，有些人会说“客户并没有要求做这些”。
“但客户也没有要求做第三号合并最小项的方案，为什么我们就会选择这个？”
答案是：第四个方案是增强系统的数据挖掘能力――“挖掘具备潜在价值的产品”。
3.2 Want和need在这节，我引用“Want”和“Need”来说明如何在实践中理解需求。
特别要说明的是，关于用“Want”和“Need”来阐述需求的方法，也许有很多其它出处，我是在接受周浩宇老师培训过程中获得了这些信息，通过思考溶入到自己的知识体系中。
在软件需求的特定语境下，我们这样来定义Want和Need Want：想要的，指每个人基于自己的知识、技能等积累，希望产品能够拥有的特性、能力、交互等等。“Want”是个人基于自己理解提出来的，随着个人理解加深，往往容易发生变化。 Need：需要的，指产品为了解决具体的业务问题而必须拥有的特性、能力、交互等等，“Need”需要结合专业背景来发现。
在一个良好的团队中，每个人都会希望对产品有更多的贡献，尤其是新产品或新版本，大家都愿意加入自己的创意，习惯于做加法，导致产品的范围逐渐扩大。这些情况就是比较典型的“Want”。
而“Need”则侧重通过专业的分析和论证来发现真正的需求。
3.3 Want和need的例子为便于理解，我再举个例子，某企业内部办公自动化系统中，每个人可以看到自己的的任务列表。
|
任务名称 |
任务来源 |
状态 |
起始时间 |
结束时间 |
完成% | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
Total: |
|
|
|
|
|
|
现在团队中有人提出了一个想法，“为任务列表增加日历视图，就像MS OutLook中的日历一样。”
这是一条“Want”信息。如果要把这条加入到产品中，还需要更充分的理由。
下面是可能的理由：
1：用户有了这个功能以后，会更方便的查看他所有的任务 2、某同类软件就有这个功能，我们也可以有 3、某客户曾说过希望有日历功能 4、这个功能工作量很少的，一下子就可以做好的
虽然这些理由中没有 “我觉得”、“我认为”这些主观性很强的词汇，但这些都只能称之为Want信息，并没有足够的证据来证明新的想法是必须的，比如第二条，“有同类的软件做了这些功能”，潜在的信息是“也有同类的软件没有这些功能”，显然，这些信息的说服力不够。
进一步的理由：
1、我看到系统使用者把我们的系统中的任务复制，再粘贴到Outlook的日历上，如果我们的任务管理功能有了日历视图，用户就不用做这样工作了。 2、在主要的三个竞争对手产品中，有两家的系统中有日历视图。
上面两条信息比之前的更明确，但未必是更有说服力，分析第一点理由，如果多数用户习惯将Outlook作为常用的提醒工具，那么即使在OA系统中增加了日历视图，可能用户依然不会因此而改变使用习惯。也许用户更需要把OA任务信息导出成Outlook兼容的格式，这样用户就可以更方便地将任务导入Outlook中。
从“任务的日历视图”这个例子中，并没有有效的证据证明这是一条“Need”信息，基于已知的信息，团队可以考虑放弃实现这个建议。
当面对需求变更请求，团队任何成员都应该学会对深入判断，这对于我们的产品或项目，究竟是不是一条“Need”信息，或者，这只是一条“Want”信息而已。
忠告：不要等到需求来不及完成的时候，再来考虑做减法。
