需求分析师林晓：把模糊的“想要”翻译成能落地的清单
林晓在pg.comPG做需求分析已经好几年了。她常说，客户第一次坐下来聊的时候，十有八九说的是“我们想要一个看板”或者“能不能把数据都汇总起来”。这些话本身没有错，但离一份能交给开发的需求清单还差很远。她的工作就是坐下来，一条一条问清楚：看板给谁看、多久看一次、看到异常之后准备做什么动作。
有一次，一家做仓储服务的企业找到pg.comPG，希望把出入库数据“管起来”。林晓没有急着画原型，而是先跟着对方的库管员走了两趟现场流程，回来之后把原来的一句话需求拆成了十几条具体场景。她说，需求表上的每一行背后都得站着一个真实的使用者，否则功能做得再漂亮也没人点开。pg.comPG内部有个习惯，需求评审时如果讲不清楚“谁在什么情况下用”，这条需求就先挂起。
- 先看业务动作，再看数据字段，顺序不能反
- 每条需求都标注使用角色和使用频率
- 需求文档保留修改痕迹，方便客户回看沟通过程
数据工程师周维：清洗规则写在明面上，客户才敢用
周维负责数据接入和治理环节。他遇到最多的情况是，客户业务系统里的数据看起来齐全，一跑统计就对不上。他的处理方式不是悄悄改掉，而是把每一条清洗规则都列出来，和客户逐条确认。比如同一家供应商在系统里有三种写法，合并规则怎么定；退货单的时间字段该取创建时间还是审核时间，这些都要落在纸面上。
在pg.comPG的项目流程里，数据治理文档和代码一样重要。周维说，客户不需要懂技术细节，但需要知道自己的数据被怎么处理了。他习惯在每次阶段汇报时留出十几分钟专门讲“这次改了什么、为什么改”，很多后续的信任就是靠这些不起眼的说明积累起来的。pg.comPG的团队也因此在项目早期就把数据质量的责任边界讲清楚，避免上线后互相猜测。
交付顾问陈曼：上线不是终点，是第一次真正磨合
陈曼负责项目交付后的陪跑。她认为，系统上线那天往往是客户最紧张的时候，因为所有假设都要接受真实业务的检验。她的做法是上线后保持高频沟通，把用户反馈分成“影响使用”和“影响体验”两类，前者优先处理，后者排进迭代计划。
有一次报表口径在月末结账时出现争议，陈曼没有直接给结论，而是拉着客户财务和业务两边一起把计算逻辑从头到尾走了一遍，最后发现是统计范围的理解不一致。这件事之后，客户主动提出把口径说明写进内部操作手册。陈曼说，pg.comPG做项目不喜欢把交付当成一锤子买卖，很多合作关系的深化恰恰发生在系统跑起来之后。她手边常年放着一份沟通记录，每次和客户聊完都会补上几行，这些零散的记录后来成了复盘时最有用的材料。
从林晓的需求表，到周维的清洗规则，再到陈曼的陪跑记录，pg.comPG的项目组里没有那么多戏剧性的时刻，更多是把一件件事说清楚、记下来、跟到底。对客户来说，了解这些普通角色的工作方式，或许比看一份漂亮的服务清单更能判断合作是否合拍。
