神马是敏捷?(4)——敏捷不能当饭吃

标签: 敏捷开发敏捷
2229人阅读 评论(0) 收藏 举报
分类:
摘要:
敏捷不是灵丹妙药,不能当饭吃!这是本系列文章最后一篇,我们将会谈谈敏捷对组织架构、团队文化的要求,特别是对薪金待遇的要求!最后根据我的个人理解,给出我对敏捷的定义。

本文大纲:
1)部门设置惹得祸?
2)强矩阵还是弱矩阵?
3)敏捷对团队文化的要求
4)敏捷对薪金待遇的要求
5)敏捷的本质是什么?

本文是系列文章的第4篇,如果还没有看过第1、2、3篇,建议先看看!

第一篇:敏捷的“官方”定义

链接:http://blog.csdn.net/fireball1975/article/details/17049373

第二篇:敏捷流程框架及敏捷实践一览

链接:http://blog.csdn.net/fireball1975/article/details/17056017

第三篇:敏捷在中国的水土不服

链接:http://blog.csdn.net/fireball1975/article/details/17094667



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)有效、简单!  


敏捷学习资料

体验最火的敏捷——SCRUM(视频课程):http://www.umlonline.org/school/viewthread.php?tid=2524

超越极限编程(视频课程): http://www.umlonline.org/school/viewthread.php?tid=321

每日例会 = 僵尸大会?(视频课程):http://www.umlonline.org/school/thread-2602-1-1.html


作者:张传波

创新工场创业课堂(敏捷课程)讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

www.umlonline.org创办人


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    豆芽儿-软件研发人才成长社区
    我的常用链接
    我正式出版的书
    个人资料
    • 访问:663182次
    • 积分:9677
    • 等级:
    • 排名:第1902名
    • 原创:274篇
    • 转载:1篇
    • 译文:0篇
    • 评论:387条
    博客专栏
    最新评论