关于南极动物公司的 H 总半夜回复邮件，凌晨上线生产环境这个段子，总是有一些人拉出来说事。弄得好像判断他人是否勤奋，只能是通过这个人凌晨三点是否还在工作来识别一样。先不说 H 总当时是不是在国外，有没有时差这个问题。有几个公司真得把开发、测试、上线这个流程跑通了？没跑通，有几个人敢这么冒冒然上线？冒冒然上线了，有几个人敢白天蒙头睡觉？敢白天蒙头睡觉，有几个公司允许不考勤的……扯远了，拉回来。这篇文章是我去年12月初看到的，当时就想翻译，结果一拖就成了跨年度项目了（我得承认，我偷懒了）。当了很多年的程序员，也做了几年技术管理工作，感觉原文作者的经历还是很有代表性的。至少如果现在还天天忙着用代码行数来判断程序员贡献的领导，可能得评估一下公司的技术、开发工具相关选型是不是还在原始社会了。原文在这里，请翻墙阅读。 ————翻译分隔线———— 你的程序员在勤奋工作，还是在偷懒？ Mike Hadlow 撰写 当人们进行体力劳动时，很容易判断他们是否在努力工作。你可以看到汗流浃背的劳动过程。还可以看到他们工作的结果：砖墙越来越高；地上的洞越来越大。认可并且嘉奖辛勤的劳动绝对是人类最基本的本能，这也是体育运动如此经久不衰的让人着迷的原因之一。但用这种本能的赞赏来面对技术研发的员工时，就成为了一个问题。高效的知识型劳动者经常让人觉得他没有在努力工作。
Tag Archives: 团队
我们要什么样的.NET程序员
外刊IT评论今天抽风，发了很久以前的一篇博文的译文出来：《为什么我们不要.NET程序员》。本文一发，各种口水接踵而至。这篇文章实际上是《CEO Friday: Why we don’t hire .NET programmers》的译文，原文作者在发文后的两天的时间里不断的根据读者反馈对文章进行了更新和补充。但是遗憾的是外刊IT评论却未能翻译完整（不，不，你们不要指望我会翻译剩下的部分，我对此毫无兴趣。），这使得这篇很有闪光点的文章立刻变成了“孰优孰劣”的口水文章了。 看看中文翻译后的评论吧： 有一种人，自己写不出东西，就怪能写出东西的人使用的工具太先进 弱智文章 SB文章，还以为有什么高深的见解，完全是个自以为是的家伙。至多不过是了解了.net之外某一些东西，对自己完全不了解的东西大放厥词还放出优越感来了。 俺作为一名.NET程序员，鉴定结果为，“此文纯属标题党”，一笑而过~~~ 我对留下这些评论的程序员感到悲哀…… 我们的团队也有着大量的.NET工程师，我每天与他们共处。他们中间有聪明的、优秀的、稳重的工程师；也有躁动的、浮夸的、随意的编码人员。他们能够产生符合设计规范和要求的代码和系统；也会在不经意之间向系统引入致命 bug 而导致生产环境的崩溃。他们其实与依赖其他技术架构的程序员并无多大的不同。
[翻译]想要更好的质量？干掉你的QA团队吧。
这是典型的“死Coder责任制”和“QA无用论”合体。大家仁者见仁、智者见智吧。个中道理还是得自己参悟啊！ 原文在此：http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team，原作者是Mike Gualtieri，一位应用开发和部署专家。 ————翻译分割线————
没有大团队——Nothing is big enough!
刚才看到 Fenng 写的这篇博文：大技术团队的危险性。其中的一些东西，确实有一些感触。 维基百科上对于“团队”的定义是这样的（http://zh.wikipedia.org/wiki/%E5%9B%A2%E9%98%9F）： “团队由若干独立成员共同组建，有临时与长期之分。团队要为某一共同目标而奋斗，这需要团队成员贡献各自不同的专业特长。对团队的管理不同于上下级关系的管理，是横向的交流与沟通而不是纵向的命令与服从。” 虽然不是一个十分正式的定义，不过能说明几个问题。 团队不是一个人在战斗。 团队有统一的目标。 团队成员一定有分工。 团队的工作方式是合作的，而不是管制。 团队成员不光可以是个人，还可以是一个紧凑的组织，部门甚至公司。成员间进行平等的沟通、交流，相互支撑最终达到一个确定的、统一的目标。 由于沟通交流是平等的、横向的，那么就意味着任何沟通都是点对点的。当团队成员增加时，沟通的难度也就加大。 听起来有点像早期没有交换设备的点对点电话。在只有2个端点时有1条通信链路，3个端点就增加到3条，4个端点就增加到6条……那么对于一个有 n 个成员的团队，每个团队成员就需要有 n-1 个沟通链路。当沟通链路数足够大时，整个团队的人都在忙着沟通，而不是真正进行工作。当超过临界，沟通链路超过单个成员所能承受的极限时，为了维持团队正常的运作，有一些沟通链路会被忽略。一些工作关系相对疏远的成员不再进行沟通。这时从行政架构上虽然还是一个大团队，但是这个大团队已经不复存在，由若干个自然形成的小团队取而代之。 4-5个人组成了开发小组。4-5个开发小组组成了技术组。技术组、客服、市场……组成了项目组。项目1组、项目2组……组成了项目部……自最终稳定的团队结构是树形的，是分层的。站在每层去看，每层的团队都是小团队。当某一层上的团队开始有大团队出现时必然会有新的层次出现，将大团队重新划分为小团队。 这或许就是“无为而治”的道理吧。 硬是要将这种很有美感的、自然的组织架构重新排布，徒增本不需要的沟通链路，那么团队的结果或许跟瓦沙一样最终沉没。