种瓜得瓜，种豆得豆
对今天很多中国软件企业来说，并不是开发人员没有事情可做，而是需要做的工作实在太多，根本无法满足这些企业业务的需求。然而不少公司都无法再投入更多的资源在研发上，例如花更多的钱来招聘更多程序员。上个月在CSDN的CTO俱乐部里，就有不少CTO在讨论这方面的问题，当然，冒头者多数是小型软件公司，只有二三十人的开发团队规模。然而，大公司同样面临这个问题。
从某种意义上说，当老板是一件很不容易的事，每天面对的就是公司各级主管要钱、要人的请求。其实大多数人都明白，只要有足够多的资源，就可以解决任何问题。但作为商业机构，资源的有限性本身就是一个需要不断去优化的矛盾。看起来，无限制的投入研发资源一定是不可能的，那么如何用这三五条枪，十来个人去满足那些并不见得有多少利润的业务呢？
作为业务部门的人，每次向开发人员提出开发需求的时候，常常得到的答复是：“你的项目半年以后可以开工。”这种情况在很多软件企业屡见不鲜。而只有老板级的人对研发团队下指示，才能从一定意义上得到满足。
其实，不少公司的研发团队拥有的开发资源是充足的，至少在一定程度上可以满足企业的研发需求，但是研发工作就是不见进展。尤其是那些已经有十数个或者数十个研发人员的公司，已经开始出现了分工以及多层组织结构。但是有不少老板天真地认为，自己的研发团队有足够的实力去完成所有的开发任务。
不得不说这是不可能的，并且占大多数情况。作为老板，总认识几个同行业的竞争对手，也了解他们的人员构成和规模，怎能不知道自己的资源能做多少事？问题在于，老板是不是真的把研发管理当成了企业发展一个重要的战略组成？既然是企业发展的战略组成，那么管理是一定需要成本的，所谓种瓜得瓜，种豆得豆。在研发团里上下了多少工夫，就有多少收获。
CTO通常也是企业的老板之一，他们确实认真看待了研发管理的问题吗？
管理体制专业化
在认真考虑研发管理问题的开始，需要有严格的人员定位。CTO在企业中到底扮演什么角色？如果在小型企业，这个问题根本不用说，他们需要面对的就是各种各样的复杂问题，从技术到管理无所不包，但是在稍大一点的企业，CTO的职能就开始发生变化了。因为人数的众多以及业务的发展，一个人根本无法驾驭这么多具体的工作细节，甚至一些重大的问题，例如人员甄选、资源调度等都需要依靠更多的管理者来完成，而这些管理者往往都是需要管理成本的，如何组建一个研发团队的组织结构，就成了很多CTO需要去考虑和驱动的首要问题。
一些研发工作做得看起来不错的企业，通常会有两个人直接向CTO汇报，他们分别是技术总监和研发总监，由技术总监帮助所有的项目组以及部门团队解决技术问题，由研发总监解决除了技术之外的一切问题。
开发人员除了技术，还会有什么其他问题？不少老板对这个问题基本上没有什么概念。人事、行政、沟通、协调、文化建设甚至于资源的分配等工作，都需要有人来解决，这些繁杂的工作如果消耗掉了CTO的大多数时间，那么我们CTO如何去帮助企业制定发展战略？
也许有不少人要问，公司本身就已经配备了这些相应的部门，为什么还要另起炉灶单独处理？这是因为在软件企业当中，开发人员本身就是一个主体部分。比如微软，到2008年底有91000 名员工，其中超过20000 人是研发人员，这些人在上述与企业管理相关的工作上有许多不同的要求，试问一名普通的人力资源经理，如何去判断一位应聘者的技术能力？如果你的技术主管每天都忙于招聘合适的程序员，那么开发怎么办？
除此之外，稍大规模的企业，还涉及到对中层干部的选拔和任用等多方面问题，以研发总监为核心的研发团队管理体系，其作用会随着企业规模的不断增大而发挥日益重要的作用。这一点上，共产党指导的军队，除了编制上的首长之外，还有主抓管理的政委，其作用正在这里。
人员配备量力而行
然而，所谓“稍大”规模到底是什么规模？这个问题，我曾经问过不少企业的技术主管，他们当中有CTO也有中层的技术主管和项目经理等，通常情况下，7~8 个人是一个主管认为比较合适的规模。其中有一位精力旺盛的主管告诉我，他最多可以管理多达11 个人，也就是说在这样的情况下，他可以了解向他汇报的每一个人的具体工作，然而一旦突破这个极限，就根本无法控制了。
这一点上，军队的建制很值得我们参考。通常在高一级的管理当中，3 这个数字被认为是最有效的管理数字，一个军通常有三个师，一个师通常有三个团，一个团通常有三个营……基层人员的管理数量通常稍大，但不会超过10 个单元。在军队当中，这种建制所体现出来的效率经历了人类上千年的经验积累。
事实上，当你的开发团队人数超过10 个时，你可能已经开始需要建立多层的组织结构了。例如微软在研发管理上的模式，通常一个产品组会被分成项目经理组、程序开发组和测试组。同样是最能够发挥效率的组织结构，让微软在大规模用户的客户端产品开发上，比其他软件公司遥遥领先。
一层又一层的汇报机制， 带来的不仅是人数上的暴增，而且还带来了很多管理上的成本，对于这些成本，不少国外企业的高级技术主管都认为是应该支付的，只有在极少数时候，才可以突破这种层级设置的法则。例如Google，其研发的扁平在业内很有名气，其项目总监直接负责数千个项目，尽管这让人难以想象，但是这种模式竟然得到了很好的运行。这是因为Google 和一般软件公司有很大的不同，让一般企业难以置信的利润率可以确保这家公司能从业界招聘到最好的程序员，众多能力超强的人在一起，往往会主动比拼实力，从而形成了一个良好的向上发展的氛围。
然而，这种模式在一般企业根本行不通，所以我们会看到“半年以后可以启动你的项目”这种情况屡见不鲜，因为相互的推诿和拖延已经成了在这些企业中的毒瘤。作为CTO的技术主管，根本无法关注除了技术、管理等之外的诸多问题。研发体制，则成为一针强有力的反病毒注射剂。当然，如果你的研发团队规模并不大，那么作为CTO的你，只好承担所有工作了，一旦你觉得自己无法承受压力，也许就应该在组织结构上想办法了。
大棒胡萝卜都不能解决的问题
作为老板，最关注的问题仍然是这个：招来的人不用心干活怎么办？于是，各种各样的考核机制出现了。为了让程序员拼命干活，老板们想出来的招数确实不少，这当中有用鞭子抽的，有用胡萝卜引诱的，有放羊的，有达尔文式的，总之手段层出不穷，但收效却不多。
最简单的考核办法莫过于考勤+工作量的考核法。反正程序员必须每天都来上班，并且干够至少8 小时，规定的代码量也必须要完成。这种方式程序员自有应对的招数：每天准时上班，准时下班，写代码不用过脑子，能用就行，凑足了行数或者功能就完事。由于知识工作者的特殊性，导致工作量很难进行具体的衡量，这不像原来的军队，以斩首来计算那么客观。如果较真地进行工作量考核，无疑会支付太高的管理成本。因此这种考核方式，往往在坚持了一年左右以后，常常会被很多老板放弃，或者最后沦为形式主义。但如果老板们愿意投入资源来做这个工作，并通过良好的研发体系来帮助完成考核，这种方式也能取得较好的效果。
拍脑袋的方式是国内很多软件公司都在使用的一种方法，这种方法通常行之有效。毕竟谁在干活，谁在偷懒，对于主管来说很容易区别。当然，其弱点也很明显，主观因素太多，可能会导致不少人不服气，最后反而激化了内部的矛盾。毕竟，只有客观的数据才能让人心服口服。如果在这种方法上加入一些奖惩机制以及优胜劣汰的原则，则会加剧这些矛盾和冲突，因此很多公司都比较谨慎使用这些方法，最后导致整个研发团队的效率低下，形成不良的风气。
当然，也有不少修道的老板对于研发管理不闻不问，顺其自然。这种方法基本上靠运气，如果招来的程序员或者主管上进，那么就会比较理想地完成任务。反过来，也就不存在考核的问题了。其实在考核上，员工只希望做出了成绩能有回报，不过程序员的工作是知识性工作，验证起来很难做，因此要达到员工的这个要求并不容易。
给每个程序员打烙印
不容易并不代表不能做到。事实上，还是有不少企业能将考核这件事做好。但是我们看到的所有例子，都不仅仅是企业的研发做得很好，而其他部分的工作却不理想。这是因为企业的研发管理，与企业文化息息相关。
比如前文所说的Google，因为这家公司的每一个员工都深信自己在业界是最好的：拿着最好的待遇，公司有最高的利润，享受最好的福利（比如专用厨师），同事是业界最优秀的（比如Internet的发明人），他们就应该是最好的。一旦在这样的环境下，自己的工作没有做好，比自己的同事差得有些远，就会觉得无地自容，从而激发他们不断用心把每一项工作都做到极致。这种企业文化，深深地烙印在了每一个开发人员心中，再加上一些能够算得上是客观的考核，形成了凝聚力很强的团队。
另外还有一些不同的文化也能促进团队的凝聚和效率发挥。比如马云在阿里巴巴推行的“六脉神剑”，从考核机制上也一定程度地调动了程序员的积极性。而其企业文化本身所崇尚的无隔阂交流（在阿里巴巴完成了一个好项目，主管会被剥光了衣服扔进西湖），让整个团队充满了活力，并形成一种遇到问题，公司内部一致向外的文化。
当然，企业文化是需要积累和沉淀的一种东西。如果学得不像，就有可能会遇到更大的麻烦。这就像学习跆拳道的小朋友在一起，如果一言不合，就拳脚相加，事实上只学到了跆拳道的“形”，没有学到跆拳道尊师重道的“神”。这种例子在国内屡见不鲜， 一些公司原本在国外有良好的传统和文化，一进入中国就变了味。原来大家积极进取的精神，变成了高高在上不可一世的官僚主义，产品和项目的研发自然无法顺利推进。
结语
研发管理是一个很大的话题，一篇短短的文章很难讲完，但是我们却应该关注它。在中国这个市场上，软件利润不高是事实。关注研发管理，同样也是增加软件附加值的一种方式，这种附加值的增加，不仅会为中国的软件企业带来更多利润，同时也让能我们在一个更高的水平竞争。
（本文来自《程序员》杂志0911期CTO专刊）
对今天很多中国软件企业来说，并不是开发人员没有事情可做，而是需要做的工作实在太多，根本无法满足这些企业业务的需求。然而不少公司都无法再投入更多的资源在研发上，例如花更多的钱来招聘更多程序员。上个月在CSDN的CTO俱乐部里，就有不少CTO在讨论这方面的问题，当然，冒头者多数是小型软件公司，只有二三十人的开发团队规模。然而，大公司同样面临这个问题。
从某种意义上说，当老板是一件很不容易的事，每天面对的就是公司各级主管要钱、要人的请求。其实大多数人都明白，只要有足够多的资源，就可以解决任何问题。但作为商业机构，资源的有限性本身就是一个需要不断去优化的矛盾。看起来，无限制的投入研发资源一定是不可能的，那么如何用这三五条枪，十来个人去满足那些并不见得有多少利润的业务呢？
作为业务部门的人，每次向开发人员提出开发需求的时候，常常得到的答复是：“你的项目半年以后可以开工。”这种情况在很多软件企业屡见不鲜。而只有老板级的人对研发团队下指示，才能从一定意义上得到满足。
其实，不少公司的研发团队拥有的开发资源是充足的，至少在一定程度上可以满足企业的研发需求，但是研发工作就是不见进展。尤其是那些已经有十数个或者数十个研发人员的公司，已经开始出现了分工以及多层组织结构。但是有不少老板天真地认为，自己的研发团队有足够的实力去完成所有的开发任务。
不得不说这是不可能的，并且占大多数情况。作为老板，总认识几个同行业的竞争对手，也了解他们的人员构成和规模，怎能不知道自己的资源能做多少事？问题在于，老板是不是真的把研发管理当成了企业发展一个重要的战略组成？既然是企业发展的战略组成，那么管理是一定需要成本的，所谓种瓜得瓜，种豆得豆。在研发团里上下了多少工夫，就有多少收获。
CTO通常也是企业的老板之一，他们确实认真看待了研发管理的问题吗？
管理体制专业化
在认真考虑研发管理问题的开始，需要有严格的人员定位。CTO在企业中到底扮演什么角色？如果在小型企业，这个问题根本不用说，他们需要面对的就是各种各样的复杂问题，从技术到管理无所不包，但是在稍大一点的企业，CTO的职能就开始发生变化了。因为人数的众多以及业务的发展，一个人根本无法驾驭这么多具体的工作细节，甚至一些重大的问题，例如人员甄选、资源调度等都需要依靠更多的管理者来完成，而这些管理者往往都是需要管理成本的，如何组建一个研发团队的组织结构，就成了很多CTO需要去考虑和驱动的首要问题。
一些研发工作做得看起来不错的企业，通常会有两个人直接向CTO汇报，他们分别是技术总监和研发总监，由技术总监帮助所有的项目组以及部门团队解决技术问题，由研发总监解决除了技术之外的一切问题。
开发人员除了技术，还会有什么其他问题？不少老板对这个问题基本上没有什么概念。人事、行政、沟通、协调、文化建设甚至于资源的分配等工作，都需要有人来解决，这些繁杂的工作如果消耗掉了CTO的大多数时间，那么我们CTO如何去帮助企业制定发展战略？
也许有不少人要问，公司本身就已经配备了这些相应的部门，为什么还要另起炉灶单独处理？这是因为在软件企业当中，开发人员本身就是一个主体部分。比如微软，到2008年底有91000 名员工，其中超过20000 人是研发人员，这些人在上述与企业管理相关的工作上有许多不同的要求，试问一名普通的人力资源经理，如何去判断一位应聘者的技术能力？如果你的技术主管每天都忙于招聘合适的程序员，那么开发怎么办？
除此之外，稍大规模的企业，还涉及到对中层干部的选拔和任用等多方面问题，以研发总监为核心的研发团队管理体系，其作用会随着企业规模的不断增大而发挥日益重要的作用。这一点上，共产党指导的军队，除了编制上的首长之外，还有主抓管理的政委，其作用正在这里。
人员配备量力而行
然而，所谓“稍大”规模到底是什么规模？这个问题，我曾经问过不少企业的技术主管，他们当中有CTO也有中层的技术主管和项目经理等，通常情况下，7~8 个人是一个主管认为比较合适的规模。其中有一位精力旺盛的主管告诉我，他最多可以管理多达11 个人，也就是说在这样的情况下，他可以了解向他汇报的每一个人的具体工作，然而一旦突破这个极限，就根本无法控制了。
这一点上，军队的建制很值得我们参考。通常在高一级的管理当中，3 这个数字被认为是最有效的管理数字，一个军通常有三个师，一个师通常有三个团，一个团通常有三个营……基层人员的管理数量通常稍大，但不会超过10 个单元。在军队当中，这种建制所体现出来的效率经历了人类上千年的经验积累。
事实上，当你的开发团队人数超过10 个时，你可能已经开始需要建立多层的组织结构了。例如微软在研发管理上的模式，通常一个产品组会被分成项目经理组、程序开发组和测试组。同样是最能够发挥效率的组织结构，让微软在大规模用户的客户端产品开发上，比其他软件公司遥遥领先。
一层又一层的汇报机制， 带来的不仅是人数上的暴增，而且还带来了很多管理上的成本，对于这些成本，不少国外企业的高级技术主管都认为是应该支付的，只有在极少数时候，才可以突破这种层级设置的法则。例如Google，其研发的扁平在业内很有名气，其项目总监直接负责数千个项目，尽管这让人难以想象，但是这种模式竟然得到了很好的运行。这是因为Google 和一般软件公司有很大的不同，让一般企业难以置信的利润率可以确保这家公司能从业界招聘到最好的程序员，众多能力超强的人在一起，往往会主动比拼实力，从而形成了一个良好的向上发展的氛围。
然而，这种模式在一般企业根本行不通，所以我们会看到“半年以后可以启动你的项目”这种情况屡见不鲜，因为相互的推诿和拖延已经成了在这些企业中的毒瘤。作为CTO的技术主管，根本无法关注除了技术、管理等之外的诸多问题。研发体制，则成为一针强有力的反病毒注射剂。当然，如果你的研发团队规模并不大，那么作为CTO的你，只好承担所有工作了，一旦你觉得自己无法承受压力，也许就应该在组织结构上想办法了。
大棒胡萝卜都不能解决的问题
作为老板，最关注的问题仍然是这个：招来的人不用心干活怎么办？于是，各种各样的考核机制出现了。为了让程序员拼命干活，老板们想出来的招数确实不少，这当中有用鞭子抽的，有用胡萝卜引诱的，有放羊的，有达尔文式的，总之手段层出不穷，但收效却不多。
最简单的考核办法莫过于考勤+工作量的考核法。反正程序员必须每天都来上班，并且干够至少8 小时，规定的代码量也必须要完成。这种方式程序员自有应对的招数：每天准时上班，准时下班，写代码不用过脑子，能用就行，凑足了行数或者功能就完事。由于知识工作者的特殊性，导致工作量很难进行具体的衡量，这不像原来的军队，以斩首来计算那么客观。如果较真地进行工作量考核，无疑会支付太高的管理成本。因此这种考核方式，往往在坚持了一年左右以后，常常会被很多老板放弃，或者最后沦为形式主义。但如果老板们愿意投入资源来做这个工作，并通过良好的研发体系来帮助完成考核，这种方式也能取得较好的效果。
拍脑袋的方式是国内很多软件公司都在使用的一种方法，这种方法通常行之有效。毕竟谁在干活，谁在偷懒，对于主管来说很容易区别。当然，其弱点也很明显，主观因素太多，可能会导致不少人不服气，最后反而激化了内部的矛盾。毕竟，只有客观的数据才能让人心服口服。如果在这种方法上加入一些奖惩机制以及优胜劣汰的原则，则会加剧这些矛盾和冲突，因此很多公司都比较谨慎使用这些方法，最后导致整个研发团队的效率低下，形成不良的风气。
当然，也有不少修道的老板对于研发管理不闻不问，顺其自然。这种方法基本上靠运气，如果招来的程序员或者主管上进，那么就会比较理想地完成任务。反过来，也就不存在考核的问题了。其实在考核上，员工只希望做出了成绩能有回报，不过程序员的工作是知识性工作，验证起来很难做，因此要达到员工的这个要求并不容易。
给每个程序员打烙印
不容易并不代表不能做到。事实上，还是有不少企业能将考核这件事做好。但是我们看到的所有例子，都不仅仅是企业的研发做得很好，而其他部分的工作却不理想。这是因为企业的研发管理，与企业文化息息相关。
比如前文所说的Google，因为这家公司的每一个员工都深信自己在业界是最好的：拿着最好的待遇，公司有最高的利润，享受最好的福利（比如专用厨师），同事是业界最优秀的（比如Internet的发明人），他们就应该是最好的。一旦在这样的环境下，自己的工作没有做好，比自己的同事差得有些远，就会觉得无地自容，从而激发他们不断用心把每一项工作都做到极致。这种企业文化，深深地烙印在了每一个开发人员心中，再加上一些能够算得上是客观的考核，形成了凝聚力很强的团队。
另外还有一些不同的文化也能促进团队的凝聚和效率发挥。比如马云在阿里巴巴推行的“六脉神剑”，从考核机制上也一定程度地调动了程序员的积极性。而其企业文化本身所崇尚的无隔阂交流（在阿里巴巴完成了一个好项目，主管会被剥光了衣服扔进西湖），让整个团队充满了活力，并形成一种遇到问题，公司内部一致向外的文化。
当然，企业文化是需要积累和沉淀的一种东西。如果学得不像，就有可能会遇到更大的麻烦。这就像学习跆拳道的小朋友在一起，如果一言不合，就拳脚相加，事实上只学到了跆拳道的“形”，没有学到跆拳道尊师重道的“神”。这种例子在国内屡见不鲜， 一些公司原本在国外有良好的传统和文化，一进入中国就变了味。原来大家积极进取的精神，变成了高高在上不可一世的官僚主义，产品和项目的研发自然无法顺利推进。
结语
研发管理是一个很大的话题，一篇短短的文章很难讲完，但是我们却应该关注它。在中国这个市场上，软件利润不高是事实。关注研发管理，同样也是增加软件附加值的一种方式，这种附加值的增加，不仅会为中国的软件企业带来更多利润，同时也让能我们在一个更高的水平竞争。
（本文来自《程序员》杂志0911期CTO专刊）
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/2777/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
Think Different - 从苹果的用户体验说JavaEye的用
WindowsXP下subversion的安装和配置评论列表
