PG官网

  一个客户的项目做了一半，看到 demo 后提了个新想法：想在现有订单系统里加一个会员分销返佣的功能，让老客户推荐新客户下单能拿提成。开发方评估完回了一句：这属于新增需求，要加钱，周期还要延两周。客户当时就急了，说当初谈的时候不是说好的吗，怎么做到一半又要加钱。

  这事我们做这行每年都要处理好几起，几乎每个定制项目中途都会遇到。先别急着判断谁对谁错，把 "改需求" 这件事拆开看。大部分扯皮，都源于把三种完全不同的情况混成了一种，互相觉得对方不讲理。

第一种，真新增功能，该加钱

  原需求清单里没有的东西，要新做一个完整模块，这种情况加钱延期是合理的。比如原计划就是一个标准商城，客户下单、付款、看物流，现在要加分销返佣、多级代理层级、佣金自动结算、提现审核。这已经不是 "界面上改一改" 了，等于另起了一个新的功能模块，要重新设计数据库表结构、写后台接口、做管理端配置页面、还要测各种分佣边界情况。

  客户觉得 "我就加这么一点功能"，但开发的工作量不是按 "看着东西多不多" 算的，是按动了多少底层代码算的。合同当初签的就是原范围的活，范围变了，价格和周期跟着变，这是行业惯例，不是开发公司故意坑人。判断标准就一条：需求文档里有没有写过。写了，那是开发该做的；完全没提过，就是新增。

第二种，当初没说清楚，不该加钱

  需求文档里写得太模糊，开发按自己的理解做出来了，客户要的是另一个东西。比如文档里就写了一句 "订单管理"，开发理解成 "能看订单列表、改状态"，客户心里想的其实是 "能改价格、能拆单合并单、能导出对账单给财务"。这不算客户新增功能，是当初需求阶段没有把边界问清楚。

  这种情况扯皮最多，双方都觉得自己有理。判断标准也很明确：翻回当初的需求文档，里面有没有对应描述。写清楚了，开发没做到，那是开发的问题，不该加钱；根本没写清楚，那就是双方都有责任，不该由客户单方面承担加钱。成熟的做法是开发方在需求阶段就把模糊的地方挨个确认，而不是做到一半才说 "你当初没说这个"。

第三种，小调整，不该加钱

  改个按钮文案、调个位置、换个颜色、修个显示不对的地方，这些都属于正常开发过程里的小修改，根本不该算变更、不该加钱。成熟的开发公司一般会在项目里留一部分免费修改量，就是给这种小调整准备的。

  最怕的是开发方把小调整也打包进 "变更" 里收费，或者反过来，客户把 "加一个新模块" 也当成 "小调整" 要求免费做，两边预期差太远，后面就没法合作了。

真正该防的，是三种混在一起算一笔糊涂账

   实际扯皮里最常见的，就是客户提了一个 "感觉不大" 的需求，开发报价的时候把 "小调整" 和 "真新增" 混在一起打包报，一笔糊涂账，客户觉得被宰了。或者反过来，开发方怕得罪客户，小修改也接、大功能也含糊应下来，做到一半才发现工作量远超预期，开始拖进度，最后两边都不满意。

   避免扯皮其实不难，三条规矩立在前面就行。一是需求阶段写细，什么功能做、什么明确不做，列成清单双方签字，模糊的地方挨个问清楚，这比做到一半扯皮成本低得多。二是变更走书面，微信群里随口说一句不算，要写个简单的变更确认单，写清楚加什么功能、加多少钱、延多久，双方确认了开发再动手。三是分批做，别把一整年想做的功能全塞进一期，先把核心流程跑通上线，后面要加什么，二期再排，灵活度也大。

  做软件中途改需求，几乎是不可避免的事。老板看到实际跑起来的东西，才会冒出新想法，这很正常，不是客户事多。问题从来不在 "变了" 这件事本身，在于变的时候有没有规矩。

  规矩立在前面，变更就是正常的协作；规矩没有，每一次改需求都是一次吵架，项目做到最后，双方心里都憋着一口气。