从一个烂尾项目说起
从小到大就是个倒霉蛋。干啥啥不成，买啥啥亏本。说出来你们可能不信，我第一个正儿八经的项目，一个做电商后台的活，烂尾了，直接导致我差点把裤衩都赔进去。
那会儿刚出来单干，雄心壮志，觉得凭自己的技术，随便接个活都能搞定。接了这么一个活，说是做一个中小型的电商平台后台，就包括商品管理、订单处理、用户系统这些最基础的功能。谈好价格，签了合同，我就开始吭哧吭哧地干。
刚开始那叫一个顺。
- 技术栈选的都是自己最熟的，Python加Django，数据库用的PostgreSQL。
- 功能分解也做得挺细致，每天都能看到进度条在往前走。
- 甲方看起来也挺满意，时不时过来看看，提出些小修小改的需求。
问题就出在，我那时候太相信所谓的“专业”了。我把所有精力都放在了代码实现上，觉得只要代码写得漂亮，性能优化得这项目就肯定没问题。
厄运是怎么找上我的？
事情的转折点发生在项目做到三分之二的时候。甲方突然换了一个对接人，之前那个对接人，就是跟我签合同的那个，据说被调去干别的了。新来的对接人，那叫一个外行指挥内行。
他一上来就推翻了之前我们定下的好几个核心设计。比如，非要让我在用户系统里加入一套极其复杂的会员等级积分规则，这套规则听起来就像是用脚趾头想出来的，逻辑上就自相矛盾。我说这不行，这会把整个系统架构搞乱。他直接一句：“你只管实现，别管对错，老板就要这个效果。”
我当时犯了个大错，就是没有及时止损。想着合同都签了，钱还没全拿到手，忍忍算了。我就硬着头皮开始改，一边改一边骂娘，感觉自己像个流水线上的拧螺丝工。
这种妥协带来的结果就是，项目进度开始失控。新功能不断叠加，逻辑越来越混乱，代码里到处都是补丁。很快，我就发现自己陷入了一个泥潭，每天都在忙着修复因为改动而引起的新的bug。原计划三个月完成的项目，拖到了第五个月，才勉强进入联调阶段。
等联调的时候，大问题来了。那套复杂的积分系统跑起来，数据各种错乱。订单结算逻辑也因为频繁变动，时不时就出现少算多算的情况。甲方一看，炸了！他们觉得我技术不行，把项目搞砸了。
避免“大祸临门”的血泪教训
最终，项目黄了，我也没拿到尾款。因为耗费了太多时间精力，后面接的几个小活也耽误了，收入断崖式下跌。那段时间真是体会到了什么叫“祸不单行”。
这个经历让我明白了，所谓的“大祸临门”，很多时候不是外界飞来的横祸，而是自己一步步妥协和盲目自信造成的。
第一条：设定清晰的边界，并死守它
我以前总觉得，甲方是上帝，说什么都得听着。现在我明白了，在专业领域，我才是专家。如果一个需求从根本上破坏了项目结构，或者逻辑上根本跑不通，就必须坚定地拒绝。拒绝不是为了对抗，是为了保护项目最终的成果。在项目开始前，就得和对方把“什么能改，什么不能动”说清楚。
第二条：警惕项目中的“盲目乐观”
我当时就是太相信自己的能力了，觉得再烂的需求，我也能用代码实现出来。这种盲目自信是导致烂尾的元凶之一。一旦发现项目开始偏离轨道，进度明显拖延，就应该马上停下来，召开紧急会议，评估风险，而不是抱着“再努力一把就能搞定”的心态硬撑。
第三条：对关键变动保持敏感
在我这个案例里，换对接人就是一个巨大的风险信号。新的对接人必然带来新的想法，而这些想法往往与前期的努力背道而驰。如果遇到这种关键人事变动，必须马上重新确认需求和工作范围，甚至考虑重新签订补充协议，把风险量化。
后来我重新出发，再接项目就谨慎多了。现在我手里有份自己总结的“风险清单”，任何一个项目只要触碰到清单上的高风险项，我就会立刻拉响警报。不再追求完美的技术实现，而是追求稳定和可控的交付。实践证明，少犯错，比追求速度重要得多。
避免厄运，就是避免自己制造的“内患”。成熟稳重，就是知道什么时候该说“不”，什么时候该抽身而退。
