郭菁菁的博客

但我们的探索不会停止，后续内容将以「进阶实践」和「专题拆解」形式，继续更新。也是写给所有想成为“系统型BA”、“有长期积累的人”的一份礼物。我希望能把更高质量、更实战可落地的内容，持续、系统地做下去。从流程、规则、数据，到利益相关者、变更管理、优先级排序……这不仅仅是一套技术列表，更是我十多年项目实践的精华沉淀，未来的内容，还会更实战、更高级、也更有趣。

由 BA 组织和引导的结构化、目标明确的集体工作会议通过互动活动，让不同干系人协作完成特定任务目标可以是：挖掘需求、澄清流程、制定方案、识别风险、规划路线图……不是“开会听汇报”，而是“动手一起做”。如果你也是 BA，你一定懂得：真正有力量的 Workshop，不是让人觉得被安排了一个任务，这是我们一起创造出来的成果。如果你也有过一场特别成功（或特别崩盘）的 Workshop 体验，欢迎留言一起交流！我们 BA，不只是笔记员、画流程的人，我们是不同声音间，搭建理解和共识桥梁的人。

在项目采购、系统选型、外包合作中，我们常常要面对一个巨大的风险：选错供应商，项目全盘崩塌。而 Vendor Assessment，就是业务分析师的重要武器，帮项目在签约之前，提前筛雷、防坑、选对伙伴。在我的项目经历里，每一次认真做 Vendor Assessment，都避免了不少“上线一半跑路了”“服务态度急转直下”“功能落地差强人意”的惨剧。Vendor Assessment（供应商评估）是指：它的本质是：不是选看起来最热闹的，而是选最能交付成功的。通常，我会从这几个角度评估供应商：曾经，我参与一个 CR

User Story 是一种简洁的需求描述方式，通常采用这样的格式：作为[某类用户]，我希望[完成某个动作]，以便[实现某个目标]。谁需要（角色）要做什么（功能）为什么要做（价值）而不是一上来就列详细的系统规格。重点是：关注用户视角，不是产品视角。如果你也是 BA，你一定懂得：真正的需求，不是写在文档里，而是藏在用户心里。User Stories，让我们成为用户心声的翻译官，让技术的手，真正触摸到业务的脉搏。如果你也有过靠 User Stories 扭转乾坤的故事，欢迎留言一起交流！

我们 BA 不是写代码的，但我们写的 Use Cases & Scenarios，就是开发的“剧本”，测试的“脚本”，业务的“蓝本”。用精致的剧本，带领整个团队看清未来该如何运作。这是 BA 的剧作能力，也是沟通能力的巅峰体现。

它不是简单列优缺点。它是一种系统性分析方法Strengths（优势）：内在的、有利的因素Weaknesses（劣势）：内在的、不利的因素Opportunities（机会）：外部环境中，有利的机会Threats（威胁）：外部环境中，潜在的风险一句话总结：SWOT 是看自己、看环境、看希望、看危机，一个都不能少。如果你也是 BA，你一定懂得：真正的战略思考，不是脑补未来的好日子，而是用一份冷静又清晰的局势图，走出一条属于自己的胜利路线。

它不是单纯列个流程图，也不是写一堆功能列表。描述一个对象（Entity）在生命周期内经历的所有状态定义每个状态可以进行的动作，以及动作触发的状态变化明确状态之间的转换条件和不可逆限制换句话说：State Model 就是对象的一生轨迹，什么时候可以做什么，什么时候不能做什么，一目了然。如果你也是 BA，你一定懂得：真正稳定可靠的系统，不是靠补丁堆砌出来的，而是从一开始就把“对象的命运”规划清楚了。如果你也有靠 State Modelling 救火的故事，欢迎留言一起交流！

问题清晰、指向明确：问题一定要具体到行为，而非模糊态度选项有限、但有启发性：给出三到五个互斥选项，引导用户思考而非跳过用户愿意填写：设计要贴近语境，甚至带一点“像我说的”那种亲切感比如与其问：“您觉得我们客服体验如何？不如问：“在上次联系客服后，您是否遇到以下问题？（可多选）”我相信，一个 BA 的专业价值，不只体现在 BRD、流程图、需求澄清会议里，也体现在这些“细节之处”的调研设计能力中。问卷，是需求调研的起点，但不应该是生硬提问，而是温柔又精准的对话邀请。

它不是干巴巴的人口统计学数据表，也不是拍脑袋想象。通过用户调研、数据分析、访谈等手段汇总出的一组典型用户模型帮助产品、设计、营销团队以“人”为中心思考和决策如果你正在做一个C端项目，不妨从今天起，花点时间真正走进用户的世界。用心构建一份活生生的User Persona，未来的每一次设计、每一个决策，都能更准确打动人心。

Stakeholder Personas 是一种人物画像工具，业务分析师通过系统地刻画关键干系人的典型特征，来帮助自己和团队更精准地理解、沟通和影响他们。基本背景（角色、职位、职责）目标（他们想通过项目实现什么）挑战和痛点（他们害怕什么）行为特征（决策方式、沟通偏好）态度（对变更/项目的初始态度）影响力与依赖关系（他们能影响谁、受谁影响）比起冷冰冰的Stakeholder List，Stakeholder Personas让干系人真正“活了起来”。

它不是简单地列名单，更不是“谁职级高就听谁的”。识别所有受项目影响的个人、团队、组织。分析每个干系人的影响力、立场、兴趣、沟通需求。以可视化图表的形式，呈现出干系人之间的关系和动态。换句话说： 是从一开始就把“谁是朋友、谁是关键、谁可能反对”搞得一清二楚。如果你也是 BA，你一定懂得：项目成功，从来不是一个人单打独斗，而是洞察每一个力量，织成一张牢不可破的支持网络。如果你也有通过 Stakeholder Map 发现关键支持者、化解潜在危机的故事，欢迎留言一起交流！

是一份有组织、有结构地记录所有与项目相关干系人的详细清单。项目发起人（Sponsor）项目经理（Project Manager）业务部门代表（Business Units）技术支持团队（IT Team）最终用户（End Users）外部供应商（Vendors）法律顾问、安全顾问、审计部门……甚至有时，政府部门或媒体任何对项目的成败有影响力、有兴趣、或有需求的人，都应该出现在你的干系人列表上。在忙碌与交付的压力中，请别忘了抬起头，看看周围那些沉默而关键的人。

Sequence Diagram（序列图），属于 UML（统一建模语言）的一种，用于展示对象、系统、用户之间按时间顺序发生的交互。它通过垂直排列的时间线，展示消息的发送、接收、执行顺序，让复杂的业务流动过程变得直观、易懂。序列图 = 系统沟通的时间电影。复杂场景，优先画序列图，别光靠嘴讲。每条消息都问自己一句：合理吗？必需吗？画完自己读一遍，看流程是否顺畅自然。每一个复杂系统，其实就是无数小对话编织成的网络。懂得描绘对话，就是在掌控系统的灵魂。用 Sequence Diagram，

Scope Modelling（范围建模），是指通过图表、文档或其他形式，明确项目、产品或分析的边界什么是包括在内的？什么是排除在外的？Scope 模型让所有利益相关者在一开始就达成一致，避免后期争议、返工和范围蔓延（Scope Creep）。Scope 模型 = 项目的护城河 + 行军地图。Scope 模型不是“多此一举”，而是“少走弯路”的秘籍。边界清晰，才能心无旁骛。每次变更，都应及时更新Scope模型，否则小变化积累成灾难。在项目之初，选择一条清晰的路径，总胜过在迷雾中奔跑。

直译为根本原因分析是一种系统的方法，用于找出导致问题发生的最底层、最本质的原因。而不是只处理表面的后果。发生了什么？为什么会发生？最深层的原因是什么？只有消除根因，问题才不会反复出现。不要害怕暴露深层问题，找出真因，才有成长的机会。多用结构化工具，比如鱼骨图+5 Whys组合，效果更佳。将RCA作为常规动作，而不是出了大事才临时抱佛脚。每一次痛苦的问题背后，都隐藏着一次组织成长的机会！表面上解决问题的人，只是灭火者；而能找到并消除根本原因的人，才是真正的系统建设者。

又称为角色与权限表每个角色（Role）负责什么每个角色拥有哪些权限查看（View）编辑（Edit）删除（Delete）批准（Approve）分配（Assign）谁，在什么范围，能做什么。每个项目一开始，就应建立并分享Roles and Permissions Matrix。在关键节点（如上线前、变更审批），用矩阵快速对齐所有人。权限管理不是小事，尤其涉及到客户数据、财务信息时。

风险分析（Risk Analysis）识别出潜在风险评估每个风险发生的可能性和影响程度排序优先级风险管理（Risk Management）制定预防措施（如何降低风险发生概率）制定应对计划（如果风险发生，怎么快速应对）持续监控和调整预判、准备、监控、应对，永远主动，不做被动受害者。世界上没有完美无缺的项目，只有敢于面对风险、善于管理风险的项目。真正的高手，不是等风来，而是提前看到风向，调整航线。作为BA，是我们手里最重要、最锋利的一把剑。让我们，每一次出发，都带着预判风暴的智慧，

目标明确：到底是确认方向，还是对细节做最终把关？角色齐全：业务、开发、测试、产品各方代表都在现场，有问必答互动充分：不是读 PPT，而是用来对齐理解、暴露风险、校正预期预先发材料，设置期待反馈的问题（例如：“这三种路径是否都覆盖到你们的实际操作？”）会上做 10 分钟 recap，讲逻辑，不讲字句留 30 分钟讨论，鼓励提问，“越尖锐越好”会后整理意见清单、更新版本，发Review 的目的是“发现分歧”，不是“装作大家都同意”。

Prototyping 是快速制作系统、产品或流程的简易版或模型，目的是让干系人能在正式开发前，提前看到和体验预期成果。手绘草图低保真线框图（Wireframe）高保真交互原型（Interactive Prototype）简单的流程模拟（Storyboard）可演示的小功能模块（Proof of Concept）关键不是“完美”，而是“快速落地”和“促进理解”。在需求的世界里，文字再美，想象空间也可能无限偏差；而一张原型图，就是打破幻想、抵达共识的第一步。

Process Modelling 不是画画。识别业务流程中的每一个步骤、角色、条件，如业务活动、参与者、决策点、系统交互、异常路径等用标准化的方法（比如 BPMN、泳道图、流程地图）把流程可视化让“谁做什么、什么时候、怎么做”一目了然帮助团队统一理解、发现问题、设计优化方案换句话说，Process Modelling是：让流程“看得见、说得清、改得动”的基础用流程图“还原世界的运行方式”作为BA，我们不只是流程的“记录员”，更是流程的“发现者”和“优化者”。

是一种系统性地识别、描述、理解和改进业务流程的技术。通过对现有流程的深入分析，找出瓶颈、浪费、风险和改进机会，为优化流程、提升效率、降低成本、提升用户体验打下坚实基础。一句话总结：只有看清每一步，才能走好每一步。清晰认知现状流程找出问题与潜力空间支撑流程再造与自动化提升业务连续性与韧性为系统建设打下坚实基础流程是企业的血脉，掌握流程分析，就能看清业务运转的底层逻辑，用系统思维和科学方法，打造出更加高效、有韧性、有生命力的组织。

简单来说，就是根据价值、紧急性、风险、依赖关系等因素，确定各项需求、任务或功能的优先顺序。它帮助团队集中精力投入到最重要、最有影响力的事情上确保有限的时间、预算和资源，创造最大的价值。做正确的事情，比把事情做正确更重要。聚焦真正重要的事优化资源使用，提升产出效率减少项目风险与返工成本提升干系人满意度支持灵活应变和敏捷交付一个聪明的团队，不是做得最多的团队，而是做了最该做的事的团队。Prioritization，让我们在复杂中清晰，在有限中创造无限。

结构层级角色分工职责与权限沟通与协作路径权力与影响网络它不是简单地画一张组织图，而是建立一份变革导航图在这张地图上，谁是“关键桥梁”，谁是“潜在阻力”，谁是“无声但强大”的影响者？系统可以部署，流程可以设计，但人和组织的协作模式，才是真正决定项目成败的核心。Organizational Modelling，不是“可选技能”，而是每一个成熟 BA 的必修基本功。用组织建模，看清复杂关系，为你的方案铺出一条真正可落地的变革之路。

是一种基于实地场景的分析方法，通过直接观察用户的行为、工具使用与流程执行，捕捉那些无法通过访谈获取的真实问题与改进机会。看见用户“说不出口”的操作痛点揭示流程文档与真实操作的差距捕捉“习惯动作”背后的隐性需求发现潜在风险与 workaround（临时替代操作）访谈说的是“他们以为自己怎么做”；观察揭示的是“他们真的怎么做”。走进现场，是一种态度；看见细节，是一种能力；理解真实，是一种专业。让我们用 Observation，练就“识别需求真相”的火眼金睛，做最懂用户的BA。

非功能性需求（NFR），指的是系统**“怎么做”而不是“做什么”**的那一部分。“这个系统的质量如何？一个系统真正的价值，往往不在“功能上做了多少”，而在“体验上做得多好”。非功能性需求，是决定系统质量、口碑与可持续性的底层支撑。作为 BA，学会驾驭 NFR，你会从“功能翻译者”，成长为真正的“系统设计合伙人”。从现在开始，不止问**“系统能不能做这件事？”**“做这件事，够快、够稳、够安全吗？

Mind Map（思维导图）是一种视觉化的结构工具，通过树状图的方式，以中心主题为核心，向外发散出关键词、子主题、细节、关系等。它不是简单的图画，而是模拟人脑的联想方式，激发理解与创造的过程工具。从中心出发层级递进关键词为主强调连接性与结构性可视化呈现大局快速捕捉灵感，不遗漏任何关键点理清复杂问题，分层次梳理信息高效沟通展示，让别人一眼看懂思路对我来说，Mind Mapping 不是“画图工具”，而是是用视觉化的方式，让大脑的思考更高效、更有条理，是一种高效的认知建模方式。

Metrics是数据，KPI是战略目标下最重要的数据。所有 KPIs 都是 Metrics，但并非所有 Metrics 都是 KPIs。术语定义关键词举例Metric（度量指标）对某一具体业务活动或过程的数值化衡量可计量、可追踪网站访问量、需求变更次数、用户登录成功率等KPI（关键绩效指标）反映关键业务目标达成程度的重要指标战略性、结果导向客户留存率、项目交付准时率等Metrics 是工具，KPI 是方向盘。偏了没？快了没？值了吗？

对我来说，一份真正有价值的 Lessons Learned，不是随便聊聊“这次还挺顺利”，而是通过结构化的方法，找到真正能提升未来项目成功率的关键洞察。问题可复现：不是“感觉不顺”，而是明确地说出“当时发生了什么”原因有拆解：是流程设计问题？职责不清？沟通方式不当？建议能落地：下一次该怎么做？具体的流程、提醒、检查项是？编号问题描述原因分析影响范围改进建议责任角色适用阶段LL-008市场需求未被采集，字段定义错误项目初期未覆盖市场团队访谈，默认使用旧字段营销模块、数据分析模块。

在复杂项目中，真正击垮团队的，往往不是巨大的挑战，而是无数个小问题的失控叠加。而 Item Tracking，就是业务分析师在混乱中维稳控场的隐秘武器。它是我们用来追踪、管理和关闭各种开放事项的一张强大清单。在我做 BA 的这些年里，Item Tracking 是我每个项目中都会自建的一套“安心系统”。它不是工具，而是一种认知习惯：凡是提过的，必须追踪；凡是未解的，必须记录；凡是责任不清的，必须钉死。在一次跨部门 ERP 系统上线项目中，早期大家总是“以为别人会处理”，每次会议都讨论得热火朝天，但没人明确负

在我做 BA 的这些年里，Interviews 是我用得最多、也最依赖的一种“信息挖掘工具”。我相信，一个 BA 的专业力，不只体现在写文档和画流程图，更在于“能不能从混沌中找出结构”。如果我没约这个访谈，只按文档建模，系统上线后肯定大翻车——因为你根本不知道，流程背后有多少“潜规则”和“灰色逻辑”。我曾经负责一个银行的信贷审批流程优化项目，系统里有个环节是“区域主管审批”，流程图里只写了一行。我常提醒团队：访谈是“关系性工作”，不是“挖信息任务”。这些问题，才能把“流程”转化为“真实行为地图”。

我们 BA 的工作，不止于“系统内部”，更在于连接系统之间的动脉血管。Interface Analysis，是让信息自由流动的建筑图纸，更是打破信息孤岛的利器。如果你也做过那些“接了接口却谁都不满意”的项目，欢迎一起来聊聊你踩过的坑，我们一起把桥，搭得更稳、更准、更通畅。

Glossary，简单来说，就是术语统一表。它收录了项目或组织中重要的专业词汇，并给出清晰、统一、权威的定义。明确：每个术语有清晰、无歧义的定义一致：全体项目组、业务方、技术方在使用时含义一致易查找：按照字母或主题分类，方便快速检索可维护：随着项目演进不断更新你可能觉得做 Glossary 是件“小事”，但实际上，它是支撑整个项目沟通体系的基础设施。很多项目不是败在技术上，也不是败在流程上，而是败在“以为大家理解一致，结果全错”的幻觉上。

Functional Decomposition，不是随意拆需求，也不是把大问题胡乱切碎。它是一种有逻辑、有系统地，把复杂业务或系统目标，分解成一系列更小、更具体、更可操作的功能组件的过程。分而治之：把大功能拆成小功能，小功能再拆成更小的子功能层级清晰：每一层都保持逻辑完整，既不过分细碎，也不过度粗糙聚焦结果：每个功能块都指向具体的业务价值或系统行为如果你也是 BA，你一定懂得：真正能驾驭复杂项目的人，不是靠硬抗混乱，而是靠一刀刀理智、清晰的功能分解，建立起属于自己的掌控感。

Focus Groups，不是单向的“用户访谈”，也不是漫无边际的“聊天会”。它是一种结构化的小组讨论，邀请目标用户或干系人围绕特定话题，分享看法、需求、痛点和期望。小组形式（通常6-12人）有明确主题（比如探讨新功能期望、改版方向）有引导者（通常由 BA 或专门的主持人担当）有讨论大纲和记录机制通过小组互动，激发出个体访谈中难以触达的深层需求和潜在观点。如果你也是 BA，你一定懂得：真正的用户声音，不是问卷里的选择题，而是面对面交流时那些一闪而过的真实表情和话语。

在变化快速、竞争激烈的商业世界里，Financial Analysis 是我透视企业底层逻辑的利器。它让我用冷静、专业的眼光，看穿表象，发现真相，制定更聪明的行动方案。

在快速变化和信息不完整的现实世界里，靠谱的 Estimation，既是专业的体现，也是信任的基石。它让我能够掌控项目节奏，在不确定性中，稳稳前行。

它并不仅仅是“翻资料”。它是通过对现有文档的结构化解读与推理当前系统或流程是如何运作的其中有哪些显性与隐性规则有哪些可能存在的冲突、不足、改进点项目干系人对“问题”或“解决方案”的既有认知你是在和系统历史对话。如果你也是 BA，你一定懂得：真正的高手，是从文档中读出“没写出来的部分”。如果你也有过“文档分析救了项目一命”的经历，欢迎留言一起探讨。我们 BA，不是信息的搬运工，而是意义的还原者。

在变化加速的商业环境中，掌握 Decision Modelling，意味着掌握了驾驭复杂决策的能力。它让我在充满不确定性的环境中，依然可以冷静推演，系统应对，成为那个能让混乱变清晰，让犹豫变果断的人。

我们 BA，不是最终拍板的人，但我们是让正确决策变得可能的人。Decision Analysis，就是我们在不确定中拿出理性判断的秘密武器。不是更聪明，而是更系统、更透明、更有力。

在数据驱动一切的时代，Data Modelling 是BA搭建信息世界的地基与骨架。它让我们BA在面对复杂需求时，依然能保持冷静、清晰、专业，成为那个能驾驭混乱、搭建秩序的人。