一个技术人的知行笔记
去年三季度我接手了一个车联网平台的二期项目。项目预算砍了30%，工期压到四个月，但业务方要的功能从36个变成了42个——因为竞争对手刚上线了实时路况预警功能。我翻着那份《资源加载表》时，头顶的灯管开始闪，会议室空调坏了，汗顺着领口往下淌。当时项目组一共12个人，包括我在内，4个开发，3个测试，2个前端，1个UX，外加2个刚从其他项目借调过来的新人，连Git分支都不太会用。
这种情况下，每个PM的第一反应是“我要加人”。但加人是最偷懒的解法，也是效率最低的解法——布鲁克斯法则说过，对已延误的项目加人只会让它更延误。于是我做了一个决定：把所有需求卡片从Jira里倒出来，打印成一面墙。然后我拿了一管红色马克笔，当着业务方和开发组长的面，把所有“好看但不必要”的功能全部划掉。
2019年三季度，我接手了一个政府智慧城市项目的二期工程。项目金额八千万，工期18个月，甲方是某省会城市的大数据局。一期做得磕磕绊绊，二期换了我上去救火。头一个月我干了一件事——把一期所有合同、会议纪要、验收报告翻了个底朝天。翻到第三周，后背出了一层冷汗：一期的技术方案里明确写着“所有数据须在本地政务云部署”，但我们二期采购清单里赫然列着“公有云弹性计算资源”这个大项，预算六百万。原因很简单，一期项目经理觉得政务云性能不够，私下和供应商商量换了方案，但这事儿既没走变更流程，也没向甲方报备，更没人去核查这事合规性意味着什么。
2019年深秋，我走进深圳一家跨境电商公司的会议室，桌上摊着刚上线的ERP系统验收报告，甲方CIO老张翻着报告，脸上没有半点喜色。这个项目花了700多万，历时14个月，团队加班超过2000小时，系统功能实现率100%，Bug率低于行业标准——但上线两周，仓库实际发货效率反而下降了18%。
老张把平板推到我面前：“销售部说新系统让拣货员每天多走3000步，仓储部抱怨流程太复杂，最要命的是，财务发现日均订单处理量比旧系统还少200单。”他苦笑着补了一句：“你们交付了一个完美的系统，但没有交付商业价值。”
那是我职业生涯里最沉重的一课。我花了整整三个月复盘，才真正搞明白：项目收尾和商业价值产生之间，隔着一道绝大多数项目经理看不见的鸿沟。
2019年6月，我负责的某商业银行“智能风控平台”项目正式通过验收。庆功宴上，业务方总监举着酒杯对我说：“这项目做得漂亮，比预期提前两周上线。”我笑着碰杯，心里却压着一块石头。
那块石头，来自三个月前的一次复盘会上的尴尬。当时我向分管副总汇报项目进度，PPT翻到最后一页“预期收益”时，他打断了我的话：“这些收益指标，你打算什么时候开始验证？项目结束就没人管了吗？”
会议室安静了五秒钟。我支吾着说“后续会有运维团队跟踪”，但自己都知道这是个敷衍的答案。那晚我盯着项目章程里的收益实现计划——那页纸写得漂亮，什么“上线后6个月内不良贷款识别率提升15%”，可是谁来测？用什么基准对比？业务数据权限在谁手里？这些细节，当初写计划时我一个都没落实。
那次之后，我做了一件事：在项目进入UAT阶段时，提前拉了一个“收益追踪联席会”。参会人包括业务方数据组负责人、IT运维主管、还有风控部的模型验证员。我开门见山：“项目交付那天不是终点，你们3个月、6个月后要看的数据，今天就得把取数口径和基准定下来。”
具体怎么做的？我要求业务方提供一个“基线数据快照”——就是项目上线前系统运行的原始指标，比如当时人工审批的误判率是多少、平均审批时长是几天。这个快照必须是能在数据库里跑出SQL查证的，不能是“我记得大概怎么怎么样”。然后，我在项目管理工具Jira里单独建了一个“收益跟踪”Epic，给每个收益指标设了三个检查点：上线后1个月、3个月、6个月。每个检查点都绑定了一个具体的执行人，不是“相关部门”，而是“风控部张姐负责取数”、“IT运维李工负责导出日志”。
2019年秋天，我在一家软件公司负责一个企业级CRM系统的二期升级项目。项目做到第四个月时，财务总监突然发邮件通知我：下季度预算砍掉40%，如果不能证明项目已经带来或即将带来明确的商业价值，直接冻结。
我当时后背一阵发凉。会议室里坐着CTO、CFO、运营VP，我只有15分钟汇报。他们不是不懂项目，而是每天要面对几十个项目的资源争夺。你跟他们讲“架构优化”“代码质量提升”，没人会点头。他们要的数字只有一个——这个项目凭什么比别人值得活下去。
去年夏天，我接手了一个汽车零部件MES系统的交付项目。那是我职业生涯最混乱的三周——客户需求每天变，开发团队进度看板上的红条越长越多，我每天开会到晚上八点，回家瘫在沙发上刷手机到凌晨，第二天六点又爬起来救火。项目经理变成消防员，每周写日报时才发现，这周到底干了什么，脑子里全是一团浆糊。
转折发生在一个周四的深夜。那个项目延期风险已经爆了——我们承诺的验收节点是7月31日，但到7月20日，核心功能连UAT都没通过。我坐在办公室，白板上的行动清单写满了三十多项：供应商电话没回、数据库迁移方案要签字、测试环境不够用……每件事都急，但周末一过就忘了一半。那天我老婆打电话问几点回家，我对着白板说“再等会儿”，但其实根本不知道自己在等什么。
第二天早上，我做了个决定：每天下班前花10分钟，就10分钟，用手机备忘录写下三件事——今天实际干了什么，明天必须干什么，今天哪个决策可能错了。规矩很简单：不能写“跟进需求”，要写“上午10点和采购部张工确认了物料编码规则，发现他们用的供应商代码和SAP系统不一致”；不能写“解决Bug”，要写“测试环境数据库连不上，经查是运维同事升级MySQL版本没通知”。我从那天开始，坚持了整整两年，直到现在。
去年春天，我接手了一个ERP系统升级项目，预算800万，周期10个月，团队30人。前三个月一切都按照PMBOK的流程在推进：需求基线锁定、WBS拆解到第四层、关键路径上的风险都登记在册。到了第四个月，客户CIO拿着一份新文件来找我，脸色很难看。
“我们跟董事会汇报了项目进展，但董事会问了一个问题——你们花800万升级系统，能帮公司多赚多少钱？”
会议室里安静了大概十秒钟。我当时的反应还是条件反射式的，掏出风险登记册说：“我们规避了停机的风险，提升了数据准确率……”CIO打断我：“这些技术指标董事会听不懂。他们想知道的是，这个项目跟公司今年要砍掉的三个亏损业务线有什么关系？”
那个晚上我失眠了。我做了十几年项目经理，一直觉得自己挺专业，按时交付、控制成本、管好变更，这些动作我做得无可挑剔。但在那一问面前，我发现我所有的工作都是在回答“怎么把项目做完”，却从来没认真想过“这个项目到底应该做什么”。CIO转述董事会的潜台词其实是在说：你们做了很多事，但做得对不对，没人知道。
上个月，我接手一个“已验收”的智能仓储系统项目收尾工作。客户在验收报告上签了字，但财务那边迟迟不付尾款，项目团队已经原地解散了大半。我去找客户PM对账，对方甩给我一句话：“验收是验收了，但你们交付的东西，我们内部复盘发现好几个环节没达到预期效益，这尾款我们得再议。”
那一刻，我意识到自己犯了个致命错误——在整个项目周期里，我只盯着进度和交付物，从来没和客户认真聊过“这个项目到底要解决什么问题”。那个项目从启动到验收，花了11个月，投入了30多人，客户临时加的需求改了四轮，但最后大家发现，核心的库存周转率提升目标，连基线数据都没对齐过。
去年秋天，我接手一个已经运行了8个月的ERP系统实施项目。前任项目经理留下了一份“项目周报”，厚得像本书——每周都有14页，记录了每个模块的进度、风险、问题、变更请求。更可怕的是，团队有5个人每周花两天时间填各种表格、更新JIRA工单、做演示文稿给PMO看。我开会问团队：“你们觉得你们在干什么？”一个开发组长苦着脸说：“我们好像在做一个PPT给另一个PPT看。”
这句话是我职业生涯中听过的最真实的项目诊断。
那次经历让我开始重新审视一个残酷的事实：很多项目之所以失败，不是因为我们做的事太少，而是因为我们在做“做事的准备工作”上花的时间，超过了事情本身。 用大白话说，我们一直在“准备干活”，从来没真正开始干。
这个系列写到这里，该聊点未来的事情了。
前三篇文章分别是：FreeInk 的全栈解析、硬件路线与软件路线的对比、各个项目的技术栈全景。这一篇我不打算再拉清单了——我想聊聊我看到的几个信号，以及它们可能会怎么改变我们读书这件事。
先说一个暴论：今天的电子书阅读器，在上手体验上，还没有超越十年前初代 Kindle Paperwhite 的水平。 无论是开源还是商业，市面上的阅读器本质上还是在做同一件事——把电子墨水屏换成分辨率更高的、加了前光、调了刷新率——但你在阅读器上能做的事情，和 2012 年没有本质区别。
翻页。标注。查词典。调字体。
就这些。
但这几年出现了一些有意思的信号，让我觉得这个局面可能快要被打破了。