阿米巴经营之软件经营-写得不错留作记念
每次敏捷开发培训课上，最备受关注的问题可以说是团队管理和绩效管理。
“敏捷开发注重团队合作”“敏捷开发不考核个人”“敏捷开发放权”“敏捷开发对人的主动性要求高”……这些新话题可以说对一般程序员而言是非常陌生的，因为一般的程序员，基本上是距离客户最远的人。前面有市场、销售、售前，后面有测试、技术支持，因此最有理由远离“尘世纷扰”，只需遵循指令照章办事。一旦程序员们被“放权”“主动”考虑“客户价值”并与队友们“团队合作”而且“不被考核”，反而不知所措。
阿米巴经营就是解决这个问题的。
本文会通过对阿米巴经营与软件开发管理及敏捷开发之间的关系，配合本人在一家公司管理市场/销售/实施团队时做的绩效管理改革（当年的营业额同比增长200%），分析软件行业实施阿米巴经营的一些潜在措施。
序言：何为阿米巴经营
阿米巴经营简单说就是把企业分解成众多独立工作的小组，而每个组员都具备经营意识和行为。
对常年做开发的程序员而言，阿米巴经营整体还是不太好理解的。下面结合软件开发业的特点，及敏捷开发中相关的术语，做一些介绍。
阿米巴经营有5个大目标，他们是：
1. 全员参与经营
李彦宏将狼性文化定义为敏锐的嗅觉、不屈不挠奋不顾身的进攻精神，群体奋斗。他同时表示将淘汰小资，他将小资定义为有良好背景，流利英语，稳定的收入，信奉工作只是人生的一部分，不思进取，追求个人生活的舒适才是全部的人。“要让所有员工更明确如果想找一个稳定工作不求有功但求无过的混日子，请现在就离开，否则我们这一艘大船就要被拖垮。”
软件公司整体上有两大类人与“经营”距离甚远，一种是行政人员（HR、财务、文秘……），另外一种是技术人员（开发，测试，美术，技术支持……）；而经营感最强的则是业务人员（市场，销售，售前，产品经理……），当然还有公司老板。如果管理不当，很容易造成经营感若的人员变成“小资”。2. 以核算进行目标管理
3. 透明管理
4. 公司的上下整合
5. 培养领导人
若正在为长期没有得到职务提升而感到困惑，下面的内容可能会有所帮助。因为越向上的职位越不像一个打工者，而是像一个企业的经营者。
何为经营
对一个开发团队而言，大致需要“经营”以下四种主要内容：产品，团队，技术，过程。当然仔细分析，可能还有更多相对次要的内容。
对于一般开发人员而言，不太好理解“经营”的含义，然而经营意识的缺乏，正好是研发管理中最大的问题之一。
曾经有一个与员工一起培训的部门经理，在第一天培训（讲用户故事，需求管理，用户建模，版本规划等）最后拍案而起说：“研发团队不关心市场经营，这个就是我们现在最缺少的！”。
具体缺少什么呢？我们来看看一个开发团队的两种职责描述，就能发现问题。
这是一种很正常的描述：
1. 产品：收集、描述和分析产品需求。
2. 团队：计划并分配人员完成任务。
3. 技术：保证产品的技术先进性与质量。
4. 过程：建立和维护项目管理制度。
……
这些都是中规中矩的管理概念，甚至可以说，如果能按上述条目完成管理，已经属于比较好的了。但在阿米巴式经营，或者说百度提到的“狼性”文化中，这些还不够。
因此整体上可以看出，做这四件事情的人，显然是“被雇来”按照“既定制度”管理产品、团队、技术和过程的。
当然这里边有一个先有鸡还是先有蛋的过程：“如果我们本来就被雇来奉命行事的，又怎么可能不奉命行事呢？”这正是阿米巴经营要解决的问题。
其实很多时候领导都希望放权，但当看到所有人对“做什么”都不关心，而只是盯着“怎么做”，领导就退缩了。
经营什么
经营产品
经营产品就是要真正把产品当作自己要做的东西，而不是别人雇自己来做的东西。
要经营的内容，大致包括：
1. 基于产品的商业计划（时间上的，偏重营收分析）
2. 客户群定义（空间上的）
……
实际开发中比较容易忽略的是1和2，典型的情况包括：
1. 开发人员只盯着发版计划，却不关心发版的产品的销售情况和客户反馈
2. 开发人员不断开发功能，却不知道产品可能卖给谁，甚至连用户是谁都有点模糊（在我培训课程中有一个沙盘演练环节，此情况屡屡出现！）
……
如果陷入了这两种情况，就要思考是否忘记了主动经营产品。
还有一些比较复杂的以后或许有机会会讲到（确切说，现在还没有足够的能力写出来），比如：产品线规划，即不同产品的搭配，以在原客户群中产生附加值或占领更大的市场。
经营团队
精英团队就是要把自己的部门、小组当作自己的小公司一样经营。包括：
1. 思考合理的人数和知识体系
2. 思考下属员工的职业生涯规划
3. 理解和优化团队的投入产出比
……
“投入产出比”是一个很重要的属性，就是要理解自己团队在公司中的位置，并利用营收数据来指导团队的发展。
举个例子：曾经有一次我们的团队营业额达到了上一年的3倍多一点，而大家的收入也平均增长了30%左右（这个是估计的），但大家仍然觉得心里不平衡：因为3倍和30%还是有很大差别的。但随后的营收分析揭示了一点：其实即使我们在营业额暴增之后，每年仍然净亏损150万元左右。有了这个数据，团队就冷静多了，也有了新的目标。这不是说要用这种方法“防止给下属加薪”，而是说无源之水是不长久的，要令团队知道、思考和改善自己所处的经营状态。
对开发团队而言，可能没有直接可以考量的营收指标，但是另外一些指标一般也是一笔糊涂账：
团队的生产率？质量？成长性？……
别说具体的数值，可能连合理的定义方法团队都较少去思考。这些都是缺少经营感的表现。
当然要做到精英团队很难！但这正是需要做的原因之一，因为一旦做成，别人很难复制。
经营技术
经营技术是说，不要只是把做产品/项目的过程当作完成任务或提升自己能力的过程，而是要当作为企业积累技术的过程。
这听起来很容易，但做起来有难度，比如这几个问题：
1. 团队是否有一个可复用的技术库？（DLL，类，函数，各种层面的）
2. 团队是否有一个机制令得这些库被充分利用？（一个可度量指标就是代码行/功能点，越低越充分）
……
一般而言若不进行有效管理，20人团队的代码冗余率可能在95%左右，也就是95%左右的代码是多余的。在2004年的一次技术改造中，一个19万行，13人×9年的产品，被改造为1.3万行，1人×1.5年的相同产品（更关键的是缺陷少了，这次改造的直接动因就是原来产品的缺陷众多而且隐藏很深）。
这并不是个例：这家公司是纳斯达克上市的上千人的电信软件公司，其开发和管理强于一般的中小公司，后者的技术水平可能更差。但由于普遍而言人们使用别人代码的比例很低（我们常常感觉到用过别人的东西，但若自己数数，又会发现不过就几百行代码而已），所以人数越多可压缩的比例越高；再加上由于多数人连自己的复用做的也不好，所以在未完善管理的情况下，对代码进行大规模压缩的潜力一般都接近在2×人数倍以上。
注意这个例子中，较少的代码不但有更高的生产率，质量也随之提高，甚至更加明显。
类似这种规模和周期的软件及团队，都应该刻意地在开始就不要只以完成当前任务为唯一目标，而开始架构和积累整个技术架构。
“若刚开始的时候老板不给充分的时间怎么办？”一则我从来没有见过老板指着我们的可复用库说：“不要编写这个，直接给我垒代码”；二则及时被给予足够的时间，多数团队也没有形成这样的可复用库；三则可复用库的生效速度是很快的，若前三个月投入复用的时间还没有赚回来，那么多半做错了……考虑到这些，多数时候缺少对技术的经营，其实是我们软件人员自己的问题。
经营过程
过程就是人们做事的方法，说大一些，就是“企业文化”。
文化是很容易被谈论又很容易被忽视的东西。很多底层的程序员能看到远在天边的企业文化，但却看不清楚自己面前的编码文化。
在2001年的一个团队里边（就是我第一次感受松结对编程与139团队的那个团队），刚开始只有5个人，人们不需要专业的测试人员而仰赖高手帮助新手查看代码和自己自主测试来保障质量；一年以后，当团队扩张到25个人的时候，这个传统仍然存在——此时我们的专业测试人员只有2个，而且只负责整体测试。
这是因为在团队成立的开始，团队尝试建立起一种以高质量为荣的团队文化，所有制造大量的缺陷程序员（包括刚开始时的我本人），都会同时受到鄙视和帮助，人们可以选择接受两者，或者只接受前者。结果是接受帮助的人逐渐摆脱了被鄙视的局面，他们继承了这种传统，进而帮助后来的新人。
可以被经营的过程有很多，有很多完全无需领导授权即可进行，另一些需要在进行一定程度后说服领导进行下一步的支持。这些过程包括：
1. 代码审查
2. 开放的办公室空间
3. 白板和经常的讨论会
4. 基于白板的简单设计（比如预想陈述）
5. 看板
6. 松结对编程
7. 1-3-9团队
……
谁来经营
“如果老板能让我放手管理，我也可以经营好我们的团队。可是……”这是常常听到的一句话。
实际上，老板一般都是“放手”管理的。多数团队的领导者（尤其项目经理）与自己团队相处的时间，超过再上一级的100倍。若这些时间——其实应该说是精力——被充分用来经营团队，而不是简单地执行传声筒和工头的角色，本文所说的经营完全可以实现。