神马是敏捷？（4）——敏捷不能当饭吃

摘要：

敏捷不是灵丹妙药，不能当饭吃！这是本系列文章最后一篇，我们将会谈谈敏捷对组织架构、团队文化的要求，特别是对薪金待遇的要求！最后根据我的个人理解，给出我对敏捷的定义。

本文大纲：

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）部门设置惹的祸？

下面我将会列举三个例子，前面两个是“杯具”，后面一个是“洗具”。

案例1：需求设计部 PK 编码及实施部

先上图：

图4.1 部门之间的PK

某软件公司设立了两大部门：

需求及设计部：顾名思义，就是负责软件需求分析及设计工作。（后面简称“A部门”）

实施部：负责编码实现，负责软件的安装、部署、上线、培训客户等工作。（后面简称“B部门”）

公司内部有一个任务管理系统：A部门经过需求分析及软件设计后，通过该系统分派编码等任务给B部门，这个任务叫“工单”，而分派任务的工作叫“下单”。B部门需要完成这些任务，并接受A部门的检查。B部门如果不能按时按质量要求完成任务，B部门的绩效考核就会差；而B部门如果认为A部门分派的任务不合理、描述不清，可以拒绝该任务，称之为“踢单”，“踢单”越多，A部门的绩效考核就越差。

没有这样的部门设置和考核机制之前，两个部门的人可以无分彼此地一起商量事情，共同解决问题，而这样的部门设置及考核机制建立后，两个部门的人经常为了一个“工单”而扯皮，工作的焦点变成不是如何让项目成功，而是如何界定两个部门的工作边界以及想办法推卸责任。

这样的情况，如何敏捷？

案例2：客服部 PK 开发部

某网站有大量的用户访问，用户可以向客服部投诉问题，客服部记录问题后移交个开发部处理。用户向客服部描述问题的时候，往往是描述不清的，往往只有“大概”的说法，而客服部往往也不能进一步向用户问清楚情况，往往只能记录问题而已。于是这样的问题移交到开发部时，开发部就会说：记录不清楚，无法定位问题所在，无法重现问题。开发部将问题踢回去，要求客服部进一步了解清楚情况。而客服部认为这些问题应该由开发进一步去搞清楚细节，毕竟客服不懂技术，可能无法跟用户了解清楚情况。于是有些用户提出来的问题因为客服部和开发部的扯皮，一直悬而未解，直到不了了之……

这样的情况如何处理？又如何敏捷呢？！

案例3：服务部与开发部的协作

我曾经在某公司的开发部工作，公司也有服务部等其他部门，我们公司当时销售产品为主，客户数量有几千甚至上万。客户使用软件过程当中，自然会遇到很多问题，就会求助于服务部，服务部能解决很多问题，但有时候遇到一些复杂的问题或者程序出错可能就无法处理，就会转给开发部处理。

我负责其中一个产品，我是这个产品的开发者。服务部转发过来的问题通常也是记录不清的，有时候服务部的同事会直接将用户的电话转过来。我不会厌烦这样的事情，反而是非常喜欢这样，我很关注用户使用我们的产品的感受，我会主动找客户问清楚细节。有时候服务部有一段时间没有意见反馈过来，我会主动问服务部同事：是不是出了什么状况？因为我相信只要软件有人在用，就不可能没有问题，没有问题就意味着没有人用这个软件。每次处理完问题后，我都会向服务部的同事通报处理的情况，并告知服务部的同事下次遇到类似问题应该如何跟用户沟通。开发部不仅仅是我，所有的同事都是这样的态度工作的，开发部和服务部之间的协作是无缝和良好的。

我能这样做是因为我人品好、工作态度好吗？非也，这是因为我有强大的利益驱动，我是按软件的销售额拿提成的！最终用户使用软件的感受，我当然要关注，我要改善软件让软件更加好卖，我好拿更多提成啊！

好的人品和好的工作态度，当然会帮助工作做得更好更主动，但如果有不合理的部门设置和绩效考核办法，就会逐步将这些“好东西”磨掉，甚至让好的员工忍受不了选择离职！合理的部门设置和绩效考核办法，能释放大家的工作积极性，让“懒人”变得更加勤劳和主动，同时淘汰掉不合适的员工。

上述三个例子说明了什么呢？你是属于哪种情况呢？很明显，能不能敏捷与公司的某些机制有关系，下面继续详解……

2）强矩阵还是弱矩阵？

请看图：

图4.2 矩阵式管理

软件公司一般会分为若干部门，比方说：行政部、财务部、研发部、质量部、销售部等等。公司越大，有可能部门分得越细，研发类直接相关的部门还可能细分为：项目管理部、需求部、开发部、测试部等。通常部门的划分标准是根据按工作性质，细分部门的目的是希望术业有专攻，公司老板希望各部门能越做越专业，各部门各司其职，共同地完成公司的运作。软件项目需要各类专业人才,包括以下方面的专业人才：需求分析、软件设计、项目管理、程序员、测试工程师、实施工程师、配置管理员、QA等等，这些角色在项目中各司其职，发挥各自的作用，这些角色可能来自不同的部门。对于某位项目成员来说，他又双重领导，分别是他所在部门的部门经理，还有就是项目中的项目经理。

上述部门及项目架构，就是矩阵式架构，基本上大部分公司都是这样运作的，但又会分为弱矩阵和强矩阵。

弱矩阵：各人以部门职责为主，各人做好自己的事情就可以了，各人主要对部门经理负责。

强矩阵：各人以项目利益为主，不仅仅完成本岗位的工作，还需要跨职能地工作，只要对项目成功有意义的事情，都鼓励项目组成员去完成，各人对项目成败直接负责。

如果你们在开展项目工作中需要经常协调各部门，但经常要浪费很多时间和成本，要求其他部门配合就好像求“阿爷”做事情一样；如果你们项目工作中某部门的文档输出是另外一个部门工作的输入，而这个文档经常成为扯皮的载体；如果项目出了问题领导要问责，各部门引用各自部门职责来相互推卸责任，最后可能会变成流程的错、过程的错…… 如果你们有上述情况之一或者是有类似的情况，那么恭喜你，你们是“弱矩阵”！

如果项目小组成员能在项目经理的带领下，无论是来自哪个部门，都能为项目的成功出力，都能自觉地做到“跨职能”地工作；如果项目出了问题，我们会认为这是我们的错，而不是具体某个人或某个部门的错…… 恭喜你，你们是“强矩阵”！

看上去似乎“强矩阵”比“弱矩阵”更好，其实两种模式各有特点和适应面：

弱矩阵：

1）流水线生产，适用于稳定的项目或产品。
2）每个人完成自己的工作职责，对岗位负责。

强矩阵：

1）适用于高难度、高挑战的项目或产品。
2）每个人都对项目成败负责。
3）每个人除了完成本职工作，还需要跨职能地工作。

很多公司规模比较小的时候，一个人需要完成很多种工作，自然而然就是“强矩阵”；公司慢慢做大后会细分部门，但管理者没有用某种考核方式来捆绑各部门的利益，就逐步会变成“弱矩阵”。经历过由小到大的老板可能都会感叹，为什么公司越大效率越低，很可能就是这个原因。

前文的案例1、2，明显就是按“弱矩阵”的思路来管理企业，结果出现了很多问题，这些问题不是部门职责不清的问题，而是体制出了问题；案例3虽然也划分了部门，但一个有效的绩效考核办法将大家的利益捆绑。

我们的软件项目通常都是“高难度”和“高挑战”，基本上不太可能流水线生产，所以我们更加需要“强矩阵”的管理模式，如果要实践敏捷，“强矩阵”的管理模式是必须的。不过我也见过有人分享“弱矩阵”下的敏捷实践，具体我还没有研究过，我觉得“弱矩阵”下部门内可以部分敏捷，但如果项目需要各部门协调时，“弱矩阵”可能真的无法敏捷。

3）敏捷对团队文化的要求

下面分享两个跟团队文化有关的案例。

案例1：皇帝急太监就是不急！

某项目经理为了项目心急如焚（皇帝急），而其他项目成员表示淡定（太监不急）：你安排任务给我就行了，老子的工作就是完成任务。项目经理很郁闷，为什么大家不能主动一点、多承担一点呢？为什么只有我急，大家不急？

案例2：“木头人”团队

某项目经理和某项目成员一起外出吃午饭，项目经理苦口婆心地跟他说：沟通很重要啊，一个项目的沟通很重要啊，很重要啊…… 如此这般说了很多沟通很重要的大道理，某项目成员一致不吭声，最多只是偶尔“嗯”一下，或者点一点头。项目经理还是私人出钱请项目成员吃饭的呢，他这样做是有原因的！因为他在实际项目中经常问大家有没有问题，大家要么不吭声要么就说没有问题，然后后面项目问题超级多。救命啊，他受不了了，为什么大家都藏着掖着，不沟通不说话呢！于是他才想出请吃饭这招，但你可以看到请吃饭的沟通效果是怎样的？

前文提到中国软件研发人员的几个特点，如：一块木头、机械工人，如果没有合适的管理方式，特别如果是“弱矩阵”的管理模式，那么就会放大这些特点，结果就变成上述两个案例的情况。

敏捷对团队文化是有要求的，就是：我们要在一条船上！

如果只有项目经理在船上，其他人在其他船上或者是脚踏几条船，项目情况跟我无关，出问题我就跳船或者换船！这如何敏捷呢？

4）敏捷对薪金待遇的要求

现在到了本文最高潮的部分了，因为我需要你回到几个“尖锐”的问题，请你根据满意程度用1-10分对以下三个问题打分：

1）你喜欢这份工作吗？
2）你的薪金多少？你满意吗？
3）你满意你的老板吗？

这三个尖锐的问题，我上现场课程的时候也会问大家，但我不需要大家现场打分，大家给个眼神给我就行了。因为学员们身边就是他的同事甚至是老板，他们是不方便当面打分的。但这三个题目，我在网络课程中问出来时，大家打分超级踊跃（因为大家都见不到面，互相不知道是谁），不仅仅是打分，各种抱怨都来了！

欢迎你评论本文时对这三个问题打打分，我想看看三个尖锐问题会不会炸了锅！

有一次我分享一篇关于敏捷团队建设的文章中提到“能力更高的人更有责任去推动水平低的同事进步”，结果网络上马上有人说：凭什么能力高的要多干活啊！如果你对这份工作不满，一直想跳槽只是暂时实施不了；如果你对薪金不满；如果你对你的老板不满（这里的老板泛指你的上司及上司的上司，不一定是公司老板）…… 你会对知识分享感兴趣吗？你会对敏捷感兴趣吗？

如果你是公司管理层，你想实施敏捷，请先用着三个题目自测一下，看看你们员工估计是怎样的打分（当然你不可能真的让员工去打分的），如果分数很低，你需要检讨问题在哪里，强推敏捷并不能提升分数，反而会让员工更加厌恶公司。

敏捷更多是一种精神层面上的要求，是一种精神文明，但精神文明是建立在一定物质文明的基础上的。员工得不到尊重，员工的生活得不到保障，温饱不解决，你跟我谈敏捷，就是扯淡！

有机会你可以问问国外实践敏捷很成功的大师们，能成功实施敏捷的团队，他们的薪金是怎样的？一般都是高于业界平均水平的。

但这是在中国啊，我们还有很多中小型企业，薪金可能低于业界平均水平，我们岂不是不能玩敏捷呢？

员工对公司的满意度，除了来自于薪金，还来自于对公司对每位员工的成长关怀。如果不能让我们的薪资水平在行业前列，那么我们就更加应该创造一个可以加速员工成长的工作环境，让员工可以学到更多赚钱本领，让员工可以争取到更高的薪酬。

5）敏捷的本质是什么？

本系列文章最开始的时候给出了敏捷的“官方”定义，经过几篇文章铺垫后，现在可以用简单的说话小结一下我对敏捷的理解了。

敏捷的核心基础：我们在一条船上！包括：

1）项目组所有人在一条船上。
2）员工和公司在一条船上。

敏捷的几个重要特征：
1）所有人对项目成功负责。
2）所有人直接需求驱动地工作。
3）所有人都需要跨领域地工作。
4）持续交付、迭代前进。
5）小步前进，持续改进。
6）有效、简单！

本文是系列文章的第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大战需求分析》作者

软件知识原创基地创办人

张传波 软件知识原创基地创办人

分类: 敏捷开发

标签: 敏捷开发, 敏捷