阿米巴经营之软件经营-写得不错留作记念

来源：互联网发布：淘宝分期免息什么意思编辑：程序博客网时间：2024/04/29 05:57

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

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

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

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

序言：何为阿米巴经营

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

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

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

1. 全员参与经营

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

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

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

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

2. 以核算进行目标管理

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

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

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

3. 透明管理

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

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

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

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

4. 公司的上下整合

有没有遇到过这些情况：

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

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

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

5. 培养领导人

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

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

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

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

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

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

若正在为长期没有得到职务提升而感到困惑，下面的内容可能会有所帮助。因为越向上的职位越不像一个打工者，而是像一个企业的经营者。

何为经营

对一个开发团队而言，大致需要“经营”以下四种主要内容：产品，团队，技术，过程。当然仔细分析，可能还有更多相对次要的内容。

对于一般开发人员而言，不太好理解“经营”的含义，然而经营意识的缺乏，正好是研发管理中最大的问题之一。

曾经有一个与员工一起培训的部门经理，在第一天培训（讲用户故事，需求管理，用户建模，版本规划等）最后拍案而起说：“研发团队不关心市场经营，这个就是我们现在最缺少的！”。

具体缺少什么呢？我们来看看一个开发团队的两种职责描述，就能发现问题。

这是一种很正常的描述：

1. 产品：收集、描述和分析产品需求。

2. 团队：计划并分配人员完成任务。

3. 技术：保证产品的技术先进性与质量。

4. 过程：建立和维护项目管理制度。

……

这些都是中规中矩的管理概念，甚至可以说，如果能按上述条目完成管理，已经属于比较好的了。但在阿米巴式经营，或者说百度提到的“狼性”文化中，这些还不够。

因此整体上可以看出，做这四件事情的人，显然是“被雇来”按照“既定制度”管理产品、团队、技术和过程的。

当然这里边有一个先有鸡还是先有蛋的过程：“如果我们本来就被雇来奉命行事的，又怎么可能不奉命行事呢？”这正是阿米巴经营要解决的问题。

其实很多时候领导都希望放权，但当看到所有人对“做什么”都不关心，而只是盯着“怎么做”，领导就退缩了。

经营什么

经营产品

经营产品就是要真正把产品当作自己要做的东西，而不是别人雇自己来做的东西。

要经营的内容，大致包括：

1. 基于产品的商业计划（时间上的，偏重营收分析）

2. 客户群定义（空间上的）

3. 产品版本规划（基于时间及客户群的综合分析）

……

实际开发中比较容易忽略的是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×人数倍以上。

注意这个例子中，较少的代码不但有更高的生产率，质量也随之提高，甚至更加明显。

类似这种规模和周期的软件及团队，都应该刻意地在开始就不要只以完成当前任务为唯一目标，而开始架构和积累整个技术架构。

“若刚开始的时候老板不给充分的时间怎么办？”一则我从来没有见过老板指着我们的可复用库说：“不要编写这个，直接给我垒代码”；二则及时被给予足够的时间，多数团队也没有形成这样的可复用库；三则可复用库的生效速度是很快的，若前三个月投入复用的时间还没有赚回来，那么多半做错了……考虑到这些，多数时候缺少对技术的经营，其实是我们软件人员自己的问题。