项目立之根本——项目中的需求质量

秀咖

说到需求质量，我们先得知道需求质量是如何定义的，引用PMBOK中对基准的需求质量的要求是这样描述的——只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。其实不只是这些属性对于IT行业来说，还有很多别的定义，咱们暂且不表。
那我们怎么理解这句话呢：
一、明确的
“明确的”意思是任何需求都是必要的能够使用一定的标准去判断需求是不是能够得到满足，并且能够通过一些手段进行验证。好比说需求说事需要一个杯子，那我们就必须知道这个杯子的材质，尺寸，还有一些性能参数是如何定义的，不能只是说我们需要一个杯子。那可能对于这个需求的描述就是：
我需要一个杯子，圆口，直径15cm，高25cm，有课密封的盖子，304不锈钢材质，烤漆面，5米跌落无损伤，高温耐热150℃……
通过这些描述，我们能够很明确的知道，这个杯子应该有什么样的属性，同时，我们也就能够通过测量，知道这个杯子的尺寸是不是符合要求，通过跌落测试，高温测试对杯子的性能进行确认也就是我们通常说的测试。
二、可跟踪的
很多同学不知道需求要跟踪什么，其实对于需求来说，跟踪的内容其实会包含两个大部分。第一个大部分是指，需求的成果，即可交付成果是不是能够满足最初的需要，其实，并不是说，我们对成果进行验证这么简单，而是要在项目研发的每一个环节对项目原始需求对应。以杯子为例，我们生产的时候，要对材料进行选择，需求要求要选304不锈钢，这是一个很明确的需求，那我们是不是可以选择一些比较好的材料呢？答案是不可以！有的时候是成本原因，有的时候是特性决定的，但是根本原因就在于，追踪的目的在于合适而不是满足，就像买鞋一样，你穿42码的鞋子，没有人会因为大码跟小码一样钱就买一双45码的穿吧，也不会因为40码便宜，去买40码对吧。
还有一个方面就是要追踪需求的状态。需求在研发生命周期中的状态并不是一贯的，也不是说从需求直接就到了产品。他一定是在一个生命周期中不断变化的，在不同的阶段和状态下，对需求的管理方法也是不一样的。比如我们基于需求管理定义需求状态为准备中，已发布，待处理，研发中，测试中，验证中，取消等状态（仅供参考），每个状态上，我们对需求的态度都是不一样的，同样，处理需求的团队也在需求在项目的过程中变化，最后会交付给客户。
其实所谓的可跟踪性就是指我能够在项目生命周期对需求从生到死的过程进行管理，同时要对应到原始的需要——通常是一些商业目的，业务需要等。
三、完整
所谓的完整，通俗来说，就是不能说半截子话，或者是，在表达需求的时候，要对使用场景和解决的问题说清楚。比如说，一个父亲跟要去另一个城市打拼的孩子说，想吃点啥就吃点啥。但是，如果是一个大夫跟一个病人说同样的话，那就完全不是一个问题了。所以，在表达需求的时候，一定把前因后果、场景用途表达清楚，上面杯子的例子中，我们只是知道，我们要用不锈钢，要有盖子，要有强度，要耐高温，但真实的原因是什么呢？其实我们真需要的是一个在旅行场景下使用的保温杯。所以，如果吹毛求疵的对需求进行完整的描述大约应该是这样的：
为了能够在旅行的时候让我能喝上热水，我需要一个 保温杯，圆口，直径15cm，高25cm，有课密封的盖子，304不锈钢材质，烤漆面，5米跌落无损伤，高温耐热150℃……
四、相互协调的
这个怎么理解呢？其实很简单，就是说，需求质量不只是单看某一部分，要整体来看。往往的，我们的一个需求整体是要解决一系列的问题的或者说，我们解决的问题都是有普遍联系的。那就预示着，需求整体来看，不能突兀关联，就是没关系的俩事，你非得给放在一起，就好像你给胡萝卜嫁接上苹果想让他长出草莓那个感觉一样，也不能互相矛盾，比如说上面的需求中，我们很清楚的看到这是一个保温杯，如果说，从整体解决方案的角度来看，我还有个需求，要求我们希望这个产品有个把，有个嘴能把水倒出来（虽然不太恰当，但是希望大家理解这个意思），这就矛盾了，就已经歪曲了这个需求的真实意义。
五、主要相关方愿意认可的
这一点我觉得最重要，归根结底来说，你生产出的产品和成果事要交付给用户使用的，或者你的相关方希望能够从这个项目的成果中获取到什么利益。那就不能霸气的说，我不要你觉得，我要我觉得了。从根本上来说，你觉得更重要，即使不合理，即使反人类，但是当相关方愿意承认这就是真实需求的时候，那这就是真实需求了。
当然了 ，对于需求质量的定义没有一个绝对正确的答案，但各种理论都大同小异，关键问题在与，我们如何做能够对得起用户的信任，对得起用户花钱买你的东西，对得起团队辛辛苦苦完成的成果就是人家想要的那个。需求质量不只是对一个需求获取和分析人员产生作用，对整个项目和团队都能够产生至关重要的做用，甚至决定着一个产品或者项目的成败。这里有几点建议提供大家参考，如有偏颇，忘批评指正：
第一， 想办法让需求的来源可靠。
我当项目经理的第一个项目就栽了，原因特别简单，就是没找对提出需求的人。往往我们在项目中我们经常会遇到两个极端的情况，一种是特别愿意配合你，在我们收集需求的时候，给你讲了很多很多实际的应用场景，甚至带着你去参观现成，协助你做需求分析和需求方案
其实，对于第一种，不管是项目经理，还是需求收集人员，并不能代表这位需求方是优质的。注意，这并不是阴谋论。从实际情况的角度来说，此位相关方的业务用户画像应该是，具体业务部门出身，可能是直接的终端用户，职位不高。所以，他的需求可能是真实的，具体的，但不一定是普遍适用的。特别针对信息系统来说，使用的相关方的广度，在一定范围内是有一定程度的，某一个点，不能代表一个面，我们往往很愿意跟这种人打交道，需求收集也感觉会很顺利。但是我们要想清楚，这样收集上来的需求是不是能够让主要的相关方愿意接受呢，换句话说，这位需求人事不是主要的需求方呢？
那对于另外一种人，我们就更得小心了，就是那种特别不愿意配合你，也不说好，也不说不好，拒人以千里之外的感觉。我们都非常清楚，需求收集是一个很困难的工作，有些人是说不清楚说不明白，需要你的帮助，更可怕的是，有些人不愿意说。为啥不愿意说呢，特别简单，一个单位的中层干部，你去给他单位做信息化改造，你这就是要颠覆他的工作习惯，改朝换代的节奏，你如果问他意见呢，他的意见一定是这个是不办。但是说不办就不办了嘛？必然是不可能的啊，作为项目经理或者需求收集者，我们是不是就可以从对方的角度来出发，了解一下对方的关键痛点，先解决让他愿意说，再解决能说的对的问题。
找准关键需求方，只是让来源可靠的一个方面，另外一个更重要的方面要看咱们收集需求的时候，怎么去深入挖掘真实意图。所谓去伪存真，往往伪需求面具下藏着的就是用户的真实需求。说到这就得用一点手段了。
第二， 采用多样、多方位的需求收集手段。
我们能从书本上，实践中学习到的需求收集手段特别多，只是PMBOK中在收集需求那一个过程就给我们提供了十余种需求收集的方法。其实对于这些理论层面的东西，我们更关心的是这件事怎么应用在日常的需求收集活动中。就比如我们给一个传统企业做信息化改造这样的项目。通常来说我们是不是要先识别一下关键相关方对吧，于是我们对这些关键相关方就要进行一个访谈。就说访谈这个事情，对于一个信息化项目的项目经理来说，聊天是肯定会聊的，但是有这样一个缺陷，你不一定懂你对方单位的这些具体业务。通过访谈，我们是能知道我们的信息系统可能会需要去解决几个问题，但是通过分析这些访谈的结果你会产生更多的问题。
那问题来了，这要问谁去？那我这有几个选项，一个叫标杆对照，一个叫引导式研讨会。对于标杆对照，我们可以去参照已有的或者相似行业的系统，看看人家是如何解决这些问题的。通过一些参考和改进，生产更好更高效的产品，如果对这个不明白是什么样，那就去看看鹅厂的产品。引导式研讨会，学习过PMP的朋友都会知道这是一种引导技术与焦点会议的结合，本质上来说，就是召集一些对业务熟悉的人，有必要的话，客户也可以参与进来，针对这些问题共同探讨出一个能够达成一致的结果。
其实这种方法和手段很多，关键的问题在于，对不同的项目，不同的相关方，方法也不是一成不变的，这对项目经理和需求收集人员的要求是比较高的。见人说人话，见鬼说鬼话，不在于你用的这个方法的学术名词是什么，在于你真的可以把用户需求收集上来。不但要需求换收集上来，关键的哪句话，要完整，协调，且有人愿意承认。
第三， 需求表达要说人话。
需求收集还有一个更难的地方就是往往在需求传递的过程中就不是原来的需求的样子了，有一副著名的漫画叫秋千的故事：


从漫画中我们可以看到，对于需求来说，各个角色的理解是不一致的，这里有的情况是行业和知识背景的差异，更多的是，都不说人话，学术一点说，就是需求语言差异。那我们如何去消除这种差异呢？有几个关键的实践我觉得可以值得尝试一下，第一个我们叫做用户故事，基本格式是：


同时，用户故事也循着一个叫INVEST的原则，这与我们前文中写到的需求质量就对应上了。


用户故事的好处在于，一切从用户的角度去出发，不管是什么样的角色，都能够理解用户这个行为，用户故事通常用卡牌书写，放在一个团队都能看到的地方，从而引发一些深层次的讨论，和进一步的确认。也就是对用户故事的3C（卡片(Card)、交谈(Conversation)和确认(Confirmation)。）
还有一个更好的，就是原型。这对于很多做新产品开发或者互联网行业的朋友是很熟悉的。比如Axure，XD都是非常好的原型工具，最不济，一张白纸一支铅笔也能说明问题。对于大多数人类来说，带图的东西，一般比一大段文字从感官上的理解要明确的多，何况还有些不说人话的东西呢。同时，往往我们在收集需求的时候说不清楚的那些事，拿个仿真原型给人家看看，这不就能说得清楚了嘛。这种方式我们叫做可视化沟通。
这里的说人话，不是语言的问题，问题在于，让整个团队和相关方，都能明白你的需求想表达的意思，而且要认可这个意思，很多地方讲需求需要无二义性就是这个道理。我们如果在互相之间找不到一种共同的交流方式，那也没有关系，就去创造一种。
第四， 让需求受控。
很多的时候，我对面对需求变更，特别是IT行业中的需求变更是比较排斥的。但是在这里我想说的是，受控的意思并不是绝对的不能变更，或者说必须将需求锁定在某一个范围。随着我们对VUCA这个词越来越熟悉，我们也知道，这已经越来越趋近于一个不可能发生的事情了。也就是我们说的所谓“拥抱需求”
但是，拥抱需求并不等于需求蔓延。我们是不是还要去控制需求呢？答案是肯定的。我们要控制的并不是变化，受控在这里的意思是，围绕着用户价值，尽早识别变化的产生，以便于控制对项目和最终成果产生的影响。所以，小步快跑的生产可交付成果，频繁炎症需求的适用性就成了现在的普世价值。这样做的好处是让研发团队和需求管理团队能够尽早的验证成果是不是符合用户价值，如果不是，尽早改进。
除此之外，受控的另一个方面是，我们要保证所有的需求都有过正式的发布，这与传统做法是相一致的。并不是说我们拥抱需求就可以在需求层面随意的发挥，需求通过获取、记录、评审、验证的过程也是必不可少的。换句话说，一口唾沫一个钉的事情还是要做。定义好的需求，要通过正式的发布，才能作为开发的依据。这是对团队负责，也是对用户负责。
就像上文中讲到的，需求质量除了需求本身的质量之外，用户和相关方层面是评价需求质量最重要的一个层面。
第五， 请专业的人，干专业的事。
从PMBOK第六版开始，PMI在每个过程中加入了“发展趋势和新兴实践”这个小结。另外，在每一年的《职业脉搏调查》中，也会对未来的一些趋势做数据层面的分析和预测。对于范围管理这一部分，在第六版中主要提到的趋势有两个，其中一个讲的是需求管理的边界的延展，延展到更高层次，也就是项目集甚至项目组合层次，这个比较虚，可能有些同学就不太明白。另外一个说的是，重视项目中，商业分析师与项目经理的合作。
PMI有个专门的认证叫PMI-PBA，即商业分析专业人士。这个认证对项目分析师的要求其实我们可以近似理解为现在大家都能够普遍接受的项目经理岗位。通过一系列的手段和方法，从实现商业价值的角度实现组织的战略目标。
其实从现今的行业发展来说，职能的细分没有为什么，就是大势所趋。让专业的人干专业的事已经成为当代企业的普遍价值观，跟重视合作对项目和相关成果产生的影响。所以有一个合作良好的商业分析师或者产品经理与项目团队进行合作，是最快也是最直接的解决需求质量问题的选择。
就像本文开篇所说，需求的质量在项目中起到关键的作用，甚至左右着项目的成功与失败。但是，需求质量的保证，需要企业，流程，人，全方位的保障。单从某一个方面去完善是不足以成功的。作为项目经理来说，不断的提升自己的管理水平和软技能是不二的选择，希望大家都能获得成功。
http://weixin.qq.com/r/Bz8AGKzEgfH_reh792oV (二维码自动识别)