纵观我与 InfoQ 的结缘,似乎我贡献的话题基本上都与研发和团队管理话题有关。当然,这并不奇怪——对我个人而言,从我终于发现自己更喜欢作为团队的杠杆而非孤胆英雄的时候起,我就决定了在自己的职业生涯中,更多地关注如何让一个团队变的更好。但除了这个理由之外,我对于这个话题的执着也来自于另一个原因:那就是随着阅历和经验的增加,我越来越发现,做一个好的研发管理者着实不易。
2015 年 12 月 ArchSummit 北京站上,应 InfoQ 的邀请,我很高兴的成为了大会的联席主席,并作为“研发管理”的出品人。按照计划,我同时还会在该主题下贡献一个话题,和各位听众分享在快速发展的组织中如何“为行驶的汽车换轮胎”。但是很不巧,由于所在公司的需要,我必须在 ArchSummit 那几天去趟纽约,所以很遗憾错过这次活动。幸好,虽然成为好的研发管理者着实不易,但国内却仍有那么一些执着于持续提升研发团队的技术管理者,他们在自己的岗位上不断实践,在业务快速发展与变化、团队规模快速扩张、技术基础快速发生变化的情况下不断思考与改进,提升着自己与团队的能力。这次 ArchSummit 北京站,我很高兴的邀请到了 Rancher Labs 联合创始人及 CEO 梁胜、互爱游戏 CTO 曾著、Mobvista CTO 王平、小猿搜题产品技术负责人唐巧等几位出色的 CEO/CTO/技术负责人,与听众们分享他们的所思,所得。
按说,有了“研发管理”专题的几位出色的演讲人,只管静待他们精彩的演讲开场就好。但是,错过 ArchSummit 的我还是希望用这个机会和大家分享我对研发管理的看法,权当本专题之外小小的热身。
管理(Management)与领导(Leadership)通常被比喻为“推”和“拉”,领导发挥着拉的作用,确定使命,描绘愿景,激发员工的动力;而管理则发挥着推的作用,适当的分配任务,确保这些任务可以在合适的时间内以合理的成本完成。“研发管理”的名字虽然只带有管理二字,却显然同时覆盖了管理和领导两个领域的内容。一个软件组织的研发团队,由于组织的商业模式不同,所处阶段的不同,显然会有不同的做法,但无论如何,研发管理既需要团队的负责人具有好的预见性,根据公司的业务状况和所处阶段设定使用,把技术的愿景植根在员工的内心;同时,团队的负责人又需要根据团队的规模,人员的能力,项目的状况合理的分配任务,帮助团队的能力成长,并能够通过合理的原则与制度,让组织能够向着自我完善的方向发展。相对偏传统企业的 IT 部门,也许技术管理者只需要更多的把精力放在管理,关心项目,资源分配,进度就可以;但对于业务变化迅速的互联网企业,技术团队的管理者就必须有足够的业务与技术远见,在不断变化的环境中同时承担推和拉的职责。
大多数软件企业的技术管理者都是“学而优则仕”的技术人员,毕业于理工科,一般都没有机会系统性的学习领导与管理(当然,在国内也极少有有价值的这类课程),因此大多数技术管理者都是自学成才——通过向自己的上级,工作伙伴或是书本学习,结合自己的实践,创造出属于自己的“工具箱”。然而,由于这个领域并不像纯粹的技术领域一样黑白分明,而“工具箱”的有效性很大程度上取决于所处的环境,因此依靠单打独斗,独自摸索的过程既痛苦又低效。回想起我在技术管理方向上摸索的痛苦,我只能庆幸于自己的运气,所幸这些摸索最终变成了我自己的管理风格。我想,这必然是我执着于进行技术管理类分享的原因,希望能够有这么一个机会,邀请来自各具特色的组织,具有不同经历与经验的 CTO 们,和大家一起分享他们的见解。在他们描述自己如何行事的“干货”背后,更多的是他们的思考,带领大家一起追求对研发管理“Why”的思考。如果本次 ArchSummit 北京站“研发管理”专题真的能够激发各位听众的热情与兴趣,能够让各位独自摸索的技术管理者有那么一些些体会与启发,那我一定会感到由衷的高兴。
感谢龙永昕对本文的审校。
评论