从2001年在网易成为一名项目经理,到2011年进入腾讯,我经历了从“领导”几个人到几百个人的好几种管理岗位,名字有的叫“总监”,有的叫“经理”,还有什么O之类的。但是在十年之后,现在的我没有一个下属,一般的人看来似乎有点不可理解。正常来说,中国人的传统是“学而优则仕”,管人的总比做事的看起来要“高级”一点。那么,为什么我要“急流勇退”呢?其实并不是我觉得做一般的管理工作力不从心,也不是因为厌倦了管人,或者想要做闲云野鹤,而是我发现,如果要真正的管理好一个技术团队,还是要从技术方面下手。而这些真正能对技术团队管理有帮助的技术,不实际的去学习和实践,是非常难以掌握和熟练的。
技术团队有多难管,从人员流动这个事上,就能最直接的体会到。我记得我第一次参加网易的校园招聘,招聘了的几十个应届毕业生,这些毕业生在一年之内,有70%都离职了。他们有的是去考研、有的去留学、还有继承家族生意和考公务员的。当然留下来的那批,也有一部分在两年之内跳槽了。按理说网易也算是不错的公司,尚且面临如此之高的离职率,其他的公司可能会更加严重。我在这个事情上,花了无数的精力希望打造一个“具备凝聚力”的团队,试图降低这种流动性。但是无论如何努力,技术团队还是会“维持”着某个流动率,所以我意识到,如何降低人员流动对工作的冲击,才是一个必须要做的事情。我们知道,软件开发的交接,不是一个简单的事情。因为软件开发的文档、代码、工作关系,甚至很多工作的经验,都是以一种智力形式存在的。这种智力产品,如何从一个人的大脑迁移到另外一个大脑,如果不借助任何工具,无异于师徒传授技艺,是一个效率很低,结果非常不确定的过程。所以我认为,技术知识在团队内的共享,必须要有一些强而有力的技术工具来保障,才能成功。
技术团队的管理除了要应付人员流动的挑战外,如何衡量技术人员的工作量,从而预估工期和掌控开发进度,这也是一个巨大的挑战。这方面关于“项目管理”的知识也算汗牛充栋了。在实际的工作过程中,我们也尝试各种方法,但是不管使用什么“项目管理”的方法,我们总会发现,在项目经理的表格,到产品里可运行的代码之间,总有一道深深的鸿沟。不管我们的开发进度预留多少buff,也不管我们的项目进度报告的周期,从月、周细化到日甚至小时,都无法真正的准确的回答——现在项目开发到什么地步、将来的某个时间点,项目可能开发到什么程度。所以我开始承认,掌控技术项目开发进度,在一些需求变更特别频繁的领域,特别是互联网、游戏这类没有明确客户代表的领域,是一个非常模糊而且复杂的工作。我们必须抛弃工业时代对于某个“项目”的管理思路,而采用更新的思路,以及更有效的技术工具,才能真正的对项目管理提供有效的推动。
|