PG官网

  去年有个做仓储的客户找我聊返工的事。项目做了三个月，上线第一周，拣货员在仓库里骂人，系统规划的取货路线绕着货架走，明明隔壁就有的货，非要跑到另一头。老板把开发叫来，开发打开需求文档，说当时就是这么写的。老板转头问 IT 主管，主管说他不懂拣货，当时问过业务，业务回了一句「按现在的来就行」。

  还有一次更典型。退货流程调研时，业务部门没人到场，IT 主管凭印象讲了一遍，开发照着做了。上线后客服说退回来的货要拆成良品和不良品分别入库，系统只有一个「退货入库」按钮。这一改，牵动库存、财务、报表三个模块，报价单拉了满满一页。

  这类返工，怪不到开发头上。调研阶段没到场的人，后面都会以返工的形式补上。

一、只让 IT 一个人对接，问题出在哪

  IT 熟悉的是系统、账号、服务器、接口，具体业务动作是业务员每天在做。拣货先取哪一排、退货怎么分良品和不良品、对账差一分钱怎么处理，这些问题 IT 答不上来，只能回去问，问一圈再转述给开发，信息已经走了两道手。

  一个人对接，所有细节都靠二手转述。业务随口说一句「差不多就行」，到开发那里就变成一条确定规则，中间没人追问这个「差不多」到底差多少。等系统上线，操作员发现不是自己想要的，开发翻出文档说白纸黑字写着，双方都没撒谎，问题出在传话的人身上。

  更要命的是决策人不在场。要省一个人工步骤还是多一道审核，IT 主管不敢拍板，开发只能挑最简单的做法。范围、优先级、预算这些事，本该在会上一次定清楚，结果变成会后一层层请示，项目还没开工就先拖了两周。

二、该到场的三种人，少一个都别扭

• 第一种是业务实际操作人。每个关键岗位来一个，仓库拣货、客服退货、财务对账，谁天天干这个活就谁来。不用领导替他们发言，领导讲的流程往往比实际少两步。

• 第二种是能拍板的人。老板或者项目负责人必须在场，预算、范围、工期冲突的时候当场定。很多项目开会时全是执行层，谁也不敢说「这个不做」，会议纪要写得满满当当，回头一样都落不了地。

• 第三种是 IT 对接人。他负责系统边界、账号权限、接口条件、部署环境这些技术约束，同时把业务的话翻译成开发能理解的语言。他不替业务回答业务问题，只负责把问题问到位。

  一场调研会别超过六七个人。人一多就开始客气，真问题反而没人提。业务和 IT 分开坐，谁负责哪块写清楚，比一屋子人点头有用。

三、会上必须问出来的四类细节

• 第一类是角色和场景。谁在什么情况下做什么，单据怎么流转。拿退货来说，客服登记、仓库收货、质检判定、财务退款，四步四个人，每步的输入输出都不一样。只写一句「支持退货」，开发只能凭经验猜。

• 第二类是现在怎么做的。让业务把正在用的单据、表格、微信群截图拿出来，照着讲一遍。嘴上描述的流程和实际跑的流程，经常差两步，那两步往往就是系统上线后最容易被骂的地方。

• 第三类是异常情况。缺货怎么办、退货怎么算、审批被驳回回到哪一步、客户重复提交怎么处理、网络断了能不能先记账。正常流程谁都会讲，异常才是真正的工作量，也是后期变更最集中的地方。

• 第四类是数量和峰值。一天多少单、月底多少单、活动期间翻几倍，这些数字决定表结构、查询方式和服务器配置。还有哪些行业习惯不能动，哪些监管要求必须留痕，也要在会上点出来，别等上线了才说要改。

四、纪要怎么确认，才不算白开

  纪要当天出，控制在一页纸，按角色分段。仓库只看仓库那一段，客服只看客服那一段，别扔一份二十页的文档让老板签字，没人看得完，签了也等于没签。

  写纪要要用业务的话，别写「实现库存批次维度管理」这种。写成「退货要分良品和不良品，分别入库，良品可以再销售」，操作员一眼能看懂，看不懂的地方就是还没问清楚的地方。

  每条后面留一个确认栏，让实际操作人回一句「是」或者「不是」。邮件回复、群里确认都行，截图存档。原型出来以后再对一遍，文字能藏住歧义，点开页面藏不住。

  纪要真正的作用，是给半年后可能吵架的双方留个凭据。当时谁确认的、确认的是哪一版，白纸黑字摆在那里，比在会上争谁记错了有用得多。

  回到那个仓库客户。后来补做了一次调研，拣货组长到场，拿着一张手绘的库位图，二十分钟讲清了哪条路线顺、哪个区要先取。开发改了两周，返工费没再提。

判断标准很简单，调研会上有没有那个每天亲手干活的人。有，后面省事；没有，后面补课。