问题
这个不是培训课上的问题,而是最近一些电话和微博上的问题。
起源是有客户打来电话,希望不只是听听培训(包括内训),而是希望能有长达十天二十天的现场指导活动,指导企业完成敏捷的部署。虽然这的确是一个很好的商业机会,整体上却不太可行;或者说即使可行,也不是企业想象中的“行”法。
最近微博上面关于华为敏捷推广的讨论也间接地揭示了这一点。(华为的讨论是由现在或过去的华为员工发起的,可参考@曾小萌HW 及其微博过程中所涉及的其他人)
除了简单的“应该由敏捷开发的主体也就是企业来主导”的直觉外,也说说具体的现实问题。
分析
1. 信息不对称
有两重,一重是外部教练对企业的信息了解甚少,二重是企业对敏捷了解甚少。
本人不太认同“互补”的概念,或者说,仅仅由互补,解决不了问题。正像敏捷开发中提倡跨职能团队,教练和企业也应该是个跨职能团队,而不是强分工团队。
所以,必须两者合为一体才能解决问题。当然下一个问题,是教练应该去了解企业,还是企业去了解敏捷?
这里我们先否定“都要”这个答案,过年的时候如果你问小孩子:“你要苹果还是橘子?”他们都会给出这个答案,我们需要一些更加理性和现实的答案。
2. 动机不对称
抛开各种高尚的或理想化的思路,必须意识到教练了解企业的动力,远远小于企业了解敏捷的动力。
原因何在?因为敏捷毕竟是一种知识,资料公开,体系完整,了解它的难度相对较小,而掌握好它的收益却很大;而“企业的情况”虽然是咨询师必须掌握的,但一则模糊不公开,二则真的“不太值得”掌握(相对敏捷知识而言)。
企业其实也潜移默化地理解和支持这一点,比如如果有10天的咨询工作,企业一定不会选择前9天做“调查和分析”,最后1天给出“解决方案”,而是相反。
所以主观和客观地分析,都令咨询师其实很难有机会真正深入了解企业。
借用敏捷宣言中的语法,一个敏捷咨询师必须客观地承认这一点,并有以下宣言:
我们一直在实践中探寻更好的软件开发方法,
身体力行的同时也帮助他人。由此我们建立了如下价值观:
企业学习和理解敏捷 高于 咨询师了解和具体指导企业
也就是说,尽管右项有其价值,
我们更重视左项的价值。
然后在客户惊讶的目光下(“这家伙居然说他不愿意多了解我们的企业现状!”),思考最负责任的做法。
方案
方案1
中高层必须认识到自身改进的重要性,而不要简单寄希望于外部力量。
最近几次参加培训课的读者一定还能记得解决一个“从来没有听到也搜索不到的敏捷开发问题”所需思考的三个层面(未来有文详细解释),比如“我们的站立会议沉闷散漫,各说各的,开不起来,怎么办?”,答案包括三层:
1. 找到一个直接方法,比如国外流行的“迟到罚款箱”之类的东西,有的企业还考核按时结束率之类的。
2. 找到生态系统方法,比如先共同估算再开立会,计划会上先估算后分配之类的,确保人们互相了解别人的工作,才有值得交流的内容。
3. 找到组织级的方法,比如139团队(师傅为成败负责,所以会主动帮助别人),破除强分工,面向团队进行绩效考核等等,都能打破个体的沉默。
前两层基本上一线人员或者最多动用部门经理,问题都可以解决。而第三层组织级方法,泛指那些关于组织架构、绩效考核、部门划分、角色定义相关的方法,都需要上层介入。
拥有多年工作经验的软件研发管理者应该都能感觉到:大型软件企业的根本问题,不是研发技术问题,也不是市场销售问题,而是企业组织架构的问题(国家亦然!)。组织级不做改进,仅仅靠敏捷开发自身的实践,很难成功。所以企业的中高层,不能安排好下面的“敏捷开发推进工作”就一走了之,而是要不断倾听来自下层的“组织级要求”,从组织架构到绩效考核,都要倾听。
不过,不是机械地盲从敏捷的要求,而是要去理解其背后的管理理念,从更高的层次让整个企业敏捷起来。关于敏捷的一个可怕的事实是:敏捷开发的创立者、培训者、教练者、实践者,几乎都没有大型企业或部门的管理经验!(这不是说“敏捷开发层次低”,而是说“敏捷开发本来就是关于一线工作的”)所以,在组织级推广敏捷的时候,高层领导必须去学习、理解、主导,才能确保敏捷开发能帮助达成企业的商业目标,而不是敏捷做好了,企业倒退了。
方案1+2
综合一下,大致有这么几条应该是必需的
1. 无论内外的教练,企业内部都要有人来主导敏捷开发的推广
2. 这些人应该上可达企业高层,下可达一线人员,成为利用整个公司力量解决问题的部门。
3. 除了人员要内部具备之外,敏捷开发最后不能“文”在企业内部,而是要“化”在企业内部,这需要上下各层对敏捷开发的真正理解。
附1:方案2中的例子问题比较复杂而答案写得很简略,可参考以下内容:
1. 敏捷生态系统中关于此问题的讨论:http://cheny.blog.51cto.com/3988930/1100229
2. 松结对编程中关于共同估算的讨论:http://cheny.blog.51cto.com/3988930/1100183 这是之三,要完全理清头绪,恐怕之一~之四都得看。
附2:关于“企业整体敏捷”
前面提到了“敏捷开发是关于一线工作的”,其实不然,日后会有一个子系列,关于整体敏捷的,会综合性地描述企业组织级的敏捷思想和方法,预计会发布在“敏捷开发团队管理”系列里边,敬请关注。
转载于:https://blog.51cto.com/cheny/1102204