系统分析师的能力——不是画UML是能把一句话需求翻译成可落地的系统设计

系统分析师的能力——不是画UML是能把一句话需求翻译成可落地的系统设计大部分人以为系统分析师的工作就是画用例图、写需求规格说明书。做了二十年下来我的体会是系统分析师真正的能力不是把需求写清楚是从一句话需求里读出对方没说的80%然后把它变成开发能直接动手的设计文档。这篇不讲UML语法讲的是系统分析师这个角色真正的能力维度。文章目录系统分析师的能力——不是画UML是能把一句话需求翻译成可落地的系统设计一、系统分析师不是高级需求调研员二、系统分析师的五个能力维度1. 业务翻译——把政策文档和业务语言翻译成数据模型2. 流程图读解——一个框的上下游决定了整个系统的设计3. 从现有系统反推设计——运维文档里藏着完整的数据模型4. 从零定义协议——接口不是你传我收是你我之间的一份契约5. 系统边界划分——什么放里面什么放外面三、系统分析师和其他角色的区别四、什么阶段的系统分析师才算能独挡一面五、结语一、系统分析师不是高级需求调研员很多人分不清需求调研和系统分析的边界。区别很简单需求调研告诉你用户要什么。用户说“我要在系统里看到自己的养老金发放记录。”系统分析告诉你系统应该怎么设计才能满足这个需求。这不是一个查询页面就能搞定的事——养老金发放涉及参保人信息、缴费年限计算、待遇核定规则、银行发放入账、失败补发、对账核查。一个查看发放记录的需求背后是一个完整的业务流程。如果只按用户说的做——做一个查询页面调用已有的发放记录表。用户看到了记录但他下一个问题你回答不了——“这笔钱为什么是这个数“你给他看发放明细他接着问为什么扣了这么多”。你继续展示扣款构成他又问这个计算依据是什么”这就是只做调研不做分析的后果——你在用户的追问下不是在回答问题是在补课。而系统分析的工作是在回答这些问题之前已经把数据链路和业务逻辑全部搞清楚。二、系统分析师的五个能力维度1. 业务翻译——把政策文档和业务语言翻译成数据模型系统分析师面对的第一手资料不是需求文档是政策文件、培训材料、业务流程图。养老待遇算法文档里写着基础养老金 个人指数化平均工资 省社平 × A / 2 × 缴费年限% 个人账户养老金 个人账户总额 ÷ 计发月数 如果新 老总额 老 (新 - 老) × 比例 如果新 老总额 老系统分析师的工作不是把这个公式抄进代码是翻译成数据结构个人指数化平均工资——需要哪些字段计算缴费基数从哪张表取历年省社平工资存在哪张参数表里计发月数——是固定值还是根据退休年龄查表如果这个人提前退休计发月数要不要调整新 老的判断——新算法和老算法分别存储还是实时计算如果政策变了两套算法的历史数据和外层判断标准还在不在翻译不是把政策语言变成SQL。是把一个业务规则翻译成数据模型计算逻辑异常处理策略。政策说总额为新老算法的较大值——这七个字落到系统里是两张计算结果表、一段对比逻辑、一条审计记录。2. 流程图读解——一个框的上下游决定了整个系统的设计系统分析师的日常工作之一是拿到一张跨职能流程图然后把它翻译成系统架构。全省医保结算平台的流程图上五个泳道外省社保局、全省结算平台、市县社保局、定点医疗机构、参保人。不是五条平行的线是四条不同深度的数据交互链路。本省参保人这一侧流程短——本地数据库就存了参保信息身份认证一个查询就能搞定结算过程是内部事务。外省参保人那一侧流程长——本平台对这个人的缴费记录、报销比例一无所知所以流程上多了申请审核和身份认证每一个环节本质上是在建立跨省之间的数据信任。而流程图里重复出现五次的那一个动作——“提交入库”不只是一个存储步骤。医疗费用关系到审计追溯住院信息、费用明细、结算凭证缺一个链条就断。他不是在记录数据是在给未来可能发生的争议预先备好可查的依据。3. 从现有系统反推设计——运维文档里藏着完整的数据模型不是每个项目都配有完整的需求文档。很多时候给你一份运维文档、一张表设计、一个PPT功能列表——你得从这些东西里反推出系统设计。只有HIS的表设计——一个Excel两个sheet86张表名再加一个类说明——每个模块、每个类对应哪些表、做了什么事。这两份资料放在面前系统分析师要做的不是照着看这个功能名字是什么——是顺藤摸瓜从表结构中读出业务流程。一个完整的患者在医院里的从挂号到出院结算的主链路——看gy_brxx了解患者基本信息怎么存从什么时候建档、怎么登记挂号、怎么进入诊疗环程看ms_gh了解谁来收费、怎么开票、历史挂号数据会不会影响这次就诊流程看ms_cf01看医生怎么交处方、处方怎么流动到药房和收费看yf_kcmx了解药房什么时候从系统判定这个人今天已经用了这个药看zy_brry理解入院登记的时候系统要核哪些条件、床位从哪张表里派发给病人一直到看zy_zyjs追踪出院结算时的统筹支付金额从哪些明细里累积计算而来。这86张表不是八十六个独立结构是一整个诊疗流程的物化。系统分析师面对一堆没有注释、没有说明的数据库设计直接从物理表的结构中猜出这个系统的业务流程——这不是技巧是看过的系统足够多之后你对每一类业务会有哪些核心表已经心里有数。不是瞎猜是经验推导。4. 从零定义协议——接口不是你传我收是你我之间的一份契约两个系统之间要传数据最简单的方法是什么传个JSON对方按约定字段解析。但系统分析师不能只是约定一个JSON格式——他要想的是这份JSON在不同的业务场景下会有哪些异常。医院和社保之间传费用明细不是一条处方记录到社保系统查询一下就完事。一个病人一次就诊可能有几十条处方明细、多条检验、检查、治疗。甲方说你给一个接口医院把费用传给社保社保返回报销结果。但你问甲方如果药店给了处方而医院没做发药确认——这笔费用怎么处理如果同一个病人的同一条处方明细被重复传了两次社保端怎么防止重复结算——是让医院端控制重复发送还是社保端的结算系统做幂等判断接口不只是你传我收的问题。接口背后是数据流转约束是谁负责哪些检查、谁承担哪些后果、两端分别在不完美环境下怎么做的最坏打算。系统分析师的职责不是定义接口格式是为每一个参与方明确的界限。5. 系统边界划分——什么放里面什么放外面业务功能的完整性不代表所有东西都要由一个系统包揽。系统分析的价值在于决定什么在当前系统范围什么依赖外部什么不做。当一个医保系统设计结算流程时你的决策是——费用明细结算在本系统的业务逻辑范围内银行扣款的核实归属外部银行的接口养老保险的跨省转移归属国家统一平台的对接。这些边界划清楚了合同就不会无限延伸划不清楚验收就是噩梦。边界不是拍一下脑袋就能定好的。你需要清晰的回答什么数据在本系统处理、什么数据依赖外部、如果外部系统不可用本地数据能不能临时代替核心服务。边界划好了系统的职责范围就框住了边界划歪了你不仅要维护本系统的功能还要接住外部服务未履约的责任。三、系统分析师和其他角色的区别维度需求调研系统分析架构设计输入用户说我要什么政策文件、流程图、业务文档系统分析产出的数据模型和业务规则工作记录需求签字确认翻译——把业务规则变成数据结构和流程选型——用什么技术栈、什么架构模式落地输出需求规格说明书数据模型 接口定义 业务规则 边界划分技术架构图 模块划分 技术选型一个好的系统分析师不是写需求文档的人是在需求和分析之间搭桥的人。开发拿着你的分析文档能直接开始设计表结构、设计接口、设计异常处理——不需要再去找用户确认这句话什么意思。四、什么阶段的系统分析师才算能独挡一面系统分析师的成长不是学会了UML就算出师——是能做关键决策并且能承担这个决策的后果。当你回答一个接口要把数据推到MSMQ而不是另一个API调用的时候你敢说为什么——不是因为Queue比API更可靠是基于你现在对两个系统架构的理解你知道现在最适合的路线。如果有人问六个月后如果系统迁移到新平台这个接口怎么办你能回答我在当初的决策中预留这个接口可以被替代的空间。当你把一个需求分解到几个细化的数据结构里你知道三年后这个系统能不能继续扩展、能不能应对新加的业务规则。当你分析一个系统改造方案甲方说我希望把这些信息在两个小时内实时展现在大屏幕上你不要顺着他说好我设计一个数据实时同步方案——你要先问他你这大屏幕看的是汇总统计还是明细数据、“这些数据是从一个库里跑到另一个库还是只用同一套数据转换展示形式”。系统分析师的成长不是学会了多少工具和方法论是做了多少决策承担了多少后果然后从后果中学会了做出更好的决策。五、结语系统分析师的核心能力不是画UML、不是写需求文档、不是向甲方提问。是从一句话需求里读出80%的隐藏信息然后把它翻译成开发能直接动手的设计文档。你做过的养老保险算法解读——几千字政策文件翻译成两张计算结果表的对比逻辑。你做过的医保结算流程图反推——一张5个泳道的流程图读出中间层的架构决策和5次提交入库的审计防线。你做过的HIS表结构反推——86张只给了名字的表从里面猜出一整个诊疗流程。这些不是在学校学的——是在真实项目里面对一个模糊的需求、一份不完整的文档、一套没有注释的数据结构一次次从线索中反推出完整设计的过程中打磨出来的。系统分析师的成长不是一个技能的培养而是一个不断做决策、不断承担后果、然后从后果中学会更好决策的轮回。每一份你不完整拿到的输入都是下一个可以变得比上次更快更准的机会。