变更走流程，不留口头承诺
任何范围调整都会形成一份变更说明：改什么、影响哪几个模块、需要增加多少工期。双方确认后再排进迭代，避免做到一半发现目标已经变了。
交付方式
把一个大项目拆成能验收的小段
项目最容易失控的地方，往往不是技术难度，而是范围说不清、责任分不明。j9 的做法是把整体目标拆成可独立确认的阶段，每段都有看得见的产出物。
先对齐口径，再动手开发
启动后的前两周，我们会和业务岗、审批人、财务或运营对接口逐一坐下来，把现在的做法画成流程，把数据从哪里来、到哪里去标清楚。这份材料会一直跟着项目走，后续任何讨论都以它为准，避免口头理解各说各话。
- 访谈覆盖一线操作岗与管理岗，不只对接信息部门
- 流程现状与目标状态分开描述，改动点单独列清单
- 每阶段结束提交交付物，确认后才进入下一段工作
6个可独立验收的推进阶段
12类阶段交付物与确认单
48h工作日内的响应承诺
90d上线后陪跑与优化期
实施路径
j9 项目交付的六个阶段
每一步都对应明确的动作、需要客户配合的事项，以及这一阶段结束时可以拿到的文件或可用版本。
-
需求诊断与业务流程梳理
安排 3–5 场业务访谈，把当前流程、审批节点、台账与报表来源逐一记录。我们会区分「必须本期解决」和「可以放到下一期」的需求，避免一次铺得太开。
- 《流程现状说明》
- 《需求优先级清单》
- 范围边界确认
-
方案设计与原型确认
把需求翻译成功能结构、角色权限和页面原型，逐屏和业务方过一遍。会在这一阶段明确哪些操作由系统自动完成、哪些需要人工审核，减少上线后的反复调整。
- 功能结构图
- 角色与权限表
- 可点击原型
-
系统开发实施
按模块拆成两到四个迭代，每个迭代结束提交一个可以实际操作的环境。业务方可以在真实数据上试跑，发现问题当轮提出，不必等到全部做完才第一次看到效果。
- 每周可用版本
- 迭代评审记录
- 接口对接文档
-
数据看板搭建
统一指标口径是这一步的重点。我们会和业务负责人确认每个数字怎么算、从哪张表取、什么时间更新，再搭建管理看板与异常提醒，让数据可以被追问，而不只是好看。
- 指标口径说明
- 管理看板配置
- 异常提醒规则
-
测试验收与数据迁移
按真实业务场景跑全流程测试，覆盖正常路径与常见异常。历史数据在清洗后分批导入，导入结果逐条核对，双方在验收单上确认后再切换正式使用。
- 场景测试报告
- 数据迁移核对表
- 验收确认单
-
上线运维与持续优化
上线后进入 90 天陪跑期，处理日常问题、调整配置、按使用反馈做小步优化。同期完成分角色操作培训，并把系统说明文档交给内部对接人留存。
- 培训与操作手册
- 问题处理台账
- 优化事项排期
过程保障
让进度停不下来的三件事
项目延期通常来自信息不对称。我们用三条固定机制，把可能扯皮的地方提前变成有记录的动作。
固定节奏的沟通机制
每周一次进度同步、每个迭代一次评审、关键节点一次确认会。会议结论当天发出书面记录，缺席的同事也能在两分钟内了解当前状态。
文档随项目同步交付
结构说明、接口清单、指标口径、操作手册在实施过程中持续更新，不做上线前突击补文档。内部人员交接或日后追溯，都有据可查。
节奏与配合
双方各自要投入什么
交付速度取决于配合密度。下面是我们通常会投入的角色，以及希望客户方配合的事项，方便在立项前把人力排期一起算进去。
-
客户方：一个说了算的对接人
由一位熟悉业务、能拍板优先级的管理者统一对接，避免每次确认都要开会等人。
-
客户方：业务岗按阶段参与评审
原型确认、迭代评审、验收测试各安排一场，每次 60–90 分钟，由实际操作人员参加。
-
j9：固定的项目负责人与开发小组
项目负责人全程跟进，开发人员在迭代期内不做跨项目抽调，保证上下文不中断。
-
j9：每阶段的书面交付物
阶段结束时提交文件与可用版本，双方确认后归档，进度与口径以归档内容为准。