规划中需要包含一些硬性的内容，比如这个目标要解决什么问题，怎么确定它解决了，解决得好不好，好的结果谁认可等。规划一定要有重点，没有重点那不叫规划，那是日程计划。很多同学对做规划不投入，也有自己的“想法”，比如公司业务或者战略变化太快、组织调整太频繁，下半年在哪个团队工作甚至做什么都不一定，所以规划做得并不认真。不否认变化频繁的存在，以及这种组织架构变化对规划的影响，但是如果你一直这样思考，你永远无法从变化中获得价值，因为你一直在置身事外。
2. 研发要比产品还懂业务
雷军说过：“永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰。”对于研发同学，你要比业务同学更懂业务，才能找到技术与业务平衡的空间。对大部分同学而言，常常是只熟悉自己负责的系统，但是对于想要更大空间和更多成长的同学，我可以给出明确的结论：只熟悉自己负责的系统是不够的。
首先，不同的人对熟悉的定义不一样。对于你负责、你贡献代码、你进行设计并且完成需求交付的系统，单是熟悉远不够。你不仅要知道它的前世今生，思考它的一路成长，纠结它的未来发展，同时还要清楚它的风险与隐患，它的生与死。
基于你清楚的核心系统，由它开始做业务场景上的外延，以此了解你的上下游，并且能做到结合业务场景去挖掘。从业务的角度、从产品的链路、从技术的调优和隐患多个视角去切，让自己的设计维度与视角不断拉升，这样你有把握或者有掌控力的范围会越来越大，未来才会有更多的机会。
管理层面
团队是一个宏观与微观并存的事物，宏观上我们说组织、讲战略、定规划、要排兵布阵，微观上我们关注沟通、成长、情绪。大部分同学之所以在微观上受挫，就是因为没能把握到宏观的节奏。公司是一个盈利组织，技术中心是一个成本部门，技术中心之所以会有某一个组织，那么一定是：“公司期望这个组织解决某一类问题，并且解决到一定程度。”
所以在这里你要理解一个关键词，“结果和KPI”并不取决于你怎么定义它，而是给你下放目标的组织与管理者对你的期望是怎样的，你们的GAP往往未必是结果的差别，而是期望的落差。
1. 拥抱变化
其实大多数时候不需要你去拥抱，变化会突如其来的抱住你，勒紧你的脖子让你有那么一瞬间觉得呼吸困难。互联网公司之所以变化快，很大程度取决于它的业务属性，相比传统公司，互联网公司能更快、更清晰地感受到与市场的契合程度，并且及时调整策略。
结合这几年的经历，到近两年加入阿里巴巴，我的核心感悟有两个：
一是对业务的发展和环境的变化要敏感。如果能在变化到来之前主动发起变化，那么化被动为主动是好的。即使不能，也要清晰地去感受和思考变化背后的动力在哪儿，去找到关键的发力点，让自己可以适应变化。
二是变化带来的工作内容的调整、汇报线的调整、团队的变化等，不管好坏，在一个时间段内都是相对的，而不是一个人工作生涯中的。在不可能事事如意的情况下，调整自己的心态，让自己从情绪中跳出来，更多关注事情本身会是一个更好的选择。
2. 加人不能解决问题
即使嘴上再怎么说“不能”，但是动作会很诚实，依然会尽可能多地要HC，希望把更多“核心”的系统建设在你的职责范围内。其实，从管理的角度，你可以看一下你有没有“有效加人”，一些技术 Leader 不关注新人的 Landing，相当于只盯数量不盯质量，后结果肯定是一塌糊涂的。
从理论的角度，加人肯定是有帮助的，你的资源变多了，周转的空间和操作的余地都丰富了。但是从经验看，大部分情况下，加人没有产生终的价值变化（项目的结果、业务的成败）。因为系统的开发、项目的推进并不是单纯的资源堆砌，1000 人日的系统哪是 1000 个人做就做出来的。真实的世界里，我们往往不是败在资源的使用量上，而是资源的使用方向和使用效率上。
3. 有意识地向上管理
这个问题源于过去经历的两个点：一是我经历了无数次的组织关系调整，我发现不管是我自己还是我团队的同学，大家相比于自己做什么以及带不带人、带多少人外，更关注的是自己的汇报线。自己汇报给谁，谁是我Leader，我和他处不处得来，他能不能让我有提高、有成长。二是很多同学会对与Leader的相处关系有困惑。
基于这两个点，我把向上管理作为一个单独的话题加了进来，先说结论：要！要！要！必须要！一定要！
连马老师都说员工离职的三大要素之一就是和Leader处不来，你怎么还能心安理得的忽略它。如果大家对于向上管理还停留在服从甚至谄媚的态度来处理你们的关系，我只能说太稚嫩了。我没有系统地学过向上管理，也没有体系化地看过这方面的书，所以我只说一下自己的理解。
个体在一个组织里想得到报酬和收益，基本的方法就是促进组织的成长与提高，并且同步提高自己，这样就可以从中分得自己的那份收益。这就要求你产出的结果是要对组织有正向溢出的，但是这个方向与标准并不是所有人都清楚或者能准确地把握到。
经常有绩效差的同学很沮丧甚至抱怨说自己经常加班，甚至是部门走的晚的，也要处理工作等。先不讨论背景，如果命中上面这一条的，我先给你个忠告：除了按件计费的工厂，其它任何地方体力上的付出与终结果都没有明显的直接关系。就像你上学的时候一定有那么几个别人家的孩子，要么就是特别努力学习特别好，要么就是看上去每天和你一起玩，但是成绩总是碾压你。从学校到社会，这个现象并没有消失，别迷信加班和体力上的付出，大多数人只要能不去思考，在体力上愿意做出的付出，远超你我的想象。
与Leader相处和沟通，本质上是为了达成一致的目标和互相认可的结果。这是一个非常关键的初衷，我有时候开玩笑和团队的同学聊，说你们要好好看看我的Leader到底想干嘛，这样你们做出来，我好去汇报。方向、节奏、结果的对焦对于工作的展开和拿成绩是至关重要的，同时你要从他身上获取更多的信息以便于自己的判断决策和学习，不断从他们身上吸取养分。
在一些环境中，体力上的付出是必须的，但是仅有体力上的付出终只能感动你自己，你的团队并不想每天陪你加班到11点或者发布到凌晨2点，更没有兴趣凌晨1点半还拉个电话会讨论方案。所以一定要做好“期望管理”，Leader对你的期望、对项目的期望、你对他给予你空间和支持的期望，大家一定要对焦清楚，并且目标一致。
架构层面
还有一点我觉得也很重要，就是在架构层面，包括业务架构、技术选型和细节实现上，要有清醒的认知。
1. 关键的是定义问题
爱因斯坦说过：“提出问题比解决问题更重要！”定义问题是个脑力活，解决问题是个体力活。大家往往习惯于看到一个问题就冲上去锤它，从概率上来讲，很大可能会陷入一个解决问题的黑洞，就是你不停地在解决问题，但是终你的情况没有变好。
当你面临一个困难或者一个情况时，首先比较重要的是定义问题，这到底是要解决什么、解决了有什么好处、怎么确定解决了。其次是定义结构，这个问题的关键点组成，你对应的解法是怎样的，这其中得失要怎么权衡轻重，并且终解决的效果如何贯穿和透传，由点及面。?
一个团队可以不停歇的埋头干，但是未必会干出成绩。大部分习惯罗列面对的问题，但是对这些问题并没有做一个全局的分析和梳理，其实难的就在“找问题”上。?
2. 问题的本质没那么高深
有时我们做一个项目，可能有一个产品需求，大家看完觉得不好做或者做不了，因为系统现在不支持，改造成本太高，并且还伴有很多不确定的技术风险。相信很少有人在这种情况下会无脑的要求加人、加工期来解决这个问题。大多数情况下我们会看有没有捷径或者其他方案，让产品效果达成，哪怕技术实现脏一些、绕一些。