对敏捷组织转型的9点体会

　　前几天参加了Scurmgathering 2012 Shanghai大会，有机会听到几位国际大师的演讲，受益匪浅。也认识了很多圈内的朋友，思维碰撞，把酒言欢，不亦乐乎。这篇博客是受大会启发对敏捷组织转型的一些思考，算是对这场我参加过的最棒的技术大会的回应：

　　大会上我记住的关键词有：

　　Coaching, self-organizing team, complex system, B=f(P,E), 稳定系统，管理3.0，Dance with the system，人的改变，环境的改变，现代管理思想，代码人生

　　组织转型是一项艰难的工作，险象环生，阻力重重。我自己深度参与了两个大型公司的组织敏捷转型：诺西和百度。这里就和大家分享下自己对敏捷组织转型的一些看法，欢迎大家拍砖。

　　------------------------我是正文分割线-----------------------------

　　1. 组织是一个稳定但有缺陷的系统

　　一个组织是一个系统(包括人、工具、流程、文化)

　　系统是相对稳定的

　　稳定但不完美

　　不完美但是自我完全并可以运转

　　没有完美的系统，就是说系统都有缺陷

　　系统有缺陷是正常的，而且无论如何改进，缺陷不可能全部消除，只是程度和多少的区别

　　2. 系统的缺陷是问题吗?

　　首先，问题是什么呢?问题是人的体验和人的期望之间的差距。

　　系统的缺陷不一定会导致体验和期望之间的差距。

　　3. 那么问题是如何产生的呢?

　　从这个定义分析问题产生的原因有两种可能：

　　a. 期望没变，但体验下降了 =》产生问题

　　b. 体验没变，但期望提高了 =》产生问题

　　4. 问题产生了就需要改变系统吗?

　　不一定。除了改变系统还有两种办法：

　　a: 降低人的期望

　　b: 启动现有系统的协调能力，提高相关体验

　　a. 降低期望的解决方案听起来很消极，但我告诉你，其实这是非常有效并广为使用的解决方案。比如：婚姻问题、政府问题，等等。不过，这个会上瘾(因为好简单好直接)，而且最终结果往往很惨 -- 系统的崩溃。

　　b. 系统都具备自我协调能力。这里我说“自我协调能力”而不是“自我改进能力”。不是每个系统都能自我改进。自我协调能力是指能系统对自身的某个环节的体验做出提升(即局部优化)的能力，成本是牺牲其他环节的体验，总体体验是否提升无法确定，不过某些问题可以得到解决。直到外部对系统提出全面提升体验的刚需，系统才会陷入困境。

　　注：

　　自我改进能力是对总体体验进行提升的能力。

　　持续改进能力是对系统总体体验进行持续提升的能力

　　5. 那什么时候必须对系统进行改进呢?

　　a. 期望降低至底线，无法继续降低

　　b. 系统现有协调能力无法再对系统进行有效的局部优化

　　6. 系统改进的关键是什么?

　　我认为有两个关键点：

　　a. 因为系统改进有不小的成本，所以如何提前让系统在没有触底前意识到改进的必要性就尤其重要，因为如果触底了才开始改进，就会因为无法承受改进的成本而陷入泥潭(除非保证系统改进的每个阶段都产出一个完整的改进的系统)

　　b. 系统改进的最终目的是提升其“自我改进能力”，这样才能保证系统的自我进化：就是系统会根据外界的变化，自动进行调整去适应其变化。因为变化往往是对系统效率的更高要求，所以自我进化能力往往表现为系统效率的自我提升。

　　7. 那么如何在有能力承受改进成本是开始改进呢?

　　这是个麻烦问题，呵呵。很多公司做到了这点，但很痛苦;没做到的公司反而活的轻松些(无意识)。

　　谈到方式，我认为有三种：

　　a. 自底向上型：这是很诗意的方式。文化好就OK，文化不好就先搞好文化，因为不好的文化会驱逐基层的先知先觉者。

　　b. 自上向下-强制命令型：领导意识到了，然后采取行动直接改变公司流程、更新工具、管理实践。貌似这样容易些，其实不然，除非是领导拥有金日成般的魅力，否则一样会导致人的反弹。

　　c. 自上向下-敏捷型：领导意识到了，然后采取行动巧妙地改变系统参数，加强加快问题的影响，从而让人们更早意识到改变的必要。

　　8. 那如何实施系统的改进呢?

　　(终于到了这个问题 ：)对不起大家，有点儿绕~~~~)

　　系统往往是复杂系统(Jurgen Appelo)，系统里的问题是有或强或弱的相关性的，就是说 Pn = f(P1, P2, …，Pn-1)，基本上很难对问题给出简明的解决方案。

　　但幸运的是，系统具有其自组织性(Joseph Pelrine)，所以我们可以迭代使用(激励-观察-调整-确认)的方法来对系统进行改进。比如：为了提升质量，设立QA/RD人力比的KPI给QA部门，然后观察发现：QA人员已无法满足RD对测试人员的需要，RD开始愿意对质量付出更多，调整：组织公司PMO/QA资源大力支持RD在生产早期环节提升质量的行动(单测、代码评审、编程规范等)，确认：测试中发现代码缺陷明显降低，而且RD在早期生产环节中质量能力提升。下一个迭代就可以考虑取消人力比KPI，尝试其他激励，比如：对管理者的能力提出新的要求，等。

　　这部分要深入谈内容太多，请大家都说说吧。

　　9. 敏捷组织转型的五个特点

　　一、敏捷组织转型的特点是有一套完整的目标价值观、目标框架和各种成熟实践的组织转型。所以这个过程中，如果不能从系统的特点入手，往往容易做成把解决方案当成问题本身的转型，结果就是怨声载道、阻力重重。比如：把各种敏捷成熟度模型设成系统的KPI，杀伤力惊人!你见过单元测试覆盖率2个月内从10%提高到80%的吗?你见过QA自己搞持续集成RD都不知道的吗?

　　二、敏捷组织转型还有一个特点是它有一套完整的理论支持，但理论又比较复杂不容易被传达。这导致了很多问题，懂的人决心很大，不懂的人顾虑重重、瞻前顾后;懂的人愿意付出前期成本，因为他知道一定有回报;不懂的人，凡事要数据看收益(有趣的是：这本身又增加了额外成本：)

　　三、敏捷组织转型还有一个特点是它涉及组织的所有层面，从产品、市场、研发、测试、运维、管理、人事、财务、销售、甚至客户。需要特别有经验的人才能合理定义边界进行分阶段的实施。

原文转自：http://www.ltesting.net