干过项目的，谁没在群里见过这句？“再宽限两天，绝对能上线。”“这回我算得明明白白，保准不拖。”结果呢？全成了甩锅的挡箭牌。延期？那是日常。到底卡哪儿了？手生？心飘？其实吧，咱们太迷信“最后冲刺”了。活儿，是一天一天熬出来的。汉弗汉弗在《PSP》里抛出的观点，看着有点反常识，但仔细琢磨挺对味。交付能靠谱，根本靠不到最后那阵子盲目死磕。全凭对过程较真儿的量化和纪律。
这书的主张，剥开那层学术外壳，核心诉求就一句大白话：把做软件这摊子事儿从“玄学”拽回“工程”。汉弗汉弗说得直白，个体软件过程，就是逼着程序员当回质检员。老老实实记账。敲代码花了几小时？修了几个坑？每个节点到底耗了多久？听着挺枯燥，甚至有点反人性。搞技术的嘛，谁不爱吹自己灵感一来通宵搞定？可汉弗汉弗的账本算得死死的。人脑估算复杂活儿，准头差得离谱。没数据垫底的日子安排，纯纯是自欺欺人。我带过几个实习生，一开始都拍胸脯说“这模块两小时搞定”，结果一记流水账，光调环境、读文档、改拼写错误就耗了快三天。一旦开始攒过程数据，你就不靠“蒙”工期了。改靠“算”了。
这关不好过。全因为戳破了职场里那层窗户纸。工位上，有人明明熬得眼圈发黑，也死活不肯歇下来对账。真不是活儿离了谁都不转。是怕一停下来，就撞见自己“根本排不准时间”的尴尬。PSP给的就是一面冷冰冰但特管用的照妖镜。记下来。拆开看。再调头。书里第4至第7章扒拉估算与计划，第8至第12章死磕质量与设计。这俩根本不是各干各的。而是一圈咬合的齿轮。估得太松？实测数据立马打脸。图省事跳过测试直接上手，bug数据能把你追得满楼跑。纪律不是给创造力上镣铐。它是给天马行空的念头，铺条能走车的道。可能有人觉得太较真儿了。你想啊，没量尺子的裁缝，缝出来的衣服能合身吗？
话虽如此，把这套路往哪儿都套，肯定水土不服。汉弗汉弗自己也明确划定了边界：PSP主要适用于有明确需求、可拆分、可重复迭代的工程场景。要是碰上手把手从0到1的科研，或者全凭灵光一闪的创意活儿，硬上量化和流程，纯粹是捆住手脚。那会儿，留点试错的余地，比死磕“准不准”管用多了。不过退一步讲，PSP好歹给了个清醒的标尺。搞不定量化的时候，至少得认账。承认这事儿存在变数，跟同事交底时多留点余地，别拿盲目自信把信任透支光了。我觉得吧，未必非要把“量化”当成万能药。它更像是一套防翻车的刹车片。
我私底下倒觉得，作者对“数据”这块儿，有点捧得太高。过程量化确实能让交付心里有底。可它治不好“方向跑偏”的病。需求要是个伪命题，你工时记得再细、缺陷盯得再紧，也不过是在高速公路上把方向盘握得更稳当罢了。但这不影响PSP的里子。它拎出来一个早被大伙儿晾在一边的事实：多数项目的延期与失控，不是因为技术多难，而是因为过程多脏。咱们早就习惯把底下的烂摊子用加班和补救粉饰过去，却死活不肯认账：没有纪律的工程，注定是一场靠运气续命的赌博。可能有人会说，现在敏捷开发不也强调灵活吗？但灵活不等于瞎搞。没底子的“快”，最后全得在返工里还债。
可预测性从来不是把自由往死里掐。而是老老实实认现实的账。把“大概”“应该”“没问题”这些糊弄人的词儿扔了。肯花时间记一笔、回头看、接受自己真实的干活节奏，交付的准头自然就出来了。咱们缺的，真不是敲得更快的键盘，也不是更聪明的代码。就是那份敢直视镜子看过程的老实劲儿。下次再听谁拍着胸脯喊“马上搞定”，不妨顺手问一句：你拿表掐过，这事儿到底得花多少实打实的时间吗？