小程序为什么一定要先定需求？改需求的代价有多大

小程序改需求不是改几句话，改的是原型、界面、后台逻辑、测试用例和上线排期。本文算清一次需求变更的真实成本，给出需求该在什么阶段定、哪些能改哪些别改，以及五步把需求锁定在开工前的方法。

一句话改需求，背后动的是五处

「这个页面加个筛选就行，很简单。」这句话在项目里几乎每周都会出现。听起来像是加个下拉框，实际牵动的东西可能远超预期。

一个筛选条件的背后，通常要做这些事：数据库加索引、接口加参数、前端加交互、后台管理加配置项、测试补用例。如果这个页面已经被其他功能引用，还要回归测试受影响的路径。真正的工作量往往是最初那句话的几倍。

青梅睿创在定制开发项目里见过太多这样的例子：项目延期很少是因为开发慢，多数是因为需求一直在动。

一次需求变更的真实成本

把变更成本拆开看，会更容易理解为什么要控制。

这张表的结论很直接：同一个改动，在需求阶段提出来几乎不花时间，在测试阶段提出来可能就是一次项目延期。它不是供应商在抬价，而是工程本身的规律。

为什么需求总在开发阶段才想清楚

因为大多数人在看到东西之前，很难说出自己要什么。这是人之常情，不是谁不专业。

需求阶段的描述是抽象的：「要有会员体系」「要能看数据」。等到原型出来，才突然具体起来：「会员要能分等级」「数据要能按门店看」。看到实物才会产生真实判断，这是认知规律。

所以正确的做法不是要求客户一开始就想到所有细节，而是缩短反馈回路：多用原型、多用参考截图、早一点看到能点开的东西。看得越早，改得越便宜。

哪些能改，哪些轻易别改

把需求分成三类，处理方式完全不同。

第一类：业务流程变更。 比如原来一单一结，改成可以挂账。这类改动动的是数据结构，几乎是重做一半。轻易不要在中途改，宁可二期做。

第二类：字段和规则增减。 加一个字段、改一个校验规则、调整一下排序。这类改动相对可控，但要评估影响范围，尤其要看有没有统计报表依赖这个字段。

第三类：界面和文案调整。 颜色、间距、按钮位置、提示语。这类改动成本最低，可以放到最后统一走一遍。但要注意，界面反复改同样会消耗排期，最好集中一次性提完，不要今天改一点明天改一点。

把需求锁在开工前的五步方法

第一步：先写业务流程，不写功能列表。 从客户下单/用户进店开始，一步步写到结束，每一步写清谁在什么情况下做什么。流程理顺了，功能自然就出来了，而且不容易漏。

第二步：用原型代替口头描述。 哪怕手绘草图也比纯文字强。原型上标注清楚每个按钮点了会发生什么，比开三次会有效。

第三步：把「必须有」和「可以有」分开。 首版只做必须有的，可以有的一律进二期清单。这份清单双方各留一份，是后续谈变更的依据。

第四步：找真实的业务人员过一遍。 老板点头不代表一线能用。让实际会用系统的人走一遍原型，往往能提前发现一堆问题。

第五步：变更走书面确认。 变更内容、影响范围、是否影响排期，写清楚再动手。微信聊天记录也算，但要归档到一个固定位置，不要散落在多个群。

变更不可怕，混乱才可怕

完全不变更的项目几乎不存在，也不应该是目标。市场在变，需求自然在变，把所有变更都拒掉的项目往往上线即过时。

真正要避免的是无记录的变更。两个常见后果：一是项目结束时双方对「做过什么」记忆不一致，容易吵；二是排期不断被蚕食，最后没人说得清为什么延期。

一个低成本的做法是设一个变更清单表，每项写四条：变更内容、提出时间、影响的工作量、是否进本期。哪怕不做严格评估，记下来就能减少大半纠纷。这也是北京青梅睿创科技在项目交付时会一并提供的表格之一，客户用不用都行，但建议留着。

需求定得清，报价才准

需求不清还有一层影响，容易被忽略：报价会虚高。

供应商在需求模糊时报价，必然要留出应对不确定性的余量，这个余量最后是客户付的。反过来，需求清单清楚的项目，供应商敢按实际工作量报，总价往往更低，排期承诺也更敢给。

所以把需求定清楚，不只是省变更的钱，也是省报价的钱。

常见问题

问：需求一定要全部定死才能开工吗？

答：不用全部定死，但核心业务流程必须定清楚。界面细节可以边做边调，业务逻辑最好不要边做边改。

问：中途加需求加钱合理吗？

答：看合同约定。多数定制合同会写明首版范围，超出范围按变更处理。关键在于首版范围写得够不够具体。

问：能不能先做一个能用的版本，再慢慢改？

答：可以，这也是比较推荐的做法。但要注意首版的架构和数据模型要设计到位，否则后期改动会非常伤。先做小、做对，比先做大、做糙更好。

问：需求文档要写多细？

答：写到别人照着能做出一样东西的程度就够了。不用写成教科书，但每个功能的操作路径和结果要明确。

问：供应商说改需求要加两个月，可信吗？

答：可以要求拆开算。让供应商说明改哪些模块、动多少工作量、影响哪些测试。说得清的通常是真的，说不清的可能是在推脱或者压价时留了坑。

问：需求阶段要花多久？

答：小项目三五天，中等项目一到两周。这段时间看起来没产出，实际是整个项目性价比最高的一段。

小结

需求变更的成本随阶段呈指数上升，这是工程规律，不是谁在吓唬人。控制变更的关键不在拒绝变更，而在缩短反馈回路、把核心逻辑定在开工前、把变更记下来。青梅睿创做定制开发时，通常会把需求确认和原型评审作为两个独立节点，客户签了字再进开发，这一步多花的几天，基本都能在后面省回来。