博客
归档 →多花几十万、延期半年，起因不是现场跑不通，是甲方换了领导
「现场改方案实录」第 1 篇。蓝图签完、功能已在开发，甲方换了领导，要更少人、更自动化，换成他熟悉的做法。需求来回改，最后由甲方一线业务确认，在原方案上优化、不推翻主流程；几十万开发费甲方出，延期半年。再来一次：立项时约定出了问题怎么处理，蓝图请能拍板的领导一起签，签后变更重评需求、费用、周期。
现场和系统一冲突，让步的为什么总是系统
「现场改方案实录」序篇。硬件到位以后，现场和系统冲突，让步的基本是系统：改硬件贵、周期长，改系统便宜、快。系统让步时，人的分工也会跟着变。上一系列讲每一站的规则，这个系列讲规则在现场被打破的那一次，每篇按背景、问题、解决方案、对你有什么帮助来写。12 篇背后有三条线：只把要人判断的那一步交回给人，改方案最后常常回到上线前的数据表，变更怎么处理要在立项和签合同时写下来。
每个工厂都说自己特殊，定制做多了，系统就成了一个厂一套
定制最常见的 6 类：单据打印格式、特殊物料处理、工厂特有流程、报表看板、本厂设备系统对接、不同打印机驱动。定制是独立于标准功能、按业务自身特殊要求做的需求。做多了产品标准统一不了，严重的变成单独服务运维。要事先约定、不进通用配置、项目组和业务方审批签字。
工时估不准的，往往不是哪个功能难，是那几个你说了不算的环节
需求从蓝图拆：产品经理出产品设计文档，给开发讲完再开发。开发经理按功能点拆前端、后端、接口，估时间、定人，和项目经理商量计划。最常估不准的是设备联调、第三方系统和供应商对接，因为不受控。测试四轮，内部测完无阻塞再交业务用户。开发期间的新需求先过项目经理，开发不直接对接业务方。
蓝图评审会开成了答疑会，问题往往不在方案，在讲的人满嘴术语
蓝图调研先找关键用户、看工厂规划图。蓝图前面交代依据和范围，每个业务域按六块写，流程表每一步写到岗位。初审最常打回的是逆向流程没设计；终审卡在评审人听不懂，要换现场说法、拿一张单据走一遍。签了再改，走变更审批，关键用户和业务负责人再签。
立项书最该写细的一页，不是方案，是「前提和假设」
立项要定死 8 样：范围、目标、验收标准、里程碑、组织、人力、预算、交付件。最常漏的是需求变更、增加和延期带来的时间、人力成本，没有具体约束，这些要写进「前提和假设」。组织写清谁拍板、谁把关，人力按角色估人天，交付件按阶段列到责任人。
项目推一步走一步，问题往往不在项目组，在业务方没人做主
项目组三方：IT、业务、供应商。推不动的信号一层比一层深：没有关键业务方、有人不响应、响应了没人做主、没人协调内部，最后项目组推一步走一步。供应商换人先交接清楚，能力不行就入厂面试、试用留厂，或者加人。
项目延期从来不是突然发生的，是周例会上一周一周攒出来的
风险清单里最常见的是进度风险和成本风险。进度盯蓝图设计、功能实现、上线试用三个节点，上线推进按六层拆。延期了先书面预警、升级到业务方主要领导，再把周点检改成日点检。
系统验收迟迟签不下来，问题往往不在系统
从上线到验收：先上一条线，试制订单从少到多，各岗位磨合，再全面切换。验收看 5 个指标，门槛要在立项时定。签不下来，多半是标准没定、需求没停、拍板的人换了。