推进组织转型时，经理转型是重点，更是难点。

按照责任区分，经理可分为项目经理和职能经理。

1.项目经理转型

项目经理何去何从？

组织敏捷转型，铺面而来的就是项目经理转型的问题。项目经理何去何从？

在传统组织中，项目管理职责由项目经理一人承担。项目经理是项目团队成员的上级，主要采用命令控制式的管理风格，管理单独的项目成员，而不是让项目团队成员们自我管理。在Scrum组织中，传统的项目管理职责由产品负责人、ScrumMaster、开发团队和其他经理共同承担。正如《管理3.0实战手册》所述，管理是所有人的责任，团队需要自我引领。那么团队自组织以后，项目经理何去何从？原来的项目经理，根据他本人的意愿，可以承担Scrum三种角色里的任意一种：

1. 如果肯放弃命令控制式的管理风格，很多项目经理都可以成为优秀的ScrumMaster

2. 如果有足够的领域知识及其他技能而足以履行产品负责人的角色，项目经理也可以转做产品负责人。

3. 或者，有技术背景的项目经理也可以选择成为开发团队中的一员，虽然这种情况不多见。

为什么项目经理转型是重点？

项目经理转型，首先解决了项目经理自身职业发展的问题，更重要的是，填补了Scrum中两个重要角色（ScrumMaster和产品负责人）的空缺。ScrumMaster将服务于Scrum团队，推进Scrum落地，推进组织拥抱敏捷，他们是组织转型的中流砥柱。产品负责人对最大化产品的投入产出比负责，引领着团队成功开发出创新型产品，是组织取得业务成功的带头人。

为什么项目经理转型更是难点？

首先，地位的变化导致难堪的人际关系。

从前的项目经理是开发者的顶头上司，项目经理与开发者是上下级关系。ScrumMaster或产品负责人，只是一个团队中的不同角色，与开发者是平级关系。这样的转型对于项目经理来说仿佛降级一般难堪。面对昔日的手下，难免尴尬。所以，能否在思维方式上充分拥抱敏捷，深刻理解组织转型的必要性，愉快的接受自己的新岗位，接纳所有来自外界和自己的各种情绪变化，对于转型成功与否有着不容忽视的影响。只有处理好这些，才能顺利开始转型。这是转型成功的第一步。

其次，角色的变化导致管理风格的改变

项目经理的管理风格以命令控制式为主，这是项目经理角色导致的。项目经理是整个项目的最终责任点，开发者是项目经理的下级，是项目经理可以掌控的资源，项目经理当然可以命令控制下级。转型以后，从前的项目经理现在不再是开发者的上级了，命令控制式的管理风格再也行不通了。ScrumMaster必须掌握教练技术，以服务型领导的新姿态，帮助团队提升自组织能力，引导团队不断改进。产品负责人必须掌握充分的领域知识，像枢纽般协调里里外外的各种需求。如上节所述，在思想上接受新岗位，顺利迈出第一步后，还必须在技能上与时俱进，自己转型，同时带来团队转型。这是转型成功的第二步。

再次，大环境的制约导致转型的两难

敏捷经常最先在研发部门推行起来，而其他部门往往还习惯于传统的思维模式，这种局面常常让转型中的新手ScrumMaster和产品负责人左右为难。

例1，人力资源部门的绩效评价制度对于Scrum价值观有制约。Scrum开发团队强调开发者们拥有同舟共济的精神。而HR的绩效评价制度仍然秉承传统的精英思维，不搞以团队为单位的集体评价，只搞以个人为单位的个体评价，并且一定要将同一团队开发者绩效分出三六九等，区别对待。这必然导致一年开发有难同当，年终加薪有福不同享的结果。试问，只要有一次有福不同享，日后有难怎能同当？ScrumMaster再倡导同舟共济，还有谁会相信呢？在这种大环境里谈同舟共济，说也不是，不说也不是，ScrumMaster该怎么干下去？

例2，项目管理部门签订的传统的固定范围、固定时间、固定成本的三固定合同对于开发团队自组织的制约。Scrum提倡，在做冲刺计划时，开发者自己主动从产品待办列表中拖取产品待办项，不提倡产品负责人强迫开发团队接受超负荷的开发任务。然而，如果按照合同，每个冲刺需要完成的特性超出开发团队实际能够承受的负荷呢？如果为了遵守合同，产品负责人从开发团队手中拿回控制权，就违背Scrum原则；如果遵守Scrum原则，产品负责人把控制权交还给开发团队，就违背合同。在这种大环境里，控制权放也不是，不放也不是，产品负责人该怎么干下去？

从第三步起，项目经理转型与组织整体转型的连接更紧密，转型之路任重道远。

2.职能经理转型

职能经理还是职能经理

Scrum指南没有提到职能经理。组织敏捷转型，职能经理也会像项目经理一样消失吗？

在第十三章，Kenneth S. Rubin花了大量笔墨谈职能经理的领导力转型。表13.4对比在传统环境和Scrum环境中职能经理的职责，13项职责中8项相同或相似，5项有差别，差别在于Scrum要求更高。职能经理如果在传统环境中都干不好，在Scrum环境中很可能更干不好。如果在传统环境中干的很好，经过适当改变和提高，在Scrum环境中也会干的很好。可见，组织敏捷转型，原来的职能经理还是职能经理，名头没有变，主要职责没有变，需要改变的是思维模式，是领导力。

Scrum环境中职能经理职责差别点

协作塑造优秀团队

传统环境中，职能经理分配人员到项目中。在Scrum环境中，职能经理们需要一起物色团队成员，力图组建多样化的、技能充分混合的跨职能团队，即团队的每个成员各有所长，彼此所具备的技能能够互补。两者相比，Scrum要求职能经理在部门人员与团队人员的技能搭配上更多用心。

绩效评审

Scrum环境中的绩效评审与传统环境中的绩效评审相比，有两点要求更高：反馈频率和关联团队绩效。在反馈频率方面，Kenneth S. Rubin认为传统的一年一次或两次的反馈频率与Scrum团队短期冲刺的执行和学习节奏不匹配，建议大幅提高反馈频率，将其调整到与团队学习周期一致，比如每个冲刺都提供反馈。在关联团队绩效方面，Kenneth S. Rubin认为传统的个人绩效评审由于鼓励个体行为而导致人们牺牲团队利益，因而会干扰团队的出色表现。他建议个人绩效评审应定位于个人绩效对团队绩效的贡献。

重点关注团队的完整性

敏捷的精髓在于团队，作为生产能力的单位，团队代替了个人。所以经理应该积极保持团队的完整性，避免在冲刺过程中从团队中抽调人员去支援更受关注的项目，不应该把一个人分配到多个团队。

纵观全局

Kenneth S. Rubin指出，职能经理应采用系统化视角，不要只关注自己的“一亩三分地”。职能经理思维模式局限在自己的部门中，会导致各个部门背离组织在系统层面的更高利益。

度量和报告向敏捷原则看齐

这些原则包括：关注闲置工作，而不是闲置员工；通过可工作的、经过验证的资产来度量进度；建立快速反馈机制等。

职能经理转型，知易行难

然而，以上所有转变，知易行难。

根据2011年行业内的一项敏捷调查，经理们最大的顾虑就是担心管理失控，担心自己的角色变得无关紧要。以下是一些实际案例：

案例一：测试经理不愿承诺协助塑造优秀团队

一位来自传统行业的测试经理，反对把它部门的测试员安排进入各个开发团队，而要求所有开发团队完成特性开发后，对测试经理提测试邀请，由测试经理统一安排。因为她担心产品质量失控，担心自己部门的人员失控，担心自己在组织里的影响力被削弱。

案例二：人事经理割裂团队绩效与个人绩效

某组织长期以来使用分级评等制度评审个人绩效：20%位精英，70%为普通员工，10%为低绩效员工。当项目成果令客户很不满意，导致客户不再继续投资这个项目的时候，人事经理仍旧沿用这个分级评等制度评价这个项目的员工。没有客户投资，就把组织的公共费用划拨给项目成员，该升职的升职，该加薪的加薪。项目做砸了，90%的人不受影响，岂非怪相！

职能经理对转型持什么态度？站着职能经理的角度，他们有三个问题需要得到回答：

1.为何转型？职能经理需要了解转型的背景和原因

2.谁做决定？决策者必须是对职能经理有足够影响力的人

3.有何不同？职能经理会对自己个人做转型的影响分析，我改变了会怎样？不改变又会怎样？有何不同？

职能经理身处层级组织机构的中层，对上向副总裁负责，对下管理部门员工。俗话说，屁股决定脑袋。这样的位置决定了职能经理必然关注老板的思路，关注本部门业绩，行事谨慎。谈到转型，职能经理的内心活动是这样的：转型，原因是什么？要求我“纵观全局”，老板对这个问题是怎么想的？如果老板关注，我就“纵观全局”。如果老板不关注，那么搞敏捷对我有什么影响？我改变了，能提高部门业绩？会导致部门管理失控吗？我能把自己的这一亩三分地种的更好吗？我不改变，谁能把我怎样？如果职能经理心中的这三个问题不能得到满意的答案，就会婉拒。他们说：我们的业务不适合敏捷，我们的客户不习惯Scrum，我们部门的员工素养不够……如此等等，貌似都很合理，其实都是托词。实质问题还是那三个问题：为何转型？谁做决定？有何不同？

成功转型的组织又是怎样做到让职能经理转变态度的？

查阅世界巨头，如微软、IBM等组织的转型历史，我们看到了这样的话：The commitment to Agile is driven bycommercial necessity，Corporate vice president,Brian Harry, publicly announced in his blog thecommitment to

Agile and Scrum。从这些资讯中不难找到职能经理心中前两个问题的答案：为何转型？商业使然。谁做决定？总裁级高管。对于一个组织来说，如果商业特点导致敏捷转型确有必要，总裁级高管拍板转型，处于中层的职能经理是不会不同意转型的。于是第三个问题迎刃而解，不跟着总裁转换思想，职能经理恐怕得走路。

IBM敏捷教练Lisa在ScrumGathering上指出大组织的敏捷转型必须“从上至下”，可见这是一种经理转型的成功模式。经理转型是组织敏捷转型的难点，对于不同的组织，不同的业务，应该还有其他成功模式等待我们去探索。