1. 为什么信息化项目总是栽在需求上两个真实教训干信息化这行十几年我最深的体会是大部分项目的失败不是输在技术选型上而是死在需求阶段。你想啊代码写错了能改架构选错了可以重构但需求从一开始就偏了后面所有的工作都是在错误的路上越走越远。先讲一个我早年踩过的坑。某个制造企业要上设备管理系统业务部门提的需求是能看设备台账、能记录保养记录就行。我们归档、出方案、排计划都很顺利开发团队吭哧吭哧干了五个月系统上线当天车间主任看了一眼就皱眉头这不对啊我要的是每台设备旁边能直接扫码看到历史维修记录你们这个得先进系统再搜索操作太慢了。一句话核心场景变了整个交互逻辑要推倒重来。事后复盘才发现需求调研的时候我们只访谈了设备科的科长没去车间里看维修工是怎么干活的系统的真实使用者从一开始就没被认真对待。第二个教训是需求三天一变的失控项目。某个物流园区的信息平台需求评审会上大家都很客气业务部门说先按这个做结果开发到一半运营总监换人了新总监上来第一件事就是推翻原有的报表口径十几个统计维度全部调整开发团队加班加点改了两个月好不容易稳住版本财务那边又提了新要求所有结算数据必须和银行流水对得上精确到分。需求不断增加、不断调整项目延期九个月预算超支一倍。最后我们花了整整四个星期做需求清理砍掉四成谁都想加、谁都不负责的伪需求项目才勉强收口。这两件事让我彻底明白一个道理信息化项目的需求采集与管理本质上是在和不确定性掰手腕。业务在变、人在变、管理口径在变需求如果没有一套系统化的采集流程和管控机制项目必定失控。这篇内容我就把我这些年用下来比较成熟的需求采集方法、需求整理框架、评审和变更管理机制完整地梳理一遍。不管你是甲方信息部门的项目负责人还是乙方实施顾问或者刚入行做需求分析的同学应该都能找到直接能用的东西。2. 需求采集前的排兵布阵干系人识别与访谈策略很多人一接到需求采集任务就拿着本子去会议室找领导聊聊完回来整理一下就觉得完事了。这样做最大的问题在于——你没想清楚该找谁聊、想聊出什么、怎么聊才不会跑偏。需求采集前的准备工作至少应该花掉整个采集周期三分之一的时间。2.1 干系人清单谁才是真正的需求来源需求从来不是凭空冒出来的它寄生在具体的人身上。一个信息化系统从立项到上线至少要经过这些人的手分管领导他决定要不要做、批多少钱、业务部门负责人他代表部门提整体诉求、一线业务骨干他是每天用系统的人、IT运维团队将来系统归他们管、外部协作方比如供应商、客户如果系统存在数据对接。我的习惯是画一张干系人分析表把每个人对项目的影响力和对需求的明确度都标出来。影响力高且需求明确的人是核心访谈对象比如业务部门的副职或资深专员他们往往是实际操作流程的活字典影响力高但需求模糊的领导访谈重点是听方向、定边界而不是抠细节影响力低但天天用系统的一线员工反而要花时间跟他们聊操作场景和痛点。记住一个原则宁可多访谈一轮也不要漏掉系统上线后骂你三天的人。尤其是那些在业务链条末端的岗位比如仓管员、客服、质检员他们不参与立项但系统好不好用、流程顺不顺体感全在他们身上。漏掉了他们就等于埋了一颗上线后才会响的雷。2.2 访谈提纲设计的技巧问题要按三层漏斗来排访谈提纲不是随便列几个问题就行的。我用的方法是三层漏斗先问目标再问流程最后问痛点。第一层问目标口径是这件事你想通过系统解决什么问题注意别问你要什么功能功能是解决方案层面的东西业务人员提的功能需求往往是错的但你直接否定又容易打击积极性。第二层问流程拿一张白纸让访谈对象画一遍现在的业务怎么走——从单子进来、谁审批、用什么表单、数据录到哪个Excel里、最后结果怎么归档。这一层最出东西很多隐形流程就是这么被挖出来的。第三层问痛点要追问具体细节这个事情最花时间的是哪个环节有没有出现过因为信息不透明导致扯皮的情况细节越多需求的有效信息量越大。访谈中最容易犯的毛病是急着写结论。业务人员说一句我们想要报表能导出你马上就记下来支持导出——其实他真正的需求可能是每周要给领导发一次邮件汇报手动整理太麻烦。所以访谈纪要的格式我建议统一成原始描述需求推测把业务人员的原话和他的实际诉求分开记录回去再做交叉验证。2.3 现场跟岗的价值听来的需求永远是二手的如果说访谈是需求采集的常规武器那现场跟岗就是核弹级别的手段——有条件一定要用。我第一次到车间跟岗跟着维修师傅跑了半天看到他在现场是用一个发黄的笔记本登记设备故障回办公室再抄到Excel里。那一刻我立刻意识到系统的录入端不能设计成等维修完成回办公室再录必须做到手机端边修边录。这个需求坐会议室里访谈十次都挖不出来。跟岗不需要很长时间每个核心岗位跟半天到一天就够重点是观察三件事系统使用者在真实环境下的操作路径、现有工具Excel/纸质单据/微信的使用方式、让人多花时间却毫无价值的工作环节。这三件事正好对应了系统要优化的三个方向。3. 需求采集的五种实用方法以及各自的适用场景需求采集的方法论工具书里讲了很多——用户访谈、问卷调查、头脑风暴、联合应用设计JAD、原型法、观察法、文档分析、数据分析。但落到实际操作层面真正高频使用、见效最快的就是下面这五种。我按自己使用的频率和效果排个序顺带说说每种方法适合什么场景。3.1 方法一一对一访谈——万金油但要注意投入产出比一对一访谈适用范围最广从高层领导到一线员工都能用。优点是能深入挖掘隐性需求受访者没有压力容易说真话缺点是耗时一天能深访4个人就算效率很高了。对话时间控制在四十分钟到一个小时最好超过一个小时双方都累低于半个小时又挖不出深度。访谈地点很有讲究。在会议室里访谈业务人员往往会表演给你看讲得比较官方约在工位上聊他顺手就能打开自己天天用的Excel和系统指给你看这里就是卡壳的地方效果完全不同。所以除非对方明确要求我一般都会主动提出要不我去你工位聊。3.2 方法二业务流程工作坊——把相关人拉到一张桌子前工作坊Workshop最适合处理跨部门业务流程不清晰的情况。比如一个销售订单从下单到发货要经过销售部、计划部、仓库、物流四拨人每个人只知道自己这一段谁都不清楚完整链路。把干系人拉到同一间会议室大家带着各自的流程图现场拼接、现场对齐矛盾当场暴露。工作坊主持的关键是制造冲突并控制冲突。让两个部门代表就同一个环节的描述PK能挖出很多书面材料里看不到的口径差异。但要注意别让讨论失控变成翻旧账主持人的职责是不断把话题拉回当前流程是怎么走的和理想的流程应该怎么走这两个框架里。3.3 方法三问卷调查——适合摸用户痛点的面不适合深挖问卷适合做需求优先级的筛选和用户痛点的摸底比如面向几百个终端用户收集你希望移动端系统解决什么问题。但问卷设计有个大坑不要问开放式问题——你收到的会是希望系统更好用这种没有任何信息量的废话。要把开放题变成半结构化的选择题排序题比如列出十个候选痛点评分让用户排序这样数据才好量化处理。3.4 方法四纸质单据与Excel分析——顺着现有数据反推需求信息化系统的本质是把现有工作流里的信息载体数字化。所以翻翻现有的纸质单、Excel台账、财务报表是需求采集里性价比极高的一步。把一张销售订单从创建到归档要经过的所有字段列出来你就得到了新系统的数据字典雏形。我还会让业务部门把全年几个典型月份的Excel数据脱敏后发我做分析。看数据结构和数据质量能发现很多问题比如客户名称在三个Excel里有三种写法这就是主数据治理需求的来源比如备注字段被当作业务关键字段使用这就是字段设计需求的来源。3.5 方法五快速原型验证——用最小成本让需求现原形很多需求矛盾书面描述里根本说不清楚一看到界面就明白了。所以需求采集后段我强烈建议做一个低保真原型——用Axure甚至PPT画几十个关键页面拿给用户点一遍。用户看到原型后的第一反应往往比前面十次访谈加起来都有价值。原型验证最妙的地方是会逼出原先以为大家已经达成一致、其实并没有的问题。比如审批流的驳回方向、权限粒度、首页展示指标这些内容在需求清单上只是一句话但在原型上看一眼业务部门立刻会冒出大量真实反馈而且全部是可落地的。4. 把碎片需求钉成蓝图从用户故事到需求规格说明采集回来的需求是碎片化的、口语化的甚至有大量互相矛盾的内容。这个阶段的核心任务就一句话把用户想做什么翻译成系统要做到什么并且让它结构清晰、可验证、可追踪。很多项目到了开发中期才发现需求理解不一致就是这一步偷了懒。4.1 需求去伪存真三类最容易混进来的假需求在整理需求清单前先要会识别假需求。我总结了三种高频出现的类型第一类是解决方案型需求。用户说我们要上OCR识别发票这其实是他自己对解决方案的设想真实的业务需求是减少手动录发票的工作量、降低录错率。如果直接按OCR去做万一后续发票格式变化或者预算不够项目就卡死了。正确的做法是把解决方案需求还原成业务需求再让技术团队去评估用什么方案。第二类是个人偏好型需求。某个关键用户说我觉得页面应该把金额放在左上角加红加粗这属于个人审美偏好不算需求。对这类需求要单独记录不要进需求清单除非后面有空迭代再评估。第三类是孤岛型需求。需求描述里充满了我们部门自己用不用跟其他系统对接的假设但系统上线之后才发现数据要跟上下游系统核对。这个在评审阶段特别容易漏一定要逼着用户描述清楚数据的来源和去向。4.2 用户故事和用例两种需求表达方式的配合使用需求整理阶段我一般是双轨并行对业务人员用用户故事沟通——描述作为XX角色我希望XX以便XX优点是业务人员一看就懂对开发团队用用例沟通——精确描述前置条件、主流程、异常流程、业务规则、数据实体。两者之间要保持对应关系每条用户故事至少能关联到一个用例避免业务说一套、开发做一套。举个例子。用户故事是作为仓管员我希望在收货后24小时内能在系统里查到库存变动以便在线发货时能准确承诺交期。翻译成用例就要分解成扫码收货触发库存增加、库存变动消息推送给订单模块、订单模块根据最新库存重新确认可用量。这样开发才有精准的落地指令。4.3 需求优先级排序用MoSCoW而不是都用紧急标注所有需求整理完之后要做优先级排序我用的比较多的是MoSCoW方法分成四类优先级含义项目中的处理策略Must Have必须实现否则系统无法上线纳入一期范围开发测试全保障Should Have应该实现但可以通过变通方案临时绕过尽量纳入一期精力不够放二期Could Have有最好没有也能接受放二期或后续迭代询价评估Wont Have本期明确不做明确回复防止需求蔓延这个排序动作一定要让业务决策人拍板而不是需求分析师自己拍脑袋。把几十条需求摆到桌面上让负责人明确说出如果非要砍先砍哪五个这个决定权交出去之后后面需求变更的压力也会小很多。4.4 需求规格说明书的黄金结构需求规格说明书SRS是需求阶段最重要的交付物结构上我的模板一般是项目背景与目标业务目标、范围边界、非目标角色与权限矩阵每个角色能看什么、能改什么业务流程清单核心流程、异常流程功能需求列表按模块分组每条包含描述、优先级、验收标准数据需求关键实体、字段说明、数据字典接口需求对接系统、交互方向、数据格式非功能需求性能指标、安全要求、可用性要求验收标准场景级验收清单、用户可验收的操作路径每一条功能需求的描述我都要求必须带验收标准。验收标准的格式是当我在XX页面执行XX操作系统应展示/生成/发送XX结果耗时不超过XX秒。没有验收标准的需求到测试阶段必然扯皮。5. 需求评审里最容易踩的三个坑以及我的应对方式需求评审这个环节很多项目经理当成走个流程签个字就完事了。但根据我的经验评审会上埋的雷最后基本都会在测试或上线阶段炸出来。下面三个坑是我见过最多的也是我后来重点防的。5.1 坑一评审只叫IT业务决策人不出席有些项目需求评审会开得飞快因为参会的都是信息中心和乙方开发业务部门就派了个专员来旁听真正能拍板的人没来。结果就是会上讨论的很多问题专员不敢表态散会了再去问领导来回折腾好几个星期需求清单迟迟不能定稿。我的应对办法很简单会前打招呼明确告知业务分管领导和部门负责人必须到场并且提前把会议材料发过去要求参会人带着明确的授权来——现场能拍板的现场拍板拍不了板的当场指定一个接口人限期反馈。建立这样一个决策在场的机制后评审效率提升太明显了以前两个星期定不下来的需求清单现在两次评审会就能收敛。5.2 坑二只评审内容合理性不评审业务规则完备性有些评审会大家绕着一个页面布局、一个按钮颜色聊半天却没人认真看异常流程的业务规则。比如库存管理模块大家只确认了出库、入库的基本流程至于库存不足时订单能否超卖负库存允不允许存在盘亏了走什么审批流这些关键规则一条都没提到。到开发阶段程序员来问库存为负你们到底怎么处理业务说不可能为负测试一跑发现还真会触发最后紧急开会补规则。现在我在评审前会让需求分析师先做一轮规则完备性自检专门列出系统里所有可能的异常分支强制要求业务方给出明确的规则数据为空怎么办、数据重复怎么办、操作超时怎么办、权限不足怎么办。宁可评审会多开两个小时把规则问题当场钉死也不要让这些悬而未决的问题流向开发。5.3 坑三缺乏量化验收标准凭感觉看起来没问题需求评审通过的标准如果不是可量化的那就不算通过。早期的评审会业务方说这个报表要能导出来大家说可以需求就过了。等到开发完成业务一看说我要的是导出Excel你这导出来的是CSV又得返工。我的做法是把每条关键需求的验收标准细化到可度量比如报表导出要写清楚导出格式Excel 97-2003还是xls、含哪些sheet、合计行加底色、导出耗时上限、对千行以上数据的排序规则。需求评审会实际上应该是验收标准的评审会验收标准过得了需求才算过。6. 需求变更不是洪水猛兽变更管理与版本节奏控制就算需求采集做足了功夫变更是躲不掉也压不住的。业务环境一直在变管理思路一直在变政策要求也会变需求变更管理的目标不是消灭变更而是让变更有序、可控、有成本意识。6.1 变更的来源分类不同来源要采取不同应对我把需求变更来源分成四类变更来源典型表现应对策略业务逻辑修正之前说的XX口径理解错了应该是YY要真正确认原需求理解有误优先处理管理需求变化换了领导/新制度流程要配合调整评估影响做优先级排序政策合规要求外部监管新规数据必须新增字段必须整改排期也要让路伪需求/镀金需求顺便把XX也做了吧严格走流程附带成本和风险提示重点是最后一种镀金需求。业务方经常会说反正你们都在改了顺手把这个小功能也加上如果不设防每次变更都顺手加一点项目就会被活活拖死。我的原则是哪怕是很小的需求也必须走变更登记流程不能口头答应。口头答应一次后面所有的需求边界都会破防。6.2 变更影响分析表改一个字段引发的连锁反应处理一次变更请求最核心的动作是影响分析。我习惯让团队填一张变更影响分析表四个关键栏功能影响、数据影响、时间影响、测试影响。简单说一个字段的新增可能牵动数据字典、前端表单、列表查询、数据库脚本、导出报表、数据接口六处改动时间上至少要多三天测试上至少需要多两轮回归。把影响分析做透了很多轻松加个小需求的请求自然就退回去了。6.3 变更控制委员会与版本分批发布我参与的中大型项目一般会成立变更控制委员会CCB成员包括业务方决策人、项目经理、需求负责人、技术负责人。普通变更由项目经理判断影响范围若影响可控、工作量小于某个阈值我们通常定3个人天以内可直接进入当前迭代排期超出阈值的必须上CCB会议讨论CCB负责回答两个问题这个变更做不做、做了要砍掉哪个已有需求来换排期。还有一个务实的做法是版本分批机制。把上线计划拆成三个版本V1.0是核心业务底线Must HaveV1.1是优化增强Should HaveV2.0是扩展迭代Could Have。需求变更进来的时候先判断它属于哪个版本周期——能排到V1.1就不强行塞进V1.0这样核心版本能按期上线业务方也有了明确的期待时间变更压力被版本节奏消化掉了。7. 需求追踪与验收让每一条需求都有始有终需求管理做到最后一步是把落地的需求跟业务目标封口。很多项目在这个阶段掉链子需求清单躺在文档里吃灰开发测试各做各的最后验收的时候才发现一堆需求漏了做或者做偏了。需求追踪矩阵RTM就是解决这个问题的关键工具。7.1 需求追踪矩阵怎么维护才不变成形式主义需求追踪矩阵本质上是一张从需求到设计、到开发、到测试的映射表——每条需求对应于哪个设计文档、哪些功能模块、哪些测试用例全部列出来。维护这张表要避免两个极端一是只挂需求编号不对应测试二是表格越铺越大没人维护最后没人看。我的建议是把RTM的维护嵌入到每个迭代的日常流程里。开发排期时需求负责人按迭代把RTM中对应需求的实现状态列更新为实现中提测时测试负责人更新测试用例数和测试通过状态上线前由PM做一次RTM盘点清出没有测试用例覆盖的需求和测试未通过的需求。盘点结果如果发现有需求既没进开发计排期RTM里还挂着待处理那就在启动会上逐条过要么本周排进去要么正式申请变更调整范围。RTM的例行盘点建议每两周一次随着每轮交付逐步收敛空行到验收前基本能保证清单上的每条需求都有一条可追踪的实现轨迹。7.2 用户验收测试还原真实场景而不是按剧本演一遍验收测试UAT是检验需求管理成果的临门一脚。好的UAT应该是让用户按真实业务场景操作走一条完整的业务链条比如接到一笔客户订单→发货→收款→对账→生成报表。而不是让用户跟着预先写好的测试脚本一步一步点那样只会得到一份漂亮的验收报告和一个上线就崩的真实下场。我做UAT前一般会做三件事第一准备几套覆盖正常流程、异常流程、边界情况的完整业务数据第二让测试人员先把系统所有功能自测通过再请用户进来第三给每位参与UAT的业务用户发一张场景任务卡上面只有一个业务目标比如处理一笔库存不足的订单让用户自己想办法完成过程中发现的卡点才是最有价值的缺陷。7.3 需求冻结与上线后的需求延续系统上线不等于需求管理结束而是进入新一轮迭代。上线前一周我会做一次需求冻结新增需求一律只记录、不排期集中精力处理已发现的问题保证上线版本稳定。上线稳定运行两周后再重新开启迭代通道。上线后新收集的需求我仍然会按前面的标准流程走一遍记录→分类→影响分析→优先级排序→排期。但反馈渠道更重要我会给业务部门开通一个固定的需求反馈入口不管是周会提还是系统工单并明确说清提需求不限次数但排在哪个版本由CCB统一决策。这些年做下来我对需求采集与管理的最终体会是八个字前期做笨功夫后期才不返工。访谈多跑几趟、流程图多画几版、验收标准多抠几个字开发阶段就会顺很多。而那些跳过这步、想靠开发阶段敏捷快速迭代来修正需求的做法往往只会让项目陷入无止境的返工和扯皮。需求管理的核心永远不是流程有多完美而是你有没有真的把每一个业务场景钻透、把每一句我以为变成已验证。