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