ARTICLE · 998865
软件开发合同避坑02:需求清单为什么必须做合同附件?
--------------------------------
找人开发一个小程序、APP或者管理系统，签合同的时候，经常会看到这样一句话：
“乙方按照甲方需求完成系统开发。”
这句话看起来没什么问题。
但真到了项目后期，双方最容易争的恰恰就是两个字：
“需求”
甲方说：
“这个功能我一开始就说过。”
开发方说：
“合同里没有，报价的时候也没包含。”
到了这一步，再翻聊天记录、语音记录、会议记录，项目基本就已经进入扯皮阶段了。
01 软件开发最怕的，不是需求多
真正麻烦的是：
双方对“到底要做什么”理解不一样。
举个很常见的例子。
需求里写了一个：
“会员管理功能”
这5个字到底代表什么？
是只需要查看会员列表？
还是需要会员等级？
要不要积分？
要不要余额？
要不要标签、筛选、导出、充值记录、消费记录？
如果需求清单里只有几个大标题，双方虽然签了合同，实际上对项目范围还是没有真正达成一致。
02 为什么不能只靠微信聊天记录？
很多项目在签约之前，会聊很长时间。
微信里可能有几十张截图、几百条聊天记录，甚至还有大量语音。
但开发真正开始以后，你会发现一个问题：
今天说的内容，可能第二天又改了；
销售理解的是一种意思，产品经理理解的是另一种意思；
项目做到一半，再回头翻聊天记录，很难确认最终版本到底是哪一个。
所以聊天记录适合沟通需求，
但不适合长期充当项目的唯一需求标准。
03 需求清单为什么一定要做合同附件？
核心原因只有一个：
把“双方聊过什么”，变成“双方正式确认要做什么”。
一份比较完整的需求附件，至少应该能够说明：
① 系统需要做哪些端？
② 每个端包含哪些功能模块？
③ 每个模块具体需要实现什么？
④ 哪些内容属于本次开发范围？
⑤ 最终验收按照什么标准判断？
最重要的是，合同正文里最好进一步明确：
需求文档属于合同组成部分，双方按照需求文档确定开发范围，并作为后续验收的重要依据。
这样需求清单就不再是一张普通的功能表，而是真正和项目交付挂钩了。
04 需求清单还有一个作用：防止无限加需求
软件开发过程中还有一种特别常见的情况：
项目开始的时候，只说做A、B、C三个功能。
做着做着，又增加了D。
后来又觉得E也应该有。
到最后，最开始报价5万元的项目，实际工作量可能已经变成了8万元甚至10万元。
如果没有明确的需求附件，甲方会觉得：
“这些不都是系统应该有的吗？”
开发方则会觉得：
“这明明都是后加的需求。”
所以需求附件不仅保护甲方，也是在帮助双方划清项目边界。
05 需求清单不要只写“大功能”
这一点也很关键。
有些合同附件看起来有两三页，但仔细一看，全是这种写法：
会员管理
订单管理
商品管理
数据统计
这种其实还是太粗。
比较稳妥的方式，是继续往下拆。
例如：订单管理
订单列表
订单详情
订单状态
订单搜索
订单导出
拆得越明确，后面双方理解偏差越小。
06 签合同前，重点检查这5件事
01 有没有单独的需求文档或功能清单？
02 需求有没有拆到具体功能，而不是只有几个大标题？
03 合同里有没有明确需求文档属于合同附件？
04 后续验收是不是按照已经确认的需求范围进行？
05 新增需求和需求变更，费用、工期怎么处理？
很多人觉得需求清单只是开发人员看的东西。
其实从合同角度看，
它解决的是整个软件项目里最重要的一件事：
这笔钱，到底包含做什么。
项目开始之前多花一点时间，把需求清单确认清楚，
往往比项目做到一半以后再争“这个到底算不算需求”，省事得多。
更多作品集在这里~^_^~
