做过诊疗类项目的人大概都听过这句话：工期就是写代码的时间，功能砍一半，周期自然缩一半。一家开了三家店的宠物连锁医院找小程序开发团队做挂号和电子档案的时候，也是照这个逻辑压价的——需求清单从二十六项砍到十七项，交付期从三个月压到两个月。项目最终走了九十六天，比原计划还多六天，而这九十六天里真正在敲代码的时间是三十一天。

那份九十六天的排期账，编码只占三分之一

项目收尾后把工时表按阶段拆开，六段的日历天数分别是：需求确认与原型十二天，编码三十一天，旧档案清洗与核对十四天，第三方联调加平台审核十九天，排号模型返工十三天，测试与试运行七天。加起来正好九十六。

编码那三十一天里装着五个模块的全部前后端：挂号号源、宠主与宠物档案、疫苗与驱虫提醒、医生排班、检验报告回传。这个数字不算注水，两个人写一个月，功能量对得上。真正要解释的是剩下的六十五天，其中没有一天是耗在"写得慢"上。这个比例在小程序开发项目里并不算特例，只是很少被拆到台面上看。

第一处拖延：等的不是一份资料，是十一个决策点

开工第一周整理出十一件必须院方拍板的事：号源提前几天开放、一个宠主名下最多绑几只宠物、免疫和驱虫能不能免挂号直接到店、宠主端能不能看到血常规和生化的原始数值、老会员储值余额是否迁进新系统、三家店号源互通与否、医生临时停诊后已挂的号是自动退款还是转诊、既往病历对宠主开放到哪一层、价目表由总部还是门店维护。

十一条里有六条牵着两个以上部门。检验报告可见范围那一条，从提出到定稿隔了九天，开了三次会——分诊台想让宠主自己看报告减少电话咨询，医生担心宠主拿着一项偏高指标去别处对比后引发纠纷。开发这边不是闲着，先把不受影响的模块往前挪，可挪到第三周就挪完了，档案模型这条主线只能停下来等。累计净等待十七天，其中八天完全空转。

砍功能不会让决策点变少。被砍掉的九项里有四项是"以后再说"，等于把决策推到二期，留下来的十七项之间的耦合一点没减。

第二处：旧档案清洗跟功能条目数毫无关系

院方交过来七个 Excel 文件加一份旧收银系统导出的 CSV，宠主记录一万一千四百条，宠物记录一万三千八百条。真正能直接入库的不到七成。

同一个宠主换过手机号就会多出一份档案，按姓名加地址比对合并之后，宠主剩九千两百条。宠物重名更麻烦，叫"小白"的一百三十七只，叫 Lucky 的八十三只，不能按名字去重，只能拿宠主手机号、品种、出生年月三项做联合判断。体重字段里有四千三百条写的是斤，另有两百六十条数值写成"八点五"却实际是斤，靠品种对应的体重区间才挑出来。疫苗名称统计出四十七种写法，映射到九种标准疫苗，"猫三联""妙三多""三联"这类要人工确认一遍才敢并。出生日期缺失三千一百条，只能加一个估计月龄字段兜着，这直接影响疫苗提醒的推算。

体重这一列必须洗干净，不是为了报表好看。处方剂量按毫克每公斤算，档案里的体重要取最近一次称重而不是首次录入值，单位混着就是给用药埋雷。这十四天是纯数据活，需求清单砍到十项还是三十项，这十四天一天都省不下来。

第三处：外部依赖的时间不由开发方支配

小程序类目里宠物诊疗要提交《动物诊疗许可证》，第一次提审被退回，原因是营业执照经营范围的表述和所选类目对不上，补材料重提又走了四天。生化仪的报告回传更被动，设备走串口输出，需要在院内加一台中间服务把结果解析成结构化字段，厂商工程师只能约周三或周五上门，两次上门之间隔了一周。电子发票走税控服务商开通流程，报件到可用十二天，这十二天里开发只能先按沙箱字段写好接口。

这三件事加起来占掉十九天，没有一天由小程序开发这边决定。放在项目后期做，等待就是纯串行的等待。

返工十三天，起因是把接诊时长当成了常数

第一版排号按固定十五分钟一号排，试运行第二天下午就积压了四十多分钟。拿秒表在店里数了四十例真实接诊：免疫和驱虫平均六分钟，内科初诊十八到二十二分钟，皮肤科复诊要刮片镜检，二十五分钟以上，需要拍 DR 或做 B 超的还要排设备。急诊插队占全天接诊量的一成八，且不可预约。

第二版改成按科目给不同时长：免疫八分钟、内科二十分钟、皮肤科二十五分钟、影像三十分钟。仍然崩，因为两个医生可能同时把病例送去同一台 B 超。第三版才把设备当成独立资源池锁进号源，并且每小时留一个空档吸收急诊。三版之间还夹着分诊台的使用习惯调整，前台习惯手写小黑板，改成扫码取号之后老年宠主的到号提醒又补了一轮语音播报。这十三天是唯一可以归到开发方账上的损失，代价来自动手前没有去现场量数据。

他们确实砍过功能，只省下六天

砍掉的三个模块是住院日报、洗护预约、积分商城，报价里合计十一个人天。实际工期只缩短六天，两个原因：这三块跟档案模型的耦合本来就浅，砍掉不减少任何决策点；洗护预约砍了，洗护业务照旧要占用同一批技师和同一个前台，第七周不得不补一个手工登记入口，又吐回去两天。

按人天算的账和按日历天算的账不是一回事。小程序开发的报价单按人天列，客户按日历天理解，偏差就出在这里：砍掉的是并行度高、依赖少的活，留下的是串行的、要等人拍板的活，工期自然压不动。

第八周加两个人，反而倒亏六个人天

进度落后一周多的时候从别的项目调了两名开发进来。头两周净产出是负的。原因不在编码能力，在领域规则：幼犬首免三针每针间隔二十一天、狂犬要满三月龄才能打、驱虫按体重段给剂量、疫苗提醒要区分"已完成基免"和"中途断针需重新起针"。这些规则一条都不在需求文档里，在老兽医的经验里，新人只能反复问。带问题的人正好是全组唯一摸透档案模型的那个开发，两周后新人日产出恢复正常，被占用的那个人少交付了六个人天。

换一种估法，工期的自变量根本不是功能条数

把四段拖延的性质排一下：等决策十七天、洗数据十四天、等外部十九天、返工十三天，六十三天里只有十三天是开发方自己能压缩的。所以小程序开发的周期估算，真正该问的是三件事——需要客户方签字的决策点有多少个、外部依赖有几条、旧数据有多脏。

照这三样能落地成具体动作。立项那周就把决策点列成明面清单，每条写清谁签字、给多少小时，这个项目后来定的是四十八小时，超期按默认方案先做，二期再改，改动工时提前写进合同。旧数据不要等迁移那天才看，先抽两百条人工判一遍算出脏率，按每千条零点六个人天估清洗量，这个项目抽样脏率三成一，估出来的清洗工时跟实际只差一天半。外部依赖全部提到第一周发起，类目资质、发票服务商、设备厂商排期，谁都不等编码完成。像排号这种由现场行为决定的模块，动手前去店里坐两个半天，拿秒表数四十例真实时长，比开三次需求评审会有用。

这家医院第二家店的挂号与档案上线用了二十三天，功能一项没砍，还比一期多了住院日报。差别在于决策点清单开工第三天就签完了，旧档案在一期已经洗干净，设备接口是现成的。九十六天和二十三天之间那七十三天的差距，从来不在代码里。