我是在 2014 年入职饿了么，从前端和 PHP 一直做到后端架构和团队，从 2014 年到 2017 年陆续负责过公司客服、销售、代理商、支付、清结算、订单这些业务的产研与团队；2018 年从业务研发团队抽身，6 个人组起一个小组投身机器学习，试图结合实际的业务场景通过技术改造业务；2019 年回归到平台（中台）研发，负责交易、金融、营销三个中台的研发和团队工作。基于我在饿了么4年和阿里巴巴 2 年研发经历，从技术、业务、管理和架构层面分享一些我的思考。
技术层面
别把你的懊悔、决心、对稳定性的思考、各种奇妙的idea以及执行力体现在事故复盘会上，系统的安全生产和火灾一样，事前才有意义。
2. 链路设计
大部分产研缺少全链路的视角，往往看到的是自己负责的点，但是对于一条线乃至整个面是看不到的，也没有机会去思考这些，而对于一些大项目和长链路系统而言，这是致命的。
我的建议是，对你所负责的系统，它关键的上下游、核心业务的链路一定要熟悉，包括数据、接口（调用、功能、逻辑）、各种异常的处理和特殊的设计。能帮你达成这一目的的最简单的办法就是画图、画图、画图！重要的结论说三遍，一定要自己能把系统的大图画出来，然后做到可以根据大图随意放大和缩小。放大到将链路画到业务场景里，突出业务逻辑和上下游交互，缩小到某一次调用的处理逻辑大致是怎样，数据是怎么变化。
经常画图，不用纠结形式和标准，重要的是形成自己理解系统的一个框架，一个自己的思维方式，需要的时候可以随时拿出来用。
日常不管是聊需求还是做系统设计，习惯性的把图画出来，就达成了一半。剩下的一半就要看图去想、去找问题。
3. 技术债务
永远不要骗自己说，现在为了这个需求先挖一个坑，过一段时间再来填（重构 or 重做）。
技术债务和金融债务一样，它必然存在，并且会像无赖一样一直赖着，隔三差五会爆发一下。随着时间的推移和业务的发展，你会发现架构越来越混乱，不同系统的领域边界越来越模糊，系统和需求与组织关系的映射越来越复杂，服务内编码风控越来越不一致，重复的轮子一个接一个隐蔽的出现。
“太忙了没时间梳理哪些问题”、“改那些问题需要上下游一起改，费时费力，推不动”、“现在还没出问题，而且正在整理了，别催”。这是我们经常会听到的声音。其实，技术同学多少都有点代码洁癖，有很多问题不处理不是主观的原因，而是客观上因为精力、时间、ROI等因素，往往要等问题真的爆发后，大家才能狠下心去处理那些问题 。
我以前处理技术债务的思路，是要有一个检查清单，我会定期的复盘所有的系统，并且结合自己团队和其他团队的事故去全量扫雷。系统本身是一个平衡的产物，是时间、功能、风险、未来可能性等几个方向平衡的结果。所以技术债务对于研发同学的考验，不在于你怎么在日常工作中保证系统技术债为0，而是你要评估清楚在有限的资源和时间下，哪些问题是刻不容缓的，哪些问题是可以往后放的。
很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统的增加会极大地阻碍业务的发展，形成一个个的黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。这种将就将导致系统腐化堕落，技术债越垒越高，丑陋的代码疯狂滋长，像肿瘤一样消耗你所有的能量，最后还要你的命。
4. 警惕大项目
并不是所有人都有能力操盘大项目，也不是所有人都能够平衡好交付压力、上线质量、产品逻辑以及时间窗口，这是一个非常有挑战的工作，需要纯粹的技术能力之外的很多软性能力来辅助，比如组织的沟通协作能力、向上要权要责的能力、平衡产品业务期望的的能力、突发情况应急转变的能力等。越大的项目对于Owner的要求也越高，真能把大项目做好不怎么留大坑的少之又少。
大项目从启动到立项所用的时间很多时候是远超项目实际的开发周期的，项目的顺利推进需要“妥协”，但项目的成功需要坚持。很多项目之所以失败，是在做的过程中方方面面不断妥协，最后做出来的东西已经远离了最开始想要的样子。
业务层面
团队是一个宏观与微观并存的事物，宏观上我们说组织、讲战略、定规划、要排兵布阵，微观上我们关注沟通、成长、情绪。大部分同学之所以在微观上受挫，就是因为没能把握到宏观的节奏。公司是一个盈利组织，技术中心是一个成本部门，技术中心之所以会有某一个组织，那么一定是：“公司期望这个组织解决某一类问题，并且解决到一定程度。”
所以在这里你要理解一个关键词，“结果和KPI”并不取决于你怎么定义它，而是给你下放目标的组织与管理者对你的期望是怎样的，你们的GAP往往未必是结果的差别，而是期望的落差。
1. 拥抱变化
其实大多数时候不需要你去拥抱，变化会突如其来的抱住你，勒紧你的脖子让你有那么一瞬间觉得呼吸困难。互联 公司之所以变化快，很大程度取决于它的业务属性，相比传统公司，互联 公司能更快、更清晰地感受到与市场的契合程度，并且及时调整策略。
结合这几年的经历，到最近两年加入阿里巴巴，我的核心感悟有两个：
一是对业务的发展和环境的变化要敏感。如果能在变化到来之前主动发起变化，那么化被动为主动是最好的。即使不能，也要清晰地去感受和思考变化背后的动力在哪儿，去找到关键的发力点，让自己可以适应变化。
二是变化带来的工作内容的调整、汇 线的调整、团队的变化等，不管好坏，在一个时间段内都是相对的，而不是一个人工作生涯中绝对的。在不可能事事如意的情况下，调整自己的心态，让自己从情绪中跳出来，更多关注事情本身会是一个更好的选择。
2. 加人不能解决问题
即使嘴上再怎么说“不能”，但是动作会很诚实，依然会尽可能多地要HC，希望把更多“核心”的系统建设在你的职责范围内。其实，从管理的角度，你可以看一下你有没有“有效加人”，一些技术 Leader 不关注新人的 Landing，相当于只盯数量不盯质量，最后结果肯定是一塌糊涂的。
从绝对理论的角度，加人肯定是有帮助的，你的资源变多了，周转的空间和操作的余地都丰富了。但是从经验看，大部分情况下，加人没有产生最终的价值变化（项目的结果、业务的成败）。因为系统的开发、项目的推进并不是单纯的资源堆砌，1000 人日的系统哪是 1000 个人做一天就做出来的。真实的世界里，我们往往不是败在资源的使用量上，而是资源的使用方向和使用效率上。
3. 有意识地向上管理
这个问题源于过去经历的两个点：一是我经历了无数次的组织关系调整，我发现不管是我自己还是我团队的同学，大家相比于自己做什么以及带不带人、带多少人外，更关注的是自己的汇 线。自己汇 给谁，谁是我Leader，我和他处不处得来，他能不能让我有提高、有成长。二是很多同学会对与Leader的相处关系有困惑。
基于这两个点，我把向上管理作为一个单独的话题加了进来，先说结论：要！要！要！必须要！一定要！
连马老师都说员工离职的三大要素之一就是和Leader处不来，你怎么还能心安理得的忽略它。如果大家对于向上管理还停留在服从甚至谄媚的态度来处理你们的关系，我只能说太稚嫩了。我没有系统地学过向上管理，也没有体系化地看过这方面的书，所以我只说一下自己的理解。
个体在一个组织里想得到 酬和收益，基本的方法就是促进组织的成长与提高，并且同步提高自己，这样就可以从中分得自己的那份收益。这就要求你产出的结果是要对组织有正向溢出的，但是这个方向与标准并不是所有人都清楚或者能准确地把握到。
经常有绩效差的同学很沮丧甚至抱怨说自己经常加班，甚至是部门走的最晚的，周末也要处理工作等。先不讨论背景，如果命中上面这一条的，我先给你个忠告：除了按件计费的工厂，其它任何地方体力上的付出与最终结果都没有明显的直接关系。就像你上学的时候一定有那么几个别人家的孩子，要么就是特别努力学习特别好，要么就是看上去每天和你一起玩，但是成绩总是碾压你。从学校到 会，这个现象并没有消失，别迷信加班和体力上的付出，大多数人只要能不去思考，在体力上愿意做出的付出，远超你我的想象。
与Leader相处和沟通，本质上是为了达成一致的目标和互相认可的结果。这是一个非常关键的初衷，我有时候开玩笑和团队的同学聊，说你们要好好看看我的Leader到底想干嘛，这样你们做出来，我好去汇 。方向、节奏、结果的对焦对于工作的展开和拿成绩是至关重要的，同时你要从他身上获取更多的信息以便于自己的判断决策和学习，不断从他们身上吸取养分。
在一些环境中，体力上的付出是必须的，但是仅有体力上的付出最终只能感动你自己，你的团队并不想每天陪你加班到11点或者发布到凌晨2点，更没有兴趣凌晨1点半还拉个电话会讨论方案。所以一定要做好“期望管理”，Leader对你的期望、对项目的期望、你对他给予你空间和支持的期望，大家一定要对焦清楚，并且目标一致。
架构层面
著名的大数学家波利亚有一本名著《怎样解题》，其中给了一个四步解题法，可能站在研发的角度看会更有感觉：
往期精彩文章回顾
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！