从开发者到技术管理，视角有哪些变化
共 1685字，需浏览 4分钟
·
2021-09-19 04:00
做技术一般有两种发展路线，一种是纯技术，一种是管理。这两种路线有什么不同呢？
本文来尝试从不同的视角来解读下日常的工作，分能力、意愿、分工、协作、梯队、文化六个维度来看。
开发者视角
我们都是从开发者开始的，这个视角大家会比较熟悉。
能力
入职以后，公司给我配备了导师，有什么不会的可以问他，他会带我三个月的时间。
三个月之后，我已经能够独立做一些需求的开发了。
接到一个需求，这个需求大部分是我会的，但也有一部分是我不会的，需要去学习。
做完这个需求之后我的能力提升了，以后再做这种需求能够 cover 住了。
领导让我独立负责一块事情，自己设计方案和进行后续的规划。
虽然中途犯了几次错，但现在我已经能够独立 owner 这个项目了。
意愿
现在的工作内容是我想做的事情，所以动力也很足。
我现在做的这个工具，能够提高很多效率，为公司节省 xx 人日的成本。
分工
我一直负责 xx 方面的需求的开发，这块事情交给我可以很好的解决
做一块事情做久了，想去做下别的事情，正好公司有轮岗的机制，可以熟悉下其他方面的工作。
协作
团队内每块事情都有专人负责，遇到什么问题，我能很快找到对应的人解决
和同事之间合作久了，都不需要沟通，我想做什么他立马就能 get 到
公司经常出去团建，我们现在比较熟悉了，合作起来也很顺畅
梯队
公司每个方面的工作都至少有两个人来做，我们能够互相 backup
xx 离职了，但是还好 zz 对那一块也比较熟悉，就把那块事情交给 zz 来接手了
他入职的时候是 p6，现在升 p7 了，也能带新人了
文化
遇到一件事情不知道怎么选择，想到公司有 “xxx” 的文化，所以我选择这样做
我认可公司的价值观，同事之间价值观也都一致，在这里待得比较舒服
管理者视角
工作若干年之后，我们可能会从开发者转为管理者，这时候对同样的事情就有不一样的视角了。
能力
团队一起做事，能力上限是大家能力的集合，希望团队成员能能力互补
入职了一个新人，潜力不错，让 xx 作为他的导师，带他熟悉一下，希望他过段时间能够独立做一些需求
xx 某方面的能力可以提高，这个需求可以让他锻炼一下这方面能力，就让他来做了
希望 xx 能够独立负责这个项目，我打算逐步放手，让他自己去设计方案做规划，逐渐让他自己 owner 这个项目
意愿
我了解过 xx 和 yy 都想做什么，也了解他们的能力，会综合他们能做的和想做的来给他们分配一些工作
每个项目、需求都要讲清楚目的是什么，能够带来什么影响，让大家知道自己做的事情的意义，这样动力会更强一些。
分工
每一块事情要具体的人来负责，这样遇到什么问题就可以找对应的人来快速解决，而且职责划分明确了，大家在团队内也会更有存在感
做一块事情一段时间之后，可以让大家轮岗做下别的事情，这样大家能够对整体都比较熟悉，而且也能够相互 backup
协作
月底组织一次团建，让新人 xx 和大家认识下，也好后面合作的时候顺畅一些
xx 和 yy 合作很久了，对彼此比较了解和信任，一起做某件事情效率特别高，这就是团队凝聚力的体现
梯队
每个方面都要有 backup，不能某个人离职了那块事情就没人熟悉了
团队内有 p6 xx 人，有 p7 xx 人，需要再招聘或者培养 xx 个 p7，才能 cover 住团队要做的事情
文化
xx 的行为不符合我们团队的价值观，会给团队带来不好的影响，找个时间和他聊一聊
定期的组织技术分享，打造学习型的组织，让大家能够主动的提升能力
总结
大部分开发者都会走上管理岗，最大的不同是之前只需要对自己 owner 的项目负责，能力上限取决于自己，而做管理后，需要对团队内部所有的项目负责，能力上限是团队内所有人的能力的集合，而且对待能力、意愿、分工、协作、梯队、文化等方面都会有不同的看法。
从高效开发的开发者，到辅助团队成长的管理者，视角是要有一些变化的。