[转] 建设稳定的技术团队

原文链接：http://blog.csdn.net/explant/article/details/7585912

“中国的问题，压倒一切的是需要稳定。没有稳定的环境，什么都搞不成，已经取得的成果也会失掉。”

————邓小平 1989年2月26日

建设稳定的技术团队

 

    团队管理工作的基础是稳定，一个常常处于不稳定状态的团队是无法进行有效管理的，更不用说其绩效的提升和建设。

    目前国内整体环境并不理想。融资渠道的短缺，IT需求长期滞留在初级阶段，跨国软件和互联网巨头对市场的瓜分等都造成IT企业或互联网企业的研发部门长期处于资金紧张的状态。同时，国内劳动保护的滞后，法律维权的高昂成本和愈演愈烈的通货膨胀又使劳动者长期处于紧张的生存状态。以北京而言，如果一名普通IT人员在京买房定居会带来巨大的负担和生存压力。

    压力是把双刃剑，一方面促使我们不断追求进取，另一方面带来极大的不稳定性。长期压力之下，这种不稳定性也会日益明显。在此背景下，一个组织很难以自身力量解决组织内部成员的所有问题。因为组织本身直接承受社会和市场的各种压力。同时，组织通过组织结构和工作流程，将这种压力转移给组织内成员。通过组织有效的劳动，压力转为现金流，从而得到释放。组织成员的工作也就可以被描述为压力的积累和释放的过程。如果无法适时的释放这些压力，必然造成组织成员怠工或逃逸的现象。对于一个以稳定为基础的组织而言周期性释放组织成员的压力是非常重要的。

    组织成员的压力主要表现为几方面：1、生存压力，也就是吃穿住用行等方面，特别是“住”的方面。同时对稳定而安逸的生活的追求也是此类压力来源之一。2、项目进度压力，这也是常见的压力来源之一。由于种种原因，往往是开发周期预估失误、技术难度需求超出开发者能力等，引起项目可预期的延期交付会直接给开发人员带来压力。3、竞争压力。合作和竞争是同时存在的，也是团队内部博弈的结果。这种竞争存在于开发者之间，同时也存在于开发者和其他部门的合作者之间。开发者之间的竞争目的很明确，为了更好的业绩。而开发者和其他部门合作者的竞争，经常表现为某种矛盾，则是为了项目的话语权进而表明自己在项目中的地位来实现自我价值，是开发者对团队认同的需求和自我价值实现的需求。4、组织认同及自我价值体现的的压力。被周围的环境认同，同时对环境施加影响，进而实现自我价值的体现，属于马洛斯需求理论中较高层次的需求。由于IT领域内绝大多数技术人员都是经历过高等教育的知识分子，此类需求而产生的压力比其他行业更为明显。

    组织成员压力的释放是周期性的。释放周期也许，大部分情况下，与项目周期不同。也就是说组织内部压力释放在项目周期内是分阶段的迭代过程。以原型开发模型为例。组织内部压力的释放应该在一次原型迭代之后经行，而非项目结束之后。换言之非迭代过程的线性开发模型，比如瀑布模型，有可能带来过长的释放周期。（在线性开发模型中可以利用里程碑工具建立释放周期。由于其过程强烈依赖于具体环境，本文对此不作具体描述。感兴趣的朋友可以参见拙作《团队的业绩管理》）。

人对于优越的物质生活的追求是无止境的。所以直接的物质奖励无法有效释放组织成员的生存压力，职能暂时缓解。明确的价值交互制度和奖励制度是有效的解决方法之一。我很推崇短期小额加薪的方法，比如每两个月加薪一次，每次额度从几个到几百不等。以3000元薪资水平为例，每两个月增额5%，每次薪资情况如下：

1月	2月	3月	4月	5月	6月	7月	8月	9月	10月	11月	12月	平均
3000	3000	3150	3150	3307	3307	3472	3472	3646	3646	3828	3828	3317

 

    另一种推荐的方法是级别薪资制度。技术人员的发展一般来说分为两条路径。一种是伸向技术领域的专家型发展方向，一种是倾向于管理的技能管理者方向。无论哪种方向，职责级别上都趋向于扁平化。专家型成员可以分为专家、高级工程师，中级工程师，初级工程师等级别；管理者可分为基层管理，中层管理，高层管理等级别。组织成员需要有充分的成长空间，简单的级别划分无法满足这一要求，也就无法有效释放员工压力。级别薪资制度是脱离于职务级别制度之外的体系制度。其分级可以认为设定。以13级薪资制度为例。初级薪资水平设定为a,不同级别段薪资增加幅度不同。随着GDP的增长，每年调整一次基数。

1级	2级	3级	4级	5级	6级	7级	8级	9级	10级	11级	12级	13级
0	500	500	500	500	1000	1000	1000	2000	2000	2000	3000	5000

    在我和团队就此方案经行讨论时，团队成员提出一个问题，多长时间一个1级成员可以成长到13级。我的答案也许有些令人沮丧。这是一个非常长的时间。

    项目进度压力的释放过程是随着开发周期的展开而逐步释放的。所以短的开发周期也就意味着小的进度压力。这也对应着项目管理理论中“小目标”的说法。越是复杂的项目，其时间估计越困难。以HelloWorld为例。对“HelloWorld”这样的小目标，时间估计最简单也最准确。将复杂的工作拆为简单的模块再经行时间评估会提高预估的准确性。拆分的标准为“可识别”。也就是说一个模块小到开发人员可以准确评估其用时的程度。在一个开发周期内，产品需求应该是封闭的。产品需求的变动会打乱原有的计划。需求的变化允许发生在下一个开发周期开始以前。也就意味着一个开发周期不可能太长，大概在两周到一个月之间。在开发周期内，随着对开发计划认知的深入开发机会可能会要求调整。比如原先预估的一个模块会被重新拆分为几个更小的模块。这种问题没有太好的解决办法，只能就具体问题而定。好在此类问题不会带来太多的延误，应该在风险控制的冗余时间范围之内。

    竞争压力往往是正向压力，其产生和释放多依赖于企业文化的建设。职责划分在鼓励竞争的企业文化中只是指明某个职位应该做什么或大部分时间做什么，而不是规定只能做什么。比如技术人员负责产品实现，但绝不是说技术人员只能做产品实现，对其设计、运营等方面无发言权。我推荐以产品为核心，以技术为导向。以产品为核心不是说以产品人员为核心。相反的，往往以技术为导向的企业，其市场表现更好。

    组织认同及自我价值体现的的压力可以利用升职、升级、任务分配等多方面释放。此类压力最终释放于自我的满足感。

    另一个团队不稳定的因素是缺乏流动性。一个缺乏流动性的团队会应为缺乏新生力量和内部压力不足而逐步僵化。设想一下，一个呆在自己位子上十年如一日的初级程序员对组织有什么好处呢？对于小型团队，保持5%左右的流动性是好的。解雇组织内成员其作用是复杂的。建立一个富有弹性的淘汰制度是必要的。团队扩张也是必要的，但是人才筛选需要严格把关。