PG官网

  项目做到验收前，客户在群里发一句，帮我在列表上加个导出，最好能按月份筛。销售回得很快，可以。开发打开代码，先问了一句，哪个列表，导哪些列，给谁看。群里安静了十分钟。这个场景在很多定制项目里都出现过，客户觉得只是加个按钮，开发却知道，按钮后面还有一串没露头的东西。

一、小功能一进系统，牵动的往往不是一处

  客户看到的是一个导出按钮，开发看到的是按钮背后的数据来源、字段口径、权限范围和异常处理。列表里的数据可能来自三张表，导出还要走异步任务，文件大了要分片，空数据要提示，失败要能重试。按钮只是入口，后面每一环都要有人接。

  很多小功能之所以显得小，是因为它只被看见了一个角。客户在页面上点一下，觉得这件事十分钟就能做完。开发要把这个动作拆开，先确认数据从哪来，再确认谁能看，还要确认导出以后拿去做什么。少一个字段，文件就缺列；多一个筛选条件，旧索引就可能失效；权限没想清楚，客户拿到文件就能看到别人的数据。

  老系统里还有一层麻烦。同一个字段在三个页面有不同叫法，同一个状态在接口和数据库里对不上。改一处，另外两处跟着报错。开发表面上在加功能，实际在给旧账做整理。这部分时间不会写在报价单上，但一定会落在排期里。

  客户听到的两周，背后往往有十几件小事要处理。开发没有故意留余量，只是这些事不写在按钮上。小功能进了系统，就不再是一个孤立的按钮，它会和原来的数据、权限、流程绑在一起。绑得越深，改起来越慢。

二、改一处要回归一片，测试成本最容易被忽略

  代码改完只是开始。一个列表页的筛选条件变了，和它共用查询条件的分页、排序、统计、导出都要重跑。一个按钮加上去，权限、日志、消息通知、移动端适配也要跟着看。测试不能只点两下看看能不能打开，还要把受影响的路径一条条走完。

  很多项目没有自动化测试，回归靠人点。人点就有遗漏，遗漏就流到客户现场。上线后客户说，导出是好了，但统计数字不对。再查，是筛选条件只改了一个入口，另一个入口还在用旧参数。这种返工的时间，常常比开发本身还长。

  环境也会拖时间。开发环境的数据和客户现场不一样，测试环境的外部接口又经常断。一个导出功能在本地跑得通，到客户机房就卡在文件写入权限。小功能要上线，得把环境、数据、权限和外部依赖一起验一遍。这些活看不见，但都要人做。

  还有一类问题来自历史数据。客户现场跑了几年，表里有空值、有重复、有格式不一致的旧记录。新功能一上线，先把这些旧数据翻出来。开发要补兼容，测试要造数据，客户还要确认哪些能改哪些不能改。一个小功能，收尾变成一次数据清理。

三、排期不是只看开发，还要抢版本窗口和人力

  开发手里通常不止一个项目。今天修线上问题，明天配合客户验收，后天还要写投标材料。一个两天的小功能插进去，就要把原来的活往后挪。挪一个可以，挪三个就乱。排两周，真正动手的时间可能只有几天，剩下的是等。

  版本窗口也是硬约束。客户系统在跑，不能今天改完今天就发。要等窗口，要做备份，要通知使用部门，要安排人值守。发版前还得把这一版的其他需求一起验，不能为了一个小按钮单独开一次高风险发布。窗口排不进去，功能做得再快也只能等。

  如果客户催得急，开发只能加班插队。插队的代价是别的项目延期，或者线上问题没人跟。两周的排期，其实是在给整个团队留缓冲，不是在故意拖。客户听到的是两周，团队看到的是人力、窗口和风险三笔账。

  有些小功能还要拉上第三方。短信通道要报备，支付接口要申请，地图服务要配额，客户机房还要开端口。这些事不归开发管，但要开发去跟。一个按钮能不能按时上线，很多时候卡在外部流程，不卡在代码。

四、把「小功能」说清楚，报价和排期才不会反复

  最省时间的做法，是客户提需求时把四件事说清楚。用在哪个页面，给谁用，数据从哪来，什么算做完。比如导出，要哪些列，要不要合计，空数据怎么显示，文件大了怎么处理。这些说清楚，开发才能给出准确的排期。

  开发也要把边界写回去。哪些包含，哪些不包含，改了口径算不算变更，验收标准是什么。不要只回一句可以做。可以做和两周做完之间，差的是范围、依赖和测试。报价单上写清楚，后面就少吵架。

  小功能当然能做，只是不能被当成顺手。把它当成一个正式需求，给它范围、时间和验收，反而做得更快。客户少一句随口，开发少一次返工，排期也就不会每次都变成两周。