近几年面试了不少新人,当问到职业规划时,大多都会说先积累技术,然后往架构师的方向发展。这可能是技术人的一个特质,喜欢跟机器相处,沉浸在代码之中,而不喜欢跟人打交道。
现实的情况是,一些中小公司可能没有专职的架构师岗位,即便有,也是需要身兼多职,很多时候程序员都在没做好准备的情况下,却被公司推到了管理岗位,即便是冠上了架构师的头衔,也需要做很多管理的工作,通常会面临下面的一些问题:
初次接触管理岗,需要和人打交道了,难以适应
仍然把自己当成是一个高级的开发者
需要多任务并行处理事情,分不清主次
团队成员从3、5人发展到10来人时,流程、做事方式等都需要转变,也会面临巨大的考验
今年年初,我就面临了一次很大的考验,团队的成员越来越多,公司的项目也越来越多,产品团队这边压力非常大,我也几乎到崩溃的边缘,甚至还给领导写了一封“诉苦”信,归根结底,还是能力的提升速度没有公司的发展速度快。
经过领导的引导和自己的调整,我觉得已经突破了瓶颈,并在这大半年的时间里有了明显改善和进步,下面分享一点我的体会。
心态
做任何事情,心态都非常重要,不好的心态会使你对完全能够胜任的事情也产生排斥的想法,最终做出非常糟糕的结果。举一个加班的例子:
如果你觉得8点就能搞定下班,但因为各种非自身原因导致10点才能完成;
提前考虑的比较周全,认为需要到11点才能完成任务,但因为配合的很好,10点就完成下班了。
同样是10点下班,后一种点心态就会好很多,因为在事前心里就有了预期,而实际结果比预期的好。
所以我们在进入管理岗位后,就要有随时会遇到各种问题的预期,解决一个个点问题就是我们升级打怪的过程。就像我们领导说的,必须经历痛苦才能够成长。
任务归类
作为一个开发人员,领导安排的任务按时交付就算合格了,如果能再考虑下扩展性、重用性、性能等问题就算是很优秀了,做的事情相对单一,平时也不会受到很多外界的干扰。
一旦走上技术管理岗位,会感觉事情突然翻了很多倍:
制定产品的任务计划
需要考虑团队成员的成长
合理地安排任务
各部门之间的协作
重难点技术的攻关
核心代码的编写
解决团队成员遇到的各种问题
…
如果没有一个合理的安排和归类,就会像无头苍蝇一样,到处乱窜,一天下来感觉非常忙碌,但好像又什么事情都没做。所以任务的归类非常重要。
事情再多,都可以按照,重要紧急、紧急不重要、重要不紧急和不重要不紧急这四个象限来进行分类。类分好了,先做什么,后做什么,就一目了然了。
任务下放
程序员通常都很自信,觉得自己写的代码是最好的,看别人的代码总觉得有各种各样的问题,在排查一些历史问题的时候,经常会说,这谁写的代码,这么烂,最后一看Git记录,发现是自己写的。
所以到了管理岗位后,任何事情都喜欢亲力亲为,就造成了自己忙死,而团队成员工作不饱和。带领团队后,对团队中每个人的性格和优缺点都要了如指掌,这样才能做到知人善用。
在上面一步做了任务归类后,就可以清楚地知道哪些是可以分配下去,哪些是需要自己处理。例如:
项目组反馈了一个紧急Bug,这是需要做的是准备好重现环境,安排合适的人进行排查和修复,而不是直接打开VS开始调试代码了。
懂得合理地分配任务,才能有更多的精力去做更重要的事情。
善用工具
不同的时期,有不同的做事习惯和风格,最早我团队只有3个人的时候,平时的沟通和任务的分配基本都是口头转述,因为这样效率最高,但仅限于团队成员足够少,并且每个人都能够配合默契,这样口头转述的内容才能不失真,真正地做到有效率。
慢慢地团队中加入了很多新鲜血液,再用口头转述就会存在很大的问题,同样的一句话,一个新人的理解和你想要达到的效果可能相差很远。这时就需要有文档了,我们现在使用语雀来写需求文档,更多的时候,我是让开发人员自己来写这个文档,然后我再来复审,看需求的理解是不是完全清楚了,这样做有一个好处,开发人员不是被动地接受任务,而是主动地参与思考。
团队成员增多,每天的需要提测的任务也越来越多,如果还是手动地发布部署会浪费大量的时间,这时就需要使用Jenkins、Docker等自动化构建的工具了。还有需求和任务的管理也必须工具化、流程化,这一块我们采用的是我们自己做的产品搭建出来的任务系统。
善用工具,可以将繁琐的,重复性的工作交给机器来做,就会有更多的精力去做更重要的事情。
最近一段时间的新的体会,希望对您有所帮助。