关于晋升的几点感想
最近公司晋升季，辅导了几个同学的晋升，于是有如下的几个感想，随便写写。
-
工作中，不光要低头干活，还要抬头看路。老黄牛大家都喜欢，但是老黄牛确是晋升最慢的，甚至可能压根不会晋升。
-
工作中很多时候在任务分配的时候就注定了谁能晋升了，或者说在任务分配的时候，就注定了哪些人的晋升材料上可以浓墨重彩的描述一些事情了。
-
其实Java里面经常将“面相对象编程”，其实在工作中，“面向晋升工作”或者“面向领导工作”也未尝不可呢。
-
关于晋升材料
-
技术价值：
- 横向：质量、效能、成本。
- 纵向：能不能、好不好、先进不先进。
-
技术同学的晋升材料，还是需要主要讲清楚技术价值。大家晋升的时候很少讲技术价值（质量、效能、成本），更多的还都是在讲业务价值。而这个业务价值，如果换一拨人也大概率这样。甚至很多的时候这些业务价值，极大概率不是因为某些特定技术同学产生的，更多的可能是由于业务运营同学产生的。
-
在描述你所做的事情的时候，一定要围绕着：业务问题->业务痛点->技术问题->技术痛点->目标->难点&挑战->策略和思路->动作->技术结果和业务结果。这样才具有逻辑性。
-
关于晋升材料中具体言语描述，要经常问问自己，你写的材料和别人写的有啥区别，是否这段材料在其他场景也能使用（如果能使用，则可能写的太宽泛了，不够具体）。
-
晋升材料中，如果提太多能力建设的事情，其实很多时候太low了。
-
因为大多数人讲不清楚“你做的这个能力建设到底好不好，先进不先进”。评委也很难识别你做的这个事情怎么样。因此如果非要讲能力建设，那么就必须通过业界对标的形式来说明，说明你做的有多好。
- 业界对标的时候，可以参见BeafQPS方法论。
-
其次能力建设这部分，最好在结果中说明：你建设的这个能力，已经产生了什么技术价值，比如这个能力已经被复用到了xxx地方产生了yyyy结果，这样会好很多。单纯的能力建设太low。
-
-
日常就需要积累关于晋升材料中可能用到的文字描述、图片素材之类的。
-
-
关于Team Goal 或者OKR的编写
- 技术同学写的Team Goal或者OKR，是否可以直接被业务同学拿过去直接使用？（如果能直接被复用，则说明写的不是技术价值）比如技术同学和业务同学都在讲迭代效率，那么双方在描述迭代效率上是否会有区别呢？
-
如果你是方向负责人、团队负责人，那么要经常考虑你的团队是否投入了太大的精力在业务需求上，是被业务需求（问题）驱动的，还是说你的系统的架构、能力建设已经走在了业务的前面，已经在技术架构、技术贡献上做了足够多的探索。如果一个团队如果一直在做业务需求，那么这个团队的技术同学的独特价值怎么体现，是否随便换一拨人来搞也能ok。
-
日常工作中，我们的工作内容需要聚焦。其实对于团队和个人来说都是一样的。
-
我们首先需要有一个目标，然后基于这个目标拆解出动作，通过执行这些动作而产生对应的结果。
- 但是往往很多时候，我们可能初期有一个目标，但是执行的动作确不是这个目标拆解出来的，导致我们最终将上述流程反过来：拿着动作和结果去反推（或者重新定义）结果。
-
-
体系化是一个很有专业性的描述。我们的经验、能力建设、方法论等的都需要有体系化的整理。
- 比如你搞稳定性，你如果搞了很久的稳定性，确没有形成一个很体系化的内容，那么说明你专业性不够强。
