编辑导语：需求分析师，是一个连接各处的桥梁，需要和产品经理、开发、测试、用户等进行沟通。本文作者从自身经验出发，对需求分析师的主要工作及需要具备的技能和素质进行了梳理，希望通过此文能够加深你对需求分析师的了解。

前言

客户是一家上海的中外合资的汽车技术研发公司，所服务的类型是项目管理的IT信息系统的建设。具体细化是整车和零配件的实验验证管理IT信息系统开发。

首先提到是显性知识和隐形知识的概念。一言以蔽之，即是知识是否有过编码的过程。对于，客户公司以及笔者所服务的KM公司而言，这已经是“常识”一类的认知了。但是在实践中发现这里面依然存在着很大的问题。

具体而言之存在着：

1. 项目文档的缺失；
2. 项目沟通障碍；
3. 岗位边界模糊；
4. 项目合作方法存在认知差异（需求和开发同步推进）等重大问题

这些问题都需要在项目实施中去弥补实现。

一、场景化下的需求识别

客户需求：需求分析师需要在历史文档和访谈的基础上，将业务流程和系统页面画出来，具体的输出里程碑是经过客户书面确认的产品Demo和产品需求说明书。

项目需求：需求分析师需要在单位的工作日里面，输出产品的Demo和PRD，并对程序开发团队进行培训讲解，以保障项目的正常推进。

所谓知易行难无非如此，需求分析师需要面对的是客户的压力和本身项目组的压力，成功则保障项目按计划推进，反之则项目延后，甚至有项目解散的可能。

故而，产生需求识别的知识萃取话题。

1. 为什么需要对这类知识进行萃取（萃取的需求背景）？

• 如果不能在工作计划内形成客户确认的产品Demo和PRD，会产生项目滞后或者项目解散的可能。
• 产品Demo和产品的PRD属于需求分析师的核心KPI指标。

2. 目前表现出哪些问题（萃取的现状）？

a、单位工作日内获得了客户确认的产品Demo和PRD,但是客户提出了新的需求；（走需求变更流程）

b、获得了客户确认的产品Demo和PRD，但是项目超时；

c、没有获得客户确认的产品Demo和PRD，需求和开发同步推进；

d、Demo和PRD没有获得客户认可，项目解散。

3. 涉及岗位或人群，人员数量？

笔者公司内的咨询团队，衍生至行业内的同行。

综合以上表述，利用任务描述的模板，总结提炼如下：

需求分析师需要在工作计划内，掌握具体的业务定位，熟悉客户的具体操作业务流程，用精准的语言和专业的软件工具输出产品的原型图和产品功能需求文档，并对程序开发团队进行有效的业务开发培训。

二、问题的提出、存在的痛点和希望实现的目标

1. 目标

a、产品的Demo和PRD；

b、开发团队的业务培训。最终实现项目的及时、成功上线。

2. 痛点

a、历史文档的欠缺。由于项目交接和对需求分析工作重要性的认知不足导致项目文档缺失。如、关键的业务流程分析缺失。

b、行业专业知识的沉淀。需求分析师过往的项目经验积累和学历背景不可能完全符合客户的专业需求。

c、沟通的障碍。语言的沟通障碍，客户习惯于中、英文混合表述；客户不愿意或者限于权限不方便讨论更深层次的原因。

d、项目实施方法的认知误区。由于开发进度（或者来自更高层的压力）客户更倾向于越过需求阶段的工作，直接开发一步到位。需求分析师没有职权获得有效的沟通时间或者机会向开发团队进行有效的沟通培训。

e、信息传递的有效性和完整性。对于信息传递的有效性，相信笔者的同行大多能够胜任，但是信息传递的完整性则不能保障。举个案例：军队夜间行军时口令传递的失真。在这个案例的基础上，大家对于完整性将有更深入的理解和体会。进一步讲，客户方的“朝令夕改”则是大家都能体会的难点。对于此，只能说是“我更接近命题的真相”了。

3. 希望实现的目标

a、如何帮助客户建立正确的项目实施方法

b、如何建立信任通过访谈获得高价值的信息和获得有用的资料

c、如何对程序开发团队进行有效的沟通培训

三、解决方法

1. 正反案例的解剖

典型反面案例：

案例一、“流程引擎的问题：UI尽量满足客户的需求，涉及到流程引擎功能及重构在现有工作计划里面我们做不到（建议40万重新立项一个流程引擎改造的项目，工期重新协定）。如果客户不同意，建议投资项目终止，做好现有工作量的统计”。

案例二、“你们根本就不懂我们的业务流程，你们的演示和我和需求顾问沟通的东西不一样。这样的演示和我们的业务部门的需求还有一定的距离。”

上面的案例来自于某软件公司的内部工作邮件和某软件公司客户演示的现场。涉及到的问题点有：

• 项目SOW工作范畴的确定；
• 客户公司多项目、多供应商的系统集成；
• 客户业务流程的梳理；
• 需求分析的准确和Demo演示现场气氛的控制；

上面的大多数的痛点属于需求分析师的主要工作范畴，也有一些如:SOW的撰写不完全属于需求分析师的工作领域。

典型正面案例：

案例一、“你画的Demo比前面那位好多了，还能实现客户的需求，我们开发做起来非常轻松，以后客户这边的需求就靠你了”。

案例二、“你真棒！把我的需求用你们的专业语言表述出来了，而且你的Demo超出了我的预期，在我给我的老板演示的时候，我的上司非常满意”。

上面的案例来自于某软件公司内部的沟通培训会和客户的现场反馈。

总结：通过上面正、反两方面四个案例说明了需求分析的工作重要性，所谓是“成也萧何、败也萧何”也不过如此。

2. 知识点的提炼

仔细解剖问题背后的原因：

（1）认知方面：需求分析的工作重心的问题，项目经理或者项目总监是否能够准确理解需求分析的工作的职能需求？是否能准确理解需求分析工作在项目开发中的重要作用？当遇到强势的客户的时候，是否能够把控项目推进的重心，并且及时有效的投放资源？

（2）思维方式方面：作为乙方，从行业特性来讲是典型的第三产业、服务工作。而软件公司是典型的“程序员文化”。这二者之间的冲突如何有效的“化解”、“克制”？如何有效的达到平衡？

（3）业务能力方面

1. 知识积累：学历背景的积累和项目实施经验的沉淀。这方面的知识应用更多的体现在对客户的行业知识和专业知识的应用方面。毕竟咨询顾问的职业特征之一就是无法预知下一个客户所在的行业和形成商业合同项目的咨询服务模块。这同时也对咨询顾问的学习能力和适应能力提出了更高的要求；
2. 沟通能力：体现在对行业专业知识理解基础上的专业沟通能力。在笔者服务的项目上还多了一项语言的掌握能力上。毕竟案例中的客户所在的领域是国内最早的合资公司；
3. 业务技能能力：这是需求分析顾问的基本功。体现Axure的掌握能力和书面的表达能力；毕竟对于需求分析师的考核KPI而言，最为直观的反映就是产品Ddmo和PRD。
4. 演讲控场能力：这是咨询顾问的进阶篇。毕竟是“十年陆军、百年海军”。其中，蕴含的知识沉淀、客服意识和现场控制能力并非“一朝一夕”之功所能实现。这也就是大家通常所讲到的“内功”和“气场”。

3. 解决的实施办法结语

对于本文的标题“需求分析师胜任力之知识萃取”而言，行文之此，相信对于IT行业内的需求分析岗的主要工作已有所了解。但不免仍有遗憾。知识萃取的目的在于成果的转化，成果的转为的特征对于商业公司而言，无非是商业合同的诞生。

对于本文而言，成果转化有两个方向：其一、需求分析师培训教案的实现；其二、需求分析师能力胜任模型的构建。

这是下一个命题了。

作者：吴虹辰；微信订阅号：三稳人。这个订阅号是过去十几年来的经验积累，也是近百个项目经验的结晶，希望能对您有所帮助。

本文由 @吴虹辰 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。