<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></title> 
<link>http://www.jackxiang.com/index.php</link> 
<description><![CDATA[赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除]]></copyright>
<item>
<link>http://www.jackxiang.com/post//</link>
<title><![CDATA[给技术人上的管理课：控制和计划]]></title> 
<author>jack &lt;xdy108@126.com&gt;</author>
<category><![CDATA[WEB2.0]]></category>
<pubDate>Sun, 16 Feb 2014 02:11:27 +0000</pubDate> 
<guid>http://www.jackxiang.com/post//</guid> 
<description>
<![CDATA[ 
	给技术人上的管理课：控制和计划很多名字里面带有“管理”的工作实际上是技术工作，例如服务器管理、资产管理等。还有很多人生生地把真正的管理工作，例如项目管理、运营管理等做成了技术工 作。虽然说技术工作没有什么不好，但把管理工作做成技术工作，意味着把作为管理对象的人看作是只有一系列属性差异，却并无人性和生气的物了。大概没有什么人情愿被这样对待，因此以这样的方式从事管理工作的人大抵会以失败而告终。而技术人在日常工作中，也免不了时不时地要做些管理工作，要尤其避免这种把人看作是物的倾向。管理，永远意味着管理活生生的人。离开了这一点，就谈不上什么管理，无论是否将其冠以管理之名。<br/>在技术一线长年工作的人，往往在上手管理时，感觉莫大的困难。这里面的问题就在于把握不好控制这个环节，具体来说，就是经常会把沟通和传达的内容，从目的变成了手段。<br/>例如，很多人喜欢通过直接阅读全部源代码的方式，对于写代码的程序员实施控制。这样做究竟好不好，值得商榷。但有一些客观规律，却是很难违反。首先，一个人写的代码，另一个人理解起来存在不小障碍；其次，一个人每天能够生产和理解的代码的总量是有个上限的；再次，同样一个功能，实现它的代码可能存在多种思路，而优劣的判断标准不仅失之主观，更是极其复杂的。更重要的是，实现要求的功能，这是目的，而写怎么样的代码来实现该功能，这是手段。很多技术人做管理 的方式，就是简直是替人把工作做掉了。而这么一来，非但被管理者不能因此而领会到底工作之目的何在，而且下一回还是无所适从。你可以把饭喂到别人嘴里，但 是想让人不要饿死的话，最好还是让他感觉饥饿了自己学会怎么吃饭。<br/>这就是为什么有时候，非技术出身又来管理技术人的，反而比科班出身的，效 果还要更好些。因为他们不懂到底为了达到目的，可以采取什么手段，这反倒迫使他们把精力集中在把到底要达成什么目的讲得更清楚、更到位些。被管理者反而对 于采取的手段有了自由空间，把主观能动性发挥了出来。<br/>非技术出身的人来做管理也有问题，但问题不一样了。它变成了由于对于技术不够理解，而不能够很好地定义目的，甚至定义出很可笑的目的来。程序员这个群体里，用于调侃经理不懂技术而闹出的笑话，那是够多的了。所以管理技术人和技术工作的，如 果原先技术不过关的，还是有必要补一补技术课，不过这些是后话。<br/>因此，控制这件事，看起来好像很容易，其实却很难操作。不过，有一条原则却是无论如何都成立的，那就是管理者自己要明确到底目的何在。如果是连自己都不清楚的工作，想把别人置于控制之下，那就几乎完全不可能了。<br/>只自己明确了目的还远远不够，传达到位才是实施控制的关键。如果站得太高或业务不熟，很容易造成传达的偏差和背离，但如果管得事无巨细，结果亦适得其反。那究竟最到位的控制应该是怎样的呢？一个可行的建议，也是几乎百试百灵的建议是：在目的和手段的交界处，落下控制的闸门。比如，如果目的是实现某个功能，而手段是写代码，那么控制的最好尺度就是把所要的功能描述得全面、准确，而把写代码的充分自由交给接受这个任务的程序员；如果目的是大规模改进系统的性能， 而手段是修改配置和服务器参数以及添加资源，那么控制的最好尺度就是把性能改进的指标以及是否达标的评判标准，以及采购预算描述得全面、准确，而把具体的技术和采购任务交给对应的运维和采购部门工作人员去考虑和斟酌。当然，在必要的场合下，也不是绝对不能深入细节，特别是在需要示范和教育的阶段，但如果对于管理有着长期打算，就一定要在某个时间点完全地放手让别人来做事。这就又得出了一个所谓的控制之禅：你什么都想控制吗？那就想方设法把你的目的传达到位，然后彻底地放手吧。<br/>
]]>
</description>
</item><item>
<link>http://www.jackxiang.com/post//#blogcomment</link>
<title><![CDATA[[评论] 给技术人上的管理课：控制和计划]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://www.jackxiang.com/post//#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>