案例数量
公司名下尚无带盖章验收的客户业绩,我们不拿数量说事,也不借他人的成果充数。能摆出来给你看的,是过程产物本身——需求文档、接口契约、门禁记录、复核结论。
实施与交付
先确认业务问题,再确定系统与 AI 的分工。我们把工作拆成可检查的阶段,用原型对齐使用方式,用接口与测试约束实现,最后按约定范围交付源码、文档和部署说明。
项目实践、人员安排与资质要求都会影响合作选择。以下说明当前情况,并明确可以检查的交付依据。
公司名下尚无带盖章验收的客户业绩,我们不拿数量说事,也不借他人的成果充数。能摆出来给你看的,是过程产物本身——需求文档、接口契约、门禁记录、复核结论。
产品经理负责需求分析、业务流程、原型与迭代协同,技术负责人负责架构、实现和运行保障。双方共同确认阶段产物与验收要求,支持你方检查或委托第三方复核。
资质情况与实际实施工作分别说明。交付文档按 CMMI 过程域组织(需求→设计→测试→验收→追溯),本公司未申请也未取得 CMMI 评级。
每一步都有可检查的产物和验收要求。具体文档与验证范围按项目规模裁剪,并在开始前与双方确认。
业务需求 → 需求规格 → 迭代需求 → 原型说明 → 接口需求 → 数据字典 → 权限矩阵 → 状态机 → 验收标准 → 需求追踪矩阵 → 变更单 → 评审清单,共 12 类。小、中、大三档项目裁剪出不同的文档集,不是每个项目都套同一份模板。
产物为分层架构视图、具名架构决策记录(每条记录写明当时被否掉的方案以及否掉的理由)、量化质量属性、风险登记册、部署拓扑,并用脚本校验模块依赖图无环。实证规模:12 章节架构基线、13 条决策记录、6 项量化质量属性、16 条风险登记、2 张部署拓扑。
实证:267 条需求 ↔ 267 个接口操作标识,逐条对应,零缺零溢,多一条少一条都要说明来由。同时产出数据传输对象与实体表的血缘映射,以及 122 个状态对象的状态机契约。
审核方不复用产出方的脚本、不采信产出方的自述,自己写一套解析器把全部数字重新算一遍,逐项判通过、不通过或需人工。判为不通过的,必须实测闭合之后才放行。
捕获页面错误并断言 JS 零错误;用上下文敏感的正则扫描开发期残留;断言导航注入正确、当前项高亮正确;再实际点通新增、编辑、状态流转、导出等关键动线,而不是只看页面能打开。
业务需求 → 需求 → 接口 → 代码 → 测试用例 → 验收标准,八列双向串联,由脚本实算覆盖率与跨模块依赖入度。未回填的列显式标注「待某期回填」,不留白假绿。
一切需要另行拍板的开放问题,都登记成带编号的台账交给你。被阻塞的项计入「不通过」,不计入「跳过」——这一条决定了交付报告上的数字能不能当真。
第四步是与常见做法的关键差别。很多交付里的「已通过评审」,评的是产出方自己写的结论、跑的是产出方自己的脚本。我们要求同一份产物由两套独立实现各算一遍,对不上就返工。
下面四条不是服务态度问题,是合同与流程上的安排。它们决定了万一合作不顺,你能在哪一步、以什么代价停下来。
每个阶段结束都设一个停止点。在停止点上你可以无违约终止合作,仅结算通过验收的那些阶段的费用,未开工的阶段不产生任何费用。
首阶段以小额启动,你先看到真东西再决定要不要往下走。该笔金额抵扣总价,不重复收费——它是总价的一部分,不是另收的门槛费。
范围之外的需求不口头加塞:2 个工作日内出评估单,写明工作量与对进度的影响;经你书面确认后才实施、才计费。未确认的,不启动、不计费。
每引入一个组件都实测许可证原文,不凭记忆下结论;记录来源、校验值与核对日期,登记成开源件清单随交付一并附送。这套做法已经实测纠正过三处凭记忆会写错的许可事实。
审查方与产出方分离,审查方不采信产出方的自述。复核结论连同未闭合的部分一起给你,而不是只给一句「通过」。
我们把结论原样写出来,包括它不是「审核通过」这件事。一份从不出现「有条件通过」的复核报告,本身才更值得怀疑。
这些产物的价值不在体量,而在于每一项都能被独立重算、被逐条追回它对应的那条需求。你需要的时候,我们把重算用的脚本和判据一并交给你,或者交给你指定的第三方。