团队协作？记得处理坏苹果.docVIP

团队协作？记得处理“坏苹果” --明阳天下拓展培训 怎样能促使技术团队实现高效、紧密的合作?该如何处理团队中的“坏苹果”?知名技术博客作家、Stack Overflow创始人Jeff Atwood有三十多年的职业编程经验，通过他的切身经历分享，帮助读者成长为高效能程序员。 会议是浪费工作时间的最佳去处 今天你开了多少个会?这个星期呢?这个月呢?再自问一下，那些会议中有多少是值得参加的?如果把相同的时间用在工作上，你又能完成多少事情?我们究竟为什么要开会? 尽管有些会议是不可避免的，甚至是必需的。我们应该以怀疑的态度去看待会议，把它当成是一种降低工作效率的风险。事实上，会议往往只是在浪费宝贵的工作时间。就我而言，我采用以下几个原则，以确保我的会议是真正有用的。 会议绝不该超过一小时，否则应判以死刑 对于任何会议，第一个并且最重要的约束就是时间，因为它在任何公司都是最宝贵的资源。如果你不能把会议限制在大约一个小时内，那一定是有什么事情错得离谱了。你应该首先修正这个错误。可能是会议牵涉了太多的人，也可能是会议讨论的范围太宽泛了，或者就是整体上缺少一个能使会议不偏离轨道的必要的焦点。我不相信有人可以记住在长达几个小时的会议里发生的任何事情。当其他的一切都无法做到时，请至少把会议开得简短些! 每个会议都应该有一个清晰的目标声明 你开会要达到什么目标?你能用简洁的一句话来说明你召集会议的目的吗?我不想推荐你使用“议事日程”和“日程事项”，因为“议事日程”这个词暗示着一个巨大而乏味的分项列表——包含太多事情了!只要确保每个人都很清楚会议的目的，剩下的事自然会水到渠成。 在开会之前预先做好功课 既然你的会议有了一个清晰的目标声明，那么每个与会者都应该提前知道他们将要讨论和分享的内容，并且在走进会议室之前都已做好了准备。只有这样，我们才能把会议控制在一个小时之内。如果你没有预先做好功课，你就不应该参加这个会议。如果没有任何人做功课，那么这个会议就应该被取消。 把会议变成可选的 “强制”的会议是站不住脚的。每一个出现在会议上的人都应该是因为他们想要在那里，或者他们需要在那里。一种让你自己对会议负责的可靠方法就是让每个人自行决定是否要参加你的会议。想象一下举行一次大家都真正想要参加的会议，那一定是因为真的很有用，或者很有趣，或者很娱乐。 在会议结束时概括一下待办事项 假设你的会议从未召开过，会有什么后果呢?如果你诚实地回答“几乎没什么后果”，那么也许你的会议根本就没必要开。任何一个真正有成效的会议都会做一些决定，然后就直接导致某些事情的发生。作为一个负责任的与会者，你应该把你需要做的事情都记录下来，而且为了表明大家的责任心，参加会议的每个人最好在离开会议室之前都概括一下他们的待办事项，这样做对所有人都是有益的! 我们必须认识到会议固有的风险，并且努力使我们必须要开的为数不多的会议开得更有效率。让我们快速干活，少说废话，抓住工作的重点。 处理坏苹果 Robert Mieson发来了个关于项目病理学的故事。 我所在的团队曾经开发过一个基于互联网的职位申请以及筛选系统(客户称之为“职位零售亭”)。我们的团队和客户商定了采用Windows、Apache、 PHP5和ZendFramework来实现这个“职位零售亭”——所有的团队成员都达成了一致意见，除了一个人，我在这里就叫他“Joe”。在整个技术审议阶段，Joe不停地鼓吹采用JavaScript，即便客户很明确地表示他们希望“职位零售亭”的绝大部分实现都采用服务器端技术，并且所有的校验都应该采用服务器端技术来完成。 事实上，客户已经就这个问题签字确认了。然而，这没能阻止Joe鼓吹JavaScript——他的方式还很粗暴。每当我们的项目在前进的道路上遇到点麻烦，Joe就会发表他的长篇大论。他宣扬，如果我们采用了JavaScript来实现这个“职位零售亭”，我们的日子就会轻松很多。Joe会不停地吵吵嚷嚷，说我们如何如何完全做错了，因为我们没有采用JavaScript。他甚至不屑于了解我们实际正在使用的技术。而且每当团队中有人试图温和地把Joe带回到大部队时(通常通过电子邮件的方式)，他就会冲着那个可怜的家伙大发雷霆。以Joe这种力挺 JavaScript到了偏执的程度，他经常会发出诸如“好吧，如果我们用JavaScript来做的话……”之类的评论。他已经令人讨厌到了这种程度，以至于如果他直接退出(或者辞职，或者被解雇)，整个项目组的境况将会更好。 读完这个故事后，我努力克制自己的身体不往前倾。我把手放在下巴下做沉思状，皱着眉头，然后想问问：你们试过用JavaScript吗? Robert认为这是一个关于技术依赖的警示性故事，但我看到了另外的一些东西：一个有问题的团队成员，也就是一个典型的“坏苹果”。如果把一个