我以前处理技术债务的思路，是要有一个检查清单，我会定期的复盘所有的系统，并且结合自己团队和其他团队的事故去全量扫雷。系统本身是一个平衡的产物，是时间、功能、风险、未来可能性等几个方向平衡的结果。技术债务对于研发同学的考验，不在于你怎么在日常工作中保证系统技术债为0，而是你要评估清楚在有限的资源和时间下，哪些问题是刻不容缓的，哪些问题是可以往后放的。
很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，从长远来看，这种烂系统的增加会极大地阻碍业务的发展，形成一个个的黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。这种将就将导致系统腐化堕落，技术债越垒越高，丑陋的代码疯狂滋长，像肿瘤一样消耗你所有的能量，后还要你的命。
4. 警惕大项目
并不是所有人都有能力操盘大项目，也不是所有人都能够平衡好交付压力、上线质量、产品逻辑以及时间窗口，这是一个非常有挑战的工作，需要纯粹的技术能力之外的很多软性能力来辅助，比如组织的沟通协作能力、向上要权要责的能力、平衡产品业务期望的的能力、突发情况应急转变的能力等。越大的项目对于Owner的要求也越高，真能把大项目做好不怎么留大坑的少之又少。
大项目从启动到立项所用的时间很多时候是远超项目实际的开发周期的，项目的顺利推进需要“妥协”，但项目的成功需要坚持。很多项目之失败，是在做的过程中方方面面不断妥协，后做出来的东西已经远离了开始想要的样子。
业务层面
除了技术之外，研发同学对业务层面也需要提升认知与重视。
对于研发而言，业务就像是外语，你不理解业务就好比人在异国，与周围的环境格格不入，并且容易吃亏！相比产品、业务、运营等其他工种，技术更喜欢和技术打交道，业务在大多数同学眼中是混沌且缺少秩序的，没有技术那样清晰的实现路径和稳定共识的知识结构。并且技术相对容易证伪，而业务往往就是不停的尝试，研发都讨厌“不确定性”。在一个庞大的组织里想把技术做好，就必然要与业务打交道，毕竟业务才是一家公司存在的核心价值。
1. 基于业务规划做技术规划
很多同学习惯于把计划等同于规划。阿里是一家尊重技术的商业公司，所有的团队都在谈业务、规划里是业务规划、周报里是业务项目、汇报里是业务成果、晋升的时候也要突出你的“战功”。相比技术本身，大家更关注技术改变了什么，在业务部分聊技术团队如何做规划的原因就在于此，这是公司运营的的起点（目的），延伸出来才有具体的技术规划和组织设计作为解决方案。
深刻理解业务并设计战略，拆解战役与项目，通过组织和各种机制确保项目的执行与落地，终拿到业务结果，这是一个大公司的标准战略执行方式。研发同学做技术规划以及团队规划的时候，一定要考虑到你所在环境，公司今年要主打什么，所在大部门的目标是什么，对口的产品和业务现状如何，纯粹的技术迭代在业务上的好处在哪儿。团队目前有哪些不可抗力，或者影响规划推进的阻力。
很多同学做规划的时候会习惯性按照这个思路进行：①现状（痛点）；②对应的解决方案和策略；③展望未来。有时候②和③的顺序会反过来。很多时候大家发现终的部门规划和自己做的规划没什么关联，不知道怎么往哪个方向用力，或者干脆继续按照自己的计划先走着。
对大部分同学，我建议规划要实在。做技术规划前，找你周边的研发团队聊一下，找你对口的产品、运营聊一下，知道他们的目标是什么，知道公司几个重点是什么，结合你们目前的痛点，在现在和未来之前找平衡、找现在和未来都有收益的那部分。