项目越急，话越熟悉。
“先上线，后面再优化。”
“这个版本先简单点。”
“客户先能用，其他的慢慢补。”
这些话不一定错。
真实项目里，谁都不可能每次都用最理想的方式做事。时间、预算、人员、现场压力都摆在那里，很多时候就是要做取舍。
但带团队以后我越来越觉得，真正难的不是妥协，而是知道哪些地方不能妥协。
最容易出问题的，往往是上线前最后两三天。
群里消息刷得很快，测试在报问题，开发在改问题，产品在确认展示文案，实施在问什么时候能部署。这个时候只要有人说一句“这个先不管吧”，很多东西就会被顺手放过去。
有些确实可以放。
有些不行。
一、不是所有“不完美”都叫技术债
交付很急的时候，有些地方可以先放一放。
比如页面交互不够精致。
比如某个配置项暂时没有做成可视化。
比如报表导出格式还能再优化。
这些问题会影响体验，但不一定立刻伤到系统根基。
真正危险的是另一类问题。
数据口径不清楚。
权限边界没守住。
异常没有处理。
关键操作没有日志。
上线没有回滚方案。
这些东西一旦丢掉，后面不是“补一下”那么简单。
它可能会变成数据错乱、责任说不清、线上问题无法定位，甚至团队信用被打掉。
二、技术负责人要把底线讲在前面
我以前吃过一个亏。
项目赶上线，大家都知道时间紧，于是很多东西都默认“后面再说”。
但问题是，没人说清楚哪些可以后面再说，哪些不行。
结果到了最后，测试发现关键流程没有完整日志，异常场景也没处理好。这个时候你再说不能上，团队会很难受，业务也会觉得技术怎么到最后才拦。
后来我学到一个教训。
底线要提前讲。
不是上线前一天才说“这个不能接受”，而是在排期时就说清楚：
这个版本可以砍哪些体验项；
哪些功能可以先做人工兜底；
哪些地方必须有日志；
哪些异常必须处理；
哪些数据一旦出错无法接受。
我后来习惯在排期时就把这些写成一个很短的上线前检查表。
不复杂，通常就十来条：关键链路、权限、日志、回滚、数据备份、异常提示、现场联系人。
真正忙起来的时候，人是靠不住记忆的。越急，越要有一张纸把底线拉住。
你提前讲，大家是在做计划。
你最后讲，别人会觉得你是在卡进度。
三、急的时候更要留一点检查时间
项目很赶的时候，团队最容易压缩的就是检查时间。
开发晚一点没关系，测试压一压。
联调晚一点没关系，上线前一起看。
文档晚一点没关系，先口头同步。
听起来都能理解，但问题也在这里。
越急的项目，越需要最后有一点冷静时间。
不是为了走流程，而是为了问几个最基本的问题：
核心链路有没有跑完？
关键数据有没有验证？
失败以后怎么恢复？
上线后谁看监控？
出了问题谁能第一时间处理？
这些问题不花太多时间，但能挡住很多低级事故。
我见过最尴尬的一种情况，是功能本身没大问题，但上线后出了错没人知道从哪里查。
日志没有关键参数，操作记录也不完整，最后只能靠猜。
这种事故特别消耗团队信用，因为它不是“系统复杂所以出问题”，而是“我们连自己做了什么都说不清楚”。
四、可以妥协，但要把妥协写下来
如果确实要带着问题上线，我现在会尽量把妥协写清楚。
哪些问题暂时接受；
为什么接受；
影响范围是什么；
后面什么时候补；
如果出问题怎么处理。
这不是为了甩锅。
这是为了让团队知道，我们不是没看见问题，也不是假装一切正常。我们只是基于当前约束做了一个选择，并且知道这个选择的代价。
很多项目失控，不是因为做了妥协，而是因为妥协没有被记录。
后来大家都忘了当时为什么这么做，只剩下一堆没人愿意碰的历史问题。
五、小结
交付很急的时候，技术负责人不可能什么都守住。
但至少要守住几件事：
数据不能乱。
权限不能穿。
关键链路要可验证。
出了问题要能定位。
上线失败要能回退。
这些东西不一定显眼，但它们是团队还能继续往前走的底线。
能妥协的地方，讲清楚。
不能妥协的地方，早点说。
本系列：
- 上一篇：有些技术风险，不能只跟老板讲技术
- 下一篇：团队里不能只有一个人最懂系统
- 系列目录：带团队以后，我才明白的事
暂无评论