公司中重视人的因素起源于人性化管理之父梅奥,他在著名的霍桑实验中提出了两个结论。
(1)影响生产效率的根本因素不是工作条件,而是人本身。人期望自己“被注意”,期望自己是一个重要的存在,因而怀有归属感,这种意识助长了人的有所作为的观念和完成任务的观念,正是这种人的因素导致了劳动生产率的提高。
(2)在决定人们工作效率的因素中,个人为团体所接受的融洽性和安全感较之奖励性工资有更为重要的作用。
霍桑试验的研究结果表明了人不是被动的、孤立的个体,他们的行为不仅仅受工资的刺激,影响生产效率的最重要因素不是待遇和工作条件,而是工作中的人际关系。这个80年前的研究成果对于一个互联网公司有着重要的指导意义,互联网公司追求高效,研发依赖研发人员的能力,流程对于个人能力来说只是起辅助的作用,所以管理上应该更注重人的因素。
组织文化在很多公司都是务虚的一堆词汇,或者是老板文化。如果一个公司想推行组织文化来支持公司的业务战略或者研发战略,不妨认真思考一下公司的战略方向到底是什么,需要塑造什么样的文化来支持战略。下图是战略和组织文化的关联矩阵,杨国安教授在谈论企业持续成功的因素时阐述了“企业持续成功=战略×组织能力”的公式,两者之间是相乘关系,而不是相加,其中一项不行,企业就无法成功。
暴风的研发团队在定“优化”作为文化时就做了上述的对应,为了提高生产率,提高质量和交付的合格率(按时交付并且满足产品需求),优化和这三项的关联度最大,通过员工的优化行为可以砍掉项目中不必要的环节,而只去做对项目目标有直接影响的事情,这样就能提高效率;有优化的意识,经常去审视自己的代码或者团队成员的代码等于直接做了CodeReview,再有优化的行为将代码写得简而精,这样也能提高质量;在完成每个任务时都去思考哪些工作可以优化而把任务完成得卓越,这样保证了交付的任务能合格或卓越地交付。所以“优化”可以考虑作为团队内工作的一种文化。
一个企业的文化应该尽量是包容的,而不是单一的文化,例如质量文化、效率文化也很重要。下面的矩阵帮助公司来筛选当前阶段最重要的组织文化应该是什么,筛选的标准根据相对重要程度和当前公司的实力进行相乘,取结果高的最先在公司内推广。暴风的工作习惯是选择当前最为紧急的且重要的事情去做,而不是同一时间面面俱到地做很多事情,任何公司的资源都是有限的,只有这样做才能充分利用资源将事情做到极致。
杨国安教授在《组织能力的杨三角》中提到组织能力需要三个支柱,一是员工思维模式(愿不愿意),二是员工能力(会不会),三是员工治理方式(允不允许)。一个组织或一个团队要具备执行一个战略的能力,需要这三个支柱来建立。第一个支柱是这个团队的人对不对,有没有相应的知识技能和素质?比如暴风做Android端产品,团队成员是否具备Android的开发经验,有没有播放的开发经验,这就是员工能力。第二个支柱是员工思维,这一群人每天上班工作的时候是不是真的关心这个事情,比如开发Android暴风影音产品,团队是只完成工作还是发自内心地当成自己的产品来做,这是两种完全不同的思维,在暴风,很多团队都把产品当成自己的孩子来呵护,也为产品能得到海量用户的认可而感到骄傲。第三个支柱是员工治理,即允不允许做,就是公司让员工优化也好,做质量也好,那么公司有没有提供相应管理上的资源和支持。
在三个支柱中最重要的是员工思维的问题,公司的业务目标老板们都觉得很重要,但员工心里面想不想配合你走这条路?这是思维模式中一个要解决的问题。很多公司开大会小会每天不断讲,但效果不明显,比如产品经理说页面展现优化得不够好,研发测试员工可能会抵触,如果把微博用户反馈和观察员的真实使用反馈直接给研发人员看,他会真正意识到自己做的产品有问题,这才有效传达了期望员工通过优化提高用户体验的想法,也有助于团队养成优化的思维方式,最终对推行敏捷项目管理提供组织文化上的支持。
汉代以前,军队中还没有骑兵出现,战车是战争的主要工具,士兵乘坐的是两马拉一车的战车。中军统帅的战车由三匹马来拉,也称“三驾马车”。对于研发管理来说,“三驾马车”分别是人才、技术和流程制度。前面多处提出了实施敏捷项目管理后流程制度带来的变革,对于互联网公司来说技术型人才对于任何公司都是稀缺的,这就使如何更好地管理技术型人才成为每个互联网公司必须研究的课题。
暴风人才管理问题的症结在于能带项目团队完成工作的技术人才储备不足,也缺乏有效的人才培养机制。遇到这种问题通常是通过招聘找到外部有经验的技术人才来带领公司内部的员工完成项目工作,新人过来后融入的时间长,而且每次做创新的事情都需要从外部寻找人才。这凸显了互联网公司内部“造血”功能的不足。理性分析之后可能是行业特点所决定的。第一,整个互联网行业的人才多数是技术型人才,技术上单兵作战的能力很强,在成规模的企业中缺乏协作能力和带团队共同完成目标的能力。第二,互联网行业从技术人才转化为管理人才的难度大,人员年轻,没有管理方法,也不愿意去学习管理方法,经常把事情都揽在自己身上,以至于自己成为瓶颈资源。第三,行业人才竞争激烈,特别是对于技术类人才缺乏收入的保障,只要行业内给出现有工资的1.5倍或2倍,人才流失的风险非常大。这些行业因素无疑给人才管理带来了巨大的困难。
公司做了很多努力来提升技术人才的素质和战斗力。第一,政策导向,公司内部发布公司的用人观和人才观,让全员都清楚公司鼓励内部提拔和内部培养,在人员储备上做一些资源冗余。第二,成立项目管理训练营,针对有意愿向管理转型并且具备基本管理素质的人才提供管理的培训,培养技术人才管理的理念、项目管理的知识体系。每年经过内部的培训,实战选拔人才派到外面的培训机构进行再次培训和培养,然后回公司给机会带实际项目,并检验其水平是否有提高。第三,建立公司的资产库,将公司的各项目Wiki成果进行分类,包括项目得失、最佳实践、新技术分享,并且开放给技术人才作为学习平台。第四,给技术人才的分类和职业通道分成两个职业方向(专家序列和管理序列),建立两个序列的任职资格标准。鼓励基层员工按照公司制定的职业规划进行发展。这些努力的管理创新点在于:成体系的内部培养机制。进行技术人才资源冗余,为未来的业务做储备。
再次思考为什么上面的措施有管理可行性?一个企业要长期发展必须依赖自己的培养体系,以及自己的培养体系培养出来的人才。企业“造血”功能不足必定不能支持企业在人才储备和人才资源获取上走得更长远。如果要完成长期的人才体系培养,公司需要有足够的利润作为资源冗余的资本,暴风的经营业绩足够支持现在做人才管理的储备、挖掘和培养。从人才战略的角度考虑,公司发展了5年,有一半业务需要运营型人才,还有另外一半需要创新型技术人才。所以未来组织蓝图上需要“制度型”和“创新型”的区分管理模式。“制度型”更有效地管理了业务和运营类人才,“创新型”则更鼓励研发人才创新和成长。
任职资格体系不是绩效考核,它是从员工称职胜任角度出发,对员工能力进行分级分等,以任职资格标准体系来规范员工的培养和选拔,建立员工的职业发展通道,牵引员工不断学习,同时为员工晋升、职业发展、薪酬调整等工作提供重要的参考依据。暴风开始实施任职资格体系是从别的公司参考过来简化处理的,因为互联网视频行业技术的多样性和初期研发团队规模比较小,实施效果并不算好。随着研发团队规模的增长,在招聘和人员晋升上已经显现了作用。
暴风的任职资格体系为研发类员工提供了两条职业发展通道,一条是管理路线,一条是技术专家路线。很多技术人员其实并不想做管理,但行业内很多公司如果不提拔到管理岗位就很难拿到相应的薪酬,两条职业晋升路线解决了薪酬的公平性问题,即使不做任何管理工作,一个高级架构师的薪酬和研发总监是水平相当的,所以员工只需要关注自己是否能达到相应的任职资格要求,而不需要非要去做管理工作。在整个公司实际上也是重技术轻管理的。
任职资格搭起了任务和员工知识技能的桥梁,明确了完成任务需要的行为标准,员工要达到成功需要哪些必备知识与技能;根据行为标准对员工的工作行为进行评估,便于了解员工还需要掌握哪些必备知识。暴风任职资格体系为研发类员工分了五个级别,每个级别下又分了三个小级别(也可以认为是三等)。按照不同的技术方向来编制任职资格的行为标准,例如Web研发工程师任职资格标准、P2P研发工程师任职资格标准等。标准的制定需要先找公司内最符合标准的标杆人物,以标杆人物的行为标准来制定员工的行为要项。初期实施难度大的原因是每个等级很难找到标杆人物,因为某些领域的研发工程师可能只有一个人,所以规模小的研发团队初期实施任职资格体系时尽量采取简化的原则,不必定太多的行为标准。
合理的任职资格评估应该每半年一次,初期实施任职资格评估时需要员工来按照申报的级别来自己准备证据(日常工作中能证明自己符合某条标准的文档、邮件、代码等),主管领导审批后报给评估小组来评估是否达到申报级别。评估过程由申报人按照任职资格标准逐条来陈述自己的证据,评委可以随时提出问题来判断证据是否满足行为标准。这样,一个申报人评估下来需要至少1~1.5小时,评委至少3人,所以投入的资源还是比较多的。后期改进后不需要申报人逐条准备证据,由直接上级按照任职资格标准的模块来阐述申报人是否能够达到行为标准,好处是降低了申报人和评委的工作量,缺陷是没有深入地了解申报人哪些行为需要改进和提高。
很多人力资源界的专家认为冰山模型分成两部分,露出水面的部分叫任职资格管理,水面以下的部分叫胜任素质。尽管这种观点还存在很多争议,但如果实施任职资格管理,任职资格标准的建立应该包括知识、技能、行为、贡献等内容,任职资格的评估除了对员工进行等级评估外,还应该更注重在评估过程中对员工的待改进部分进行指导和提升。这样才能通过任职资格体系真正帮助员工持续地进步。
敏捷项目经理的培养对任何公司来说都是一个难题,不要认为会带来Sprint做敏捷规划、能够组织敏捷例会、带领团队进行Sprint总结就是一个敏捷项目经理了,那是大错特错。虽然敏捷项目管理和相对传统的项目管理貌似有些背道而驰,但不意味着传统的项目管理知识、技能、工具、方法不能应用,实际上一个敏捷教练也需要更多的项目管理知识背景和实际带项目的经验。从组织层面培养项目经理不是一朝一夕的事情,很多公司认为建立好标准化的流程,然后做好流程培训,这样工作便和人员不相关。这更是对软件行业从业人员的极大不尊重,即使是同样的流程,由于技术水平的不同执行下来结果会有天差地别。
项目管理训练营是一种很好的培养项目经理的方式,最重要的是坚持不懈的培训机制,以及培训的内容能真正帮助项目经理的成长。培训机制其实并不神秘,结合公司实际情况的基础培训加上公司一些实际项目案例的演练,长期坚持就能提高项目经理的水平。需要说明的是,这种培训机制不是立竿见影的,需要公司在培训过程中不断地优化培训内容,促成项目经理之间的经验分享,对于每个被培训的项目经理来说整个过程有些枯燥和乏味,“他山之石,可以攻玉”,学习能力强的项目经理在这个过程中学到的不仅仅是一些枯燥的方法和工具,而是其他项目经理在实战过程中解决问题的方法。虽然培训的内容不完全是敏捷项目管理,而是一些IT传统项目管理的知识、工具、技能和方法,但却能让项目经理更理解敏捷的思想。下表是项目管理训练营培训的课表和排期,可以给各公司的PMO和高层管理者借鉴。
干部培养是各个公司都去积极实施的一个项目,暴风的干部培养活动主要是“求是堂”。它包括两个活动,听一次课,选一个自己带的项目制定卓越的指标并且达到。如果项目能完成卓越的指标干部就达到毕业标准了。其中课程讲述部分主要讲述两方面的内容:业务管理方法论和研发管理方法论。业务管理的方法论强调业务要有明确的目标,要完成业务目标必须明确核心打法,核心打法和业务目标之间的因果关系要得到证明,每个核心打法要分解成关键动作来支撑。研发管理的方法包括目标、目标量化描述、找到和量化目标之间的差距、寻找缩小差距的要因、制订计划并持续优化五个步骤。例如,研发的目标是提高从点击桌面图标到客户端软件打开的启动速度,首先要定一个合理的目标(启动快),将目标具体量化进行描述(首次启动1.5秒以内),然后寻找差距(当前3~4秒),如果要缩小差距,包括磁盘I/O读/写优化、皮肤加载优化、界面显示优化三个主要因素。最后一步就是进行技术调研,然后制订一个可执行的计划。
业务管理和研发管理有哪些共性和差异呢?谈到管理其实殊途同归,下表对比了业务管理和研发管理方法论之间的共性。一个普通研发人员只需要按照敏捷项目管理的框架认领任务完成项目即可,但研发干部应该经常思考项目的目标。互联网公司不同于传统按合同交付项目的软件企业,在业务规划下有很多项目可以做,但一定要思考完成项目后是否能真正地让用户喜欢,最终达到支持业务的目的。如果一个研发项目交付的结果不能让30%的用户喜欢或者技术指标的优化空间不足50%,那么这个项目的优先级值得考虑。
研发管理和业务管理也有很多差异(参见下表),做业务是0和1的关系,比如去争取一个销售订单,赢了就能签约。研发管理是好与不好的关系,项目都能做完,就看最后的结果是否能得到客户或用户的认同。
杰克·韦尔奇在《赢》中提出了促进公司赢的各种因素,暴风的干部培训也是以“赢”为核心思想的,通过培训让大家掌握业务管理和研发管理的不同方法论,然后各业务的负责人来指导自己的干部队伍去选择他们所带的项目,按照方法论进行预演,帮助干部找到核心打法(要因)和关键动作(执行计划),最终帮助干部带领自己的团队去达到卓越的指标。这样会在公司内让干部有“赢”的欲望,也会带动员工一起获得成功。
杨立东
PMP,美国加州州立大学富尔顿分校硕士,中欧国际工商学院EMBA,华中科技大学特聘教授。北京暴风科技股份有限公司董事、首席技术官。2011年第二批“中关村高端领军人才聚集工程”科技创新人才。发表学术论文4篇。
曾从事过6年一线Java开发工作,作为项目经理带领过多个大型软件项目,2006年开始从事CMMI咨询和评估工作,服务过的软件企业超过30家,多次举办项目管理、软件度量、敏捷项目管理的公开课,培训人数超过15000人。2008年开始专注于公司级管理工作,2010年开始总结自己多年的研发管理经验,专注于互联网公司敏捷项目管理的推广和实施。