今天在CodingHorrer瞄到一篇发人深省的文章，即使是作为tech leader，如果不为团队成员留出自由犯错的空间，很难构建一个和谐的团队（哎哎，最近政治看多了，满嘴HX，大家海涵~）最近也要抽空补一下团队构建之类的知识，之前（现在的项目也是）摸黑撞墙的经历太多了。
原发表于译言，处那个啥文，大家没事也可以去顶顶~而且那边的排版比这边清爽……有空一定要改theme……
至于为啥一定要没事找事把这篇文章翻出来……考研英语有个题型叫句子翻译的知道吧？不知道？那算了……
文中所提《人件》一书， CSDN有中文版下载，但有人说翻译得惨不忍睹，实际上扫描得也惨不忍睹。仅供参考。
对了，原文下的评论貌似都挺有深度，感兴趣的同学也可以去吼吼。
你在制造微观管理僵尸吗？
你或多或少地管理其他程序员吗？那么做做Kathy Sierra的测验吧:
- 你是否以在项目“顶层”或是你（对BOSS的，译者注）的直接汇报为荣？你是否对每个项目的细节都有可靠的把握？
- 你是否相信你可以完成你作的直接汇报中写的任何任务，甚至有可能完成得更好？
- 你是否以与雇员的频繁交流为荣？这些交流包括向他们索取详细的状态报告与更新吗？
- 你是否认为作为一个管理者意味着你比雇员有更多的知识和技能，并因此更适合作出决定？
- 你是否自认比你的雇员更在意诸如质量、期限等等的东西？
如果你对以上任何一个问题回答了“是”，哪怕是三心二意的“也许吧”，那就意味着你可能正在制造微观管理僵尸。
没错，僵尸，那些除了被命令的事外几乎啥都做不了的自动机器，而且还得有人在严格监视着他们在做什么和怎么去做。对你的工作伙伴进行微观管理，这按理说来恰恰是一个有能力的团队领导者或管理者所完全不应该花费时间去做的。所以如果你确实是在微观管理，哪怕是纤若毫厘的程度，退回一步，仔细而长远地看看，你会发现它是深层次问题的标志。
而且，见鬼了，谁想和僵尸一同工作？你难道不应该努力与那类足够在自己的工作上做出明智决定的人一起工作吗？并且他们也不应该总是吃你的脑细胞吧？呃，我打个比方。
建设团队就像做软件一样，描述什么是不应该做的总是比指出那些无形的使软件开发停滞的东西要容易。不过很明显，微观管理是最大的风险之一。在《人件》里，DeMarco和Lister指出了七个他们称为团队自杀的反模式：
- 防范性管理
- 官僚作风
- 物理隔离
- 员工的时间分割
- 产品的质量要求降低
- 虚张声势的最后期限
- 小团体控制
想知道第一条指的是什么吗？猜对了：微观管理。
如果你是管理者，你会理所当然地认为你的判断比手下的要好。你有更多的经验，对于优秀可能有比他们更高的标准，那可是你作为管理者所必备的。在项目中任何你没有提出自己看法的地方，你的手下都更容易犯错。那并不意味着你不能（偶尔地）改写某个决定，或是对项目提出更细化的指导。但如果员工开始觉得他/她不被允许犯自己的错误，那么你不信任他们的信息会变得明显无比。没有比不信任更能阻碍团队形成的信息了。
大多数管理者都对自已明白何时信任或是不信任他们的手下的能力打高分。但在我们的经验中，有太多的管理员在不信任上犯错。他们遵循着一条基本假设，那就是只要不出错，手下会完全自律地干活。这实际上不是自律了。唯一有意义的自由就是与你的管理者走不同的路线。这在更广阔的范围下也是对的：（在你的管理者或是政府的监视下）做对的权利与自由浑不相关，只有做错的权利才是你自由的标志。
最明显的防范性管理策略是习惯性的方法学（“我的手下太愚蠢，没有我他们做不出系统来”）和管理者的技术干涉。从长远来看，两样都注定失败。另外，它们还是有效的团队自杀手段。感觉不被信任的人很难被纳入一个合作的团队。
最后，这一切说的不就是信任吗？如果你不信任与你一同工作的人，更不用说更重要的一点-积极地在行动中向他们证明你的信任，那么你真的还应该和他们一同工作吗？
“相信你可以完成你作的直接汇报中写的任何任务，甚至有可能完成得更好”，太对了，那要如何避免或改进呢……
都不能一概而论～有人对于指导很依赖的，也有人很烦别人去管他。
@Betty
呃……我觉得那个Quiz和文章观点有点脱节，本来Quiz就是另一个人写的……
@得失
是的，套句百搭的，任何事情都要具体分析……
学校里做项目或是做简单的外包项目，与公司里或是老师项目组里的情况有很大不同，在挑选团队成员时可以只选择那些办事效率很高的，或是和自己很对味的人。对这些本身自律性很好的同事，最好不要逼得太紧，把握大方向就好了，把更多的精力投入到团队精神的构建中更有实效性。
不过这貌似和压力产出定律相反……即条件良好的情况下，高压力获得高产出，反之越紧张情况下，放松压力可以获得高产出……大概员工素质和项目期限不能一概而论吧，不然真把大牛当民工使了。