做好需求工程师需要什么

需求是一种技能，技能就需要不断改进和完善。如果团队只把“技术”定义为“实现软件”，认为需求只要愿意去做就能做好，那是不切合实际的。
有人评论，按照需求的各项活动，技能可以分为启发技能、定义技能，管理技能等；还可以分为团队技能，个人技能。暂不论访谈技术、用例技术、或者需求变更，需求工程师最好具备什么样的素质呢？有人说优秀需求工程师所需要的素质可以归纳成一所房屋的样子： 房屋的根基是好奇心，有三根柱子：探索力、沟通力、表达力，以热情作为屋顶。
　　好奇心
好奇心，首先指对不熟悉的事物提起兴趣的能力。在做项目时，有的开发人员只对项目将要用到的新技术感到兴奋，对项目所涉及的业务领域则不感兴趣。为什么调研过程总是流于形式？为什么更喜欢在办公室“编写”用例，而不是深入第一线？为什么喜欢甲方的信息中心人员，而不是不懂电脑却至关重要的涉众？这就是原因之一。好奇心，更重要的是从熟悉中发现惊奇的能力。很多时候对业务太熟悉或者存在已有系统，也是捕获需求的一种阻碍。这种情况下很容易就想到系统里有哪几张表，怎么调用，反而钳制住了思维。必须要学会抵制各种想要向里探头的诱惑，尽量跳出来看，从熟悉中发现惊奇。这样才能从涉众提供的资源中，超越涉众的目光，开发出在局中人无法察觉的需求。需求本来就是要把系统看成是黑盒子，不关心它是如何被构造的，只描述它被使用时表现出来的功能和性能。
　　探索力
探索力，首先是寻找线索的能力。业务现实就是这样，资料在那里，涉众也在那里。你怎样去寻找线索？拍拍涉众的肩膀，“来吧，说说你对这个系统有什么需求？”这样行吗？探索力，还包括从线索中归纳出问题的能力。就象侦探一样，需求工程师需要从涉众提供的各种信息碎片中捏出真正的问题。这种探索力更强调的是“合成”，而程序员擅长的是“分解”——针对问题，采用某种软件技术解题。某开发团队在一个制作报表的需求上纠缠了很长时间，最后才发现客户方的最高负责人从未要求，也不在意有没有正式的“报表”，他在意的是随时掌控进展情况并做出平衡。如果他确实需要一份“报表”，系统可以给他提供基本数据，他宁愿用自己的人制作任何他想要的报表。可惜，没有人早一点问：为什么需要这个报表？ 日常生活中如何培养探索力？例如最近的事件，“Martin Fowler要来中国”，如果一开始只是知道这么一个事件，并不了解其中细节，可以尝试针对各个环节的信息，通过“反转”、“取代”等手法来探索。
沟通力
沟通力包括需求工程师和涉众沟通的能力。涉众往往表达的并不是需求，而是一种“需要”或者“利益”。认为客户和程序员一说，就能理解执行得到正确的软件，这种想法是天真的。例如，一名操作员涉众说系统要简单易用。但“简单易用”并不能直接成为需求。需求工程师要耐心和涉众沟通，了解涉众是以什么标准来度量“简单”和“易用”的。沟通力还包括需求工程师在不同涉众之间协调的能力。涉众往往有很多方，A类涉众的利益和B类涉众的利益可能在一定程度上是冲突的，例如，录入人员希望操作步骤尽量少，但如果因此省略了一些确认和验证的步骤，使用这些录入数据的审批人员、施工人员的利益可能就会受到损害。需求工程师需要平衡各方涉众的利益以得出恰当的需求。沟通力还包括需求工程师在涉众与程序员（也是一类涉众）之间协调的能力。例如，操作员要求“一键完成操作”，却难为了程序员。需求启发技术中的访谈、观察、会议等，无不需要人与人之间的沟通能力。而平时程序员更多使用的是和机器的交流能力，这一点也是身兼多职的程序员值得注意的。程序员如果要去承担需求工程师的角色，沟通力可能是木桶上最短的板。
　表达力
表达力在这里着重指文字表达和组织的能力。需求最常见的形式是以文字方式表达出来的。象用例文档，就是一种规范的、有层次的需求表达形式。用例的写作需要表达力，也培养表达力。