App外包前，先搞懂这四件事

很多团队在决定做一款 App 时，第一反应是找外包。这个判断本身没问题，但真正决定项目成败的，往往不是「找没找到外包」，而是发包之前有没有把几件基础的事想清楚。下面从独立开发者的视角，聊聊在把需求交出去之前，值得先弄明白的四件事。

一、先分清你要的是「项目」还是「产品」

项目思维是：功能清单列完，交付验收，结束。产品思维是：上线只是开始，后面还有迭代、数据、运营。这两种思维对应的外包报价和合作方式完全不同。

• 如果只是一次性工具、内部系统、活动页，项目制外包足够，按功能点报价，验收即结项。
• 如果是对外运营的产品，就要在合同里预留迭代空间，明确代码归属、后续改动的计价方式。否则第一版做完，第二次改需求时你会发现沟通成本比开发成本还高。

建议在需求文档里单独写一节「非本期范围」，把想到但暂不做的功能列出来。这既是给自己留后路，也是给外包方一个明确的边界。

二、报价差异大的原因，通常不在「贵不贵」

同一个需求，不同团队报出来的价格可能差两三倍。原因一般集中在几处：

• 人力构成：个人开发者、小工作室、正规公司的成本结构不同，报价自然不同。
• 技术选型：原生双端、跨平台框架、小程序加 H5 的组合，工作量差别很大。
• 是否含设计与测试：有些报价只含编码，UI 和测试要另算。
• 售后与质保：含不含上线后若干个月的免费修复，直接影响价格。

所以比价时不要只比总价，要把报价拆成「设计、开发、测试、上线、质保」几栏对齐再看。很多纠纷源于报价口径不一致，而不是某一方故意压价。

三、需求文档写到什么程度才算够

不需要写成几百页的 PRD，但至少要能让一个没参与过沟通的开发者看懂。一个够用的最小需求集包括：

1. 核心用户是谁，主要解决什么问题；
2. 主流程的页面清单，每个页面有什么元素、点了之后去哪；
3. 涉及登录、支付、推送、地图等第三方能力的地方，明确用哪家；
4. 后台需要管理哪些数据，谁有权限看什么；
5. 验收标准，比如「列表页能按时间倒序分页加载」这种可验证的描述。

页面流程图比文字描述有效得多。哪怕是用纸笔画完拍照，也比纯文字强。外包方按图估价，误差会小很多。

四、合同里必须写清的几条

技术条款之外，这几条建议逐条确认：

• 源码与账号归属：代码仓库、开发者账号、服务器、域名、第三方平台账号，全部归甲方，交付时一并移交。
• 验收方式与周期：明确几轮验收、每轮反馈的响应时间，避免无限返工。
• 变更机制：需求变更如何计价，按人天还是按功能点，写清楚。
• 质保范围：区分「缺陷修复」和「新增需求」，前者免费，后者另算。

一个简单的判断标准：如果对方不愿意把这些写进合同，说明后续大概率会有扯皮空间。

结语

App 外包本质是一次协作，而不是一次采购。把需求边界、报价口径、交付物归属这三件事在开工前对齐，项目就已经成功了一半。剩下的，才是选谁来做的问题。