“只要把任务做完做好就行，为什么我还要考虑自管理这个琐事？” ——这估计是很多管理者在推行“自组织自管理”时被提问的问题。幸好会有人提，憋在心里那就永远解决不了问题。
实际上，“把任务做好”这种结果导向的口号，和自管理的推行并没有冲突。我们用实际的例子来释疑。
老大给了菜鸟一个任务，原话是：你写些东西向新人介绍svn这个工具。
于是菜鸟写了这么一句话：svn是subversion的缩写，它是一个版本控制系统，也就是一种代码管理工具。
从形式上来说，菜鸟是“完美地”完成了老大的任务的，因为老大“貌似”只是要介绍一下。
接下来，新人们开始吐槽：你得教我怎么用啊？？？！！！
老大同意，甚至恼火，跟菜鸟说：你再补上怎么使用它的，就是写个怎么使用svn的教程。
于是菜鸟听话，很认真补上了svn的add、update、commit等所有命令怎么使用，详细到各个子参数的意义。这次菜鸟觉得很自豪，老大肯定满意了吧。
可是新人们又开始吐槽：怎么安装svn呀？我怎么没发现代码仓库管理员该用哪个命令？
于是菜鸟不等老大发话，自觉地加上了svn服务器的安装和操作教程以及svn客户端的安装教程，甚至于客户端教程还把几种客户端（命令行、Tortoise等）都说了一遍，还对多个操作系统下的使用都讲到了。
老大拿到新稿一看，立刻喷起来：杂乱死了，怎么连个目录都没有？排版乱，这一堆命令的描述改成表格，多清晰啊。这么多流程看得我心烦，怎么不画个图呢？
菜鸟郁闷了，感觉老大在刁难他。然后新人们也是这样吐槽的，他无话可说，乖乖照做。后来这个稿子改了十几遍才没人吐槽了。
实际上，老大一开始希望的结果就是菜鸟可以写出没人吐槽的文档，这才是他对这个任务的真正要求，只是他没有说得那么细。菜鸟返工了好多次才算真的把这个任务做好了。
后来，公司转用git替代svn来管理代码。因为人手问题，这回老大还是找菜鸟去写git的培训文档。
不过老大可变聪明了，是这样安排任务的：你去写篇git的培训文档，从服务器搭建和管理到客户端的安装使用说明都尽量详细提到，排版好看，易读易懂，最好别有错别字……
菜鸟心领神会，他也不想重蹈覆辙。在完成老大的超长的任务要求后，他还比老大想到了更多，例如加上了创建分支和合并的规则、分支名字的规范等等。
老大看了自然欣喜，菜鸟终于不是菜鸟了，真正地把任务做“好”了！
后来老大每次去分派任务，都学会一个技巧，把任务描述得非常详细，尽量让办事的人明白做成怎样才符合他的要求，才能叫做好。然而时间一长，老大发现自己没那么多时间去考虑和描述那么多细节，于是想到了推行自管理。
其实自管理的本质，就是让管理者的意志直接埋在大家心里，不再需要千叮万嘱。以例子来说，就是老大给一句很简单的话，你就能意会潜在的要求而不需要过多的嘱咐，甚至于比老大想到的事项更多。
自管理同样是结果导向的，甚至可以说是结果导向发展到高级阶段的产物。因为对结果的要求很多很高，管理者在没精力顾及那么多的情况下，希望大家能从他的角度出发去考虑到那么多东西。
结果导向更通俗地说就是业绩至上，有业绩就自然地升职加薪。然而很多技术领域的管理者都忽略了一点，没解释清楚怎样才算业绩好，更可怕的是他们本身也不懂怎么评估。员工呆在这样的公司，除非自学能力很强，否则很难有什么成长，常得到抱怨公司烂或领导差而离职的结果。
拿程序员的工作来说，“开发好一个模块”的潜台词是：代码具有可读性、易扩展性、高性能、没有bug、做好了单元测试、易懂无误的使用和维护文档……
自管理的结果之一，就是令大家都对“好的结果”的标准产生一致认同并自发地不断完善。这个“令”因为自管理而从“命令”变成“号令”，由认同者自觉执行而无需监管。
转载请注明出处：http://blog.csdn.net/hursing
原文地址：http://blog.csdn.net/hursing/article/details/40208239
