技术负责人：多项目并行时的交付与质量节奏

作为技术负责人，近几年同时推进跨境 ERP、智能货柜、医疗信息化与 AI/IoT 多条线。个人仍能写核心模块，但更关键的是让各线「可预期地交付」：范围清晰、风险可见、质量有底线，而不是靠周末加班换进度。并行不可怕，可怕的是每条线各自为战、临时方案永久运行、 nobody 对整体 SLA 负责。

节奏

需求拆到可演示增量，每两周有可给业务看的 Demo，拒绝半年后大爆炸上线。风险前置：货柜 MQTT 协议、医保结算接口、Shopify Webhook 先打通再堆 UI，避免界面做完才发现联调要三个月。每周固定架构评审，分歧早点吵完，ADR 留下决策理由。多项目共用 CI 模板、Docker Compose 与 lint 规则，新人换线 onboarding 从两周压到三天。排期留 20% buffer 给联调与合规审查，医疗与跨境尤其不能按纯开发工时估。

质量底线

代码评审重点看边界与失败路径：支付回调、开柜指令、医保结算必须幂等且有审计日志。Docker 与 CI 保证 clone 即可跑；staging 数据脱敏，密钥走 vault。监控覆盖核心链路：支付成功率、柜门异常、结算拒单率，告警在 SLA 内有人响应。禁止「先上再说」碰不可逆动作。

翻译能力

技术方案要翻译成业务听得懂的取舍：工期、稳定性、范围三角。说「加缓存能扛峰值但列表可能延迟五分钟」，而不是只讲 Redis。延期要提前两周预警，别最后一天爆雷。技术负责人不只对 Git 负责，也对预期负责——这是多项目并行里最难也最有价值的技能。

人力与优先级

并行线超过三条时，必须显式排优先级：本周只有一条线能占核心同学百分之五十以上工时，其余维持维护模式。技术债登记公开，和业务一起决定「先还哪条线的债」，避免 secretly 烂尾。跨项目复用组件（认证、支付、日志）要有 owner，否则每条线 fork 一份又是四套临时方案。

复盘与知识沉淀

里程碑后做简短 retro：什么估准了、什么该更早 escalate。事故复盘不带锅，但要改流程：告警、回滚、沟通模板。Wiki 记录各项目联调联系人、沙箱账号过期日，减少「只有某人知道怎么测」的单点。多项目并行的终点不是全绿 dashboard，而是任何一条线临时缺人，其他人能在两天内接手不翻车。

与业务方的节奏对齐

月度路线图只承诺「可演示范围」，不承诺「全部功能上线」。跨境合规、医疗器械注册类需求单独列依赖方与外部 SLA，不塞进普通 sprint。演示日只展示已联调通过的路径， mock 数据要标注，避免信任透支。技术负责人定期用非术语向管理层同步：哪条线风险升高、需要业务决策什么——沉默直到爆雷，是最差的多项目管理策略。

鼓励各线 Tech Lead 交叉 review 关键 PR，既统一风格也培养替补。发布窗口错开：医疗结算与跨境大促不要同夜上线，共享 on-call 才有余量。并行项目的成功，是组织学会说「这条线本周不做」。

季度层面看「并行线数量」与「人均 context switch 次数」，后者过高必降速或加人。文档与 runbook 和代码同等优先级：没有 runbook 的上线，等于把 bus factor 设为 1。技术负责人的产出，最终体现在团队能否稳定重复交付，而不是个人 hero commit 数量。

小结

多项目并行靠的是节奏、风险前置与统一质量底线，而不是个人加班。把不可逆动作纳入监控，把技术方案翻译成业务取舍，预期管理会顺很多。临时方案要有明确退役时间，否则会变成永久债务。