“敏”于思“捷”于行的团队管理模式

来源 :人力资源 | 被引量 : 0次 | 上传用户:BeginJava123
下载到本地 , 更方便阅读
声明 : 本文档内容版权归属内容提供方 , 如果您对本文有版权争议 , 可与客服联系进行内容授权或下架
论文部分内容阅读
  编者按:
  敏捷软件开发又称敏捷开发,是在一个既定的时段内将本应由一个项目组完成的独立产品开发任务切分成若干个有关或无关的任务,并行或迭代开发。相对于“非敏捷”而言,“敏捷”开发更强调程序开发团队与业务专家之间的紧密协作、面对面的沟通、紧凑而自我组织型的团队、能够很好地适应需求变化的团队组织方法。因其更注重软件开发过程中“人”的作用,人们也将敏捷开发的理念应用于组织管理当中。
  许多数码公司通过在业务部门实行敏捷软件开发方法,迅速设计与开发出产品的新功能,引入消费者参与测试,并在快速迭代中完成产品更新。但是,若想将敏捷开发推行到多个业务单元,则需要重新思考基础步骤、公司结构以及各部门间的关系。
  相反,只有极少数同时拥有线上及线下业务的公司,会在其主要的产品和应用开发团队中采用敏捷开发方式。尽管许多银行已经成立数字部门以加速推出移动端应用及网站功能,但是这些数字部门从行政结构及策略布局上,通常与IT部门以及公司其他部门相对独立。
  阻止传统型公司推行敏捷开发模式的原因有很多,但我们认为最主要的障碍是其现存的运营模式及组织结构。大部分传统型公司的产品开发依旧保持着分散和复杂的状态:一家需要在网站上搭建新功能的公司,会启动一个涉及多部门的开发流程,而每个部门都只能负责流程中的几项任务。比如:一支团队专注于前端应用开发,另一支团队负责更新相关服务器和数据库,可能还有一支团队负责协调系统前后端对接。
  对大部分公司来说,敏捷开发的试运行都极为成功,但如果不对公司结构进行调整,便很难将敏捷管理从小范围推广到所有业务单元。
  扩大敏捷开发的实践范围
  为了更好地理解大规模部署敏捷开发的障碍,我们对13家公司进行了深入调研,它们涉及金融服务、医疗保健、电子通信等多个行业,且正处于大规模部署敏捷开发的不同进程中,部分推进较快的公司已在其60%或更多的创新活动中采用了敏捷开发。
  这些公司针对一个或是多个运营模型进行了调整,主要集中在以下四个方面:调整组织结构,使之转变为以产品为主导;改进业务部门与 IT部门的交流;重新定义业务部门及IT部门的角色与职能;反思现有预算及规划模型(如表1)。
  敏捷开发的优越性已广为人知。在敏捷开发方式下,IT部门、产品开发者与业务部门共同创造产品和服务,而非简单地将功能要求汇总起来,直接丢给后方。不同团队可以利用极简版的可行性产品进行实验、测试并从中学习,最终在几天或几周内便开发出新的软件功能,而无需花费几年时间。
  传统型企业倾向于根据应用及项目来组织分配IT资源,最终形成之前提到的那种分裂式的产品开发过程。实际上,公司应当以产品为中心来分配IT资源,并将业务单元领头人、开发人员以及公司内其他成员,以一种稳定的、面对面的团队组织形式集中起来,为同一个业务结果而努力。
  采用以产品为导向的组织结构
  在大规模的敏捷开发环境中,“产品”不应被狭隘地定义为商业产品,它们也包括不同产品的组合,比如薪资管理服务,或者客户体验,或者一个产品团队共用的IT系统。因此对业务部门和IT部门的领导者来说,重新定义部门承担的责任非常重要。当产品被重新归类后,公司必须派出一支或是几支专门的敏捷开发小组,来负责这些产品的开发与维护。
  一家大型的医药设备制造商通过调整组织结构,显著地缩短了产品上市的时间。如果想在其原有基础上开发一个新的软件或是在现有软件上增加新功能时,业务部门与技术部门所共享的规格和技术要求,可能会有多达20项的交接。领导层意识到,只在单个业务单元或特定的几个产品组里部署敏捷开发是完全不可行的。
  2015年,该公司调整了产品所有权模式,使来自业务部门的产品负责人可以直接向敏捷开发团队提出软件要求,而无需通过多个部门来传递。结构上的调整促进了好几个敏捷操作团队的形成。这些根据角色或话题组织起来的小组,对公司大规模推行敏捷开发起着至关重要的作用。他们能够鼓励团队成员分享各自擅长的专业知识,促进团队与职能部门的合作,并且持续推进团队成员的业务进步。
  加强业务部门与IT部门的交流
  大部分传统企业中,来自业务部门的负责人在软件开发过程中参与有限,仅在被问及时才提出意见。为了弥补该负责人的参与不足,IT部门通常会派出一个代表作为产品负责人。这种安排在短期内会比较有效,但是会损害产品和项目的长期成功。
  由于组织结构的原因,IT部门的负责人通常并不直接与用户打交道,也无最终决定权。由于项目缺少方向性指导,工作项目优先级不明确以及责任人缺失,敏捷开发便无法进行下去,整个团队也面临着重复工作和资源浪费的问题。
  相反,一个强大的产品负责人对产品相关问题、与客户的关系以及客户本身都有深入的了解,并有权做出快速决策,以便提高效率,减少在开发过程中遇到的瓶颈。
  一家提供“软件即服务”的公司一直被如何将产品更快地推向市场困扰。这家公司存在着IT部门与业务部门决策缓慢、沟通不畅的问题,经常一年才能推出一到两个产品。2014年,该公司实施了一个三层的产品拥有权架构,由一个首席产品负责人带领一个产品区块,一个高级产品负责人带领一条产品线,以及多个产品负责人与迭代式增量软件开发团队合作。
  在这个新的结构下,IT部门和业务部门之间的交流有了显著改善。沟通更加清晰,公司也能够更快地做出决策,并保持产品团队间的一致性以及紧密合作。也是由于结构上的调整,这家公司每个季度都能向市场推出新的软件产品,有时甚至每月都推出新产品。
  重新定义管理层角色与职责
  在被调研的公司中,有半数公司都针对敏捷开发的独特要求,重新定义了原有开发模式下经理层的角色以及职责。在原来的开发模式下,项目经理通常要在应用开发团队、数据库团队及其他团队间协调不同的任务。而在敏捷开发操作下,涉及的任务以及需要协调的事务都被最小化。问题会被产品负责人或是敏捷开发团队自行解决。原来由直线经理所负责的与开发流程相关的任务,现在都由自我管理、以产品为中心的敏捷开发团队自行解决了。   这些在大范围内推行敏捷开发并取得成效的公司,流程都极为透明公开。他们向团队成员提供了清晰的指导,详细说明决策的达成方式。责任界限划分清晰,团队成员被赋予适当责任,同时也避免恶意行为或是全权委托造成过大的风险。
  重新制定预算以及规划模式
  IT部门通常都会有年度预算以及规划周期,在不同项目之间平衡预算极为痛苦,也有可能带来很大程度的重复劳动以及资源浪费。这种模式对于想要大规模实施敏捷管理的公司来说几乎就是个诅咒。
  欧洲一家大型保险公司重新调整了预算制定的过程,将预算用途分成三类:一个由业务部及IT部门经理组成的开发委员会,每月定期会面,以决定新项目是否该执行;首席产品负责人负责资金的具体分配和调整,以便在新的商业机遇出现时能够快速做出决定;产品负责人的主要职责是滚动式地审查预算,保证软件开发能够在40小时的工作框架中得到执行,维护任务及产品待办列表得到管理。预算制定过程调整后,该公司在预算方面的灵活性大大提高,并且加快了对市场的反应速度。
  有不少公司甚至尝试风投模式的预算。初始资金能够极快地批准给极简的可行产品,然后根据客户的初级反馈进行调整后再次推向市场。而接下来是否继续提供资金支持,则要根据这些极简可行产品在市场上的表现来决定。风投模式的预算使公司能在早期就消灭掉那些没有潜力的产品。
  选择正确的方式
  改革运营模式是一项大工程,需要考虑一些较大的风险以及短期内对日常工作的干扰。就像其他的管理行为调整一样,向敏捷管理转变也需要不同级别、不同职能的部门与业务单元的长期付出与承诺。
  一种极端的情况是,部分公司采用了实验室方式。 这种方式对那些暂时只有部分高层支持实行敏捷管理的公司来说比较明智,它能够迅速证明其商业理由,以便让敏捷管理获得更大规模的推广。然而,为采用实验室方式而单独建立起来的敏捷开发部门,依旧倾向于自成一派,未能在整个公司内部形成更大的影响。
  另外一种极端就是采取爆发式重组方式。公司将职能部门和业务单元规划到新的组织结构及新角色中,建立自我管理的敏捷开发小组,并同时加速业务流程。
  两个极端方式之间则为棘波方式。在这种方式下,小团队被分批次转化为敏捷开发团队,而公司整个运营模式按照不同阶段进行转化。举例来说,一家大型技术服务公司想要快速提高其数字化能力,决定将产品开发团队分为5个批次转化为敏捷开发团队。第一批次培训并部署了5个团队,而第二批次安排了20个团队。当这些团队接连被转化至敏捷开发操作后,收到的反馈以及培训资料将被改进并用于下一批次团队。
  在完成敏捷开发转化6个月后,这家公司采用了以产品为中心的组织架构,将业务部门领导、开发者、工程师以及IT部门的其他成员组织到不同的“部落”中。又过去几个月后,公司运营模式开始又一层级的调整,重点调整IT部门与业务部门的交流。由于运行模式发生改变,使得产品开发组能够与IT操作团队紧密合作。经过上述一系列调整之后,产品推向市场的速度显著提高,更因为不同团队共同参与和创造了产品,产品缺陷以及返工现象也明显减少。 责编/张晓莉
  来源:麦肯锡网站
其他文献
当公司面临新的学习计划,培训部门需要提供培训内容时,首先要从哪里入手呢?是去找专门为企业创建定制内容的服务机构,还是去找内部专家?是去找拥有现成解决方案的内容提供商,还是对内容稍加改编拿来就用?抑或,将定制和改编进行某种组合?  我们有这么多选择,一定存在既适合学员又符合企业预算要求的选择。更佳融合  培训内容的创建不一定是非此即彼的决定,有时候将创建和改编融合起来的方式更有效。美国自动数据处理公
德鲁克曾经说过,组织的重点必须放在机会上,而不是放在问题上。如果组织把精力放在出成果的地方,那么就会有兴奋感、冲动感。我想,不光是组织,人才也是如此。“机会”是人才梯队建设后组织面临的第一难题,要破解这道题,我们就要厘清在组织资源以及企业平台有限的情况下,为人才提供足够的发展机会,使人才更稳定地在组织内部发挥效能。解决不好这个问题,其负面影响将会制约梯队未来发展的机会。  一个朋友跟我讲了发生在他
人力资源数字化战略是企业数字化战略的延伸,在搭建企业人力资源数字化战略模型时,首先要建立人力资源数据库。可见,数据库的建立是多么重要,数据库是绩效考核体系的重要组成部分,是评估组织和个人关键绩效指标的可测量数据,是绩效考核KPI由定性考核转向定量考核的重要依据。在企业绩效考核中,有必要重新定义数字化关键绩效指标。关键绩效指标与数字化关键绩效指标  绩效就是指业绩和效果,绩效考核促进了绩效,使业绩得
曾采访一家民营企业,一走进公司大门就看到“举党旗、听党话、跟党走”这红彤彤的大字块,我的心不禁怦然而动。我问这位已有26年“创龄”的老板:“您在创业之初是怎样一个状态?”该老板用三个字回答:打游击。  “那时哪知道啥叫人力资源,全是人手。今天要接单,我本人就是销售;明天要结账,爱人就是出纳;新来个项目,不知道怎么谈,把朋友拉来助阵。为了活下去,啥活儿都得接,小作业、包工头、零活儿,只要能赚钱,我们
英国广播公司报道称,作为新政府反腐工作的一部分,尼日利亚从去年年底开始大力整饬政府部门严重的“吃空饷”现象。截至目前,该国官方已查出近2.4万名“幽灵员工”,并将他们从相应的薪酬名单上清除,大大节省了政府开支。该国财政部一名特别顾问透露,目前已有23846名“幽灵员工”从官方岗位移除,2月份的工资开支比去年12月节省了22.9亿奈拉(约合人民币7600万元)。截至目前,超过30万政府公职人员的个人
京东方:在成都投建数字医学中心  京东方近日公告,拟向下属全资公司京东方健康投资管理有限公司增资36亿元,投资建设京东方(成都)数字医学中心项目,项目计划于2019年9月底主体结构封顶,2020年底开业运营。作为光电显示行业巨头,京东方此举属于“跨界”。成都地区经济发展迅速,人口较多,且老龄化程度较高,医疗服务需求旺盛。根据成都市“十三五”规划,到2020年成都市社会办医每千人口床位数计划由1.6
曾几何时,星座爱好者掀起一轮又一轮的“黑处女座运动”,诸如“计划生育政策可以加一条,第一胎生处女座的允许生第二胎”、“你才是处女座,你们全家都是处女座”的段子比比皆是。大概没有人知道处女座是如何把占星学家给得罪了,总之,有星座的话题,处女座就少不了“躺枪”。不过,近日一条明确指出招聘处女座员工的广告在微博上引发网友关注:“30万年薪找个处女座来挑刺。年薪30万元,砸一个指手画脚的人来虐哥!”消息一
2020年年初,我国开启了规模最大、时间最长的居家办公模式。自此,居家办公成为2020年人力资源领域出镜率最高的词语之一。许多人甚至发问:你的办公室还有用吗?这个发问引起了众多厌弃打卡考勤的员工的共鸣:我们应该炸掉那个束缚身心的办公室,而转向居家办公。甚至连一些领导者也开始反思,每年付出高昂的办公场地费、水费、电费、办公室维护费,究竟值不值得。  很难想象,我现在正穿着睡裤,坐在自己家里寫这篇文章
移动互联时代,商业规则和市场规律都发生了翻天覆地的变化。面对不断迭代的技术、层出不穷的商业模式,不少企业领导者发出“战略已死”的感叹:“过去可以制定十年战略、五年战略,现在,你连一年之后市场会发生哪些变化都无法预测,还怎么制定战略?”显而易见,那种“一刀切”的战略制定方式已经不合时宜了。  对此,波士顿咨询公司资深合伙人马丁·里维斯等三位专家在《战略的本质:复杂商业环境中的最优竞争战略》一书中,创
古人云“富贵传家,不过三代”,根源就在于接班人一代不如一代。如今,中国已成为全球第二大经济体,而改革开放以来,创造了这一辉煌的众多企业家也都到了退休的年龄。如何实现两代人的平稳交接,成为摆在中国企业家面前的一道新难题。  一直以来,外界对于中国经济存在着不少错误看法。其中最根深蒂固的就是,很多人都觉得国有企业在中国经济中占主导。而事实并非如此。中国有近4000万家私营企业,其产值占国内生产总值的6