|饿了么4年，阿里2年：我的总结与思考( 三 )

基于业务规划做技术规划
很多同学习惯于把计划等同于规划。阿里是一家尊重技术的商业公司，所有的团队都在谈业务、规划里是业务规划、周报里是业务项目、汇报里是业务成果、晋升的时候也要突出你的“战功” 。
相比技术本身，大家更关注技术改变了什么，在业务部分聊技术团队如何做规划的原因就在于此，这是公司运营的的起点(目的) ，延伸出来才有具体的技术规划和组织设计作为解决方案。
深刻理解业务并设计战略，拆解战役与项目，通过组织和各种机制确保项目的执行与落地，最终拿到业务结果，这是一个大公司的标准战略执行方式。
研发同学做技术规划以及团队规划的时候，一定要考虑到你所在环境，公司今年要主打什么，所在大部门的目标是什么，对口的产品和业务现状如何，纯粹的技术迭代在业务上的好处在哪儿。
另外，团队目前有哪些不可抗力，或者影响规划推进的阻力。
很多同学做规划的时候会习惯性按照这个思路进行：

总结现状(痛点)
对应的解决方案和策略
展望未来

有时候第二和第三的顺序会反过来。很多时候大家发现最终的部门规划和自己做的规划没什么关联，不知道怎么往哪个方向用力，或者干脆继续按照自己的计划先走着。
对大部分同学，我建议规划要实在。做技术规划前，找你周边的研发团队聊一下，找你对口的产品、运营聊一下，知道他们的目标是什么，知道公司几个重点是什么。
然后再结合你们目前的痛点，在现在和未来之前找平衡、找现在和未来都有收益的那部分。
规划中需要包含一些硬性的内容，比如这个目标要解决什么问题，怎么确定它解决了，解决得好不好，好的结果谁认可等。规划一定要有重点，没有重点那不叫规划，那是日程计划。
很多同学对做规划不投入，也有自己的“想法” ，比如公司业务或者战略变化太快、组织调整太频繁，下半年在哪个团队工作甚至做什么都不一定，所以规划做得并不认真。
不否认变化频繁的存在，以及这种组织架构变化对规划的影响，但是如果你一直这样思考，你永远无法从变化中获得价值，因为你一直在置身事外。
研发要比产品还懂业务
雷军说过：“永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰。 ”对于研发同学，你要比业务同学更懂业务，才能找到技术与业务平衡的空间。
对大部分同学而言，常常是只熟悉自己负责的系统，但是对于想要更大空间和更多成长的同学，我可以给出明确的结论：只熟悉自己负责的系统是不够的。
首先，不同的人对熟悉的定义不一样。对于你负责、你贡献代码、你进行设计并且完成需求交付的系统，单是熟悉远不够。
你不仅要知道它的前世今生，思考它的一路成长，纠结它的未来发展，同时还要清楚它的风险与隐患，它的生与死。
基于你最清楚的核心系统，由它开始做业务场景上的外延，以此了解你的上下游，并且能做到结合业务场景去挖掘。
从业务的角度、从产品的链路、从技术的调优和隐患多个视角去切，让自己的设计维度与视角不断拉升，这样你有把握或者有掌控力的范围会越来越大，未来才会有更多的机会。
管理层面
团队是一个宏观与微观并存的事物，宏观上我们说组织、讲战略、定规划、要排兵布阵，微观上我们关注沟通、成长、情绪。大部分同学之所以在微观上受挫，就是因为没能把握到宏观的节奏。
公司是一个盈利组织，技术中心是一个成本部门，技术中心之所以会有某一个组织，那么一定是：“公司期望这个组织解决某一类问题，并且解决到一定程度。 ”
所以在这里你要理解一个关键词， “结果和 KPI”并不取决于你怎么定义它，而是给你下放目标的组织与管理者对你的期望是怎样的，你们的 GAP 往往未必是结果的差别，而是期望的落差。