在Jeff看来,团队里最重要的事情,是人与人之间地协作和沟通!所有的问题,其实都是人的问题。“不管什么问题,那总是人的问题”-温伯格。即,让你和团队陷入困境的最快的方法,就是认为技术是决定性的因素,而且你相信你能轻易解决其它方面的问题。事实上,正是你所认为的“其它方面的问题”,最可能让你和团队止步不前。
这一章里,Jeff主要列举以下几个要点:
1. 领导须以身作则
团队,首先要有的就是纪律,也就是由大家共同讨论协商并决定的标准。每个团队都需要一个领导,带领大家去遵守并有效执行这些标准。以身作则,从以下几个方面树立示范带头作用(有时候也是因为他们没有时间和权力强制其他成员执行,只得“身先士卒”):
a) 保持谦虚,总是先假定你是错的,特别是你在骄傲(这是非常不好地一面)地宣布你的发现之前,你应该努力确保你的观察结果是正确的,以维护你良好的信誉。
b) 提出建设性的批评时要小心,要注意方式方法。开发人员更容易接受非正式的建议和具有巧妙引导性的问题,而不是把同样的内容以电子邮件(或大声吼)的方式发送给整个开发小组。扩大受众面很可能会引起开发者的防御或逆反。团队其它成员会猜测你的动机,如果有人认为你贬低别个,是为了抬高自己,哦,那你就要遭了!
c) 要想赢得信誉和尊敬,最好的方法就是努力工作,并且取得实实在在的成绩。特别是不能“光说不练”,例如群发“最佳实践”、“银弹在这儿”等。如果你想建议什么,你应该为些付出行动,做好充分准备。当然,这并不能保证团队(或部分其他成员)对你的倡议一一呼应,而且还可能徒劳无功,但是团队(或大部分成员)会意识到:你付出了努力,你在积极向前。
d) 要学着在乎别人,真心地去帮助别人。无论是为了激励一些人,还是为了推动项目的前进,团队中的成员始终需要帮助和关心。“我不想别人是因为怜悯面帮助我,我不想别人是因为自私而帮助我,我想要别人对我做的是,真正的爱我--当然不是那种Gay之性情,而是真正的对人性的关怀,让我人心里感受到这份真诚和关爱”。让那些受帮助之人,必须相信你是真的关心他们,事实上你也是这么做的。“黄金准则”适用于此。
黄金准则(Golden Role):一条公正的准则,它引导人们要“像你希望别人如何对待你那样去对待别人”,换句话说,你希望别人如何对待你,你就怎样去对待别人。
2. 程序员与系统管理员应该协作
要确保程序员和系统管理员不把时间花费在内斗上,面要用他们的超自然的能力,一起来完成一个不合作就无法达到的共同目标,派给他们的任务,应该是足够艰巨的--一个需要他们完全组合并使用他们的独特技能才能完成。让每个人都能把精力专注于各自擅长的事情上,一个健康的团队里,每个人都会觉得自己的能力源上了用场,而不是被浪费了。
注:其实,我真没有明白,此处的“系统管理员”到底是什么角色!
3. 结对编程与代码审查
结对编程的优势在于它的即时性:当负责复查的人就坐在你边上的时候,你是不可能忽略他的。大多数人在可以选择的情况下(如事后的代码审查),都会选择息事宁人,但是在结对编程中,是不可能的。结对编程的两个人总是有不同的技能,面这些技能是可以传递的,当一个人向另一个展示一些技巧、精妙的变通方案的时候,这实际上也是一种临时培训。更重要的是,两个都完全了解代码,这对谁(特别是公司)都是一个好处。
代码审查和结对编程有类似之外,作用也有几分相似。当然,一个公司从零开始,建设代码审查制度也是一个痛苦的过程,可能会有很多抱怨,但代码的质量以及可维护性方面,将有巨大的进步和提高。不过,代码审查也依赖于审查人员,有的时候,他们并不愿意“浪费个人时间”在代码审查上,直到某一天他们去维护这段代码,才会收到更多的反馈,甚至是怒气冲冲地抱怨,更甚至他们想推翻重来。“反正不是我的代码,才不管它到底有多臭”!
要保证有超过一双眼睛在看你所写过的代码!
4. 正确对待会议
应当以怀疑的态度去看待会议,把它当成是一种降低工作效率的风险,始终谨记:之所以开会,是因为我们需要它!会议原则参考:
a) 不超过一个小时!否则,我们就要再仔细审核下,是否会议牵涉的人太多了,是否讨论范围太宽范了,是否缺少必要的焦点?
b) 要有一个清晰的目标声明。要确定参会的每个人都很清楚会议的目的。
c) 开会之前预先做好功课。每个与会者都应当提前知道他们将要讨论和分享的内容,并且在走进会议室之前,已经做好了准备。
d) (尽力)把会议变成可选择的。不要“强制”任何人,必须参加这个会议。每一个出现在会议上的人,都应该是因为他们想要站在那里,或者需要他们站在那里。让每个人自行决定,是否需要参加这个会议。
e) 在会议结束时,要概括一下待办事项。会议要有一个专门的会议记录人员,并且,每个人最好在离开会场之前,概括并确认一下他们的待办事项。
让我们少说废话,快速干活,抓住工作重点。
5. 剔除团队的“坏苹果”
如果把一个坏苹果留在一筐好苹果里,结果你将得到一筐坏苹果,这就是“坏苹果”法则。一个人的态度将影响到一个团队,如果想使你的企业成功,那么你必须有一个积极进取的团队。
“坏苹果”会损害其他优秀开发人员的士气,如果团队主管不愿意直接并有效处理这些“坏苹果”,那么这些主管给团队带来的扰乱,比其它任何单方面的团队领导力问题都要严重,他们这是在玩忽职守,应该敢于调走甚至开除这些“坏苹果”。
如何确定“坏苹果”,以下几条仅供参考:
a) 掩饰自己的无知,而不是尽力去向团队其他成员学习。
b) 对个人隐私有着过度的渴望,“我不需要其他人审查我的代码”。
c) 很在意自己的地盘,很在意其他人动他们的代码。”我这几天比较忙,这个问题我(不是你)下周再解决”
d) 抱怨团队所做的决定,并在团队已经继续很久了,还在重拾此话题。
e) 团队其他成员,在讲他的悄悄话或地报怨他。
f) 不积极投入团队活动。
g) 沮丧的悲观主义者,经常说“随便”,“我无所谓”,“不关我的事(我自己加的)”。
当然,有时候,一个特别优秀的领导者,一个有较强沟通能力的人,一个可以四处询问、征求意见的人,同时确保每个人的意见都被认真对待的人,或许可以挽救或降低“坏苹果”所带来的影响。
仔细想想,有的时候,自己就是那个“坏苹果”!
6. 远程办公建议。
a) 只有高手才适合!
b) 要有每周一总结,包括:上周工作总结,本周工作计划,需要处理的问题或需要协调沟通之事项。
c) 详细简洁的会议纪要,参会人?讨论的主题?所做的决定?下一步工作计划?
d) 简单无噪声的邮件列表或BBS。