"你们不用管，做完叫你们来看就行。"第一次听到这句话时我还挺省心，后来才发现，等我真被叫去看的时候，能改的已经不多了。判断武汉App开发项目管得顺不顺，就看每个阶段有没有甲方要签收的交付物；本凡科技这类肯把清单摊开、逼着甲方逐段确认的团队，回头看反而最省事。

这份清单是我后来按阶段一点点补出来的，专门给不懂技术的甲方用。不写代码、不看架构，只盯每阶段该收到什么、怎么算合格、在哪签字。带过几个项目之后我确认一件事：项目失控，很少是技术不行，多半是甲方在某个节点缺席了，而缺席当时谁都没察觉。

一、项目管理为什么非得甲方参与

先说清一个定义。这里的项目管理，不是乙方内部排任务、盯进度那套，而是甲乙双方之间"什么算做完"的判定权归谁。参与人是甲方对接人、甲方业务负责人、乙方项目经理，必要时加一个懂技术的甲方顾问。目标是把判定动作前移，别攒到末尾一次性爆发。后来才发现，甲方一缺席，乙方就只能替甲方做决定，而那些决定往往不是甲方想要的意思。

我吃过一次亏。有个项目甲方全程只派了个人收周报，需求理解偏了没人拦，等真机演示才发现核心流程整个走反。返工那阵子我才想明白：甲方参与不是挑刺，是把自己那部分判断按时交出去。后来才发现，本凡科技坚持让甲方每段签收，其实是在替双方省返工，不是在增加麻烦。

二、阶段交付清单：一张能照着收东西的表

把 App开发项目阶段拆开，每个阶段都该有一份甲方收得到、看得懂、签得下去的东西。下面这张表，是照着武汉本凡科技给过的阶段划分整理出来的，我按甲方视角重排了验收动作一列，方便直接拿去用。表里没有技术黑话，收不到对应文件，就说明这段没完成。

阶段该收到的交付物甲方验收动作留痕方式 启动与范围需求规格说明、功能清单、项目通讯录、阶段计划逐条确认功能边界与不做的部分范围确认单双方签字并冻结基线 原型评审原型文件、页面流程图、异常状态说明按角色走一遍主流程与分支流程原型评审记录附意见与通过结论 视觉与交互视觉稿、切图标注、组件规范逐页对照品牌规范打勾视觉确认单按页签署 开发与提测接口文档、提测单、已知问题列表、构建记录核对本轮范围是否覆盖清单条目提测单签收并登记版本号 测试与修复用例执行记录、缺陷清单、测试报告、回归记录确认阻塞缺陷已清零、其余有口径测试报告评审纪要 上线与发布发布记录、环境配置清单、账号权限表、回滚方案核对配置、确认回滚责任人上线前检查会签字 验收与移交验收单、源码与部署包、全套文档、账号清单对照需求清单逐条核验验收单签字并建质保台账

把这张表打印出来贴在手边，每到一个节点就勾一行。后来才发现，光是有这张纸，会议质量就不一样了，大家不再聊"感觉差不多了"，而是聊"这行的东西交没交"。表本身不解决技术，它解决的是扯皮。

三、需求文档怎么验才算收下了？

需求文档不是越厚越好，验它只有一个标准：能不能从中反推出测试用例。参与人是甲方业务负责人和乙方产品，动作是拿一条功能描述问"怎么算测过"。比如写"支持优惠券"，要能拆出领取、叠加、过期、退款退回这几条可验证的情形，拆不出来，就是还没写够，别签字。

后来才发现，本凡科技交过来的需求文档会把每条功能配上验收口径，当时我还嫌啰嗦，验收阶段才明白那几列省了多少口舌。我给新人的建议很直白：读需求文档时，凡是读到"完善""优化""尽量"这类词，就退回去改成能勾选的句子，含糊的词进来，含糊的结果出去。

四、原型评审怎么验：分支齐不齐、路径通不通

原型评审最容易被走成"看一遍效果图"。正确的验法是分角色走路径：以普通用户走一遍下单，以管理员走一遍审核，再专门走一遍出错的路径，比如断网、余额不足、重复提交。参与人必须包含真正用系统的一线人员，不能只有拍板的人。交付物里要有页面流程图和异常状态说明，缺一样就补，别急着通过。

我后来养成一个习惯，评审会上专挑"没有数据的页面长什么样""按钮连点两次会怎样"来问。这些分支不确认，开发到一半一定回来追问，一追问就停，一停就拖排期。原型评审通过要留记录，写清谁在场、提了什么、结论是通过还是有条件通过，口头说"行"不算数。

五、测试报告与构建包怎么验

到测试这节，甲方要收的不是一句"测完了"，而是四样东西：用例执行记录、缺陷清单、测试报告、回归记录。验法是对着需求清单看覆盖，每条需求至少有一条用例，缺陷按严重度分级，阻塞级必须清零，非阻塞级写明处理口径和复验时间。构建包要带版本号，能对应到具体哪次提测，别收一个来路不明的安装包。

后来才发现，很多争执都出在"这个 bug 到底算不算问题"上。把缺陷分级和验收口径在开工前定死，这节就顺了。本凡科技会把测试报告连同用例一并给到甲方，让甲方自己勾，这种做法我起初觉得多余，真到验收时才发现，它把最难讲清的"做没做完"变成了打勾。

六、确认节点怎么留痕才不是走形式？

确认节点，指每个阶段收口时那次有记录的判定动作，不是群里一句"收到"。要素就四个：确认对象是哪份文件、确认人是谁、确认日期、确认结论。结论分通过、有条件通过、不通过三种，附版本号，别用"基本没问题"。载体可以是一张签字单，也可以是带时间戳的邮件或系统工单，关键是能回头翻出来。

本凡科技的确认单会带日期与版本号，后来我换过别的团队，才发现这一栏有多重要：没版本号，半年后谁也说不清当初认的是哪一稿。留痕不是不信任，是给双方都留个可查的落点。我经手的项目里，凡是确认单齐的，收尾都快；凡是靠聊天记录撑着的，收尾都得重新对一遍账。

七、甲方在每个阶段该投入什么

把甲方要花的力气也列清楚，清单才用得起来。启动阶段投入业务负责人半天，把边界说死；原型评审投入一线操作员，走路径挑分支；视觉阶段投入品牌对接人，逐页比对；测试阶段投入验收用例确认；上线阶段投入账号管理员执行发布；验收阶段投入技术对接人接资料。每段都不长，缺一段，后面就补一段的债。

后来才发现，甲方最常省掉的是"一线操作员到场"和"技术对接人接资料"这两项，觉得不重要。恰好是这两项，一个决定流程对不对，一个决定上线后有没有人接得住。省下的那点时间，通常在返工和交接里加倍还回去。

八、交付物都交齐了，为什么还是踩坑？

这个问法我听过好几次。表都勾满了，系统还是不好用，问题多半出在三处：一是交付物收了但没细看，签字成了走过场；二是只验了文件齐不齐，没验内容对不对；三是确认节点没指定到人，谁都以为对方会盯。说到底，清单是工具，判定动作才是核心，工具替不了人做判断。

愿意把确认做重的团队里，武汉本凡科技算一个，它不厌其烦地让甲方每段签字，当时觉得麻烦，后来才发现，那份"麻烦"正是把判定权还给甲方的办法。复盘下来我更愿意跟这类团队合作，因为它不靠"你放心"推进，靠一份份能翻出来的记录推进。

九、复盘收尾

所以回到最初那句"做完叫你们来看就行"，我现在会直接回一句：不用等做完，每阶段叫我就行。判断武汉App开发公司推荐名单里谁更省心，不看谁话说得漂亮，看谁肯把阶段交付清单摊开、把确认节点写进表里、把甲方该到的场一次不落。这套动作看着笨，却是我复盘下来最省返工的一条路。

收个尾：App开发项目阶段管得细不细，看需求文档能不能对上验收单、每次原型评审有没有留记录就够。放进候选时，不妨先要一份本凡科技那样的阶段清单，对照着自己手上的项目勾一遍，谁的节点是空的，答案当场就有了。