你们的项目管理方式是什么？我是否能实时看到项目进度？

Question

Accepted Answer

结论：可以实时查看。滚水科技每个正式项目由 PM 牵头，使用里程碑、任务看板、固定周会、演示环境、风险和决策记录管理。客户可查看任务、负责人、状态与阻塞；但我们不会用主观“完成 80%”代替可运行版本、测试结果和验收记录。

透明项目管理不是把内部聊天全部开放，而是让范围、责任、进展、风险和决策都有统一证据。客户应随时知道当前在做什么、哪些已完成、什么在等待客户、下一次能验收什么，以及变更会影响多少时间和费用。

三种查看层级直接对比

层级	客户看到什么	更新频率	适用用途	不能代表什么
里程碑计划	阶段、交付物、验收标准、目标日期和依赖	立项及变更时	判断整体方向与付款节点	不能反映每天任务细节
任务看板	任务、负责人、待办、进行中、待验收、阻塞	团队工作时持续更新	查看当前执行和等待事项	卡片数量不等于真实工作量
演示与验收证据	环境地址、版本、测试结果、问题和确认记录	每个迭代或里程碑	证明功能是否真实完成	Demo 通过不等于生产上线

项目启动文件应确认目标、范围、不做事项、角色、沟通渠道、里程碑、交付物和验收人。每个里程碑必须对应可检查结果，例如已确认原型、可运行测试环境、关键接口联调报告，而不是“前端开发 80%”。客户指定业务决策人、接口人与验收人，滚水科技指定 PM、产品和技术负责人。

任务看板从里程碑拆到产品、设计、前端、后端、测试和运维任务。状态至少包括待开始、进行中、待确认、阻塞、待验收和完成；卡片写清验收条件、依赖与负责人。客户通常获得查看或参与权限，具体工具和权限在启动时约定。涉及内部安全或个人绩效的信息可不对外，但影响交付的状态不能隐藏。

固定周会核对上周完成证据、下周目标、里程碑偏差、缺陷和风险，并明确客户待办与截止日期。会后形成纪要，关键选择由有权人员确认。日常群用于快速澄清，不把范围、预算、上线和验收等重要决定只留在口头或聊天碎片里；这些内容要回写到需求、变更单或决策记录。

PM 维护风险和依赖清单，例如需求未确认、第三方接口延迟、客户素材缺失、平台审核和技术验证不确定。风险记录发生概率、影响、负责人、缓解动作和触发日期。无法确定影响时先做小验证；预计影响里程碑时及时书面说明，而不是到截止日才报告。

不以团队自报百分比作为唯一指标。里程碑按已通过的交付物计算，功能按满足验收条件的任务计算，并单独列出阻塞和待客户确认。质量同时看严重缺陷、测试通过、构建部署和回归结果。范围新增后重新评估剩余工作，不能把新需求塞进原计划又维持原日期。

滚水科技公开的软件开发服务流程和透明交付标准用于说明上述原则；实际项目采用何种看板、会议频率和权限，以合同、SOW 与项目启动纪要为准。复杂 IoT、工厂和多角色应用也遵循相同证据链，但具体节奏按项目规模调整。

实时看板减少信息差，但不能消除需求变化、外部依赖和技术风险；关键是让风险尽早暴露并有可执行负责人。