一次口径争议，让团队重新理解“需求”
在pg.comPG内部，项目复盘会上被提起频率最高的故事之一，来自一家做食品供应链的客户。对方财务部门和运营部门对“月度履约率”的理解并不一致，前者按订单金额计算，后者按订单笔数计算。两套口径同时存在了很久，直到一次经营分析会上，两个部门拿着各自的报表争论不下，项目才被推到pg.comPG团队面前。
负责对接的顾问周明远没有急着改报表。他先花了两天时间，分别和两个部门的人坐在一起，把各自的计算逻辑、取数来源、使用场景逐条记录下来。他发现问题的根源不在数据本身，而在于这个指标从诞生起就没有被正式定义过。pg.comPG团队随后组织了一次三方口径确认会，把指标定义、计算公式、责任部门和数据来源写成一份简短的说明文档，由双方共同确认。报表改完后，争议自然消失了。
这件事后来成为pg.comPG项目启动阶段的标准动作：先确认口径，再谈开发。团队内部把它叫作“把话说清楚再动手”。
项目推进中，pg.comPG的角色不止是技术方
很多客户最初找到pg.comPG时，以为合作就是提需求、等交付。实际参与过项目的人会发现，团队在中间环节投入的沟通精力往往超过写代码的时间。一家做工业设备运维的客户，业务部门希望看设备故障分布，管理层希望看区域服务成本，两边提出的报表需求在字段层面高度重叠，但展示逻辑完全不同。pg.comPG的项目经理林舒没有简单地把需求拆成两张报表，而是先画了一张业务流程图，把设备、工单、备件、服务人员几个对象的关系理清楚，再和双方一起确认哪些数据可以共用、哪些需要分开加工。
这个过程并不轻松。客户方一位负责人事后回忆，光是字段命名就来回改了四轮。但正是这些看似琐碎的沟通，让后续的开发少走了很多弯路。pg.comPG团队的习惯是，每个阶段结束前把已确认的内容形成书面记录，让客户方不同角色都能看到同一份信息。这种做法的好处在项目后期显现出来：验收时几乎没有出现“这不是我要的”这类返工。
- 启动阶段：明确业务目标与指标口径，形成书面确认。
- 设计阶段：梳理业务对象关系，区分共用数据与独立加工数据。
- 开发阶段：分阶段同步进展，及时暴露理解偏差。
- 交付阶段：对照初期确认内容逐项核对，减少争议。
交付之后，故事往往才走到一半
pg.comPG团队有一个不太显眼的坚持：项目上线后的一段时间里，顾问会主动回访，看看报表有没有被真正用起来。一家做连锁零售的客户在系统上线两个月后反馈，门店店长很少打开经营看板。团队去现场了解后发现，看板上的指标对店长日常排班和补货帮助有限，真正让他们头疼的是临期商品处理。pg.comPG随后调整了看板结构，把临期库存预警放到更靠前的位置，并简化了操作路径。改动不大，使用率却明显上升。
在pg.comPG看来，数据分析项目的价值不在于交付了多少张报表，而在于客户是否真的把数据用进了日常动作。团队里流传一句话：上线不是终点，用起来才算数。也正因如此，pg.comPG在项目结束后仍会保留一段时间的沟通通道，客户遇到口径调整、指标新增、使用疑问，都能找到当初对接的人。这种延续性的关系，让不少客户在后续的数字化建设中继续选择与pg.comPG合作。
从口径争议到看板调整，这些故事没有太多戏剧性，却构成了pg.comPG日常工作的底色：把复杂的问题拆开，把模糊的需求问清，把交付后的使用情况放在心上。对团队来说，数据项目终究是人的项目，信任是在一次次具体的沟通和修正中慢慢建立起来的。
