团队紧密协作

亦凉 2021-06-24 14:00 458阅读 0赞

**前言**：jeff atwood，百度百科以及维基百科上都没有其简介，他是stack overflow的创始人之一，我是读“陆其明”大牛的博客了解到的，进而就在读《effective programming：高效能程序员的修炼》一书进一步了解作者深邃的思维，我觉得对我个人而言，我很喜欢翻译的文笔，更喜欢作者Jeff给我的启发和感悟，每一节都值得我去深思和学习。

## 不关怎么说，那总是人的错 ##

是啊，不关怎么说，软件开发过程中出现的任何问题，都不能怪罪于技术的原因，都是由人造成的。作者提出了一个我喜欢讨论的问题：“你喜欢你的同事吗？”

恐怕拘泥于我们中国人的礼节和教育，我们都会义不容辞的回答：“既使我不喜欢某一个同事，但我不讨厌他（她）”。但是我能感受到，无论是在以前的公司还是目前的公司，我的确不喜欢一些同事，当然别人可能也不喜欢我。然而我想表达的也是作者的观点：“为什么我不去找到我喜欢的人、尊敬的人、挑战和激励我的人，一起工作呢？”

## 领导需以身作则 ##

很多时候，我们都能听到一个声音，一个公司的企业文化在于其老板，一个团队的执行力在于其组织者。这都是无可厚非的道理，所谓一只羊带领着一群狼无法和一只狼带领着一群羊进行抗衡也有着内在的道理。团队能够得到升华在于要有一个好的领导。

我们很多编程人员在面对他行的人时，总会沉默不语，而一旦面对自己的同行时，往往又夸夸其谈。今天早上我们几个同事还在“秉持”着自己的观点聊了很久，我发现我不是一个实干家，因为很多时候也在耍嘴皮子，弄的是假把戏。我们总是在向别人提供建议的时候滔滔不绝，我们似乎也乐于去指导别人去按照自己的意愿去做，而自己总是在行动上落空。那么这样的我们，又如何能获得别人的信赖呢？

1.  保持谦虚。在融入一个团队的时候，如果不谨言慎行，没有调查出结果之前为了表现自己多么有经验，而妄下断论，最终的结果如果是错误的话，那就倒霉了。
2.  提出建设性的批评时要小心。我承认，我在这方面做得不好，我在面对别人的错误的时候，总是容易冲动，把自己的意见强加在伙伴身上，当然是由于我和团队成员相对熟悉了，如果在融入一个团队时，就要小心了，尽量不要去冒犯他人。
3.  要赢得他人的尊敬，最好是获得实实在在的成绩。我发现这个是真理，我之前总是喜欢把自己喜欢的博文放到我们团队的群里面，然而发现别人并没有很感兴趣，我坚持写博客，把自己在CSDN上取得的成绩在群里炫耀，别人也不感冒，当看到作者这句话的时候，我能够释怀了，只有等自己做出别人无法取得到并且能够证明自己的成绩后，才能赢得别人的尊敬。
4.  百说不如一干。OK，这句话就不用再多做解释了，放之四海而皆准，做一名实干家永远是对的。

如果你希望你的团队能够成为你想要的状态，那么首先就要求自己去做到，自己先遵守规则，如果你的成员做到了，而你并没有做到，OK，低下你高昂的头颅，向他学习。如果你想成为一名好的领导，那么就以身作则，你不能披着“毕姥爷”的外衣去恶意中伤你所属的团队，是吧？！善意的对待别人，别人才有可能对你投桃报李。

## 程序员和系统管理员的黑夜传说 ##

当前我们的团队还小，我个人就同时兼做两个角色，而在之前的公司，分工很明确，一个项目的SVN管理库、系统运行的环境等等都会交由固定职能的人员来管理，我作为开发人员，的确在有的时候很讨厌系统管理员，他们要求我按照各种规定来提交SVN，当然这是对的，但是我们当时没有很好的相处。

## 结对编程和代码评审 ##

对于这个小节，我有的时候感到无力，因为我们的团队从来不曾执行过代码的“结对编程”、“代码评审”。虽然我不认可结对编程，因为那太过可怕，小团队来说简直就是要了命，因为总共就两三个人，如果还要交叉工作，那就等到天荒地老吧。但是代码评审，真的是非常棒的一件事情，然而我们却从来没有执行过，我现在都深深感到遗憾，究竟是什么造成了我们现在这个样子。

我们团队的有一些成员，总是抱怨团队之间缺少“副手”，就是说一旦某人因为一些原因不能正常工作了，其他人对他负责的业务无从下手。我有的时候就是干着急，我曾经提出的代码review，从来都得不到实践。

我很希望我们的团队成员在完成代码的开发后，能够安静的坐下来进行一次代码的review，旁观者去发现讲述者所编写的代码存在的漏洞、不完美的格式、不够简洁的表达方式，还能去理解业务，真是百利而无一害啊，真希望以后我们能够进行代码的评审工作。

## 会议是浪费工作时间的最佳去处 ##

对于会议，我们团队也有很多弊端，开会之前大家毫无准备、会议主题总是不够明确、会议内容散漫无记录、上一个会议的结果从来不落实等等，我不是多么的憎恶自己的团队，从而提出各种锐利的批评，而是内心太希望我们的团队能够凤凰涅槃，浴火重生，在未来呈现出新的面貌，为大家的职业生涯带来价值。

1.  会议绝对不可超过一个小时。虽然我无法断定这是不是一个真理，但是绝对的值得考虑，毕竟漫长的会议会让人沉沉欲睡，并且容易忘记。
2.  每个会议都应该有一个清晰的目标。这当然是必须的，如果会议跑题了，那自然也是失败的。
3.  开会之前做好功课。如果参加一个会议之前，提议者没有充足的准备那很荒谬，而如果旁听者也没有准备，那么在会上就会不知所云。
4.  把会议变成可选的。这个是个好想法，如果与会者对当前主题不感兴趣，OK，就不要去耗费时间了。
5.  在会议结束的时候概括待办事项。这很重要，另外我想追加一个就是“在会议开始之前，回顾上一次会议的执行结果”。

## 处理坏苹果和坏苹果是团队的毒药 ##

所谓千里之堤溃于蚁穴，和作者提出的观点是一致的。如果坏苹果不及时处理，我们都知道，好的苹果也会随之腐烂；而如果坏的苹果遗留在团队之中，就会成为团队的害群之马。

作者提到鉴定坏苹果的警报信号：

*  **他们掩饰自己的无知**。就如同南郭先生一样，他们精于藏匿自己的无知，他们会说“我的代码太复杂了，无法测试”。
 *  **他们对于个人隐私过度在意**。他们害怕别人查看自己的代码，从而不断回避。
 *  **他们在意自己的地盘**。他们不允许别人去修改他们的代码。
 *  **他们抱怨团队做出的决定**。总是认为自己的是对的。
 *  **他们不会积极参与团队的行动**。他们无故请假，找各种借口不参加群体活动。

OK，这个时候，团队领导要做的就是把他撵走吧！

“ 毫无疑问，有坏苹果的团队表现就会很差 。”

我们都知道木桶效应，木桶所能容纳的水量在于最短的挡板而不是最长的。如果团队之中有害群之马，而你无法鉴别出来，OK，那么你就是那个需要被赶走的人。

## 关于远程办公 ##

在这上面，也许我有很多经验之谈，因为之前在江苏富士通，由于是做对日外包项目，自然少不了和在日本的人员进行沟通，那么需要做的无非就是远程越洋电话和视频会议。

作者所说的远程办公，是建立在有相同编程热情的基础上，也是我一直想说的“有自我驱动力”，这不仅仅是在远程协作上，在团队中，同样适用。如果团队成员不是建立在同一愿景下，也没有很强的自我驱动力，团队往往就会落后于他人。

下面作者提到的几个观点，我想我们日常开发也需要类似的做法：

1.  **实时交谈**。如果团队成员不能在步调上保持一致的话，那就让人痛苦了，远程协作的时候尤其重要，因为两人身处异地，交流起来就更加容易被时间阻隔，那么好的及时通信软件很重要的。
2.  **固定的邮件列表**。这个同样适用于我们当前的开发团队，我们的团队分两块，两块的言语和架构不同，大家之间的交流就更少之甚少。虽然我们每个团队小组都有自己清晰的邮件列表，每天都会要求发送工作日报给彼此，但是我们的执行力还不够，需要加强。
3.  **语音和视频聊天**。OK，讲话在一些方面上的确比文字来的直接和痛快。

另外我接下来需要做的流程：

*  **周一的团队报告**：我们上周做了什么？这周准备做什么？有什么阻碍我们前进。这个主题和站立会议差不多，现在说起来都惭愧，说好的站立会议，我们团队也执行的不够。
 *  **会议纪要**：是的，当我们在讨论的时候，必须要把重点内容记录，所谓好记性不如烂笔头，就是这样。