项目复盘：砍掉一半人，剩下一半力，结局没变 去年 Q4 的那场大项目启动会，我脑子里大约就挂着一句话：“能不能让旧系统跑得更顺？”师哥问能不能给点工夫？我说前面我还没想好。目前细想，实际上那时候心里没底，大约率是认定“再拖两年肯定能成”，要么“还是先搞个原型吧”。
那时候认定，只要数据跑通了，业务逻辑对上了，不管成本多高，都得干。 结局呢？干了两三年，跑通的只是那最终一公里。 最启动那个需求，我脑子里画出来的图，和老板画的要求简直天差地别。老板那天拍桌子：“这个功能务必得对齐！”我说对齐？我昨天刚跟财务组吵完架，昨天中午刚跟产品组吵完架，今天老板又要对齐？我当场就懵了。
后来才想起来，他早就把需求写进文档了，我还当作他在等我看出来。 故此，这项目最大的难题，不是技术不中，是“沟通成本”忒高。我们团队所有人都在磨叽，结局做得越细，项目越烂。 记得有一次上线，服务器扛不住。
那天下午三点，机房报警，我们全员站在服务器前。我当时就慌了，心想完了，是不是需求忒复杂？
是不是代码质量忒差？后来一查，原来是出于那套报表逻辑，我们为了省那几个小时的测试工夫，硬生生把 SQL 写反了。结局一运行，数据全在报错。
那一刻，我特别想辞职，不想再听任何解释了。 后来有人劝我：“别慌，先修好再说。”我说：“我修好了还要修吗？” 那时候我认定，做项目就像下棋，每一步落子都要想好后果。
要是走错了，回头改已经来不及了。
故此我们在规划的时候，务必把“会不会出岔子”这件事，当成核心指标来抓。 最惨的一次，是那个核心的报表功能。我们团队有六个人，每人负责一个模块。最终上线时，每个模块都单独跑通了，可是跑不通。出于数据源不一样，每个模块用的数据库表结构、字段定义都不统一。等到最终联调的时候，发现数据对不上。
这时候，要是我是项目经理，我会直接叫停，说“数据对不上，不能上线”。 但现实是，老板在那边拍着桌子催进度。我说：“不中，数据对不上，不能上线。”老板说：“那就改了，改完我们再上线。”我心想，改改改，不改心里不踏实。最终团队加班到凌晨，把逻辑改了一遍又一遍，还是不中。结局数据对不上，还是不中，最终只能发版给另一个客户端跑。 那一刻，我特别想哭。
我想，要是那时候我就坚持一次，哪怕只改了一半，是不是就成功了？ 后来复盘了一下，才发现那个核心报表的逻辑，实际上就是我们整个项目标“大动脉”。出于那套逻辑是通用的，所有模块都依赖它。
要是那套逻辑不通，所有模块都得废。 从那赶明儿，我们团队做了一个转变。
不再追求“功能堆砌”，而是启动追求“逻辑复用”。我们随意砍掉了两个子模块，把原本分散的几套 SQL 逻辑，全体抽取成一个统一的中间件。结局呢？子模块删了，中间件还在，所有模块都顺畅了。 那个报表功能，原本要搞两周，目前只花了三天。并且，这个中间件被我们拿去用了三个不同的业务系统，效果出奇的好。 故此，我们目前的做法是，不管项目多大，不管人有多少，只要核心逻辑能复用，我们就先别急着写代码，先把“逻辑层”搭好。
这个逻辑层，就是那套通用的数据字典、那套统一的接口规范、那套通用的业务引擎。 我不再喜爱用“起初、其次”这种词。出于在我眼里，逻辑的自然流淌，才是好的。就像水流一样，你别管它从哪边来，它自然会流向哪儿。
要是为了把你从左边推到右边，硬生生把路堵成死胡同，那叫工程倒灌，不是工程。 目前回头看，这个项目别看没达到预期的完美程度，但那套逻辑复用机制，让我们赶明儿在做类似项目标时候，心里有底了。
哪怕赶明儿项目规模更大，流程更复杂，我们有信心把核心逻辑抽出来，让每个人都能玩得转。 我也知道，沟通这事儿，有时候真挺难的。
有时候我认定老师忒烦，有时候我认定用户忒急。但我越走越认定，只要坚持住“逻辑复用”这根弦，项目做得再好，也比那些“功能堆砌”做得烂的多。 最终，我想说，做项目最难的不是技术，是人心。心不齐，技术就是空中楼阁。赶明儿要是我们再干，我不会再为了赶进度而牺牲质量。每一个模块的上线前，我都会问自己：这个逻辑，确实经得起推敲吗？要是答案是否定的，那我先不说“上线”，我先说“拉着团队聊聊一下”。 最终总结就是：别想“赶明儿如何办”，先想“目前如何干”。
哪怕目前方案看着笨，只要方向是对的，路总会通的。