需求分析师需要在历史文档和访谈的基础上，将业务流程和系统页面画出来

客户是一家上海的中外合资的汽车技术研发公司，所服务的类型是项目管理的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比前面那位好多了，还能实现客户的需求，我们开发做起来非常轻松，以后客户这边的需求就靠你了”。