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