这是敏捷开发绩效管理的第八篇。（栏目总目录）

每次敏捷开发培训课上，最备受关注的问题可以说是团队管理和绩效管理。

“敏捷开发注重团队合作”“敏捷开发不考核个人”“敏捷开发放权”“敏捷开发对人的主动性要求高”……这些新话题可以说对一般程序员而言是非常陌生的，因为一般的程序员，基本上是距离客户最远的人。前面有市场、销售、售前，后面有测试、技术支持，因此最有理由远离“尘世纷扰”，只需遵循指令照章办事。一旦程序员们被“放权”“主动”考虑“客户价值”并与队友们“团队合作”而且“不被考核”，反而不知所措。

阿米巴经营就是解决这个问题的。

本文会通过对阿米巴经营与软件开发管理及敏捷开发之间的关系，配合本人在一家公司管理市场/销售/实施团队时做的绩效管理改革（当年的营业额同比增长200%），分析软件行业实施阿米巴经营的一些潜在措施。

序言：何为阿米巴经营

阿米巴经营简单说就是把企业分解成众多独立工作的小组，而每个组员都具备经营意识和行为。

对常年做开发的程序员而言，阿米巴经营整体还是不太好理解的。下面结合软件开发业的特点，及敏捷开发中相关的术语，做一些介绍。

阿米巴经营有5个大目标，他们是：

1. 全员参与经营

这是一种典型的唤醒沉睡员工的思路。

什么是沉睡员工？百度最近的狼性与小资的消息可以说做了一个完美解释：

李彦宏将狼性文化定义为敏锐的嗅觉、不屈不挠奋不顾身的进攻精神，群体奋斗。他同时表示将淘汰小资，他将小资定义为有良好背景，流利英语，稳定的收入，信奉工作只是人生的一部分，不思进取，追求个人生活的舒适才是全部的人。“要让所有员工更明确如果想找一个稳定工作不求有功但求无过的混日子，请现在就离开，否则我们这一艘大船就要被拖垮。”

软件公司整体上有两大类人与“经营”距离甚远，一种是行政人员（HR、财务、文秘……），另外一种是技术人员（开发，测试，美术，技术支持……）；而经营感最强的则是业务人员（市场，销售，售前，产品经理……），当然还有公司老板。如果管理不当，很容易造成经营感若的人员变成“小资”。

2. 以核算进行目标管理

有些岗位是非常难以核算的，比如行政人员。

技术人员也不是太容易进行核算，别看管理指标一大堆（进度，质量，成本……），但是要具体拿出一个来做绩效考核，还真的很难。那么应该怎么做呢？答案是：用外部目标对内部人员进行核算。

比如如果用内部目标度量开发人员，开发人员会告诉你说：“我们的生产率就是生产代码（或更高级一点，功能点），所以要想提高生产率，就多招聘一些人吧”。而对外部目标而言，生产率是赚钱的速度，也就是人均产值，面对这个目标，开发人员要重新思考：“客户买我们产品的目的是什么，哪些功能值钱，哪些不值钱；能不能用更少的代码完成这些功能以提高生产率？”注意如果用内部目标，代码少生产率反而低。

3. 透明管理

一想到透明管理，做软件的第一感觉就是软件度量，其实还不然。

企业，无论是哪种类型的企业，第一个需要透明化的东西，就是营收数据：到底赚了多少钱，哪些部门哪些产品哪些人赚的；到底花了多少钱，哪些部门哪些产品哪些人花的。

如果这些都不透明，简单度量一些代码行、缺陷率，无益于企业整体的发展。当然有人会说：“我们就是一个普通的开发人员，能度量清楚自己的代码、缺陷就已经不错了，哪有闲心和能力去管理部门和产品？”如果刚才真的有这种想法，恭喜，你已经成为一个没有狼性的小资了。

敏捷开发中的透明化管理多数都是一线数据的透明化，当然原因不是“目光短浅”，而是敏捷开发本来要解决的就是这类问题。但产品经理及产品总监应该具备透明管理的意识，即要意识到自己所管理的产品是一个一方面有收益，另外一方面有投入的循环过程。原来那种不管人力研发成本、甚至不管产品销售状况而只管产品需求的产品管理方法，将很快过时。

4. 公司的上下整合

有没有遇到过这些情况：

销售部门需要一个重要的功能才能打动一大类新的客户，所需的时间也不是非常多，但去找开发人员的时候，开发人员都很忙；过了N年M月，新版本一次一次发布，都没有那个重要的功能，而新的客户也因此没有被打动；而新版本发布之后，并没有更多的客户被其中新增的功能所打动；问他们为什么不开发那个销售部门急需的功能时，大家说都很忙……

这是典型的整合问题，简单说是销售和开发两个部门的横向整合问题，但从根源上，是老板-销售与老板-开发这两条上下整合线出了问题。换言之，公司的大老板必须知道自己公司到底最近在做什么，并让所有部门协同来完成这个工作。

敏捷开发中的产品版本规划与此相关；而产品线规划（敏捷开发中没有提到），与此的关系更大。

5. 培养领导人

很多时候，公司的多数人都在避免自己成为一个可以被替代的人，相反，所有人都希望自己变成独当一面的人，因此自己的位置也就安全了。这是典型的小资思维。但另外一些人则在做相反的事情：他们在培养自己的接班人，并希望把自己的工作分出去，以便自己可以在更高的位置接手更重要的事情。这个就是典型的狼性思维。

很多人会问：“你培养好了接班人，不但没有更高的位置也没有接手更重要的事情，反而因为不需要了而被开掉了，怎么办？”这样想的人，多半没有做过这件事情，或者误以为自己做了这件事情（日后会有文章详述）。

敏捷开发中的团队协作，尤其是松结对编程及139团队，其主旨就是希望能培养人的可替代性。尤其对团队领导或高手而言，应该意识到有人能替代自己的工作——开始是技术上的，之后是管理上的——是一件能扩大自己下属团队的最佳方法，也是另下属团队能独立思考自主运营的最佳方法。

阿米巴经营在国内尚处于探讨阶段，IT公司更是如此。

不过如果大家听说过“内部创业”，或对当前游戏团队的运营模式有所了解，不难想象其操作原理。

不过要说到可分享的经验，尚为时过早。之后的文章，将通过这5点进行更深入的探讨，找到一些思路。

本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票： http://vote.blog.csdn.net/item/blogstar/cheny_com

敏捷开发绩效管理系列之八：阿米巴经营之序言相关推荐

敏捷开发团队管理系列之一：序言与出发点
这是敏捷开发团队管理系列的第二篇.(之一,之二,之三,之四) 之前的各个系列中,已经涉及了很多团队管理相关的内容,比如松结对编程系列中提到过大型团队分拆为微观开发团队的管理,产品管理系列中提到过Pro ...
敏捷开发绩效管理之九：阿米巴经营之软件团队经营什么（上）
这是敏捷开发绩效管理的第九篇.(栏目总目录) 若正在为长期没有得到职务提升而感到困惑,下面的内容可能会有所帮助.因为越向上的职位越不像一个打工者,而是像一个企业的经营者. 何为经营对一个开发团队而言 ...
敏捷开发绩效管理之十：阿米巴经营之软件团队经营什么（中）
这是敏捷开发绩效管理的第十篇.(栏目总目录) 经营技术经营技术是说,不要只是把做产品/项目的过程当作完成任务或提升自己能力的过程,而是要当作为企业积累技术的过程. 这听起来很容易,但做起来有难度,比 ...
敏捷开发团队管理系列之三：程序与测试团队II
这是敏捷开发团队管理系列的第三篇.(之一,之二,之三,之四) 测试团队的价值这样看来,敏捷开发的质量保证问题,都被发开团队解决了,测试团队的价值何在? 这个可以从第一个项目组后来的发展来分析. 在整 ...
敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效）...
这是敏捷开发绩效管理的第四篇.(之一,之二,之三,之四,之五,之六,之七) 最近在看德鲁克的书,发现其中很明确地写着"企业的绩效只存在于外部,而企业内部只有成本"的概念和说法,下面 ...
敏捷开发绩效管理之三：个体动力之源——同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）...
这是敏捷开发绩效管理的第三篇.(之一,之二,之三,之四,之五,之六,之七) 如果有10个程序员,笔者相信至少有9个是勤奋的.但是如果有一个10人的程序员团队,其中1个人不是勤奋的,而且仍然拿到与其他人 ...
敏捷开发绩效管理之二：用中医理论管理团队及其绩效（绩效考核，团队管理，自组织团队）...
这是敏捷开发绩效管理的第二篇.(之一,之二,之三,之四,之五,之六,之七) 团队管理是个由来已久的话题,各式各样的管理理论和方法层出不穷.笔者因为工作原因在过去16年里与100多家企业的团队或团队领导 ...
敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效）
这是敏捷开发绩效管理的第四篇.(之一,之二,之三,之四,之五,之六,之七) 最近在看德鲁克的书,发现其中很明确地写着"企业的绩效只存在于外部,而企业内部只有成本"的概念和说法,下面 ...
敏捷开发绩效管理之一：序言及“敏捷开发是否考核个人”（绩效考核）
这是敏捷开发绩效管理的第一篇.(之一,之二,之三,之四,之五,之六,之七) "敏捷开发绩效管理"本身是个伪命题,因为敏捷开发本身不想涉及绩效管理,这就像"C++绩效管理& ...

敏捷开发绩效管理系列之八：阿米巴经营之序言