软件工程-三 团队缺乏的不只是管理

团队:

团队至少是以三个人为规模的。这有其合理性。为什么呢？首先一个人算不得团队，那是个体。两个人则互相支撑，古文中“从”字是二人互立，就是这个意思。然而二人互立并不算团队，因为没有监督。三个人便可以构成团队，这样便有了团队的一些基本特性：主从、监督和责任。

做管理起码要能承担责任，这是最基本的素质。

同样的道理，你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？

项目完成不了，递交辞呈的那点勇气总是要有的。

做项目:

项目做不成就要掉脑袋，就好比枕着铡刀做程序；如果项目失败就要交辞呈，那可能就从来不会有项目经理。

经验丰富的工程师能尽可能接近地预估工期，但没有办法保证（预估的）工期是绝对合理的

由于没有绝对合理的工期，所以项目的完成时间可能总是被进度变更所修正，所以项目也就总是不能“成功”。

项目工期的问题不能解决，就不能保证项目成功。只有经验更加丰富，才更有可能逼近“合理的工期”。因此在这之前，项目经理面临的就是失败。这个失败可能不是由项目经理本身的能力所决定，或者也不是由团队成员的工作所决定，而是在一开始，那份给客户的项目协议就签错了。

项目经理是需要时间来成熟的。他需要机会来承受错误，而不是一开始就享受成功。

体制:

体制的内涵是分两个方面的，其一是“体”，即“体系”；其二是“制”，即“制度”。“ISO质量体系”所产生的那份手册只是“制度”。在这份制度的背后，所要求的是对旧有“体系”的改变——旧的公司转型到新的公司，不是搬来一本“管理制度”给每个员工读一遍就可以了的。

在这一转型期，第一要务是解决“体”——也就是“组织机构建设”的问题。如果把这个问题缩小到开发部门的工程环节，那就是“如何组织开发团队”。只有有了确定的团队模式，才能寻求相应的管理制度，并且才能把这样的制度实施在团队之上。

制度:

如果员工在工作中出了纰漏，那么：

• 没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失；
• 有了制度而没有惩戒他，是执行者和监督者的过失；
• 一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质问题了。

因此，先做制度总是好的。至少在选择做伏剑自刎的李离之前，你还有机会把黑锅扔到出问题的员工头上。

对于一个已经规范管理、体制健全的公司，不容许员工犯错是对的。即使是一次犯错，立即开除也说得过去。但还得是有前提的，这至少包括：

1. 员工已经接受过相关的培训，至少是员工规范和技术技能的学习；
2. 在该员工之前，相同的或者相关的错误没有被枉纵。

第一条是人性化的体现。中国人常说不知者不为过：员工不知道，管理者也没有给他知道的条件，那怎么能说是他的过错呢？如果是因为不知道而出了问题，那管理者首先应该自省才是。

第二条则是公平性的体现。不管是针对谁，制度都是一样的，没有情面可讲的，常说的“特殊情况特殊处理”在制度面前行不通。规矩一旦被破坏就形同虚设，反而被员工当做笑柄，用来类比其他的制度。如此一来，整个制度也就离崩溃不远了。反过来，在已经被破坏了的制度面前，若再做杀鸡儆猴状，那猴子是被吓着了，不平声、怨愤声也就跟着出来了。

因此最好的方法是赶紧修订制度，而不是修理人。

所以，在更加普遍的情况中，动摇了制度的人往往不是犯错的员工，而是管理者自己。

组织-角色:

在整个系统里面，有没有这样的人：他既不归任何人管理，也不管理任何人。如果有，那么就早早把他开掉好了。

但是，在你做这件事之前，确切地说是在任何错误被归咎于员工之前，管理者应该先想想是不是自己的问题。

是的。你可能很快就发现问题出在了管理者那里。因为管理者没有确定组织机构模式，或者没有为组织中的成员进行角色定位和分工。如果这样，出现“既不能令，又不受命”的人就是必然的了。

同样的道理，在工程开始“做”之前就得先把“角色”确定好——可能部分角色是与既已存在的组织机构相关的，例如“部门经理”和“开发人员”；而有些就需要临时授命。

在保障这样一个组织机构模式的过程中，以下几点内容是需要注意的：

• 如果项目针对直接客户，而且没有产品化的可能性（或必要性），那么可以将与市场（以及市场部门）相关的问题和角色先放在一边。
• 已经存在于开发团队中的成员，不适合在品质部门中兼任角色。
• （在这个模型里）项目经理应致力于减少团队中开发角色与其他部门的沟通，必要时开发经理应该站在开发人员之前进行部门间的交互。
• 品质部门、文档和培训部门以及客服部门应该主要由专职人员构成，尽管开发人员可以（或者经常会）参与文档、培训和客服工作，但这也通常是他们最不能胜任的角色。
• 这是中小型规模的公司和团队的参考组织机构模型，对大型团队并不适用。

在这个模型中，我们仍然看到了一个至少由三个人构成的团队。其中，在开发经理和开发人员之间，既存在主从关系，也存在协作关系。而项目经理，则在团队中处于领导者、组织者和团队保障者的地位。

如果非要精简到两个角色的团队模式，那么通常是开发经理兼任项目经理。因此这位开发经理一定要能清楚地区分这种双重角色的身份：在任何时候，明确自己是在进行“团队内协作”，还是“团队管理（和组织）”，还是在与“团队外交流”。

如果这个开发经理总是混淆自己的角色，那么，我建议，换人吧。

开发经理:

禀性难移，要改变一个人都难，何况是改变一个团队的既定习惯。

如果有一群开发人员像蚂蚁一样辛勒地工作着，那么，请先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析这个规律的价值，最后再尝试改变他们（的一些负面价值的规律）。

所以你要紧紧地跟随他们——除了一个地方。那地方是你去不得的，那就是蚂蚁洞。

显然，你不是开发者，你是管理人员。所以尽管你也是团队中的角色，但千万记得离蚂蚁洞远点。你在洞外张望，可以发现问题；你在洞内，就只有做“循规蹈矩”的蚂蚁。

管理者是那个可以在洞外放木棍的人。

管理-分工:

在分工之前，那个团队只能算是一个没有组织与合作的群体，所以英文中群是Group，而开发团队是Team。

弹性分工。每一个人都被要求做一颗革命的螺丝钉，哪里需要哪里拧。所以弹性分工总是被放在企业节省人力资本的第一要务上

确定被“弹性分工”的员工需要可以快速地转换到新的角色。但首先要考察的并不是他是否“有能力”胜任这个角色：能力可以通过学习来增强，而角色的转换，则首先是思想的转换。

尽管弹性分工非常有效，然而真正做弹性分工却并非易事。因而更应当留意团队成员“自激”式的角色转换，知道他是不是真的想（而不是需要）转变一下角色。

更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常是极具风险的，例如项目经理或者开发经理；频繁的开发人员的调度也会直接影响到工程的质量和进度。

明确分工是你的管理职责。做管理≠做伯乐。

大道至简：软件工程实践者的思想 第三章 团队缺乏的不只是管理