摘要：
敏捷不是灵丹妙药，不能当饭吃！这是本系列文章最后一篇，我们将会谈谈敏捷对组织架构、团队文化的要求，特别是对薪金待遇的要求！最后根据我的个人理解，给出我对敏捷的定义。
本文大纲：
1）部门设置惹得祸？
2）强矩阵还是弱矩阵？
3）敏捷对团队文化的要求
4）敏捷对薪金待遇的要求
5）敏捷的本质是什么？
本文是系列文章的第4篇，如果还没有看过前面的文章，建议先按顺序看看！
第一篇：敏捷的“官方”定义
链接：http://www.cnblogs.com/umlonline/p/3450032.html
第二篇：敏捷流程框架及敏捷实践一览
链接：http://www.cnblogs.com/umlonline/p/3450428.html
第三篇：敏捷在中国的水土不服
链接：http://www.cnblogs.com/umlonline/p/3453930.html
1）部门设置惹的祸？
下面我将会列举三个例子，前面两个是“杯具”，后面一个是“洗具”。
需求设计部 PK 编码及实施部
先上图：
图4.1 部门之间的PK
某软件公司设立了两大部门：
需求及设计部：顾名思义，就是负责软件需求分析及设计工作。（后面简称“A部门”）
实施部：负责编码实现，负责软件的安装、部署、上线、培训客户等工作。（后面简称“B部门”）
公司内部有一个任务管理系统：A部门经过需求分析及软件设计后，通过该系统分派编码等任务给B部门，这个任务叫“工单”，而分派任务的工作叫“下单”。B部门需要完成这些任务，并接受A部门的检查。B部门如果不能按时按质量要求完成任务，B部门的绩效考核就会差；而B部门如果认为A部门分派的任务不合理、描述不清，可以拒绝该任务，称之为“踢单”，“踢单”越多，A部门的绩效考核就越差。
没有这样的部门设置和考核机制之前，两个部门的人可以无分彼此地一起商量事情，共同解决问题，而这样的部门设置及考核机制建立后，两个部门的人经常为了一个“工单”而扯皮，工作的焦点变成不是如何让项目成功，而是如何界定两个部门的工作边界以及想办法推卸责任。
这样的情况，如何敏捷？
客服部 PK 开发部
某网站有大量的用户访问，用户可以向客服部投诉问题，客服部记录问题后移交个开发部处理。用户向客服部描述问题的时候，往往是描述不清的，往往只有“大概”的说法，而客服部往往也不能进一步向用户问清楚情况，往往只能记录问题而已。于是这样的问题移交到开发部时，开发部就会说：记录不清楚，无法定位问题所在，无法重现问题。开发部将问题踢回去，要求客服部进一步了解清楚情况。而客服部认为这些问题应该由开发进一步去搞清楚细节，毕竟客服不懂技术，可能无法跟用户了解清楚情况。于是有些用户提出来的问题因为客服部和开发部的扯皮，一直悬而未解，直到不了了之……
这样的情况如何处理？又如何敏捷呢？！
服务部与开发部的协作
我曾经在某公司的开发部工作，公司也有服务部等其他部门，我们公司当时销售产品为主，客户数量有几千甚至上万。客户使用软件过程当中，自然会遇到很多问题，就会求助于服务部，服务部能解决很多问题，但有时候遇到一些复杂的问题或者程序出错可能就无法处理，就会转给开发部处理。
我负责其中一个产品，我是这个产品的开发者。服务部转发过来的问题通常也是记录不清的，有时候服务部的同事会直接将用户的电话转过来。我不会厌烦这样的事情，反而是非常喜欢这样，我很关注用户使用我们的产品的感受，我会主动找客户问清楚细节。有时候服务部有一段时间没有意见反馈过来，我会主动问服务部同事：是不是出了什么状况？因为我相信只要软件有人在用，就不可能没有问题，没有问题就意味着没有人用这个软件。每次处理完问题后，我都会向服务部的同事通报处理的情况，并告知服务部的同事下次遇到类似问题应该如何跟用户沟通。开发部不仅仅是我，所有的同事都是这样的态度工作的，开发部和服务部之间的协作是无缝和良好的。
我能这样做是因为我人品好、工作态度好吗？非也，这是因为我有强大的利益驱动，我是按软件的销售额拿提成的！最终用户使用软件的感受，我当然要关注，我要改善软件让软件更加好卖，我好拿更多提成啊！
好的人品和好的工作态度，当然会帮助工作做得更好更主动，但如果有不合理的部门设置和绩效考核办法，就会逐步将这些“好东西”磨掉，甚至让好的员工忍受不了选择离职！合理的部门设置和绩效考核办法，能释放大家的工作积极性，让“懒人”变得更加勤劳和主动，同时淘汰掉不合适的员工。
上述三个例子说明了什么呢？你是属于哪种情况呢？很明显，能不能敏捷与公司的某些机制有关系，下面继续详解……
2）强矩阵还是弱矩阵？
请看图：
图4.2 矩阵式管理
软件公司一般会分为若干部门，比方说：行政部、财务部、研发部、质量部、销售部等等。公司越大，有可能部门分得越细，研发类直接相关的部门还可能细分为：项目管理部、需求部、开发部、测试部等。通常部门的划分标准是根据按工作性质，细分部门的目的是希望术业有专攻，公司老板希望各部门能越做越专业，各部门各司其职，共同地完成公司的运作。软件项目需要各类专业人才,包括以下方面的专业人才：需求分析、软件设计、项目管理、程序员、测试工程师、实施工程师、配置管理员、QA等等，这些角色在项目中各司其职，发挥各自的作用，这些角色可能来自不同的部门。对于某位项目成员来说，他又双重领导，分别是他所在部门的部门经理，还有就是项目中的项目经理。
上述部门及项目架构，就是矩阵式架构，基本上大部分公司都是这样运作的，但又会分为弱矩阵和强矩阵。
弱矩阵：各人以部门职责为主，各人做好自己的事情就可以了，各人主要对部门经理负责。
强矩阵：各人以项目利益为主，不仅仅完成本岗位的工作，还需要跨职能地工作，只要对项目成功有意义的事情，都鼓励项目组成员去完成，各人对项目成败直接负责。
如果你们在开展项目工作中需要经常协调各部门，但经常要浪费很多时间和成本，要求其他部门配合就好像求“阿爷”做事情一样；如果你们项目工作中某部门的文档输出是另外一个部门工作的输入，而这个文档经常成为扯皮的载体；如果项目出了问题领导要问责，各部门引用各自部门职责来相互推卸责任，最后变成流程的错、过程的错…… 如果你们有上述情况之一或者是有类似的情况，那么恭喜你，你们是“弱矩阵”！
3）敏捷对团队文化的要求
4）敏捷对薪金待遇的要求
5）敏捷的本质是什么？
本文是系列文章的第4篇，如果你错过了前面的文章，现在可以补救：
第一篇：敏捷的“官方”定义
链接：http://www.cnblogs.com/umlonline/p/3450032.html
第二篇：敏捷流程框架及敏捷实践一览
链接：http://www.cnblogs.com/umlonline/p/3450428.html
第三篇：敏捷在中国的水土不服
链接：http://www.cnblogs.com/umlonline/p/3453930.html
本系列文章已经全部结束，对敏捷感兴趣的朋友，请留意其他敏捷文章，谢谢！
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
软件知识原创基地创办人
相关文章
