敏于思捷于行团队管理模式.docVIP

敏于思捷于行团队管理模式 　　编者按： 　　敏捷软件开发又称敏捷开发，是在一个既定的时段内将本应由一个项目组完成的独立产品开发任务切分成若干个有关或无关的任务，并行或迭代开发。相对于“非敏捷”而言，“敏捷”开发更强调程序开发团队与业务专家之间的紧密协作、面对面的沟通、紧凑而自我组织型的团队、能够很好地适应需求变化的团队组织方法。因其更注重软件开发过程中“人”的作用，人们也将敏捷开发的理念应用于组织管理当中。 　　许多数码公司通过在业务部门实行敏捷软件开发方法，迅速设计与开发出产品的新功能，引入消费者参与测试，并在快速迭代中完成产品更新。但是，若想将敏捷开发推行到多个业务单元，则需要重新思考基础步骤、公司结构以及各部门间的关系。 　　相反，只有极少数同时拥有线上及线下业务的公司，会在其主要的产品和应用开发团队中采用敏捷开发方式。尽管许多银行已经成立数字部门以加速推出移动端应用及网站功能，但是这些数字部门从行政结构及策略布局上，通常与IT部门以及公司其他部门相对独立。 　　阻止传统型公司推行敏捷开发模式的原因有很多，但我们认为最主要的障碍是其现存的运营模式及组织结构。大部分传统型公司的产品开发依旧保持着分散和复杂的状态：一家需要在网站上搭建新功能的公司，会启动一个涉及多部门的开发流程，而每个部门都只能负责流程中的几项任务。比如：一支团队专注于前端应用开发，另一支团队负责更新相关服务器和数据库，可能还有一支团队负责协调系统前后端对接。 　　对大部分公司来说，敏捷开发的试运行都极为成功，但如果不对公司结构进行调整，便很难将敏捷管理从小范围推广到所有业务单元。 　　扩大敏捷开发的实践范围 　　为了更好地理解大规模部署敏捷开发的障碍，我们对13家公司进行了深入调研，它们涉及金融服务、医疗保健、电子通信等多个行业，且正处于大规模部署敏捷开发的不同进程中，部分推进较快的公司已在其60%或更多的创新活动中采用了敏捷开发。 　　这些公司针对一个或是多个运营模型进行了调整，主要集中在以下四个方面：调整组织结构，使之转变为以产品为主导；改进业务部门与 IT部门的交流；重新定义业务部门及IT部门的角色与职能；反思现有预算及规划模型（如表1）。 　　敏捷开发的优越性已广为人知。在敏捷开发方式下，IT部门、产品开发者与业务部门共同创造产品和服务，而非简单地将功能要求汇总起来，直接丢给后方。不同团队可以利用极简版的可行性产品进行实验、测试并从中学习，最终在几天或几周内便开发出新的软件功能，而无需花费几年时间。 　　传统型企业倾向于根据应用及项目来组织分配IT资源，最终形成之前提到的那种分裂式的产品开发过程。实际上，公司应当以产品为中心来分配IT资源，并将业务单元领头人、开发人员以及公司内其他成员，以一种稳定的、面对面的团队组织形式集中起来，为同一个业务结果而努力。 　　采用以产品为导向的组织结构 　　在大规模的敏捷开发环境中，“产品”不应被狭隘地定义为商业产品，它们也包括不同产品的组合，比如薪资管理服务，或者客户体验，或者一个产品团队共用的IT系统。因此对业务部门和IT部门的领导者来说，重新定义部门承担的责任非常重要。当产品被重新归类后，公司必须派出一支或是几支专门的敏捷开发小组，来负责这些产品的开发与维护。 　　一家大型的医药设备制造商通过调整组织结构，显著地缩短了产品上市的时间。如果想在其原有基础上开发一个新的软件或是在现有软件上增加新功能时，业务部门与技术部门所共享的规格和技术要求，可能会有多达20项的交接。领导层意识到，只在单个业务单元或特定的几个产品组里部署敏捷开发是完全不可行的。 　　2015年，该公司调整了产品所有权模式，使来自业务部门的产品负责人可以直接向敏捷开发团队提出软件要求，而无需通过多个部门来传递。结构上的调整促进了好几个敏捷操作团队的形成。这些根据角色或话题组织起来的小组，对公司大规模推行敏捷开发起着至关重要的作用。他们能够鼓励团队成员分享各自擅长的专业知识，促进团队与职能部门的合作，并且持续推进团队成员的业务进步。 　　加强业务部门与IT部门的交流 　　大部分传统企业中，来自业务部门的负责人在软件开发过程中参与有限，仅在被问及时才提出意见。为了弥补该负责人的参与不足，IT部门通常会派出一个代表作为产品负责人。这种安排在短期内会比较有效，但是会损害产品和项目的长期成功。 　　由于组织结构的原因，IT部门的负责人通常并不直接与用户打交道，也无最终决定权。由于项目缺少方向性指导，工作项目优先级不明确以及责任人缺失，敏捷开发便无法进行下去，整个团队也面临着重复工作和资源浪费的问题。 　　相反，一个强大的产品负责人对产品相关问题、与客户的关系以及客户本身都有深入的了解，并有权做出快速决策，以便提高效率