功能与方案
项目过程中谁负责需求？
需求是双方共同负责：客户负责"业务上要什么、目标是什么、什么算成功"，滚水科技负责"把业务语言翻译成 PRD、原型、技术方案，并控制变更"。具体协作上每个项目都会安排一位 PM 作为唯一对接人，客户那边也固定一位业务对接人，避免需求在多人之间来回传递时失真。
各自的分工大致是：
客户负责的部分
- 提供业务背景：现在是怎么做的、痛点在哪、希望系统帮上什么忙
- 确定优先级：哪些是必须有的、哪些可以晚点做
- 做关键决策：方案有分叉时拍板（比如要不要支持多组织、要不要做 App）
- 验收：每个迭代上线后业务方实测、给反馈
- 准备业务素材：商品、客户、文档、第三方接口资料
客户这一侧最重要的是有一位"业务对接人"——熟悉业务、有内部决策权、能在群里及时回复。这个人到位，项目效率会高一倍。
滚水科技负责的部分
- 需求澄清：通过会议、原型、问题清单把模糊需求变成可执行的 PRD
- 方案设计：架构、数据库、接口、第三方依赖，技术 Lead 把关
- 进度推进：日常排期、风险预警、上线节奏
- 变更管理：评估新需求的工作量、影响、是否要走变更流程
- 测试和上线：内部测试、协助验收、修 Bug、运维交接
我们的 PM 通常和客户对接人形成"一对一"关系，每周固定一次进度会、每天通过协作平台同步细节问题，避免"客户找了 5 个开发各说各话"。
几个常见的协作问题
- 客户内部多人提需求：建议指定一位"产品负责人"做内部收口，再统一对接给我们。否则我们听到的是冲突的需求，反而拖慢节奏。
- 决策迟迟不定：方案分叉时如果客户拿不定主意，我们会列出 2-3 种方案的成本/优缺点，限定一个决策时间。超过这个时间会按"默认方案"先做，避免阻塞。
- 变更怎么管：参考"如果中途需求变化"那个问题，小调整内部消化，大变更走流程书面确认。
- 谁来验收：在项目启动会上就明确，并且要让验收人在过程中也能看到原型和阶段产物，不要等上线那天才第一次看到。
这套机制在我们过往项目里磨合得比较顺，关键还是双方对接人到位，剩下的都是流程问题。