升职记录
升职不写博客，如衣锦夜行
距离上次写blog有大半年了。这段时间里一直在急忙忙的弄升职的事。直到昨天收到通知：升职通过，心里一块大石头落了地。
与其他的同事相比，用了5个Cycle(每个Cycle 半年)升职的我属于不长不短，恰在中游的位置。但是两年半的过程中，我经历了一系列变动：领导A在一年半时跑路；然后等来了领导B。好不容易和B制定了一系列的升职计划，进行到八个月时B又转去做其他领域；纠结继续按计划执行还是观望的时候迎来了新领导C。运气比较好，C还是很认可K的计划并帮助我在最后三个月里尽量完善升职资料，最后顺利的升职了。
下面来总结一些我认为有用，并行之有效的干货。
对项目要有Ownership
Ownership 名词。物主，身分，所有；所有权。
每次和我老板1对1聊天的时候，他总是强调要有项目的Ownership。起初我对这个很不以为意：做项目，有Ownership不是很应该的吗？但是随着参与进各类不同的项目之后，我发现每个人对Ownership的概念是不一样的。
有些人做项目做到一半，遇到一些来自其他组的阻力(blocker)后就原地躺平等别人来推动项目；有些人遇到阻力之后会积极的和其他组开会，达成共识，移除这些阻力。在绝大多数语境下，后者是对项目更有Ownership 的表现。而且要知道，对于升职的相关的项目，除了当事人之外没人会在乎项目进度与交付。所以对项目有Ownership，能更快的交付项目。项目好，你也好。
兼听则明，偏信则暗
我在开始执行升职计划的一年里，通过各种渠道找了三个导师(mentor)。一个是同组(org)的，一个是同大产品组(PA)的，和一个其他产品组的。每半个月会和三个导师分别聊半个小时左右。
有三个导师的好处就是，对于同样的一个问题，你能听到三个不同观点的反馈。并且他们会根据我自己的工作进度，职业规划给出一些很具体的建议。这样在遇到项目管理，项目选择等问题时我会有更多的信息来参考。当然，因为每个组和产品组之间的差异，不同的反馈也各有偏差。比如做应用与做底层之间对于同一个项目会有不同的难度系数。有时太多信息的反而会干扰决策。所以导师的数量和背景就需要个人的把握。
有效的文档
在谷歌，有一条广为人知的新人求生准则就是“多写文档，文档多多益善”。甚至有些走火入魔的同事们遇上个大事小情都要写文档，为了写文档而写文档。然而很多文档本身并没有太大的意义/作用。
有些文档是拿来做记录的，比如重点报告(one pager)，可以写的很潦草，注意力放在要讨论的问题本身，不需要太多引用，也不用填充太多的细节；有些文档是拿来做实现参考的，比如设计文档(design doc)，要写的很细致，引用证据丰富，并且逻辑上尽量无懈可击；有些文档是拿来协作的，比如会议记录(meeting note)、项目计划(rollout plan)，这类捞干货，有清晰的重点就可以。写有效的文档会降低沟通成本，并且不会在“写文档”这件事上浪费太多时间。
以上三点算是对这次升职的一个小结。希望能够帮助其他还在挣扎在4升5的小伙伴们。
