需求工程师必备素质细说

如何改进需求？笔者认为，首先必须意识到需求是一种技能，否则不可能改进。如果团队只把“技术”定义为“实现软件”，认为需求只要愿意去做就能做好，那么“改进需求”永远是一句空话。事实是，很多团队就算愿意去改进需求，也不知道怎样才能做好。 

按照需求的各项活动，技能可以分为启发技能、定义技能，管理技能等；还可以分为团队技能，个人技能。本文不讨论访谈技术、用例技术、或者需求变更，这些在以前的文章中已经涉及。本文讨论这些技能的最终执行者――需求工程师，他们为了掌握好这些技能，最好具备什么样的素质。 

笔者把一名优秀需求工程师所需要的素质归纳成一所房屋的样子：  房屋的根基是好奇心，有三根柱子：探索力、沟通力、表达力，以热情作为屋顶。

好奇心 

好奇心，首先指对不熟悉的事物提起兴趣的能力。在做项目时，有的开发人员只对项目将要用到的新技术感到兴奋，对项目所涉及的业务领域则不感兴趣。为什么调研过程总是流于形式？为什么更喜欢在办公室“编写”用例，而不是深入第一线？为什么喜欢甲方的信息中心人员，而不是不懂电脑却至关重要的涉众？这就是原因之一。 

好奇心，更重要的是从熟悉中发现惊奇的能力。很多时候对业务太熟悉或者存在已有系统，也是捕获需求的一种阻碍。这种情况下很容易就想到系统里有哪几张表，怎么调用，反而钳制住了思维。必须要学会抵制各种想要向里探头的诱惑，尽量跳出来看，从熟悉中发现惊奇。这样才能从涉众提供的资源中，超越涉众的目光，开发出在局中人无法察觉的需求。需求本来就是要把系统看成是黑盒子，不关心它是如何被构造的，只描述它被使用时表现出来的功能和性能： 

如何培养好奇心？其实日常生活中充满了惊奇： 

一大群人，半夜不睡觉，讨论过去一天的各种事情，然后把它们整理成厚厚的一叠纸，送到你的办公室，只收1元钱。 

有一种动物很奇怪，每天从壳子钻进钻出，一到晚上，就几个一组钻进一个壳子里盯着一个发出荧光的盒子一动不动。 

用另一种心态来观察这些事物，可以培养好奇心。看一些“短路”的漫画，或者做一些不熟悉的事情，例如你喜欢看《体坛周报》，不妨去看看《人民日报》；如果你喜欢看《程序员》，不妨去看看《知音》。

探索力 

探索力，首先是寻找线索的能力。业务现实就是这样，资料在那里，涉众也在那里。你怎样去寻找线索？拍拍涉众的肩膀，“来吧，说说你对这个系统有什么需求？”这样行吗？ 

探索力，还包括从线索中归纳出问题的能力。就象侦探一样，需求工程师需要从涉众提供的各种信息碎片中捏出真正的问题。这种探索力更强调的是“合成”，而程序员擅长的是“分解”——针对问题，采用某种软件技术解题。（这里的程序员指广义的软件实现人员。不管他是用图形（如UML）还是字符（如C#）来“编程”。）这就解释了：为什么程序员在“寻找用例”时往往会变成“功能分解”？为什么用例的道理很简单，我们却一次次地摔倒？

某开发团队在一个制作报表的需求上纠缠了很长时间，最后才发现客户方的最高负责人从未要求，也不在意有没有正式的“报表”，他在意的是随时掌控进展情况并做出平衡。如果他确实需要一份“报表”，系统可以给他提供基本数据，他宁愿用自己的人制作任何他想要的报表。可惜，没有人早一点问：为什么需要这个报表？ 日常生活中如何培养探索力？例如最近的事件，“Martin Fowler要来中国”，如果一开始只是知道这么一个事件，并不了解其中细节，可以尝试针对各个环节的信息，通过“反转”、“取代”等手法来探索： 

①为什么是Martin Fowler来，别人象Kent Beck、Scott Ambler也会来吗？ 

①Martin Fowler以前来过吗？这次来是为了什么事？旅游？讲学？ 

①Martin Fowler来了之后怎么办？会在中国开展业务吗？ 

②为什么是来，有没有中国公司“去”过Martin Fowler那里上门求教？

②是坐飞机“来”吗，能不能从网上“来”？

③为什么是中国，他去过印度吗？日本呢？ 

探索力的培养方面，Edward de Bono的书如《六顶思考帽》、《水平思维》等书虽然与软件不直接相关，但很有参考价值。和螺丝刀、拉链一样，软件实际上就是为人服务的一种工具。 

沟通力 

沟通力包括需求工程师和涉众沟通的能力。涉众往往表达的并不是需求，而是一种“需要”或者“利益”。认为客户和程序员一说，就能理解执行得到正确的软件，这种想法是天真的。例如，一名操作员涉众说系统要简单易用。但“简单易用”并不能直接成为需求。需求工程师要耐心和涉众沟通，了解涉众是以什么标准来度量“简单”和“易用”的。  

沟通力还包括需求工程师在不同涉众之间协调的能力。涉众往往有很多方，A类涉众的利益和B类涉众的利益可能在一定程度上是冲突的，例如，录入人员希望操作步骤尽量少，但如果因此省略了一些确认和验证的步骤，使用这些录入数据的审批人员、施工人员的利益可能就会受到损害。需求工程师需要平衡各方涉众的利益以得出恰当的需求。 

沟通力还包括需求工程师在涉众与程序员（也是一类涉众）之间协调的能力。例如，操作员要求“一键完成操作”，却难为了程序员。

需求启发技术中的访谈、观察、会议等，无不需要人与人之间的沟通能力。而平时程序员更多使用的是和机器的交流能力，这一点也是身兼多职的程序员值得注意的。程序员如果要去承担需求工程师的角色，沟通力可能是木桶上最短的板。 

如何培养沟通力？我们习惯于生活在一群有较高学历的软件人圈子内，而涉众往往在学历和技术知识上和我们有差距。要能够和涉众有效沟通，有意识地去改进沟通技巧是必要的。参加一些沟通技巧的训练，或者阅读一些人际交往的相关书籍，例如《人性的弱点》，这本书可以说是中国引进的最早的“沟通力”书籍之一，10多年前曾经大热。书中的倾听和赞赏的道理到今天依然没有过时。

表达力 

表达力在这里着重指文字表达和组织的能力。需求最常见的形式是以文字方式表达出来的。象用例文档，就是一种规范的、有层次的需求表达形式。用例的写作需要表达力，也培养表达力。  

我们平时习惯的是编程语言的表达能力，写个注释有时也想偷懒，更不用说自然语言表达的文档了。开会时项目主管向大家介绍项目，用词中经常充斥着 “伸缩性”之类的各种字眼，明明只是一个小小的管理系统，却起名叫“××平台”，似乎大家听不懂才说明高深。 

如果您希望提高文档的表达力，可以尝试读读这本书——《金字塔原理》。这是一本说明怎样有效写作的书籍，介绍了一种处理写作时文笔不清问题的新方法。 

热情 

我有好奇心，有探索力，有沟通力，有表达力，也掌握了各种具体的需求技能，就意味着我会积极地尽我所能去向涉众探索需求吗？没有热情作为屋顶，上面提到的各种“力”不能得到贯彻。培养上面提到的各种素质，主要靠需求工程师自己的努力。培养热情则复杂得多。

没有价值感，没有热情。软件公司可能希望通过企业文化洗脑来使需求工程师获得热情。例如讲这样的故事：有个人经过一个建筑工地，问那里三个石匠在干什么？第一个石匠回答：“我在做养家糊口的事，混口饭吃。” 第二个石匠回答：“我在做很棒的石匠工作。” 第三个石匠回答：“我正在盖世界上最伟大的教堂。”故事是很感人，但如果我内心里知道，这个软件项目纯粹是浪费纳税人金钱的政绩工程，它的开发只会有损于社会的总福利，你叫我如何提起热情来，睁眼说瞎话“我在建造世界上最伟大的软件”？  

没有利益，没有热情。这个软件系统做好了，我能得到什么好处？做砸了，对我有什么坏处？如果没有这样直接相关的利益，需求工程师是不会有热情去体会涉众的需求的。就象玩斗地主，如果只是扣分，大家只当玩玩而已，没有人会绞尽脑汁，如果扣的是口袋里的铜板，恐怕每一局考虑的就全面多了。 

如果您现在所在的软件公司没有给你带来价值感，也没有带来直接利益，就不要用强打精神用“敬业”来折磨自己了，要么请老板改变现状，要么走人吧！ 

结语 

想一想这一种最简单的涉众，婴儿。他哇哇地哭了，他的需求是什么？热了？饿了？要尿尿？有蚊子咬他？还是生病了？应用一下探索力和沟通力，你可能要摸一摸他的后颈，有汗吗？发烫吗？在脑子里查询一下“喝奶日志”，上次喝奶是什么时候？抱起来，摇一摇，哼支小曲……