专家推荐|成就业务架构师的65项关键专业技能！
今天欧洲杯，我沉浸在整理这份业务架构师的65项关键技能之中，看来公众号已成为我新的爱好之一。
整理完毕以后，发现这份内容非常有价值。如果一个业务架构师，能够掌握以下技能中的大部分必然脱颖而出。可作为业务架构师自身职业能力培养的关键标准。
本公众号只出精品，或者以精品精神去构建内容，当然如果部分做得不到位仍然是有可能的，我们可以持续进步。如果我自己认为不过关的内容，绝不会轻易发布。甚至发布后过一段时间发现做的不好，仍然会删除。
抛开战争纠葛，日本需要我们学习的恰是敬业精神、精品精神以及长期主义精神，这是很多年前被我们嘲笑的日本小个子足球、如今甚至可以叫板欧洲足球的关键原因...更是日本代表亚洲当年日俄战争干残俄罗斯迫使其赔款、让全世界震惊的关键原因。对中国而言，更需要中流砥柱，行业需要持续沉淀、分享与群体添砖加瓦。不要过多拘泥于细节，如何有利于大家、有利于这个行业发展，就是有意义的事情。
本文基于国外的最佳实践翻译总结，同时结合了我在实际业务架构规划与设计项目工作中的模拟场景与模板设计等做进一步总结，尽量仿真，希望对我们彼此都能有所帮助！
往期经典：
【专家Insight】战略笔记：数字化转型的生态建设指南
【专家Insight】战略笔记：数字化转型中的低代码评估与决策指南
Fire Gavin DeGraw - Fire
1. 主动倾听–一种沟通技巧，包括复述谈话中听到的内容以确认理解。
2. 管理会议–包含会议相关细节的文件，包括目标和待讨论主题列表。
3. 流程评估与分析–定义组织中业务流程的当前状态。
4. 头脑风暴-自发的小组讨论，旨在产生想法，而无需最初的批评或评估。
5. 业务分析计划–概述业务分析方法、可交付成果列表以及完成业务分析可交付成果的时间表的文档。
6. 设计业务领域模型–一个可视化模型，在逻辑上表示系统要实现的业务概念以及它们之间的关系。不应将它与表示实际数据库设计或体系结构的数据图混淆。尽管它们看起来相似，但是业务域模型应该使用业务域中的术语。
7. 业务流程模型–一个或多个业务用户为实现特定目标所做的逐步描述。这些步骤可以是手动的、基于纸张的或基于软件的。
8. 业务流程建模符号（BPMN）–用于创建业务或组织流程的可视化模型的标准符号。
9. 业务规则管理–定义或约束业务某些方面的语句。
10. 变更请求–总结要进行的变更的文档或信息集合。通常与正式的批准程序有关。
11. 竞争比较分析——将产品或系统的当前或潜在未来状态与组织竞争对手的状态进行比较的文档或矩阵。
12. 电话会议能力–通过网络电话进行会议，多参与者通过电话线从不同物理位置加入。
13. 数据字典–也称为数据定义矩阵，提供有关业务数据的详细信息，例如数据元素的标准定义、其含义和允许值。
14. 数据反馈规范–包含组织间交换数据所涉及的业务和技术细节的文档。可以用作管理API集成或其他类型的正在进行的数据反馈的一部分。
15. 数据流图-说明信息如何通过、进入和离开系统。在评估数据密集型流程和查看系统或组织之间如何共享数据时，它们特别有用。
16. 数据映射–一种特定类型的数据字典，显示一个信息系统的数据如何映射到另一个信息系统的数据。创建一个数据映射规范可以帮助您和您的项目团队避免许多潜在的问题，这些问题往往在开发后期或用户验收测试期间出现，并推迟项目进度，更不用说激怒您的涉众了。
17. 可交付成果列表–作为项目或计划的业务分析工作的一部分而创建的可交付成果列表。
18.需求文档分析–分析文档以发现信息相关需求的过程。
19. 实体关系图（ERD）–描述实体（或概念或事物）如何相互关联的数据模型。当由业务分析师创建时，erd可以用来理解业务领域、澄清业务术语，并将业务概念连接到数据库结构（请参见上面的业务领域模型）。
20. 可视化功能图设计–多个功能的可视化表示，通常是产品待办事项列表上的用户故事，显示它们之间的关系。
21. 给出When-Then语句—为用户故事编写验收测试的公式。给定（某些上下文）。当（进行某些动作）。然后（对可观察到的结果或要求的描述）。
22.术语表-一个可交付文件，记录了业务或技术领域特有的术语。术语表用于确保所有涉众（业务和技术）理解组织内部使用的术语、缩写和短语的含义。
23.整理产品待办事项–在sprint计划之前或期间，对新产品待办事项进行审查，以获得清晰性、估计和优先级的过程。
24.接口分析–分析接口的过程，例如连接两个软件系统的用户接口，以发现与需求相关的信息。
25.面试–一到多个涉众参与的会议，询问和回答与问题、项目或需求的任何方面相关的问题。
26. 问题列表–包含以任何方式与项目需求相关的所有问题列表的文档或存储库。
27. 会议记录–一份文件，记录了会议期间讨论的主题的实质，以及由此产生的任何决定和行动项目。
28. 思维导图——由Bola Adesope提出，这是一个以主题为中心的视觉模型，显示了不同概念和想法之间的层次关系。这是一个很好的头脑风暴工具。
29.观察力——通常在实际工作环境中观察人们使用系统或执行流程的过程，以发现与需求相关的信息。
30.组织结构图–一个可视化模型，表示组织或组织的一部分的组织层次结构。
31. 构建绩效衡量体系–收集、分析报告个人、组织、系统或组件绩效信息的过程。
32.绩效报告–显示项目、项目阶段或业务活动结果的文档或模型。
33.项目组合管理–组织、优先排序和显示组织中多个活动项目和提议项目之间关系的过程。
34.定义问题–发现和定义项目或解决方案要解决的实际问题的过程。
35. 流程改进进度报告–可视化模型，显示项目或计划对业务或技术流程所做的改进。
36.专家走查–主题专家走查未来状态过程以验证其有效性的工作会议。
37.产品待办事项–考虑中的所有需求的列表（使用用户故事语法编写）、排序，以及与其他关键特征的矩阵，这些特征有助于敏捷软件开发团队的规划和优先级排序。
38.项目列表–团队或组织正在考虑的优先项目的单个列表。
39.原型设计–一个功能可视化模型，显示尚未构建的软件系统的用户界面。原型通常允许基于样本数据的有限交互。
40.需求调查问卷–关于项目需求的问题列表。通常，问题是按功能（或业务需求或项目目标）组织的。
41.需求评审——召集利益相关者一页一行地浏览需求文档的会议，以确保文档代表了每个人对在这个特定项目中要完成的工作的完整理解。
42. 定期回顾–回顾已完成的工作（通常是针对项目或项目的一部分）以发现并提出经验教训的过程。
43.根本原因分析–分析问题以发现造成问题的根本原因或真正问题的过程。
44.范围模型–特定项目、解决方案或系统范围内特性、过程或功能的可视化表示。
45.干系人分析–一份文件，定义谁是项目团队的一部分以及他们负责什么。
46.干系人地图–描述干系人与解决方案以及干系人之间关系的可视化图表。
47.涉众请求列表–在定义范围之前，与项目或解决方案相关的请求列表。
48.专业调研–以不同格式向多个利益相关者提出的一系列问题，如在线问卷。用于从多人处收集大量信息。
49. SWOT分析–一个可视化模型，显示组织面临的优势、劣势、机会和威胁的信息。
50. 系统体系结构图–标识系统组件以及它们如何作为解决方案的一部分进行交互的可视化模型，可以帮助您找出如何最好地组织详细需求。
51.系统上下文图–一个可视化模型，定义项目或计划期间要处理的主要系统以及主要系统和其他系统之间的关系。
52. 流程前瞻分析–定义组织中业务流程的未来状态，以阐明一旦发生更改，业务流程在未来的某个时刻将如何工作。
53. 可追溯性矩阵—由Nikkita Nguyen建议，此文档用于将业务需求映射到功能需求。
54. 多重约束平衡能力-显示项目预算、进度、范围和质量之间平衡的模型。
55.用例–用例是一种文本需求规范，它捕获用户将如何与解决方案交互以实现特定目标。它们描述了用户使用软件系统完成该目标的逐步过程。
56. 用例图–一个UML（统一建模语言）图，显示参与者、用例以及它们之间的关系。
57.用户验收测试—一种验证过程，在该过程中，业务用户通常在部署新解决方案之前使用该解决方案，以确认该解决方案是否满足他们的需求。
58. 用户界面规范–定义用户与网站或应用程序屏幕上特定页面交互的参与规则的文档。
59.用户故事–从最终用户角度捕获软件功能描述的简短文档。用户故事通常用以下语法编写：作为一个{User}，我希望….用户故事通常与验收标准结合在一起（请参阅When Then语句）。
60. 视频会议–网络会议的扩展，参与者还可以共享自己的视频。
61.愿景文档–描述项目业务目标和范围的文档。
62.网络会议能力–通过网络研讨会、在线会议或屏幕共享软件和会议桥的组合举行的会议，多个参与者通过互联网连接从不同的物理位置加入，能够看到一个可视屏幕并相互交谈。
63.线框（也称为模型，与原型相关）–用户界面屏幕的视觉表示，通常是相当低的保真度。
64.工作流图（也称为活动图）–一个简单的可视化模型，用于捕获功能、技术或业务流程的步骤、决策、起点和终点。
65. 研讨会能力–在工作会议期间，对一个或多个工作产品（如需求交付物）进行实时协作的会议
--------------