研发经理构建团队的心得分享

    在开始后面的内容之前,还是需要先提前声明一下,这并不是一篇吐槽的博客,而仅仅是将自己的感触和经验分享出来。当然大家更不要认为是炫耀,毕竟已经工作了十几年,确实是因为依旧保持着一颗热爱编程的心,所以直到现在依然奋战在软件开发的一线。好了,还是让我们尽快言归正传吧。
    在过去的十多年中,我曾就职的公司多为中小型公司,有美资、金融和国内股份制等多种不同性质的企业,唯一的一家大型公司还是软件外包公司,而我在这个公司的职位则是架构师,不是研发经理。我想,在做具体阐述和分析之前,还是先亮明我的观点,即软件团队的构建过程首先要考虑的是公司性质和企业文化,再者是我们的交付物,如特定的软件项目、软件产品、运营平台,或者说干脆就是公司内部使用的软件平台或工具,最后需要考虑的才是人员成本。
    对于软件公司而言,不论是做项目还是做产品,不可否认的是研发经理,架构师和程序员都属于公司的一线员工。他们的产出都将会或多或少的为公司带来一定的收益,因此这些一线开发团队在公司受到的重视程度自然也会高于其他性质的公司。由于本人更多的时间都是工作在软件公司,所以该篇博客将主要针对如何在软件公司中构建研发团队进行分析和经验分享。
    1. 项目团队:
    这个相对比较简单,一般而言都会根据项目的技术特征去寻找合适的开发人员,比如说,先挑选一位有经验的,最好是有相关项目经验的开发人员作为这个项目的Tech Leader,之后再根据技术特点,项目总额和开发周期去寻找适当数量和能力的开发者。如果再往深一层考虑,倘若该公司比较看好这个项目,甚至有可能在一段时间之后将其逐渐过渡为自己的产品,那么就需要在组建之初即刻考虑项目中技术人员的梯度建设问题。
    2. 产品研发团队:
    相比于为了某个项目组建团队,构建一支产品研发团队就应该有更多的问题有待提前考虑和解决。因为软件产品的盈利来源并不仅限于卖出一套产品所获得的实际收入,因为软件产品基本都是可持续更新的,所以除了可以每年向客户收取一定比例的产品维护费之外,还可以在产品不断成熟之后,收取更为可观的咨询费。由此可以看出,构建软件产品团队,不能仅仅单纯的依照产品的技术特征去物色适合的开发人员,同时也需要在组建团队的伊始,就要将人员梯度建设等问题考虑进来。比如,团队中的成员分为高、中、低和专项技能专家,对于高端的技术人员自始至终都会承担最核心、最关键的开发任务,然而对于中级技术人员来说,除了要保证产品开发的顺利实施之外,在产品的不断迭代和完善的过程中,还需要将一些已经突破的技术难关和沉淀下来的一些可复用基础功能进行有效的封装,从而大大降低之后的产品升级成本和维护难度。
    在经过若干年之后,随着产品的日臻成熟和稳定,当年的初级开发者已经成为这个团队中的重要技术骨干,而中级开发人员中的佼佼者则成功跃升为高级技术人员,高级开发者可以进一步升级为专项技术专家或高级咨询人员。此刻,公司便可以充分利用现有的人员和技术优势,继续深度挖掘和规划现有的软件产品并最终形成自己的解决方案。
    3. 运行平台研发团队:
    如果你所在的公司是非常有钱且知名的软件或互联网公司,他们往往都是在看好某一平台之后,不计成本的招人并快速组件团队,以便能够成为第一个吃螃蟹的人,在此种情况下,最好的方式还是能够和猎头合作,有的放矢的找到合适的高端技术人员,而对于中级开发者,由于给出的薪水将会明显高于市场行情,因此说快算组建将不会是什么难事儿。然而更多的问题却留在了后面,如果平台快速开发完毕同时也能达到预期,这样问题将不会立刻凸现,否则这些人的薪资与能力的匹配度失衡问题将会给公司其他团队的技术人员带来一定的负面影响。那么对于那些没有如此充裕预算的公司又该如何呢?其实这也是我现在在面临的问题,我的做法是,在产品没有完全启动之前,先寻找一些可以帮助我们突破核心技术的高级技术人员,与此同时,挖掘公司内部可能用到该项技术的热身性项目,前提是这种项目或者说小的产品仍然可以给公司带来一定的收益。由此研发经理不仅可以争取到更多时间、锻炼队伍,而且也会因每个成员都能快速对号入座而减轻了压力。一旦这些热身性项目实施成功,我们的研发团队就会有效的提升在直接上级和产品经理心中的信任度。因此即便在今后核心产品的实施中遇到一些问题,他们也仍有可能给予这个团队足够的信任和理解。
    该篇博客主要是以陈述的方式介绍自己的经验和想法,并没有进行更多的论述,因此对于一些失败的场景并没有给出具体的解决方法。最后需要说明的是,多年以来我始终都会坚持一个理念(引用一个非常不错哥们儿的名言),任何困难、挫折和暂时的失败,在主义面前都是浮云。
    浅陋之谈,欢迎指正,切勿吐槽。

posted @ 2012-09-17 09:09  OrangeAdmin  阅读(6399)  评论(4编辑  收藏  举报