基建工作本身

业务中做基建很难，美团现在对技术的态度基本就是做事必先谈收益，但是这个以客户为中心的思想其实对于做基建的同学来讲来说并不是那么合适。这样做事情会有以下的问题：

1. 从归纳出发建设：在业务上线后我们根据已有的情况进行归纳，然后提炼出来一套方案其实这时候已经太晚了，基建同学会成为一个为业务腐败的代码擦屁股的人，而且不容易控制影响
2. 从演绎出发建设：在业务还没想到的时候，我们通过演绎发现这事情可能要搞但是现在没有业务需求，所以很难讲清楚收益，所以公司文化不支持你做，况且大概率你还有优先级更高的（问题1）要解决，所以你根本没机会做这个事情。
3. 边做边用：如果在业务刚提了需求，我们发现这个事情是可以沉淀到基础能力上的，但是由于做基建是需要时间的，业务根本等不起，往往就是先绕过去，后面再迭代(就是在也不迭代)，这会导致项目腐化很快，同时也会得到基建能力不行的评价

这三条就组成了目前美团基建上同学工作逻辑上的完整闭环。 按照美团文化的惯例，抛出问题后要给解决方案，

1. 增加时间，我觉得管理上需要给出一定可以“浪费”的时间，另外自己也需要为爱发电。
2. 增加洞察力，因为(问题2)上，如果真的具备洞察问题的能力，那么还是有机会争取到资源来做你认为应该做的事情的，只不过在美团尤其是在业务团队这特别的难。(毕竟沧海横流,方显出英雄本色[😄])

基建建设过程中的困境

如果业务基建能力一旦上线，会存在另一个关键问题任何底层系统的建设过程中都会存在遗漏可变性的可能性。这在我之前见过的无数项目中都发生过，这样导致底层建设人员刚走，后面一线的工程师就在吐槽架构的能力不行，设计出来的东西满足不了新需求，很难用。尤其是在创新业务中**，可能无时无刻不在做一些颠覆性的东西**，易变性分析一旦有所遗漏，做出稳定的架构还是挺难的。而且也暂时没有想到非常具备可行性的解法。

基建能带来技术深度的提升吗

另外一个事情在技术深度上，往往做业务的同学会认为基建的工作很好，会认为技术深度===技术栈的深度，这显然是不对的，背后真实的问题其实是在问你的竞争力在哪里。这里有两点：

1. 为什么在这个点上，我做过的工作证明了比其他同事要更强
2. 为什么这个能力是当前公司需要的，也就是所谓的收益。你能从0开始写浏览器，但是团队不需要也是没有用的“技术深度”(人事不匹配，要考虑自己的工作内容是不是符合职业发展的预期了)

Written by xi ming You should follow him on Github