研发组织体系和岗位职级设计


本文是《IT研发中心管理思路、策略和制度》专题的一部分。


建议提前阅读:

《岗位、职位、职务、职级》

《研发中心各个岗位的设计和配合》


本文针对于中小公司设计,研发人数在1千人以上的大公司或者小于50人的小微公司也可参考。

前言:总体思路

    打破传统架构那样的一个个封闭的部门和团队,让他们以多元的形式更好地配合,避免冗余和不一致给中后期带来的不利影响。特别是基础能力和技术,非常有必要形成统一的力量。当然,其他的,比如说业务,当业务越来越多的时候,也趋向于凝聚、沉淀成基础的共享能力。

    举几个例子:一个叫做Supercell的游戏公司,共200余人,划分为中台和前台两部分,中台凝聚力量,前台快速冲刺、试错。这种架构非常成功,后来被腾讯以84亿美元收购,每位员工贡献值超过3.5亿人民币。阿里考察了Supercell,同时结合自己遇到的问题,在2009年成立了技术保障事业部、共享平台事业务。就连原本以产品为主的腾讯,在2018年,历时6年的架构大调整中,也成立几大事业部围绕技术委员会这样一个架构,同时还有一个技术工程事业部,专门负责基础技术和架构。然后是百度,也在2018年做出了架构调整,汇聚原来分散的基础能力(基础架构、共享平台、各分散的运维等),成立了基础技术体系事业群(TG)。同年,京东集团也发布了组织架构调整,成立前台、中台、后台,短短的说明中,重点提到了专业化、系统化、组件化。

    以上例子是后期加上的,只是想印证关于我下面的设计之合理性,实际上,下面这些设计是我多年的实践、不断反思和改进的结果,有些思想和上述公司不谋而合,但是也有一些差别,因为我是针对于“中小公司”设计的,这是前提。

    先说几个经验、心得体会:

    1、一定不要让研发、运维、测试等多权分立,办事流程低下,架构得不到统一,各团队一点都不团结,互相推诿甚至陷害,那画面真的不能太美。

    2、一定要重视架构和规范(前期欠下架构的债,迟早是要还的,而且代价非常大——“IT是重要且巨大的资产,而资产的根基由架构决定”)。且架构和规范的落地,一定是从顶层向下,由行政保障。IT人员是很有性格的,而且是有些犯贱的性格,你要让他们乖乖做事,理由充分还不够,还得让事情本身是“名正言顺”、“理所当然”,所以组织架构实际上是很大一门学问。

一、部门和岗位设置

    研发中心,为抽象的概念,以产品和研发为主的中小公司,一般不设研发中心。对于特大的集团公司,可以设研发子公司。下述的“研发中心”,都是抽象的概念,泛指和产品、技术相关的组织集合。

    研发中心(或者说研发相关的组织)的管理岗位可以设:总经理/研发总监 一名,副总监1~2名(一个偏技术,一个偏产品),资深技术总助1名,其他具备管理资格的各分支和团队leader若干。( 各分支和团队leader,一般是从下面所说的 产品项目团队 和 虚拟组织 中选出来,但名额不多,不是每个组都有leader)

    全局概览图,如下    

rd-center-org.png

    上图只画了研发相关的虚拟组织,实际上,公司还有其他的虚拟组织,虚拟组织和产品研发团队,不是上下级关系。不能以传统的思维来认识这种架构。

    这个图还可以再增加其他非研发岗位的人员,纳入到研发的管理体系,研发相关的组织是没有边界的。由于没有独立的大研发部门,就没有各部门的隔阂,公司所有人员和研发人员都是一体的,只是有些离研发近一点,有些离研发远一点而已

    另外,产品研发团队的各个项目组之间不是完全独立的,因为项目组有大有小,多个小项目组也可能形成一个产品线、产品平台,通常我们会把某个业务团队的管理单元调整到一个合适的规模,比如6~9人,大的会拆分、小的会合并。

    这套架构的关键之处有几点:

    1、以产品研发团队为中心,设计了人力资源池,绝大部分研发人员都在人力资源池里面。只有少部分高端技术人才或特殊人才,跳出了人力资源池,站在更高的服务者角度,推动产品研发团队的发展。

    2、在产品研发团队之外,明确了许多虚拟组织,这些组织成员,大多不是全职参与,但提供专业服务,能使研发中心工程效率、管理及规范化、先进性等方面得到明显改善。

    和传统架构相比

    1、传统的一级、二部门较多,部门与部门之间存在隔阂。而这套架构,首先,将产品和技术绑在一起管理,上面有研发总监、研发组织部、研发管理部、安全管理部统一管理。其次,将运维和测试,定位为产品研发团队的服务组织,并与基础设施研发团队一起,受“基创团队”的负责人管理,而基创团队的负责人(总监助理级别),通常又是技术管理组的负责人,间接管理所有研发项目,但是他又受技术与架构部的负责人(副总监级别)管理。副总监不过问具体项目,但是监管所有项目并管理所有架构。所以,我们看到,组织与组织之间,都是配合关系,不能有矛盾举个例子,根据需求及内部讨论,后端架构组提出使用分布式文件存储,架构部负责人(副总监)同意说做,那么应该由中间件组负责去调研,找到一款开源的产品后,但是要做少量二次开发,于是要成立一个开发组,在基创团队负责人(总监助理)的协助下,成立这个组,安排架构和开发人员开始做,完后,再让技术管理组负责人(总监助理)要求各项目组开发经理配合接入。这个事情就这么顺利,居然都没经过研发总监和研发组织部!话说总监和研发组织部,才是最后的杀手锏,再难的事情到那儿都可以搞定

    2、所有团队都不是单军作战比如说,某个项目组,需要性能测试支援,开发经理直接跟自己的上级说就是,因为开发经理的上级和测试部门的上上级是同一个人(技术管理组组长-总监助理级别),分分钟就能协调好资源。安全技术组做事,就更简单,它可以以安全管理组(顶层组织)的名义,直接向整个公司发文运维做事也简单,中间件运维搞不定,直接由中间件技术组接手,运维想推行一个规范,直接给上级领导说,上级领导同意,分分钟直接要求下属开发经理去落实大数据技术组、安全技术组等,都是基创团队的上级部门,有需要基创的地方,直接提要求就是了基创虽然是服务部门,但它与架构部相辅相成啊(架构部的大佬基本都是基创团队的leader级成员)而且又和产品研发团队同属于开发性质,可共享人力资源池

    完美!

    但是经验丰富的人可能会说:组织安排清晰、妥当了,并不代表组织一定能按预期效果运转。是的,还需要与这种组织方式配套的工作流程,绩效管理,人才管理,组织文化等方面共同作用。重点是 与该组织架构配套的 工作流程,每个人做事的方式,和传统的也不一样,但是本文重点讨论的是组织和岗位设计,其他方面参见另一篇文章《IT研发团队管理、人才治理经验》。


虚拟组织(半虚拟的组织,大多数人是兼职)

虚拟组织工作方式:

1、大多数成员为兼职,仍然要参与产品研发部的日常工作;

    除了少数身兼数职或特殊岗位的人员外,绝大多数人都会参与到产品研发团队中。

2、工作安排灵活,可由成员自由发起某项工作,通过评审和领导审批即可去做;

3、虚拟组织内部,设置1个或多个负责人,例如部长、副部长、组长、副组长,主要负责统筹规划和评审等各项工作。

    虚拟组织负责人,对其成员的管理,侧重于专业技艺,个人发展和激励等方面,氛围很OPEN。


顶级虚拟组织研发组织部(0级)、研发管理部(一级)、安全管理部(一级),由研发总监(P10)亲自领导。(后文有详细说明)


一级虚拟组织产品与设计部,由 资深产品架构师 / 副总监兼产品总监(P9) 领导。

         二级虚拟组织:产品管理组,产品研究组,UED(用户体验设计)

  • 产品管理组:由各个项目产品的负责人组成。

  • 产品研究组:负责统一的产品规划和产品体验等研究。

  • UED(用户体验设计):由 资深设计师 领导,UI 和 UE 组成。


一级虚拟组织技术与架构部,由 资深技术架构师 / 副总监(P9) 领导。

        二级虚拟组织:技术管理组(由 高级架构师 / 总监助理P8 领导)

        二级虚拟组织:专业技术组(以技术领域区分的 各领域技术专家P6~P8)

            专业技术组 包括:

            前端技术组,网络技术,安全技术组,测试架构组,Android/iOS技术组,大数据技术组等。


一级虚拟组织基础服务与创新团队(简称“基创”团队),通常由技术管理组组长(P8)领导

    二级虚拟组织:测试服务部,由 测试专家(P7) 领导;

        三级虚拟组织:自动化测试组,性能测试组,安全测试组

    (注:安全测试和性能测试 由 技术架构部的安全技术组和测试架构组支撑)

    二级虚拟组织:运维管理部,由 运维专家(P7) 领导;

        二级虚拟组织:系统运维组,中间件运维组等。


虚拟组织说明

1、研发组织部

    类似于“阿里组织部”,主要由各组织的leader组成,每个成员都是一个组织的代表,组织部会定期召开会议。

    负责研发管理策略的研究,以及各种研发流程和制度建设,并检查其执行。

    积极推动研发能力提升、研发成熟度提升(规范化、可复用、可优化、最佳实践),使各个项目都遵循产品和架构组相关的规范和最佳实践,达到较高的研发水平和标准;推动架构/产品/技术的优化和整改,推动统一技术平台的实施和落地等。

    促进和提高队伍的研发能力,强化研发队伍,做好人员招聘,新员工入职引导和培训,积极推动和组织各种技术交流/培训活动

    组成人员:由研发总监直接领导,组成人员包括 副总监/总监助理,各一级虚拟部门的leader,加上少量核心资深的产品经理和架构师,以及一些非技术类“研发管理岗”(下面有介绍) 负责人组成。


2、研发管理部

    一个行政事务和综合事务机构,服务于整个研发中心,其事务主要由研发中心负责人和研发组织部下发,比如研发中心的员工招聘、入职引导和培训,活动组织等人力和行政工作,以及跟踪研发流程、制度的执行,考核数据收集整理等综合管理工作。

    组成人员: 综合管理,非技术类的“研发管理岗(行政+综合管理,下面有介绍)”,研发总监任部长,可以由副总监主持工作,也可以总监亲自主持工作。


岗位类型:

研发管理岗(组织及管理事务):(招聘人数1~2人)

  • 负责推动和跟踪各种规章制度的执行;

  • 负责项目的全生命周期进度管理及组织协调,通常会跨部门/中心工作;

  • 负责制定和维护研发相关的表格、文档,管理部分研发相关的系统和数据;

研发管理岗(人事及HRBP):(招聘人数1~2人)

  • 熟悉IT领域业务知识和人力招聘知识,为业务部门招聘专业人才;

  • 负责研发中心的新员工入职引导,协助办理离职、入职等手续;

  • 对接公司的人力资源及财务部门, 负责薪酬福利方面的工作;

  • 协调员工关系,组织团队建设和培训,关注人才成长并负责绩效辅导。

研发管理岗(行政和综合事务):(招聘人数1~2人)

  • 对接公司的财务及行政部,为IT部门提供办公用品、财务支持;

  • 负责统计和维护部分数据和内部系统,如考勤、通讯录等;

  • 负责研发中心各类固定资产的管理和维护;

  • 负责会议室管理,工位/办公室管理;

  • 其他行政事务管理:接待,签到,会议组织等。

    行政/综合管理的对象包括人、财、务,就像一个大管家。

    行政/综合管理岗位也分为初、中、高级,高级行政/综合管理要能站在领导的宏观高度,进行规划、规范、组织、协调和督促。

通用岗位要求:

  • 优秀的人际沟通协调能力、亲和力,有较强的文字表达能力;

  • 诚信正直,品行端正,公正客观;

  • 工作细致认真,做事有条理,责任心强,执行能力强;

  • 大学本科及以上学历,行政管理、汉语言文学、计算机等相关专业优先;

  • 有行政、人力相关工作经验优先;

  • 熟悉研发工作和技术,有过产品、开发、测试、运维等岗位工作经验优先。



2、安全管理部

    由安全管理专家担任副部长(主持工作,通常由安全技术组的组长兼任),加上弱技术类的“安全管理岗”1~2位人员组成。

安全管理岗:(偏管理、弱技术岗位,要求具备一点点系统运维知识)

  • 推动安全治理体系、管理体系和技术体系的建设和实施;

  • 负责研发中心重要资料、账号的管理和维护;

  • 研究非信息技术相关的安全问题和风险控制(办公环境安全,法务,管理风险,舆情等)。

岗位要求:

  • 具备很强的安全意识,工作认真细致,做事坚持原则;

  • 具备较好的人际沟通协调能力,具备一定的管理能力;

  • 有过安全测试、运维和DBA(数据库管理员)、法务等岗位工作经验优先。


3、技术管理组

    负责各产品线组的日常技术类管理。协调开发人员工作,参与工作量评估、技术方案评审、代码走查等工作,领导解决各产品线组的技术难题,线上故障,并做好防范方案。对研发质量负责,协调测试、安全人员工作。

    负责各个系统的架构。使其满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新,并且识别非功能型需求,做好技术选型、技术架构风险识别和评估。

    参与各种技术规范和最佳实践的研究和制定,并负责在各个项目组内落地实施,让各项目达到一致的研发水平和标准。

    组成人员:应用架构师(需要 有丰富的应用设计经验和资深的技术水平),建议1个架构师服务3~5个产品线,任该产品线组的技术经理。(技术经理,虽然侧重于技术管理,但仍然具有一定的管理性质,需要具备基本的管理能力和责任心)

    工作方式:架构师必须得熟悉自己负责的项目使用的技术及重要的功能,对于特别重要的设计,需要多个架构师参与讨论和评审。

    技术管理组的应用架构师,相对于传统的一个项目一个技术经理的配置,更能优化和节省高级技术人员,而且他们都隶属于技术管理组,方便交流和沟通。


4、产品管理组

    参与筹建产品线组,或者撤销产品线组。

    负责各产品线组的日常管理,类似于项目经理,不但要统筹产品研发工作,还要负责管理好团队人员。偏业务和管理,建议从资深/高级产品经理中选拔,业务能力占40%,项目和管理经验占30%,管理能力、责任心等占30%。

    负责各个产品设计,并推动产品的研发和落地使用或商业使用。协调产品经理/助理、UI/UE设计师、运营等工作。

    组成人员:高级/资深产品经理,建议一个人负责1个产品线组,任该产品线组的项目经理。

    工作方式:全权对产品和项目负责,有权组建新产品项目组,在技术经理的辅导下完成对项目组所有团队人员的管理。


5、测试架构组

    强技术岗位,由测试专家组成。

    建立健全测试体系,将测试意识,测试工具,测试流程,渗透到研发的各个阶段。让测试工作能在研发团队高效的开展。

    另外,负责一些复杂的测试,比如白盒测试、性能测试和中间件测试,涉及Linux、网络、各种程序等,需要具备较全面的知识,能参与到系统架构中去,辅助架构设计,参与中间件选型的测试。可以由技术架构师兼职。(注意:安全强相关的测试,放到安全技术组去)。

    举个例子:生产环境,有些测试验证很难做,因为生产环境必须要真实数据,比如真实的商户,真实的“新”客户,真实的大额资金转账等。这时,就要论“测试设计,测试数据”的重要性了。比如上面的场景,可以设置一些模拟的接口,模拟真实场景,但是却能区分测试数据,在某些不方便测试的地方,做Mock。或者设计一个反向操作,设计一种方式可以清除测试数据。(只针对核心业务场景,专门设计,其他非核心的暂不考虑)。另一种方案,放入极小部分真实的流量做测试,这时不能在UI上操作,只能在后台看日志,所以关键流程的日志一定要有,而且最好是能聚合在一起方便查看,注意这个方案有一定风险,毕竟是真实客户,出了问题要有处理方案,最好是能控制到放入流量的用户数量。

    测试平台,测试模拟器等,也都需要由测试架构组牵头设计和研发。


6、安全技术组

    强技术岗位,由信息安全专家组成。需要具备较全面深厚的知识,以及很强的动手能力。

    负责研发中心一切信息安全技术相关的事务,比如应用安全、系统安全、中间件安全、网络安全等。(行政相关的工作,则可以通过安全管理部去下发和跟踪落实)

安全专家:熟悉漏洞、病毒原理,会渗透测试,有一定开发能力。


7、网络技术组

    强技术岗位,由网络技术专家组成。

    负责网络技术研究,对研发中心各个组织(开发)提供网络技术支撑,并主导网络相关的事项。

网络技术专家:熟悉或精通各种网络技术、网络设备,包括公有云网络和网络虚拟化,深入理解网络原理,具备一定编程能力。


8、运维架构组

    强技术岗位,由运维架构师组成。

    牵头运维自动化、智能化的整体设计和技术研究。包括运维基础设施的自动化管理(参考cmdb、ansible、阿里star-agent等),容器云平台架构,底层存储(参考CephFS、GlusterFS、NAS等),CI/CD及DevOps一体化运维平台,全维监控体系,智能告警、日志采集,运维大数据平台(与大数据技术组共建),使用ChatOps、AIOps技术构建智能运维平台。

    注意,这个组做的事情,有些需要其他组的人配合。


9、其他领域的技术组(前端技术组、大数据技术组等)

    由该领域的专家领导,该领域的所有专业技术人员均为成员,但几乎都为兼职,日常以自己的项目工作为主。

    专业技术组,负责专业领域的技术研究,并将研究结果应用于开发、测试、运维等团队。另外,会定期组织技术分享、培训,也有可能会集思广益,做一些架构研讨。


运维管理部

    运维的整体设计思路,借鉴与目前越来越主流的DevOps、微服务运维、容器云运维、AIOps方法,使用各种工具,及自研运维工具,将运维工作减少60%,剩下的20%由研发团队借助自动化、智能化运维工具自己做,最后运维团队只剩20%的工作,这20%主要侧重于管理。运维团队的其他时间,可以用来研究运维相关的底层技术。

    另外,将中间件运维单独出来,成立专业的中间件运维组,由精通某中间件的人(可以是运维也可以是开发),负责该中间件的运维,例如Kafka、Redis、HDFS、SeaweedFS、MySQL、MongoDB、Etcd、Kubernetes等。

    除了中间件运维,其他运维工作(包括简单的网络操作),都由“系统运维组”负责。

    注意,这里没有网络组,简单的网络运维操作,比如开策略、简单的路由防火墙配置等,都交给安全管理组、系统运维组做了。为了让网络技术更专业,将成立网络技术组,放在技术架构部下,专门负责网络技术研究,做网络架构及解决网络疑难问题。

    PS:我发现知乎上有篇文章《阿里巴巴正在“杀死”运维》,和我的思路比较接近。

    “2016年的时候,阿里巴巴技术团队经历了一次非常大的调整:把日常的运维工作交给研发做。

    原来的 PE(Production Engineer)要么转岗去做工具平台开发,要么作为运维专家做产品规划和设计,还有一部分无法适应的只能黯然离开。

    这是阿里运维从工具化到自动化的过程里,最重要的一步。以前运维团队需要支撑集团非常多的BU,干的都是脏活、杂活、累活。”

    实际上,阿里也都是学的国外的做法:

    Netflix 从一开始就强调开发人员进行自助化运维,他们的理念是:谁构建,谁运维。其运维工作全部由开发人员完成,只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。类似的还有亚马逊,无论是电商业务还是 AWS 公有云业务,都由开发负责。

    我设计的这个运维部,是一个高度自动化运维之后的一个偏产品、研究和管理的组织,他们是真正的运维专家,我期望他们干脏活儿、累活儿、杂活儿的时间,不超过20%,如果超过这个时间,就得考虑改进,短期内将一些技术含量低的工作,交给外包或者实习生。


系统运维组

1、系统运维(普通技术岗位,偏应用方向):

    熟悉或者精通linux系统及常用工具,熟悉网络技术,熟悉虚拟化和容器技术,熟悉shell编程,熟悉监控和问题排查,熟悉各种运维工具,熟悉各种常见应用和中间件的部署和配置(nginx、mysql、redis、tomcat等)。

2、系统运维(普通技术岗位,偏主机和网络维护)

    说明:如果主机和网络维护的工作量不多(小型的数据中心),可以由应用运维和网络专家兼职!(如果使用云服务器,也可以不招聘这个岗位的人)

职责

  • 1.负责公司主机、存储和SAN交换等软硬件设备运维、优化及故障处理,负责数据机房的巡检、维护;

  • 2.负责各业务系统所需服务器的资源管理、环境搭建及部署;

  • 3.负责各种服务器、存储的配置规划、性能调优和资源可用性监控;

  • 4.负责公司网络设备配置及调试,如路由器、交换机、防火墙设置等,及网络流量分析和监控;

  • 5.负责公司主机服务器、网络等相关系统安全策略的配置和管理。

要求

  • 1.精通基础设施、数据库、网络、主机、存储、安全等相关理论及技术;

  • 2.熟悉主流服务器、存储厂商的相关产品;

  • 3.熟练掌握主流网络设备配置和管理维护;具有大公司网络系统规划设计、建设及维护经验优先;

PS:可能有人注意到,没有“应用运维组”,是的,应用都由研发自己运维,但系统运维组会提供必要的协助和管理。


中间件运维组

    上面已经介绍了,中间件包括MQ、Redis、数据库、分布式存储等,还包括一些大数据的东西。传统的运维人员根本搞不定这么多,得由研发专家兼职,且优先考虑自动化、智能化运维。某些方面也可以或需要和系统运维结合。


基础服务与创新团队

基础设施研发部(Core Infrastructure)

    负责实用类技术创新工作,研究和引进新兴技术和工具(包括但不限于前端、后端、大数据、开发、运维等),研发具有自主知识产权的技术类产品,并负责研发和落地实施。

    促进运维、测试、开发(后端、前端、移动端、大数据)等相关效率的提升。负责搭建公共技术平台&创新平台,主持研发基础组件、中间件等,包括但不限于 统一配置中心,自动化运维平台,基础大数据平台,基础开发框架,基础UI框架,自动化测试框架等。

    组成人员:由系统架构师和各类技术专家组成,副总监/总监助理/高级别架构师担任部长(建议与技术管理组组长为同一人),根据需要,成立临时或长期的项目组,选拔负责人,并分配中高级开发人员。比如:

  • 统一配置中心项目组

  • 基础开发框架项目组

  • 流程引擎项目组

    这些临时或长期项目组,都 直属于 基础设施研发部。

    另外,可以单独设置平行兄弟机构:创新研究院,专门负责前沿高新技术产品的研究。

    无论是基础设施研发部还是创新研究院,都可以承接产品类的研究和开发任务、有产品经理参与。


产品研发团队

    包括各产品业务线 或 独立项目团队,负责完整的产品研发(产品设计、开发、测试、运维等)。例如:

  • --会员产品线

  • --微商城

  • --营销产品线

  • --开放平台中心

  • --交易平台中心

  • --....

    项目组主要受“产品与体验部-产品管理组”和“技术与架构部-技术管理组”共同管理。产品研发团队成员的日常工作管理和考核,主要由产品项目经理(PO)和技术经理来负责,但他们都不是固定岗位。每个组内,产品、开发、测试等各司其职,由高级的人员带低级的人员,项目计划由产品和开发根据产品部和架构部的指导自己协调。


问题一:产品研发团队与公司的其他部门(销售,运营,管理......),是如何组织的?

答案:以人为单位来看-->

    1)人员的组织安排,是以其岗位和职责来确定的,换句话说,他的工作重心在哪里,他就应该在哪里。

    举个例子:市场部,张某某,参与辅助产品A的市场推广和运营,属于产品和市场客户之间的一个桥梁,但是他花在产品研究和测试上的时间达到了40%,而且他的工作对研发团队有着巨大的影响。但是张某某的职责还是属于市场推广和运营,他不是产品,也不是测试,而且他也不具备产品或测试的专业能力。市场部觉得他工作做得不好,可以换掉他;产品项目团队觉得他很重要,可以将他借调或者划归过去,甚至可以转岗。

    2)跨部门之间的任务协调,如果两个人熟悉,可以直接点对点直接分派任务。如果双方不熟悉,通过双方的共同上级组织和领导,也可以快速分配和执行任务。

    举个例子:客服中心,邓某某,时常需要研发团队的支持,或反馈一些问题,研发团队也有跟踪解决,但是邓某某是为客服中心服务的,她和研发团队双方之间的任务推动,可能要经过各自的上级组织和领导进行沟通。(前提是双方的上级,一定是可以顺畅沟通、达成一致的,在这个例子中,邓某某如果对研发组成员熟悉,目标清晰,她也可以直接跟该成员沟通并发起任务,最坏情况下,邓某某对研发组成员不熟,她想要给研发组发起任务,就要通过两个组织的上级关系的连线进行:邓先提交任务给自己的直属领导A,A与研发团队无直接关系,则A自动往上抛,抛到上级运营总监B处,而运营总监B和研发部的几个负责人熟悉,所以他可以直达研发部的许多个负责人,目标明确后,他可以直接把任务转到某个研发部负责人或联络人处,然后再由那个人决定将这个任务分配给具体团队的leader,再由leader分配给个人,说白了,就是通过关联关系,把所有员工串联起来,借助办公系统,还可以达到半自动化,任务很快就能推动起来)


总结:

1、任务流转是公司管理的核心机制,任何人都可以给其他人分配任务,这种机制是跨部门适用的;

2、公司整体机制是,人员可以跨部门调动,或者跨部门任职的,

3、有隔阂的实体部门之间,一定是有某种有效的沟通的,例如跨部门的虚拟组织,或者领导与领导之间的共同组织,所以两点之间一定有一条或者多条连线,通过任务的跨部门流转机制,所有不同部门之间的配合都会变得很容易。

    建议:公司成立一些跨部门的虚拟组织(例如xxx领导小组,xxx委员会,xxx管委会,xxx专项小组),将各部门leader和重点负责人紧密联系在一起,责任也一起承担,同呼吸共命运,让高层之间、跨部门之间的沟通顺畅,顺畅到双方的沟通一句话就能达成,顺畅到跨部门的配合能形成默契,通过任务流转机制,任务就能快速发起和执行。

    任务的跨部门流转,存在一个细节上的问题:研发人员都通过办公系统做在线任务分发,如果其他部门人员不用这个系统怎么办?解决方案:将在线任务分发系统,推广到全公司使用;至少可以推广到,与研发相关的协作,都通过任务分发系统进行;再退一步,即便其他部门不用这个系统,则可以通过研发部中介人进行任务中转,这个中介人不一定是研发总监或者副总监,研发总监可以安排一个或几个作为对外联系人,这样就可以将其他部门的任务转换成研发系统内部的任务。


具体岗位安排(举例)

注意1:

    某管理岗位如果空缺,则由上上级负责管理,或者指派特定人来临时负责。

    通常,某人任某部门经理,就不再任其下级部门的管理岗位(特殊高端岗位除外)。

注意2:

    岗位状态有 正式、临时、自由三种,该岗位的正式、临时成员,受该组织的上级管理,而自由成员,不受该组织的上级管理。一般来说,需要比较长期的参与到某个岗位的工作中,但是却不能受控于这个岗位时,处于该岗位的'自由'状态。


张莫某

职位/岗位:

<研发中心>技术总监 [正式]

<研发中心.研发管理部>部长 [正式]

<研发中心.技术与架构部.运维技术组>运维架构师 [自由]

职级:P10 - 首席架构师

(技术与架构部 部长空缺,由研发管理部部长直接负责)


刘莫某

职位/岗位:

<研发中心>总监助理 [正式]

<研发中心.技术与架构部.基础技术组>组长 [正式]

<研发中心.技术与架构部.技术管理组>应用架构师 [自由]

<研发中心.技术与架构部.测试架构组>性能测试专家 [自由]

职级:P8 - 高级架构师


黄某某

职位/岗位:

<研发中心>副总监 [正式]

<研发中心.产品与体验部>部长 [正式]

<研发中心.产品与体验部.产品研究组>产品研究员 [自由]

职级:P8 - 资深产品经理


注意,上面三个人,职位很高,根据规则,他们不兼任下级部门的管理岗位,但是,在下级部门不完善、人员不足的时候,他们会身兼N多岗位,只不过他们属于这些岗位的“自由”成员而已,比如技术总监,可能亲自担任应用架构师、平台架构师、安全测试工程师、中间件运维工程师等等。


李某某

职位/岗位:

<研发中心.产品研发部.会员产品线>Java开发工程师 [正式]

职级:P4 - 工程师


说明:像李某某,这是最底层的开发,只有一个岗位。


王某某

职位/岗位:

<研发中心.技术与架构部.技术管理组>应用架构师 [正式]

<研发中心.技术与架构部.测试架构组>组长 [正式]

<研发中心.产品研发部.会员产品线>技术经理 [正式]

<研发中心.产品研发部.开放平台中心>技术经理 [临时]

<研发中心.运维保障部.中间件运维组>Redis运维工程师 [正式]

职级:P7 - 架构师


说明:像王某某,这种中层技术人员,身兼N多管理和技术专家岗位,这是常态。


答疑

1、有人说,应该把测试、前端、大数据、网络等全都独立成部门:测试部、网络部、大数据部等。

回答:其实是相对独立的,但不是完全独立的。

    完全独立的坏处应该不用多说。把他们分成虚拟组织,其实考虑到他们都是研发团队中的一员,只不过技术方向不同,但本质上都是做技术的。整个研发团队有两部分:产品研发团队和基础设施研发及创新团队(简称“基创”研发团队),前者的项目按业务区分,后者的项目按技术区分,业务与业务不一定相同,技术与技术也不一定相同,举个例子,产品研发团队有“网上商城”项目和“运营平台”项目,基础研发团队有“容器云平台”项目、“自动化测试平台”项目和“大数据分析平台”项目,把他们放在一起,并没有不妥,并不一定非要按运维、测试、大数据这样来划分部门,部门对管理的危害远远大于项目组。


工位形式

1、由研发行政管理人员安排和协调,原则上不固定工位(工位都是临时的),但同组织的人最好是坐在一起,方便沟通,一般按 项目团队、岗位性质(产品、测试、开发、运维等)、虚拟组织等因素 划分区域,优先按工作重心来协调工位。行政管理人员根据情况可以随时调整大家的工位。

例1:“理财产品专项组” 的大部分人员集中在B区域,另外,给产品经理、技术经理留一个位置,产品经理、技术经理可以在这里办公,也可以在各自的“总部”办公。

例2:“运维保障部”人员集中在C区域,可以认为这个区域是运维人员的“总部”,但是个别运维人员也可能进驻到项目组。

2、中高层的管理者,建议设独立办公区、或者办公室,可选的人包括:研发中心的技术总监/总经理,副总监,总监助理,以及大部门的经理、副经理。这就好比军队中的统帅,通常不和小兵坐在一起,一来突出领导的威严、地位与特殊性,二来是掩盖领导的隐私、避免重要的谈话被人听到,或者重要的资料被人看到,三来是安静的空间方便领导的思考和决策。

3、一些特殊的岗位,也可以设单独的办公区、办公室,比如专门负责策划和架构的高级架构师,专门负责高精尖技术研究的专家,为这些高级人才、且单兵作战的那种,安排比较安静的空间,另外像负责人力资源、财务方面,需要一定隐私的也应该安排单独的区域。


管理形式


每个员工,都有一个或多个上级领导,有若干个岗位,每个岗位有一个岗位负责人,对于他的每个岗位,有一个或0个备份人员。

比如,张三,他是一名 中级自动化测试工程师(P5),他目前身兼两个岗位: 

岗位1:理财产品项目组 自动化测试工程师,该岗位有一个备份人员 李四。

岗位2:开放平台项目组 自动化测试工程师,该岗位无备份人员。

他的日常工作,主要由这两个项目组的技术经理来安排。

同时,他也是 测试架构组(虚拟组织)的临时成员。测试架构组的组长,也可能会给他安排任务,但如果有冲突,需要和项目组的经理商量。


以上,部分经典参考资料:

《Spotify的敏捷管理(部落、小队、分会和协会)》:

https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify


2 研发序列岗位级别设计

2.1 设计思路

    参考业界主流做法,比如以腾讯、阿里的标准,这样做认可度和可理解性会比较好。另外,为了让岗位级别看起来更加高大上,让职员更满意,适当把各个级别拔高一点。

    首先,将职位和职级分开,分成管理岗位 和 非管理岗位。

    管理岗位的层级单独设置,以[M+数字]表示管理岗位级别,例如M1、M2、M5,最基层的管理岗位为M1,最高层的管理岗位为M10(10个层级通常够用了,即使阿里这样的大集团公司,10也基本够用,如果层级超过10,建议尽量扁平化)

    除了管理岗位,其他绝大多数岗位都是专业岗位,以字母P代表,为了方便管理,P取值范围定为1~12(12级基本上够用了,即便一年升一级,也要12年,况且该职业的最高级,哪能是随随便便能达到的)。

    专业岗位,按职业技能划分多个职业通道(序列),比如行政、财务、设计、运维、开发、运营、产品、科研等。

    一个没有任何职业能力的毕业生,可以从这些职业通道的任何一个从1级开始,修炼,打怪升级,直到千万年薪。如同一个完整的人生指引。横轴是X个职业通道,专业技能各不相同,纵轴是P个级别,技能水平各不同。

    不同的职业通道,有着不同的级别定义策略。腾讯那种固定4层,每层3个级别的方法不可取,例如工程师序列,包括初级工程师、高级工程师、架构师、资深架构师等,硬生生的划为4层,而且每层3个级别不合适。另外,像工程师这样的序列,大多属于多人协作,到P6就能管理人了,但是像研究员这样的偏个人作战的序列,到P6还只是个初级研究员,真正到P7或者P8才具备一定的管理属性。所以,级别按序列划分,每个序列根据自身的职业特点,定义扁平的P个级别。

    另外,不是每个职业序列,都是从1级开始,最终到12级。根据职业特点,可以从1~8级的任意一级开始,从任意一级结束。不同序列的级别,存在一定的映射关系,相同级别应该尽量保持一致的重要性,且能和管理职位级别对应起来(后文列出了一个职位和职级的参考映射表)。

2.2 职业通道(序列)

2.2.1 工程师序列 和 研究员序列

    这两个序列相近,取字母P表示。

    类似于大学里面,有教师和研究员两类:

    大学教师的职称分为:助教、讲师、副教授和教授四种。

    大学里面有专门的研究所,

    研究员的职称分为:实习研究员、助理研究员、副研究员、研究员四种。

    区别是:研究员没有教学任务只承担科研任务,教授既要承担教学任务又要从事科研工作。

    研究员与教授都属于正高级职称,副研究员与副教授属于副高级职称。研究员和高级研究员是一个意思,都是正高职称。

    在研究所里,通常领导或者是学术带头人才称之为研究员,高级研究员可以说相当于教授,副研究员也相当于是副教授级别。但是在研究所里,研究员都不用教授的职称。

    研究员一般在研究所中,掌握着本学科领域内的国际国内最新进展,取得过高水平的研究成果,还要参与国家或单位的重要科研任务。通常研究所中的领导以及学术带头人是研究员的职称,作出贡献后可以被评选为院士。


    综合多方面的总结和思考,工程师序列的职级定义如下:

  • 工程师(P3~P4) - (应届生或工作2年内)

  • 高级工程师(P5) - (工作1~4年,可放宽到6年)

  • 资深工程师(P6) - (工作4~8年,可放宽到15年)

  • 架构师(P7) - (工作6年以上)

  • 高级架构师(P8) - (工作8年以上)

  • 资深架构师(P9) - (工作10年以上)

    P10及以上,暂无,待后续有需要时在设置。

    P10~P12可设置首席架构师、杰出工程师(Distinguished Engineer)、合伙工程师(Fellow Engineer)。

    P10及以上的职级都为虚级、荣誉职级,因为他们通常为某领域的领导及技术带头人,职级不过是荣誉的象征,职级是虚衔,岗位才是实衔。

    

    注意年限的限制,设计得是非常宽泛的下限很低,是考虑到一些特别优秀的人才;上限很高,是为了兼顾用人需求和人才的特殊经历),下限是对这个岗位经验的要求,哪怕是天才,也需要长年的经验积累,而且这个下限已经比较低了,不能轻易松动和违背,如果要破格定级、升级,需要高两级的人保荐才行。

    破格的例子:蒋凡,工作4年后创建了友盟,3年后被阿里收购,任阿里高级总监(M5/P10),目前已经是阿里副总裁,M6+的级别。之所以蒋凡升级这么快,是因为阿里集团CEO张勇(M9)的青睐。

    容易破格晋升的职业通道包括但不限于:高端技术类,产品类,创意类,然后是普通技术类。


    研究员序列的职级定义如下:

  • P5 助理研究员 - (应届生或工作2年内,建议硕士以上)

  • P6 初级研究员 - (博士毕业生,或硕士工作2~8年,本科工作3~8年)

  • P7 副研究员 - (博士工作2年以上,或硕士工作4年以上,本科工作5年以上)

  • P8 研究员 - (博士工作4年以上,或硕士工作6年以上,本科工作7年以上)

  • P9 高级研究员 - (博士工作6年以上,或硕士工作8年以上,本科工作9年以上)

    P10及以上,暂无,待后续有需要时在设置。

    P10~P12可设置首席研究员、科学家、首席科学家(Principal Scientist)。

    P10及以上的职级都为虚级、荣誉职级,因为他们通常为某领域的领导及技术带头人,职级不过是荣誉的象征,职级是虚衔,岗位才是实衔。


2.2.2 产品序列

    产品序列,也取字母P表示。

    综合多方面的总结和思考,产品序列的职级定义如下:

  • 助理产品经理(P3~P4) - (应届生或工作2年内)

  • 初级产品经理(P5) - (工作1~4年,可放宽到6年)

  • 中级产品经理(P6) - (工作4~8年,可放宽到15年)

  • 高级产品经理(P7) - (工作6年以上)

  • 资深产品经理(P8) - (工作8年以上)

  • 产品架构师(P9) - (工作10年以上)

    P10~P12可设置首席产品架构师、杰出产品经理(Distinguished PM)、合伙产品经理(Fellow PM)。

    P10及以上的职级都为虚级、荣誉职级,因为他们通常为某领域的领导及产品带头人,职级不过是荣誉的象征,职级是虚衔,岗位才是实衔。


2.2.3 管理序列

    管理序列,由于其特殊性,取字母M表示。

    管理序列的职级定义如下:

1、集团公司

  • M1=主管(P6)

  • M2=经理(P7)

  • M3=高级经理(P8)

  • M4=总监(P9)

  • M5=高级总监(P10) - 事业部/分子公司总经理/总裁

  • M6=副总裁VP(P11)- 事业部/分子公司总经理/总裁

  • M7=高级副总裁SVP(P12)

  • M7~8=CXO

  • M8~9=CEO

  • M10=董事长

2、中小公司

  • M1=主管(P6)

  • M2=经理(P7)

  • M3=高级经理(P8)

  • M4=总监(P9)

  • M5=高级总监(P10)

  • M5~6=公司副总经理(P10~11)

  • M7=公司总经理(P12)

  • M8=董事长(可以没有)


3、职位和职级对应关系(参考)

  • M1~2项目经理:P6~7

  • M1~2技术经理:P6~7

  • M3=高级经理(P8)

  • M4=总监(P9)

中小公司:

  • M5=高级总监(P10)

  • M5~6=公司副总经理(P10~11)

  • M7=公司总经理(P12)

集团公司:

  • M5=事业部/分子公司总经理/总裁(P10)

  • M5~6=副总裁VP(P10~11)

  • M7=高级副总裁SVP(P12)


2.3 职级评定策略

    职级评定需要解决两个重难点问题:

1、职级对人才是否有吸引力?

2、职级对新老员工是否公平?

    为解决以上问题,我们将每个级别,暗分为3档(不公开),

    例如  P6-,P6,P6+,P7-,正常情况下 P7-工资等于P6+,

    真正决定你是否能从P6升到P7的,是要看你能否升到P6+,只要能,正常情况下第二年必然到P7。

    这样做的好处是:在公司很大很知名的时候,可以在不提高工资的情况下,以更高的职级来吸引人,或者在面试官无法给出更高职级的时候,可以用低一级但较高的工资招收人。另外,对老员工每个职级都有3个档位可以调节,做得不好的可以适当降一点,做得一般的可以适当加一点。


2.4 各级别对应的薪酬

2017年重庆参考薪资(在重庆非常具有竞争力的):

P3-初级工程师: 9万 ( 8~10万,7k*13)  - (点评:应届生,重庆8~12万年薪,相当不错)

P4-中级工程师: 11万(10~12万,9k*13)  - (点评:工作一两年的工程师,9~10k,很有吸引力)

P5-高级工程师: 15万(13~18万,11k*13) - (点评:工作三四年,核心开发,月薪12k,很有竞争力)

P6-资深工程师(初级架构师): 20万(18~26万,15k*13) - (点评:工作五六年,项目负责人,月薪15~20k,步入高薪行列)

P7-技术专家(中级架构师): 28万(26~32万,22k*13) - (点评:准大神级人物,经验又比较丰富,22~25k很优越了)

P8-高级专家(高级架构师): 36万(32~42万,28k*13) - (点评:大神级人物,经验非常丰富,28~32k 奠定江湖地位)

P9-资深专家(资深架构师): 45万(42~52万,10k*13) - (点评:已经有非常丰富的技术管理经验和深厚的技术底蕴,4万月薪 无人出其左右)

M5 ~ M7:60万+(点评:企业领军人物,大局为重,大将风采,同企业共存亡)

P10~P12:60万+(点评:职业领军人物,主导一个大的体系,或者是特别稀有的战略级人才)


2.5 职级的补充说明

    保密原则:岗级存在,但是不公开,而且是保密的。公开资料上显示岗位名称但是不会显示个人职位级别。如果需要名片或者个人工作介绍需要一个Title时,需要提交OA申请一个临时的对外Title。

    隐藏职级的初衷在于公司倡导自由、平等的沟通和工作环境,大家相互之间不比职级,比的是谁成果好、能力强。

    同理,个人的公开信息处,不显示员工的学校 学历 年龄,无论学历高低、学校好坏、年龄大小,都不应该成为别人对你的印象。



© 2009-2020 Zollty.com 版权所有。渝ICP备20008982号