<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Tony Bai &#187; 管理</title>
	<atom:link href="http://tonybai.com/tag/%e7%ae%a1%e7%90%86/feed/" rel="self" type="application/rss+xml" />
	<link>https://tonybai.com</link>
	<description>一个程序员的心路历程</description>
	<lastBuildDate>Mon, 08 Jun 2026 23:32:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>说说执行力</title>
		<link>https://tonybai.com/2014/03/05/thought-on-executive-power/</link>
		<comments>https://tonybai.com/2014/03/05/thought-on-executive-power/#comments</comments>
		<pubDate>Tue, 04 Mar 2014 17:57:16 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[FaceBook]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[制度]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[团队]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[执行力]]></category>
		<category><![CDATA[流程]]></category>
		<category><![CDATA[生活]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[管理者]]></category>
		<category><![CDATA[纸牌屋]]></category>
		<category><![CDATA[锡恩4R]]></category>
		<category><![CDATA[领导力]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1491</guid>
		<description><![CDATA[You are never to dictate what I can and can not do. The only two words I want to hear from you when I ask you to do something are &#34;Yes&#34; and &#34;Sir&#34;。（我能做什么不能做什么，你管不着。我吩咐你做事的时候，只想听到两个词，&#34;是的&#34;和&#34;先生&#34;。） &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; [...]]]></description>
			<content:encoded><![CDATA[<p><i>You are never to dictate what I can and can not do. The only two words I want to hear from you when I ask you to do something are &quot;Yes&quot; and &quot;Sir&quot;。（我能做什么不能做什么，你管不着。我吩咐你做事的时候，只想听到两个词，&quot;是的&quot;和&quot;先生&quot;。）<br />
	&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &#8211; 《纸牌屋》第一季</i></p>
<p>想必大家都基本认同：最有执行力的团队莫过于军队。军队有纪律约束，有荣誉感引导。在战时，违抗命令者是可以被直接拉出去枪毙的（影视剧中^_^）。但在 现实中你的团队里，你行么？别说枪毙，说了一句刺耳的批评的话，都可能招来各种不合作。大多数工作并非金饭碗，Google , FB的员工还经常跳来跳去呢，&ldquo;此处不留爷，自有留爷处&rdquo;才是硬道理。</p>
<p>那我们靠什么保证团队执行力呢？</p>
<p>靠NB人士？也许可行。但看看你的荷包，金子够么？NB人士属于金字塔顶端，数量稀少，价格昂贵，且多聚集在国内外知名名企。对于普通企业来说，操作起来有极大困难。<br />
	大把金钱奖励？我们不是土豪，没有挥金如土的气魄，钱不是不可以给，但要用在刀刃上。<br />
	精神鼓励？可以用，但不能一直用，否则下面就要说你是&ldquo;精神病&rdquo;了。</p>
<p>回归本源，执行力是建立在员工的职业操守上的。在这样一个前提下，我们至少要做好三件事来保证执行力。</p>
<p><b>1、明确责任</b><br />
	让员工确定、一定以及肯定的明确这件事/这些事的责任人就是他/她。做好了获奖，做少了、做错了、做砸了，他就是&ldquo;罪魁祸首&rdquo;。</p>
<p><b>2、设立检查点</b><br />
	为了帮助员工工作在正确的方向上，不走偏，不做错，不漏做，我们要帮助员工建立好检查点，明确告知检查点所有内容。在检查点上有针对性的检查也是员工的责任之一。</p>
<p><b>3、频繁反馈</b><br />
	团队负责人应该像老妈子似的不断的催促和获取反馈，以即时把握执行力的真实情况。</p>
<p>锡恩的4R执行力理论还强调了一个&ldquo;即时奖励&rdquo;，<b>强化</b>任务执行与后果之间的关系，让员工第一时间感受到良好执行带来的成果，获得成就感和认同。</p>
<p>接下来就要将以上三件事耐心的变成制度、变成流程，耐心地让员工按流程要求工作而不是按负责人的指令行事。</p>
<p>最后将以上流程自动化。通过系统分配任务，通过任务单将任务相关的信息整合在一起，为执行者提供帮助。通过这样的一个系统排除管理者的人肉提醒、减少在以 上环节中的人为疏漏（比如缺少检查点，忘记反馈），尽可能排除人的惰性、忘性等带来的种种执行问题。通过系统为任务执行作出评价，可作为员工绩效的参考。</p>
<p>通过以上的措施，还可以很好的应对&ldquo;熟人文化&rdquo;：不是按某人的指令，而是&ldquo;制度规程&rdquo;去做事，按照执行力系统的分配、提醒和通知去执行、去反馈。</p>
<p>这样一来，管理者也可以从繁重的&ldquo;人肉管理&rdquo;中脱离出来，既可以通过系统众览全局进度，保证任务的按时正确执行，也可以将精力更多的倾注在其他重要方面的工作中。</p>
<p style='text-align:left'>&copy; 2014, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2014/03/05/thought-on-executive-power/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>关于2014团队改善的考量</title>
		<link>https://tonybai.com/2014/03/03/considerations-on-team-improved-in-2014/</link>
		<comments>https://tonybai.com/2014/03/03/considerations-on-team-improved-in-2014/#comments</comments>
		<pubDate>Sun, 02 Mar 2014 21:11:31 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[团队]]></category>
		<category><![CDATA[导演]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[改革]]></category>
		<category><![CDATA[深水区]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[纸牌屋]]></category>
		<category><![CDATA[过程改善]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1483</guid>
		<description><![CDATA[一个人的品行，不取决于这人如何享受胜利，而在于这人如何忍受失败。 &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;&#160; &#8212; 《纸牌屋》第一季 团队改善，不是那种很快见到成果或者效益的活儿。 但这件事你做不做呢？坦诚的说，今年我在这方面的&#8220;热情&#8221;真的不是那么高，肯定是不如前两年了，因为是时候更多地为自己的&#8220;前途&#8221;考虑考虑了。团队改善这 种活儿做好了还行，做坏了，那就成为&#8220;把柄&#8221;，成为劣迹。投入了资源，却不见成果。因为领导层可能从来都没有让你去做什么改变，也不关心你要做什么改变。 只要把领导认为要做的事情做好即可。做团队改善这事儿，纯属自己给自己加的&#8220;私活儿&#8221;：长路漫漫，遍地荆棘，费力还不一定讨好。 但身在其位，团队没有任何改善或进步不是我的风格，因此2014年，这事儿还要继续做，并且更难做。用现在一个时髦的词来形容，好比进入了&#8220;深水区&#8221;。 改善的初衷是总是好的，但在实际操作中也有可能带来负面的影响，比如因流程变化或工具切换导致的一时的效率下降。人都是不习惯于变化的，并且改变可能会触 动某些人的利益，因此阻力可想而知。从全局来看，这又是必须去做的事情。总之改善的道路坎坷，顶住压力是必须的。有些时候压力更多是来自于上面。当领导问 如果失败了谁负责，这时你应该毫不犹豫的说：我负责。没有别的选择，这就是改变带来的代价，&#8221;我不入地狱谁入地狱呢&#8220;。 我理想中的团队应该是一部精密的机器，开机后不用管的，自运行的，并生产出正确让人满意的成果。我的目标就是搭建出这样一部机器，在生产过程中尽量降低人 的因素的影响：比如惰性、忘性、马虎、态度不端正等对成果物质量的影响。我们还要在&#8220;关键环节&#8221;加入&#8220;自动&#8221;地检查，就像传统工厂的质检环节那样，这些 &#8220;检查&#8221;环节让低质量的成果无法通过。通过这些环节，你还可以全盘掌握产品的生产和质量情况。 而我就是幕后的那个&#8220;导演&#8221;。我发现自己越来越喜欢&#8220;导演&#8221;这一角色了。策划着这一切，看到一切都按照你的思路一步一步的进行下去的。导演决定了是否能拍出好片子，即便演员不一定都是大腕儿。 有同事建议我能针对一些改善措施和想法做些宣讲。我回绝了。因为大家都是那种喜欢看到结果的，在结果未出来之前，还是多做少说。这样也可以避免外界干扰你 的做事思路。另外没有两个团队面对的情况是一模一样的，也就没有一致的改善的方法，有些事情不能代劳。自己发现的问题才真实，才接地气。 坚持你认为正确的事情，坚定的做下去就是了，其他的都抛到脑后。 &#169; 2014, bigwhite. 版权所有.]]></description>
			<content:encoded><![CDATA[<p><i>一个人的品行，不取决于这人如何享受胜利，而在于这人如何忍受失败。<br />
	&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &#8212; 《纸牌屋》第一季</i></p>
<p>团队改善，不是那种很快见到成果或者效益的活儿。</p>
<p>但这件事你做不做呢？坦诚的说，今年我在这方面的&ldquo;热情&rdquo;真的不是那么高，肯定是不如前两年了，因为是时候更多地为自己的&ldquo;前途&rdquo;考虑考虑了。团队改善这 种活儿做好了还行，做坏了，那就成为&ldquo;把柄&rdquo;，成为劣迹。投入了资源，却不见成果。因为领导层可能从来都没有让你去做什么改变，也不关心你要做什么改变。 只要把领导认为要做的事情做好即可。做团队改善这事儿，纯属自己给自己加的&ldquo;私活儿&rdquo;：长路漫漫，遍地荆棘，费力还不一定讨好。</p>
<p>但身在其位，团队没有任何改善或进步不是我的风格，因此2014年，这事儿还要继续做，并且更难做。用现在一个时髦的词来形容，好比进入了&ldquo;深水区&rdquo;。</p>
<p>改善的初衷是总是好的，但在实际操作中也有可能带来负面的影响，比如因流程变化或工具切换导致的一时的效率下降。人都是不习惯于变化的，并且改变可能会触 动某些人的利益，因此阻力可想而知。从全局来看，这又是必须去做的事情。总之改善的道路坎坷，顶住压力是必须的。有些时候压力更多是来自于上面。当领导问 如果失败了谁负责，这时你应该毫不犹豫的说：我负责。没有别的选择，这就是改变带来的代价，&rdquo;我不入地狱谁入地狱呢&ldquo;。</p>
<p>我理想中的团队应该是一部精密的机器，开机后不用管的，自运行的，并生产出正确让人满意的成果。我的目标就是搭建出这样一部机器，在生产过程中尽量降低人 的因素的影响：比如惰性、忘性、马虎、态度不端正等对成果物质量的影响。我们还要在&ldquo;关键环节&rdquo;加入&ldquo;自动&rdquo;地检查，就像传统工厂的质检环节那样，这些 &ldquo;检查&rdquo;环节让低质量的成果无法通过。通过这些环节，你还可以全盘掌握产品的生产和质量情况。</p>
<p>而我就是幕后的那个&ldquo;导演&rdquo;。我发现自己越来越喜欢&ldquo;导演&rdquo;这一角色了。策划着这一切，看到一切都按照你的思路一步一步的进行下去的。导演决定了是否能拍出好片子，即便演员不一定都是大腕儿。</p>
<p>有同事建议我能针对一些改善措施和想法做些宣讲。我回绝了。因为大家都是那种喜欢看到结果的，在结果未出来之前，还是多做少说。这样也可以避免外界干扰你 的做事思路。另外没有两个团队面对的情况是一模一样的，也就没有一致的改善的方法，有些事情不能代劳。自己发现的问题才真实，才接地气。</p>
<p>坚持你认为正确的事情，坚定的做下去就是了，其他的都抛到脑后。</p>
<p style='text-align:left'>&copy; 2014, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2014/03/03/considerations-on-team-improved-in-2014/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>厨房里的领导课</title>
		<link>https://tonybai.com/2014/02/18/mentoring-in-the-kitchen/</link>
		<comments>https://tonybai.com/2014/02/18/mentoring-in-the-kitchen/#comments</comments>
		<pubDate>Tue, 18 Feb 2014 11:02:32 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[创新]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[厨艺]]></category>
		<category><![CDATA[团队]]></category>
		<category><![CDATA[基础设施]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[生活]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[项目管理]]></category>
		<category><![CDATA[领导力]]></category>
		<category><![CDATA[领导课]]></category>
		<category><![CDATA[食材]]></category>
		<category><![CDATA[饮食]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1480</guid>
		<description><![CDATA[生活中永远不缺少大道理，缺的是一颗善于思考和发现它们的心。 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; &#8211; Tony Bai 晚上回到家，家人端上来热腾腾的饭菜。吃了几口，感觉味道较为普通。盘子里那些被加工过的食材是昨天刚刚买到的，又好又新鲜。顿然一种可惜的赶脚油然而 生。为什么这么上好新鲜的食材经过家人的烹制就变得这么普通了呢，仅仅是变成了充饥之用。而这些食材在大厨手下却能妙笔生花，做出让人流连忘返的精美菜 肴。我不是很懂厨艺，但总觉的大厨烹制菜肴的过程与领导团队做一个项目或开发一款产品有着相似的内涵。小小厨房中蕴含着某些大道理，值得我在这里深思一番。 * 角色定义 既然将大厨烹制菜肴比作领导团队做事，那么我们先来熟悉一下厨房里的各个角色： &#160;&#160;&#160; 厨房 &#8211; 工作间 &#160;&#160;&#160; 厨子 &#8211; Leader &#160;&#160;&#160; 食材、调料 &#8211; 团队成员 &#160;&#160;&#160; 厨房用品 &#8211; 基础设施 &#160;&#160;&#160; 食客&#160; &#8211; 使用者，客户 &#160;&#160;&#160; 营养、口感、档次 &#8211; 主要Feature &#160;&#160;&#160; 味道 &#8211; 用户体验 &#160;&#160;&#160; 任务目标 &#8211; 制作一道色香味俱佳的菜肴。 &#160; * 好厨善选材 选材是作出上好菜肴的关键。好厨都是善选材的，就好比好领导知道应该选择什么样的组员加入团队。 主食材（团队主力）决定菜肴的基本品质，比如：档次、外观、营养、口味等。 选择食材要主次分明，相辅相成。有红花争艳，也要有绿叶陪衬，否则烧成的菜品就会内斗严重，主次不明，类别不清，让人迷惑。 选择食材切忌相声相克。一旦这样，很可能会彻底毁掉这道菜。即便做成，也可能给食客带来损害。 调料，好比美工、前端设计师，专攻用户体验。虽然主食材实现了菜肴的核心营养和口感（核心Feature），但如果没有调料的作用，就缺少了味道这一决定性的用户体验。没有好的用户体验，结果一样是失败，至少产品或结果算不上一流。 * 火候儿甚重要 大厨的另外一个特长就是对烹饪过程中火候的把握极其到位。对于不同菜肴，不同食材，大厨会选择不同的火候烹制，让食材保持最佳状态，适当吸收汤汁味道。用 错了火候，将是灾难性的。本该用文火慢炖入味的，却用了旺火，结果食不入味，对食客来说毫无吸引力；本来用旺火快速炒制的，却用了文武火，导致菜肴制作时 [...]]]></description>
			<content:encoded><![CDATA[<p><i>生活中永远不缺少大道理，缺的是一颗善于思考和发现它们的心。<br />
	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#8211; Tony Bai</i></p>
<p><span style="line-height: 1.6em;">晚上回到家，家人端上来热腾腾的饭菜。吃了几口，感觉味道较为普通。盘子里那些被加工过的食材是昨天刚刚买到的，又好又新鲜。顿然一种可惜的赶脚油然而 生。为什么这么上好新鲜的食材经过家人的烹制就变得这么普通了呢，仅仅是变成了充饥之用。而这些食材在大厨手下却能妙笔生花，做出让人流连忘返的精美菜 肴。我不是很懂厨艺，但总觉的大厨烹制菜肴的过程与</span><b style="line-height: 1.6em;">领导</b><span style="line-height: 1.6em;">团队做一个项目或开发一款产品有着相似的内涵。小小厨房中蕴含着某些大道理，值得我在这里深思一番。</span></p>
<p><b>* 角色定义</b></p>
<p>既然将大厨烹制菜肴比作领导团队做事，那么我们先来熟悉一下厨房里的各个角色：</p>
<p>&nbsp;&nbsp;&nbsp; 厨房 &#8211; 工作间<br />
	&nbsp;&nbsp;&nbsp; 厨子 &#8211; Leader<br />
	&nbsp;&nbsp;&nbsp; 食材、调料 &#8211; 团队成员<br />
	&nbsp;&nbsp;&nbsp; 厨房用品 &#8211; 基础设施<br />
	&nbsp;&nbsp;&nbsp; 食客&nbsp; &#8211; 使用者，客户<br />
	&nbsp;&nbsp;&nbsp; 营养、口感、档次 &#8211; 主要Feature<br />
	&nbsp;&nbsp;&nbsp; 味道 &#8211; 用户体验</p>
<p>&nbsp;&nbsp;&nbsp; 任务目标 &#8211; 制作一道色香味俱佳的菜肴。<br />
	&nbsp;</p>
<p><b>* 好厨善选材</b></p>
<p>选材是作出上好菜肴的关键。好厨都是善选材的，就好比好领导知道应该选择什么样的组员加入团队。</p>
<p>主食材（团队主力）决定菜肴的基本品质，比如：<b>档次</b>、外观、营养、口味等。</p>
<p>选择食材要主次分明，相辅相成。有红花争艳，也要有绿叶陪衬，否则烧成的菜品就会内斗严重，主次不明，类别不清，让人迷惑。</p>
<p>选择食材切忌相声相克。一旦这样，很可能会彻底毁掉这道菜。即便做成，也可能给食客带来损害。</p>
<p>调料，好比美工、前端设计师，专攻用户体验。虽然主食材实现了菜肴的核心营养和口感（核心Feature），但如果没有调料的作用，就缺少了味道这一决定性的<b>用户体验</b>。没有好的用户体验，结果一样是失败，至少产品或结果算不上一流。</p>
<p><b>* 火候儿甚重要</b></p>
<p>大厨的另外一个特长就是对烹饪过程中火候的把握极其到位。对于不同菜肴，不同食材，大厨会选择不同的火候烹制，让食材保持最佳状态，适当吸收汤汁味道。用 错了火候，将是灾难性的。本该用文火慢炖入味的，却用了旺火，结果食不入味，对食客来说毫无吸引力；本来用旺火快速炒制的，却用了文武火，导致菜肴制作时 间较长，营养成分流失。滥用火候甚至可能将食材烧焦烧糊，使得菜肴制作彻底失败。</p>
<p>这就好比团队Leader对团队工作节奏、进度以及压力的控制，要让团队成员在适宜的环境下发挥出最大的潜力、进行最高效的工作。过大的压力，过紧的进度都可能会压跨团队，无法达成团队目标。</p>
<p><b>* 装备，装备，事半功倍</b>！</p>
<p>厨子烹制佳肴离不开厨房用具，虽说厨房用具的好坏对于菜肴的最终烹制结果不起决定性的作用，但精良全面的厨房用具会使得大厨烹制菜肴的过程事半功倍。</p>
<p>从古至今均有美酒佳肴，但非要论一下到底什么时候的菜更好吃，相信没人能给出结论，也许古代人做的菜更好吃也不一定。但能够确定的是现代大厨所使用的厨具 肯定要比古代人更加齐全和精良，这使得现代人可以快速制作出大量精美的菜肴，可以在一定程度上缩短了菜肴制作的周期。通过这些现代化的厨具，可以更加精确 量化菜肴的营养成分，也可以将菜肴的制作工序程式化，以供复用。</p>
<p>另外不同的厨师团队使用的装备各有不同，无所谓新老，找到最适宜的才是最好。</p>
<p><b>* 厨房里的创新</b></p>
<p>中华饮食文化源远流长，创新菜品层出不穷。从厨师的角度来看，这些创新无非是创新的食材、创新的调料以及创新的烹制方法。映射的团队管理来看，领导者应善于引进创新的人才，并敢于进行组织、管理以及过程方法创新，这样才能有创新的产品、创新的文化和氛围。</p>
<p style='text-align:left'>&copy; 2014, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2014/02/18/mentoring-in-the-kitchen/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>我的工作原则2</title>
		<link>https://tonybai.com/2013/09/03/my-personal-work-principles-2/</link>
		<comments>https://tonybai.com/2013/09/03/my-personal-work-principles-2/#comments</comments>
		<pubDate>Tue, 03 Sep 2013 15:12:02 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[innovation]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[企业文化]]></category>
		<category><![CDATA[创新]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[团队]]></category>
		<category><![CDATA[基因]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[工作原则]]></category>
		<category><![CDATA[微创新]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[授权]]></category>
		<category><![CDATA[效率]]></category>
		<category><![CDATA[痛点]]></category>
		<category><![CDATA[知识库]]></category>
		<category><![CDATA[知识管理]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[组织]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1389</guid>
		<description><![CDATA[自我认知是循序渐进的，体会到了，就想将其整理出来，给自己一个交代。 &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160; - Tony Bai 关于我的工作原则，感觉之前的那篇总结的还不够，这两天通过观察自己的所言所行，又有了些思绪，这里记录下来。 * 重塑标准 简单来说就是根据组织实际情况，重新建立各种标准 &#8211; 技术标准、人员标准和产品标准。 个人认为这恰是一种实事求是的积极态度。避免陷入技术泥潭中无法自拔，不用Google的人才和做事标准来要求组织内部的人和招聘新人上，认识到存在的差 距。恰如当年钱学森根据国内人力、物力以及实际技术水准重新制定了标准，而不是照搬美国的标准，否则造导弹就会变成一个不可能完成的任务，对团队 士气也将会是一个极大的打击。 * 问题理解要透彻 很多时候，干完了才知道白干了，这往往缘于起初对问题理解的不够透彻，没有抓住焦点，导致Solution不是最合适的，引发不必要的返工。但很 多问题往往无法一次性透彻地理解，这就需要在工作方法上有所调整，以尽可能少的工作消耗去理解和摸索，对工作内容进行阶段性的反思和重构。这样在 1.0, 2.0以及3.0等后续版本的演进过程中，你会发现问题将变得逐渐清晰，焦点也会越来越清楚。而一旦问题被看透，最正确的Solution自然就会在大脑 中形成。 * &#8220;眼见为实&#8221;还不够 俗语讲：眼见为实。但在工作中，有些时候&#8220;眼见为实&#8221;还不够，因为很多时候眼中看到的是假象，这在调试和查找技术问题时显得尤为突出。无数次的问 题调查告诉我：始终要保持头脑清醒和逻辑清晰，不能人云亦云，不能轻易相信亲眼所见的&#8220;事实&#8221;。要追求逻辑的全局合理性，一丝的不 合理都要刨根问底，不遗漏任何蛛丝马迹。 * 把事情做在前面 以推进知识管理为例，在发布知识库之前就应该把发布后可能遇到的各种问题、阻碍想清楚，提前就这些可能的问题给出方法、答案的指导或以Q&#38;A的形 式与知识库一并发布。这些要做在前面的事情包括几类：解放思想的（帮助大家突破原有思维禁锢）、最佳实践的（告知以何种方式去做收到的效果最好）、基本知 识技巧普及的（以大家最易接受的方式对基本知识技巧做出诠释）、服务运维的（还以知识库为例，发布后，你要始终保证其运行稳定可靠，不能让其他人操心于此 事）等。&#160; &#169; 2013, bigwhite. 版权所有.]]></description>
			<content:encoded><![CDATA[<p><i>自我认知是循序渐进的，体会到了，就想将其整理出来，给自己一个交代。</i><br />
	&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <i>- Tony Bai</i></p>
<p>关于我的工作原则，感觉之前的<a href="http://tonybai.com/2013/08/19/my-personal-work-principles/">那篇</a>总结的还不够，这两天通过观察自己的所言所行，又有了些思绪，这里记录下来。</p>
<p><b>* 重塑标准</b></p>
<p>简单来说就是根据组织实际情况，重新建立各种标准 &#8211; 技术标准、人员标准和产品标准。 个人认为这恰是一种实事求是的积极态度。避免陷入技术泥潭中无法自拔，不用Google的人才和做事标准来要求组织内部的人和招聘新人上，认识到存在的差 距。恰如当年钱学森根据国内人力、物力以及实际技术水准重新制定了标准，而不是照搬美国的标准，否则造导弹就会变成一个不可能完成的任务，对团队 士气也将会是一个极大的打击。</p>
<p><b>* 问题理解要透彻</b></p>
<p>很多时候，干完了才知道白干了，这往往缘于起初对问题理解的不够透彻，没有抓住焦点，导致Solution不是最合适的，引发不必要的返工。但很 多问题往往无法一次性透彻地理解，这就需要在工作方法上有所调整，以尽可能少的工作消耗去理解和摸索，对工作内容进行阶段性的反思和重构。这样在 1.0, 2.0以及3.0等后续版本的演进过程中，你会发现问题将变得逐渐清晰，焦点也会越来越清楚。而一旦问题被看透，最正确的Solution自然就会在大脑 中形成。</p>
<p><b>* &ldquo;眼见为实&rdquo;还不够</b></p>
<p>俗语讲：眼见为实。但在工作中，有些时候&ldquo;眼见为实&rdquo;还不够，因为很多时候眼中看到的是假象，这在调试和查找技术问题时显得尤为突出。无数次的问 题调查告诉我：始终要保持头脑清醒和逻辑清晰，不能人云亦云，不能轻易相信亲眼所见的&ldquo;事实&rdquo;。要追求逻辑的<b>全局合理性</b>，一丝的不 合理都要刨根问底，不遗漏任何蛛丝马迹。</p>
<p><b>* 把事情做在前面</b></p>
<p>以<a href="http://tonybai.com/2013/05/03/the-past-two-years-to-promote-the-knowledge-management/">推进知识管理</a>为例，在发布知识库之前就应该把发布后可能遇到的各种问题、阻碍想清楚，提前就这些可能的问题给出方法、答案的指导或以Q&amp;A的形 式与知识库一并发布。这些要做在前面的事情包括几类：解放思想的（帮助大家突破原有思维禁锢）、最佳实践的（告知以何种方式去做收到的效果最好）、基本知 识技巧普及的（以大家最易接受的方式对基本知识技巧做出诠释）、服务运维的（还以知识库为例，发布后，你要始终保证其运行稳定可靠，不能让其他人操心于此 事）等。&nbsp;</p>
<p style='text-align:left'>&copy; 2013, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2013/09/03/my-personal-work-principles-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>我的工作原则</title>
		<link>https://tonybai.com/2013/08/19/my-personal-work-principles/</link>
		<comments>https://tonybai.com/2013/08/19/my-personal-work-principles/#comments</comments>
		<pubDate>Mon, 19 Aug 2013 15:46:33 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[innovation]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[企业文化]]></category>
		<category><![CDATA[创新]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[团队]]></category>
		<category><![CDATA[基因]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[工作原则]]></category>
		<category><![CDATA[微创新]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[授权]]></category>
		<category><![CDATA[效率]]></category>
		<category><![CDATA[海底捞]]></category>
		<category><![CDATA[痛点]]></category>
		<category><![CDATA[知识管理]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[组织]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1373</guid>
		<description><![CDATA[想了若干种开场白，但无论哪种都不能令我满意，于是索性就这么开场了。 工作了若干年，不经意间就形成了自己的行事和决策风格，这里权且称之为工作原则吧。这些原则引导我制定工作目标、实施过程改善、作出方案决策、选择和培养团队人员以及进行自我改进等。我也相信这些原则是主观的、具有时间和环境局限性的。也许若干年后，随着我的角色和工作的变化，许多原则将 不再适用，但这不妨碍我现在将其总结和分享出来。 * 对工作原则的认知 原则就像定理一样，是你在决策以及行事前要参考的东西，它将对你的思维施加强大的因果影响，指引你一步一步的得到最终的结果。个人工作原则的行成 是一个逐渐认知、逐渐丰富的过程，与个人角色的影响力多寡有一定关系。最初入职场，你所能影响的范围较小，无非就是你所负责的那个一小块区域，更 多是与事儿打交道，似乎没有什么可以决策和选择的。你要做的就是按时保质地完成一个接着一个的任务。随着影响圈的扩大，你的行为将受到更多因素的 影响，你的思维计算开始变得复杂，你的潜意识告诉你这么做是正确的。久而久之，这种思维和行事方式就固化到你的大脑中了，形成了你的工作原则，并 且原则随着你的工作年头的增加而逐渐丰富。 工作原则是个体的，主观的，也可能是错的，也许只适合你的角色，但不一定适合他人。如果两个人的工作原则一模一样，那估计是电视剧中的情形，纯属 巧合。 有原则的工作观的行成时间因人而异，有的人初入职场就有，有的人要花上个几年时间，我就属于后者，缓慢型。 有了原则，还要会使用原则，这或多或少与情商有关。有时候，折中或妥协不一定是最坏的结果。 * 做事的原则 &#160;&#160; 【要结果，也要过程】 &#160;&#160;&#160; 现代企业更强调结果导向，业绩为先。在组织与个人的绩效考核中，结果确是极其重要的指标因素，这些都无可厚非。但我坚持的原则是要结果，也要过程。个人不 是临时工，不是完成一个任务后就要离职；团队也不是打一杖就要解散的，因此每打一杖，我们既要胜利，也要打得一个比一个漂亮 &#8211; 投入少，损伤少，战果卓著，我们的人民子弟兵不就是这么发展壮大起来的么 &#8211; 鸟枪换炮了。一成不变的过程损失的是个人以及团队未来 的竞争力。因此对于软件开发团队而言，要实施积极的过程改善，改善是融于任务的过程中的。没有代码评审的，整个 Reviewboard玩玩；打包构建不规范的，弄个maven或buildc试试；测试还靠人肉的，堆个自动化的测试框架（比如 robotframework）试试。过程的改善带来的是整体能力的提升，这就是我们除了结果之外所想要得到的。 &#160;&#160; 【从痛点出发】 &#160;&#160;&#160; 这是一条寻觅过程改善点的原则，很多人也都能意识到过程的一成不变，但却始终找不到下手改进的切入点； &#160;&#160;&#160; 这也是一条组织内开启微创新的原则。在&#8220;创新&#8221;一词被用烂的今天，真正能找到组织内创新之路起点的人却少之又少。 &#160;&#160;&#160; 什么是痛点（pain point）？顾名思义，引发痛苦的点。放在组织以及过程范围内来说就是让员工或组织在内部活动过程中产生别扭、不爽以及痛苦的点。比如：每次搭建一个产 品模拟环境都要半天时间、每次都要两人/天才能完成新版本的接收测试、TMD谁提交的代码让工程编译不过去了。 &#160;&#160;&#160; 我的原则是努力去发现痛点，深入理解痛点，并尝试缓解或解决痛点。 &#160;&#160;&#160; 发现痛点的一个方法就是降低自己的忍受力，这样痛点才能得以放大。否则中国人都是极具耐性且勤奋的，一点点挫折或别扭之处或浪费时间的事情都不会被列为痛点 的。 &#160;&#160;&#160; 解决痛点的一个前提是对其深入的理解。有的痛点，我们感受到的只是其外在的表象，其深层次的东西是需要深入地理解和挖掘的。只有挖掘到深层次，才能对症下 药，药到病除。 &#160;&#160;&#160; 客户的痛点，往往是一种很好的引导产品演化或服务提升的途径。比如：到海底捞吃饭要排队，显然大家都不喜欢排队。海底捞的团队发现了客户们的这个痛点，向 排队客户提供了超出客户预想的服务。之后的事情大家都有所耳闻了：这一痛点的解决居然变成了海底捞的&#8220;招牌&#8220;。 &#160;&#160; 【事先谋划布局】 &#160;&#160;&#160; 我们知道要下好围棋，谋划布局是必不可少的。最佳布局是取得胜利的基石。要完成最佳的布局，需要棋手有对全盘的整体把握能力以及准确的时机判断能力。做事如下棋，尤其是在要完成一些重要且复杂的事情时，务必事先针对现状谋划出最佳的布局。 &#160;&#160;&#160; 在组织内部，资源和时间永远是有限的。要去完成一件不紧急但重要事情的时候，往往不能立即得到全部的资源以及充足的时间，甚至得不到其他人的认可（因意 [...]]]></description>
			<content:encoded><![CDATA[<p>想了若干种开场白，但无论哪种都不能令我满意，于是索性就这么开场了。</p>
<p>工作了若干年，不经意间就形成了自己的行事和决策风格，这里权且称之为工作原则吧。这些原则引导我制定工作目标、实施过程改善、作出方案决策、选择和培养<a href="http://tonybai.com/2012/11/01/some-experience-on-team-management/">团队</a>人员以及进行自我改进等。我也相信这些原则是主观的、具有时间和环境局限性的。也许若干年后，随着我的角色和工作的变化，许多原则将 不再适用，但这不妨碍我现在将其总结和分享出来。</p>
<p><b>* 对工作原则的认知</b></p>
<p>原则就像定理一样，是你在决策以及行事前要参考的东西，它将对你的思维施加强大的因果影响，指引你一步一步的得到最终的结果。个人工作原则的行成 是一个逐渐认知、逐渐丰富的过程，与个人角色的影响力多寡有一定关系。最初入职场，你所能影响的范围较小，无非就是你所负责的那个一小块区域，更 多是与事儿打交道，似乎没有什么可以决策和选择的。你要做的就是按时保质地完成一个接着一个的任务。随着影响圈的扩大，你的行为将受到更多因素的 影响，你的思维计算开始变得复杂，你的潜意识告诉你这么做是正确的。久而久之，这种思维和行事方式就固化到你的大脑中了，形成了你的工作原则，并 且原则随着你的工作年头的增加而逐渐丰富。</p>
<p>工作原则是个体的，主观的，也可能是错的，也许只适合你的角色，但不一定适合他人。如果两个人的工作原则一模一样，那估计是电视剧中的情形，纯属 巧合。</p>
<p>有原则的工作观的行成时间因人而异，有的人初入职场就有，有的人要花上个几年时间，我就属于后者，缓慢型。</p>
<p>有了原则，还要会使用原则，这或多或少与情商有关。有时候，折中或妥协不一定是最坏的结果。</p>
<p><b>* 做事的原则</b></p>
<p>&nbsp;&nbsp; 【<i>要结果，也要过程</i>】</p>
<p>&nbsp;&nbsp;&nbsp; 现代企业更强调结果导向，业绩为先。在组织与个人的绩效考核中，结果确是极其重要的指标因素，这些都无可厚非。但我坚持的原则是要结果，也要过程。个人不 是临时工，不是完成一个任务后就要离职；团队也不是打一杖就要解散的，因此每打一杖，我们既要胜利，也要打得一个比一个漂亮 &#8211; 投入少，损伤少，战果卓著，我们的人民子弟兵不就是这么发展壮大起来的么 &#8211; 鸟枪换炮了。<b><i>一成不变的过程损失的是个人以及团队未来 的竞争力</i></b>。因此对于软件开发团队而言，要实施积极的过程改善，改善是融于任务的过程中的。没有代码评审的，整个 <a href="http://tonybai.com/2011/03/04/some-experience-on-using-review-board/">Reviewboard</a>玩玩；打包构建不规范的，弄个<a href="http://maven.apache.org/‎">maven</a>或<a href="http://tonybai.com/2011/12/08/buildc-a-building-assistant-tool-for-c-app/">buildc</a>试试；测试还靠人肉的，堆个自动化的测试框架（比如 <a href="http://code.google.com/p/robotframework/‎">robotframework</a>）试试。过程的改善带来的是整体能力的提升，这就是我们除了结果之外所想要得到的。</p>
<p>&nbsp;&nbsp; 【<i>从痛点出发</i>】</p>
<p>&nbsp;&nbsp;&nbsp; 这是一条寻觅过程改善点的原则，很多人也都能意识到过程的一成不变，但却始终找不到下手改进的切入点；<br />
	&nbsp;&nbsp;&nbsp; 这也是一条组织内开启<a href="http://gigix.thoughtworkers.org/2013/6/16/building-innovative-organization‎">微创新</a>的原则。在&ldquo;创新&rdquo;一词被用烂的今天，真正能找到组织内创新之路起点的人却少之又少。</p>
<p>&nbsp;&nbsp;&nbsp; 什么是痛点（pain point）？顾名思义，引发痛苦的点。放在组织以及过程范围内来说就是让员工或组织在内部活动过程中产生别扭、不爽以及痛苦的点。比如：每次搭建一个产 品模拟环境都要半天时间、每次都要两人/天才能完成新版本的接收测试、TMD谁提交的代码让工程编译不过去了。</p>
<p>&nbsp;&nbsp;&nbsp; 我的原则是努力去发现痛点，深入理解痛点，并尝试缓解或解决痛点。</p>
<p>&nbsp;&nbsp;&nbsp; 发现痛点的一个方法就是降低自己的忍受力，这样痛点才能得以放大。否则中国人都是极具耐性且勤奋的，一点点挫折或别扭之处或浪费时间的事情都不会被列为痛点 的。</p>
<p>&nbsp;&nbsp;&nbsp; 解决痛点的一个前提是对其深入的理解。有的痛点，我们感受到的只是其外在的表象，其深层次的东西是需要深入地理解和挖掘的。只有挖掘到深层次，才能对症下 药，药到病除。</p>
<p>&nbsp;&nbsp;&nbsp; 客户的痛点，往往是一种很好的引导产品演化或服务提升的途径。比如：到海底捞吃饭要排队，显然大家都不喜欢排队。海底捞的团队发现了客户们的这个痛点，向 排队客户提供了超出客户预想的服务。之后的事情大家都有所耳闻了：这一痛点的解决居然变成了海底捞的&ldquo;招牌&ldquo;。</p>
<p>&nbsp;&nbsp; 【<i>事先谋划布局</i>】</p>
<p>&nbsp;&nbsp;&nbsp; 我们知道要下好围棋，谋划布局是必不可少的。最佳布局是取得胜利的基石。要完成最佳的布局，需要棋手有对全盘的整体把握能力以及准确的时机判断能力。做事如下棋，尤其是在要完成一些重要且复杂的事情时，务必事先针对现状谋划出最佳的布局。</p>
<p>&nbsp;&nbsp;&nbsp; 在组织内部，资源和时间永远是有限的。要去完成一件不紧急但重要事情的时候，往往不能立即得到全部的资源以及充足的时间，甚至得不到其他人的认可（因意 识、眼光等种种原因）。一些自下而上发起的改善措施，甚至是得不到任何资源的。只能充分评估已有的资源和时间，以设定好的节奏稳步前进，取得一些阶段性的 成果。当时机成熟时，公开成果以获得领导的首肯以及各种资源来完成后面的计划。我在组织内部推行<a href="http://tonybai.com/2013/05/03/the-past-two-years-to-promote-the-knowledge-management/">知识管理</a>时就是这样布局的，而这个局花了两年多时间才基本 完成。</p>
<p>&nbsp;&nbsp;&nbsp; 大局大作，小局小作。关键是以敏锐的眼光准确的判断形势，以确定是否该落下下一颗棋子以及落在何处。<br />
	&nbsp;&nbsp;&nbsp;<br />
	&nbsp;&nbsp; 【<i>不违背工作节奏规律</i>】<br />
	&nbsp; &nbsp;<br />
	&nbsp;&nbsp;&nbsp; 人不是机器，无法始终绷紧神经开全挂埋头苦干。人工作效率的高低和产出成果多寡符合一定的规律曲线，大致分为三个阶段：充电期、发光期与衰减期。</p>
<p>&nbsp;&nbsp;&nbsp; 不同年龄段的人的充电期、发光期、衰减期的长短不同，这个很好理解。年轻人发光期相对长，充电和衰减相对短。随着年龄的增加，发光期缩短，充电和衰减期变长。</p>
<p>&nbsp;&nbsp;&nbsp; 每个人要对属于自己的那个工作节奏做好充分认知。让发光期更有效率（每天高效利用8小时），让充电期集聚更多能量（身体上的、精神上的和知识技能上的），调整衰减期的工作内容。</p>
<p>&nbsp;&nbsp;&nbsp; 下班后尽量做与工作无关的事情（例如做自己的开源项目、融入家庭生活），努力追求工作与生活的平衡，是有利于提升充电效率的。</p>
<p>&nbsp;&nbsp;&nbsp; 长久违背这一自然规律，将使得节奏变得紊乱，而紊乱后的代价还是蛮高的。</p>
<p>&nbsp;&nbsp;&nbsp; 组织由个体组成，组织也因此呈现出一定的工作节奏，我们在考虑组织的工作负荷时不要忘了这一点。</p>
<p>&nbsp;&nbsp; 【<i>时刻抱有危机感</i>】</p>
<p>&nbsp;&nbsp;&nbsp; 危机感让人警醒，并保持持续向前的动力和热情。</p>
<p>&nbsp;&nbsp;&nbsp; 时刻问自己：如果你离开当前公司，是否能瞬即得到其他同等或更好的公司的青睐。这种危机感让你会主动追随技术潮流的发展方向，武装自己，提升自己，让自己的受欢迎度维持在高位。</p>
<p>&nbsp;&nbsp;&nbsp; 组织也是一样，没有永恒不落的公司，没有永恒不落的行业。即便是百年老店IBM，也是在沙场中几经沉浮。危机感让组织持续寻找新的业务方向、积累新鲜的技术食粮，为将来残酷的竞争做着准备。</p>
<p>&nbsp; &nbsp; 【<i>通过提升平台能力，提升整体能力</i>】<br />
	&nbsp;&nbsp;&nbsp;<br />
	&nbsp;&nbsp;&nbsp;&nbsp; 与逐个培训和激励个体提升相比，组织整体能力的提升是更具性价比的。人是最复杂的动物，基因的万千变化使得自然界的人类个体差异十分巨大，这表现在智商、 兴趣、理想、热情等多个方面。用内容一致的课程对员工进行所谓的培训，收到的效果自然千差万别，整体提升有限。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp; 但如果将个体所在的平台的能力进行提升，就好比将传统的人工生产线换成机器人流水线，员工们要做的只是改变一下自己的行为，新的行为甚至比之前的操作更为简单，我们就可以得到整体的能力提升。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp; 这种方法的划算之处还在于即便在人员流失的情况下，新进的人员在这套平台或规程下段时间内也能达到相同的生产力，即便新人在各个方面都远逊色于离开的老员工。</p>
<p><b>* 用人的原则</b></p>
<p>&nbsp; &nbsp;&nbsp; 【<em>但求最适合，不求最优秀</em>】<br />
	&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;<br />
	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 理想情况下，所有组织都希望能招到世界上最优秀的员工 &#8211; 能力最强，效率最高。但事实上在IT行业里，世界范围内集聚牛人的公司也就那么几家，绝大多数公司的员工都是很平凡的，我所在的公司更是如此。中国的IT 牛人多聚集在北上广等一线城市，那里的IT环境好，待遇优越。但没有牛人不代表无法完成工作。在现有的可用资源下，我要找的是最适合的人 &#8211; 他们在技术方面不要求十分优秀，也许只是可以胜任，但却与其工作角色十分匹配。甚至于有些角色还真的不适合牛人去做，或大才小用，或热情耐心不足（要知道 牛人一般都很自负的，对某些工作不屑一顾，自然也不会投入热情和耐心）。<br />
	&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;<br />
	&nbsp;&nbsp;&nbsp;&nbsp; 【<em>充分授权，服务到位</em>】</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 实战是考验一个人的最好工具。通过实战，人员能力还将能得到最快的提升。因此从人员能力培养的角度上去看，我更愿意给予下属充分的授权，让他们放手去做。当然伴以检查与辅导，尽量减少他们走弯路的可能。</p>
<p>&nbsp;&nbsp;&nbsp; &nbsp; 在授权前，还要充分考虑到他们即将遇到的各种困难。并事先协调资源，给他们提供周到的服务，以帮助他们顺利完成工作任务。这些服务有可能是一些基础设施平台，也有可能是一些预研储备的技术方案。就好比武侠小说中的妙计锦囊，在关键时候可以帮助下属度过难关。&nbsp;&nbsp;</p>
<p style='text-align:left'>&copy; 2013, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2013/08/19/my-personal-work-principles/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>2012小结</title>
		<link>https://tonybai.com/2012/12/18/my-summary-of-2012/</link>
		<comments>https://tonybai.com/2012/12/18/my-summary-of-2012/#comments</comments>
		<pubDate>Tue, 18 Dec 2012 07:43:04 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[生活簿]]></category>
		<category><![CDATA[2012]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[世界末日]]></category>
		<category><![CDATA[女儿]]></category>
		<category><![CDATA[学习]]></category>
		<category><![CDATA[家庭]]></category>
		<category><![CDATA[小结]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[总结]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[果果]]></category>
		<category><![CDATA[生活]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[读书]]></category>
		<category><![CDATA[豆瓣]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1149</guid>
		<description><![CDATA[趁着世界末日尚未到来，赶紧将2012年总结一番，即便是末日也不能留遗憾不是^_^。 2012年总体过得还算充实： *《七周七语言》终于出版了； * 写了近80篇Blog，虽离目标预期还有差距，但也给我带来了不小的精神愉悦； * 为《程序员》杂志写了两篇文章，虽然都是短文； * 读了30多本书，还有10多本尚未读完，不过年初制定的&#8220;扫存书&#8221;目标没能达成，因为依然不断地有大量的新书加入^_^； * 学习了一门编程语言Go（而不是年初确定的Clojure等）； * 将自己的一些关于工作方法、团队建设和管理的认知和实践总结了出来，算是一个阶段性的小结，内容包括绩效目标制定、绩效面谈、高效会议、写好Mail、个人时间管理、知识管理新认知、团队经营等诸多方面。也许后续还有补充。 2012年在工作方面的表现略显平淡。恰应了那句古语：有心栽花花不活。年初和团队成员共同确定了今年的年度主题词为&#8220;收获&#8221;，但一年下来的结果 却是差强人意：我最重视的一个关键项目没能如期发布，可谓是今年之最大憾事。我的责任自然不能脱掉，主因在于我年初过于乐观的估计。至于在其他方 面即便有较大进展，也无法弥补这一遗憾给我带来的不快。 2012年将buildc实际应用到了产品构建中，同时发现了诸多问题，也收到了许多同事的反馈。buildc也因此在持续演进，从0.1.4版本到 目前的0.2.1版本。近期正在酝酿0.3.x版本，这次改动较大，调整了很多当初的设计思路，与0.2.x版本并不兼容了。 2012年在家庭方面自我感觉收获还是颇多的。从数字上看，年初确定的年度家庭目标80%都实现了，这些目标有对父母的、有对孩子的，也有对LP 的，这让我颇为欣慰啊。最让我欣喜的是看到了女儿果果的成长，尤其是其语言能力的提升，让我们从此不必再担心了。现在面对果果这样一个已经可以与 我进行语言交流的小家伙儿，心中总是有一种莫名的感动，感谢上天赐予我这个可爱的小家伙儿 ^_^。将心比心，现在真心感觉到父母对待子女可真是没有半点私心，都是全心全力的为儿女服务，所以每个人都更应该善待父母。今年下半年，母亲得了眼 病，做了一个小手术，我也请假回家照顾。平时和父母不在一个城市生活，方方面面无法顾及，甚感惭愧，这次回家让我心灵有了些许慰藉，也让我第一次有了尽孝道的感觉。以后我每年都会设定家庭目标，但今后的家庭目标实现难度都很大，尽力而为吧^_^。 读书已然是生活中不可缺少的一部分了，但2012年似乎有些懒惰了。虽然读的书目也不少，但总感觉缺少些效率。 过去的都过去了，2012虽有小成，但觉得进步有限。身旁的人与物太过熟悉稳定，人就会变得像温水中的那只青蛙。 2013，期待能有些变化。 &#169; 2012, bigwhite. 版权所有.]]></description>
			<content:encoded><![CDATA[<p>趁着世界末日尚未到来，赶紧将2012年总结一番，即便是末日也不能留遗憾不是^_^。</p>
<p>	2012年总体过得还算充实：</p>
<p>	*《<a href="http://tonybai.com/2012/05/08/translate-seven-languages-in-seven-weeks/">七周七语言</a>》终于出版了；<br />
	* 写了近80篇Blog，虽离目标预期还有差距，但也给我带来了不小的精神愉悦；<br />
	* 为《程序员》杂志写了<a href="http://tonybai.com/2012/10/26/some-practice-on-improving-tech-preach/">两篇文章</a>，虽然都是短文；<br />
	* 读了<a href="http://book.douban.com/people/tony_bai/collect">30多本书</a>，还有<a href="http://book.douban.com/people/tony_bai/do">10多本</a>尚未读完，不过年初制定的&ldquo;扫存书&rdquo;目标没能达成，因为依然不断地有大量的新书加入^_^；<br />
	* 学习了一门编程语言<a href="http://tonybai.com/tag/Go">Go</a>（而不是年初确定的<a href="http://clojure.org">Clojure</a>等）；<br />
	* 将自己的一些关于工作方法、团队建设和管理的认知和实践总结了出来，算是一个阶段性的小结，内容包括<a href="http://tonybai.com/2012/11/17/several-important-factors-in-making-performance-goals/">绩效目标制定</a>、<a href="http://tonybai.com/2012/12/13/some-opinions-about-performance-interview/">绩效面谈</a>、<a href="http://tonybai.com/2012/12/03/how-to-organize-and-hold-meetings-efficiently/">高效会议</a>、<a href="http://tonybai.com/2012/11/28/how-to-write-a-good-email/">写好Mail</a>、<a href="http://tonybai.com/2012/11/23/some-experience-on-personal-time-management/">个人时间管理</a>、<a href="http://tonybai.com/2012/11/04/the-amateur-way-of-knowledge-management/">知识管理</a>新认知、<a href="http://tonybai.com/2012/11/01/some-experience-on-team-management/">团队经营</a>等诸多方面。也许后续还有补充。</p>
<p>	2012年在工作方面的表现略显平淡。恰应了那句古语：有心栽花花不活。年初和团队成员共同确定了今年的年度主题词为&ldquo;收获&rdquo;，但一年下来的结果 却是差强人意：我最重视的一个关键项目没能如期发布，可谓是今年之最大憾事。我的责任自然不能脱掉，主因在于我年初过于乐观的估计。至于在其他方 面即便有较大进展，也无法弥补这一遗憾给我带来的不快。</p>
<p>	2012年将<a href="http://code.google.com/p/buildc">buildc</a>实际应用到了产品构建中，同时发现了诸多问题，也收到了许多同事的反馈。buildc也因此在持续演进，从<a href="http://tonybai.com/2012/04/12/buildc-0-1-4-release/">0.1.4</a>版本到 目前的<a href="http://tonybai.com/2012/12/06/buildc-0-2-1-release/">0.2.1</a>版本。近期正在酝酿0.3.x版本，这次改动较大，调整了很多当初的设计思路，与0.2.x版本并不兼容了。</p>
<p>	2012年在家庭方面自我感觉收获还是颇多的。从数字上看，年初确定的年度家庭目标80%都实现了，这些目标有对父母的、有对孩子的，也有对LP 的，这让我颇为欣慰啊。最让我欣喜的是看到了女儿<a href="http://tonybai.com/2012/11/27/some-growing-up-details-of-my-two-years-old-daughter/">果果的成长</a>，尤其是其语言能力的提升，让我们从此不必再担心了。现在面对果果这样一个已经可以与 我进行语言交流的小家伙儿，心中总是有一种莫名的感动，感谢上天赐予我这个可爱的小家伙儿 ^_^。将心比心，现在真心感觉到父母对待子女可真是没有半点私心，都是全心全力的为儿女服务，所以每个人都更应该善待父母。今年下半年，母亲得了眼 病，做了一个小手术，我也请假回家照顾。平时和父母不在一个城市生活，方方面面无法顾及，甚感惭愧，这次回家让我心灵有了些许慰藉，也让我第一次有了尽孝道的感觉。以后我每年都会设定家庭目标，但今后的家庭目标实现难度都很大，尽力而为吧^_^。</p>
<p>	读书已然是生活中不可缺少的一部分了，但2012年似乎有些懒惰了。虽然读的书目也不少，但总感觉缺少些效率。</p>
<p>	过去的都过去了，2012虽有小成，但觉得进步有限。身旁的人与物太过熟悉稳定，人就会变得像温水中的那只青蛙。</p>
<p>2013，期待能有些变化。</p>
<p style='text-align:left'>&copy; 2012, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2012/12/18/my-summary-of-2012/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>关于绩效面谈的一些拙见</title>
		<link>https://tonybai.com/2012/12/13/some-opinions-about-performance-interview/</link>
		<comments>https://tonybai.com/2012/12/13/some-opinions-about-performance-interview/#comments</comments>
		<pubDate>Thu, 13 Dec 2012 03:01:49 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[一分钟先生]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[程序员杂志]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[绩效]]></category>
		<category><![CDATA[绩效面谈]]></category>
		<category><![CDATA[项目管理]]></category>
		<category><![CDATA[领导力，职场]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1145</guid>
		<description><![CDATA[《程序员》杂志的&#8220;一分钟先生&#8221;专栏之前曾约稿，有两个主题可供选择：制定绩效目标或如何进行绩效面谈。本打算两个主题都写写的，但碍于时间有限，最终只写了一个主题：《制定绩效目标的几个重要因素》。进入12月，想必各个公司或组织都会开展年终绩效考核，我这里也不例外。 &#160; 关于绩效面谈，印象中组织里似乎没人告诉我应该如何去做。很久以前是小兵的时候没有过多考虑，成为项目负责人后也没有接受过什么系统的培训，都是按照自己的思路去做；现在是诸多项目负责人的负责人了，是该好好系统地考量一下这方面事情的时候了。考量后的结果还可以分享给下面的项目负责人，也算是一种&#8220;辅导&#8221;吧。OK，下面就唠叨几句^_^。 一、目的 无论做什么事情，都要先弄清做事的目的，绩效面谈也不例外。 &#160; * 谋改进 &#160; 绩效面谈一个重要的目的就是谋改进，求提高。对于一个良性的组织来说，组织自然希望组织内的所有人在能力和效率上能持续提高，这样才具备获得最大收益的基础条件。因此，组织采用各种方法策略为内部成员设定绩效计划和目标、定期辅导、监督执行，而绩效面谈则是整个绩效周期中的阶段性总结的环节，它对员工在下一绩效周期的表现有着至关重要的意义。 &#160; * 定成绩 &#160; 绩效面谈是对当前绩效周期的阶段性总结，自然不能脱离开这样一个话题：员工在这个周期的成绩如何？员工想知道自己忙活了大半年到底成绩如何，组织也想得到员工的绩效成绩来作为一些职位、角色和薪酬调整的依据，甚至是辞退员工的依据。 &#160; * 增聚力 &#160; 绩效面谈，其实也是一次上级与下级的正式交流。员工的内心中都是渴望上级能时常关注和评定自己的工作。想必大多人都能体会到这点：每次与上级面谈后都能感受到自己的工作努力没有白费以及自己的工作对组织的重要性，感觉自己对后续的工作更有信心了。显然这种面谈间接地增加了员工的团队凝聚力。 二、要素 绩效面谈并无固定模式，但良好的绩效面谈应该具备以下两点要素。 &#160; * 镜子 &#160; 好的绩效面谈应该是一面镜子，可以让员工看到一个真实的自己，而不仅仅是员工自我认知中的自己；这面镜子让员工发现自我认知中的自己与他人眼中的自己的差异，认识和强化公认的优势，同时也能看到自己的不足之处。 &#160; * 号角 &#160; 前面说过绩效面谈的目的之一就是谋改进，因此一次好的绩效面谈就应该像是一支吹响的号角，为下一个绩效周期的工作进行着&#8220;战前动员&#8221;。号角声在员工内心中长久反复激荡，激励着员工持续向前，不断改进。 三、禁忌 良好有效的绩效面谈同样有一些&#8220;禁忌&#8221;要牢记，否则会对面谈的效果产生较大负面影响。 &#160; * 忌&#8220;无准备之仗&#8221; &#160; 不要将绩效面谈做成&#8220;突发事件&#8221;、&#8220;无准备之仗&#8221;，比如经理A在事前没有任何征兆的情况下来到员工B工位前，对B说：&#8220;走，我们到会议室做绩效面谈&#8221;。这种绩效面谈必然不会取得良好的效果，至少员工B没有任何思想和心理准备，面谈过程中无法真实和全面的表达出自己的观点和思想。 &#160; 绩效面谈前，上级和员工都是要做好精心准备的。上级自己要收集好面谈对象的相关工作数据，整理好面谈思路，做到思路清晰。上级需告知员工做绩效面谈准备，并给予充分的准备时间，甚至还可以提示员工该做哪些方面的准备。员工则要针对自己在绩效周期的表现做些总结，对自己做一次重新认知，整理对团队或组织的意见和建议，明确自己的面谈思路；这样做双方才能在面谈过程中做到有的放矢。 &#160; * 忌&#8220;批斗会&#8221; &#160; 绩效面谈为的是促进个人改进，团队改进，组织改进；无论如何，不能将面谈变成&#8220;批斗会&#8221;，即便是对方有再多问题和不足。人家都辛苦这么长时间了，到头来还被劈头盖脸的一顿批评，换成谁心里能不难受，那后续还能有好心情工作了么。即便是要劝退的对象，也只需阐述事实和数据就好。总之，面谈中要尽量建立正面的和鼓励的气氛。 &#160; * 忌&#8220;一言堂&#8221; &#160; 很多绩效变谈最终演化为上级一人的&#8220;高谈阔论&#8221;，下属只有听的份儿了。这种形式的面谈实难达到预期之效果。上级更应学会倾听员工内心的真实声音，与员工充分互动，记录并快速分析，给予员工中肯的建议。对于无法立即决策的事情，告知员工后续答复。 &#160; * 忌随意承诺 &#160; [...]]]></description>
			<content:encoded><![CDATA[<p>《程序员》杂志的&ldquo;一分钟先生&rdquo;专栏之前曾约稿，有两个主题可供选择：制定绩效目标或如何进行绩效面谈。本打算两个主题都写写的，但碍于时间有限，最终只写了一个主题：《<a href="http://tonybai.com/2012/11/17/several-important-factors-in-making-performance-goals/">制定绩效目标的几个重要因素</a>》。进入12月，想必各个公司或组织都会开展年终绩效考核，我这里也不例外。</p>
<div>&nbsp;</div>
<div>关于绩效面谈，印象中组织里似乎没人告诉我应该如何去做。很久以前是小兵的时候没有过多考虑，成为项目负责人后也没有接受过什么系统的培训，都是按照自己的思路去做；现在是诸多项目负责人的负责人了，是该好好系统地考量一下这方面事情的时候了。考量后的结果还可以分享给下面的项目负责人，也算是一种&ldquo;辅导&rdquo;吧。OK，下面就唠叨几句^_^。</div>
<h4>一、目的</h4>
<div>无论做什么事情，都要先弄清做事的目的，绩效面谈也不例外。</div>
<div>&nbsp;</div>
<div>* 谋改进</div>
<div>&nbsp;</div>
<div>绩效面谈一个重要的目的就是谋改进，求提高。对于一个良性的组织来说，组织自然希望组织内的所有人在能力和效率上能持续提高，这样才具备获得最大收益的基础条件。因此，组织采用各种方法策略为内部成员设定绩效计划和目标、定期辅导、监督执行，而绩效面谈则是整个绩效周期中的阶段性总结的环节，它对员工在下一绩效周期的表现有着至关重要的意义。</div>
<div>&nbsp;</div>
<div>* 定成绩</div>
<div>&nbsp;</div>
<div>绩效面谈是对当前绩效周期的阶段性总结，自然不能脱离开这样一个话题：员工在这个周期的成绩如何？员工想知道自己忙活了大半年到底成绩如何，组织也想得到员工的绩效成绩来作为一些职位、角色和薪酬调整的依据，甚至是辞退员工的依据。</div>
<div>&nbsp;</div>
<div>* 增聚力</div>
<div>&nbsp;</div>
<div>绩效面谈，其实也是一次上级与下级的正式交流。员工的内心中都是渴望上级能时常关注和评定自己的工作。想必大多人都能体会到这点：每次与上级面谈后都能感受到自己的工作努力没有白费以及自己的工作对组织的重要性，感觉自己对后续的工作更有信心了。显然这种面谈间接地增加了员工的团队凝聚力。</div>
<h4>二、要素</h4>
<div>绩效面谈并无固定模式，但良好的绩效面谈应该具备以下两点要素。</div>
<div>&nbsp;</div>
<div>* 镜子</div>
<div>&nbsp;</div>
<div>好的绩效面谈应该是一面镜子，可以让员工看到一个真实的自己，而不仅仅是员工自我认知中的自己；这面镜子让员工发现自我认知中的自己与他人眼中的自己的差异，认识和强化公认的优势，同时也能看到自己的不足之处。</div>
<div>&nbsp;</div>
<div>* 号角</div>
<div>&nbsp;</div>
<div>前面说过绩效面谈的目的之一就是谋改进，因此一次好的绩效面谈就应该像是一支吹响的号角，为下一个绩效周期的工作进行着&ldquo;战前动员&rdquo;。号角声在员工内心中长久反复激荡，激励着员工持续向前，不断改进。</div>
<h4>三、禁忌</h4>
<div>良好有效的绩效面谈同样有一些&ldquo;禁忌&rdquo;要牢记，否则会对面谈的效果产生较大负面影响。</div>
<div>&nbsp;</div>
<div>* 忌&ldquo;无准备之仗&rdquo;</div>
<div>&nbsp;</div>
<div>不要将绩效面谈做成&ldquo;突发事件&rdquo;、&ldquo;无准备之仗&rdquo;，比如经理A在事前没有任何征兆的情况下来到员工B工位前，对B说：&ldquo;走，我们到会议室做绩效面谈&rdquo;。这种绩效面谈必然不会取得良好的效果，至少员工B没有任何思想和心理准备，面谈过程中无法真实和全面的表达出自己的观点和思想。</div>
<div>&nbsp;</div>
<div>绩效面谈前，上级和员工都是要做好精心准备的。上级自己要收集好面谈对象的相关工作数据，整理好面谈思路，做到思路清晰。上级需告知员工做绩效面谈准备，并给予充分的准备时间，甚至还可以提示员工该做哪些方面的准备。员工则要针对自己在绩效周期的表现做些总结，对自己做一次重新认知，整理对团队或组织的意见和建议，明确自己的面谈思路；这样做双方才能在面谈过程中做到有的放矢。</div>
<div>&nbsp;</div>
<div>* 忌&ldquo;批斗会&rdquo;</div>
<div>&nbsp;</div>
<div>绩效面谈为的是促进个人改进，团队改进，组织改进；无论如何，不能将面谈变成&ldquo;批斗会&rdquo;，即便是对方有再多问题和不足。人家都辛苦这么长时间了，到头来还被劈头盖脸的一顿批评，换成谁心里能不难受，那后续还能有好心情工作了么。即便是要劝退的对象，也只需阐述事实和数据就好。总之，面谈中要尽量建立正面的和鼓励的气氛。</div>
<div>&nbsp;</div>
<div>* 忌&ldquo;一言堂&rdquo;</div>
<div>&nbsp;</div>
<div>很多绩效变谈最终演化为上级一人的&ldquo;高谈阔论&rdquo;，下属只有听的份儿了。这种形式的面谈实难达到预期之效果。上级更应学会倾听员工内心的真实声音，与员工充分互动，记录并快速分析，给予员工中肯的建议。对于无法立即决策的事情，告知员工后续答复。</div>
<div>&nbsp;</div>
<div>* 忌随意承诺</div>
<div>&nbsp;</div>
<div>对于绩效面谈过程中员工提出的建议和意见或是一些需求，上级应视实际情况给予答复，不能随意做承诺。绩效面谈的过程本身也是上下级就这一活动建立信任的过程。如果上级给下级随意承诺一些无法办得到的事情，那么久而久之，员工将对绩效面谈失去兴趣，失去信心，也就不会再重视这一活动，即便进行，也是敷衍了事，走个过场而已。也就是说上级的随意承诺摧毁了绩效面谈在员工心中的地位，员工也会对上级失去信任。</div>
<div>&nbsp;</div>
<div>绩效面谈还有一些细节需要注意，比如控制面谈时长、绩效面谈记录以书面形式发送给下级确认等。</div>
<div>&nbsp;</div>
<div>以上就是我关于绩效面谈的一些拙见。</div>
<p style='text-align:left'>&copy; 2012 &#8211; 2013, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2012/12/13/some-opinions-about-performance-interview/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>制定绩效目标的几个重要因素</title>
		<link>https://tonybai.com/2012/11/17/several-important-factors-in-making-performance-goals/</link>
		<comments>https://tonybai.com/2012/11/17/several-important-factors-in-making-performance-goals/#comments</comments>
		<pubDate>Sat, 17 Nov 2012 12:36:36 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[CSDN]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[期刊]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[程序员杂志]]></category>
		<category><![CDATA[管理]]></category>
		<category><![CDATA[绩效目标]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1090</guid>
		<description><![CDATA[本文是笔者发表在《程序员》杂志2012年11期上的那篇&#8220;制定绩效目标的几个重要因素&#8221;文章的完整版。 软件开发是一种创造性的工作，这种工作的成果具有不确定性且很难量化，因此经理们在给员工制定绩效目标时多没有统一标准(即便有也不一定准确，而且在一定程度上还可能会扼杀创造性)，所采用的方法也是五花八门。不过即便如此，经理们也没有放弃寻找一种更为适合软件开发领域绩效目标制定的方法。笔者也是其中一份子，在这里我将就如何制定出合理的绩效目标，与大家分享一下我的工作实践。 一般来说，一个绩效目标从无到有再到达成，至少包含三个关键阶段：准备、制定与实施。若单从绩效目标的制定来说，我们至少需要做好准备和制定这两个阶段的工作。 &#160; 准备 在与员工进行绩效目标制定之前，经理们应该做足准备工作，这些工作将直接影响到绩效目标制定的优劣。这些准备工作至少包括： &#160; * 深入理解组织全局目标 个体绩效目标的制定是为组织内全局目标的达成而服务的。作为经理，自己应该首先对组织的全局目标做好深入的理解，要弄清楚全局目标的内容、自己所带团队的负责范围以及达成该目标的各种约束，如时间、人员以及其他资源配备等。 &#160; * 明确绩效目标制定的目的和意义 为每位员工制定绩效目标到底为了啥？对于这个问题经理们自己首先要做到心中有数。对组织而言，个体绩效目标是全局目标分解后的最基本单元，个人的绩效目标达成是全局目标达成的必要条件；对个体而言，绩效目标的达成过程也是自身知识和技能得以提升的过程；对于经理们而言，通过为员工制定有挑战性的绩效目标来发现和充分挖掘个体的潜力，通过观察员工在达成绩效目标过程中的表现，还可以进一步甄别员工的优劣。 &#160; * 工作目标初步分解 在与员工进行绩效目标制定之前，经理们应先做好工作目标的初步分解。将团队所承担的大目标分解为员工个体所能承担的小目标。这方面有很多成熟的方法可以借鉴，这里不赘述。 &#160; *&#160;因人施任 工作有难易之分，人也有优秀与平庸之别。在与员工制定绩效目标前，经理们应该首先根据自己所掌握的情况对下属员工进行分类。有些人适合挑战高度和极限，而有些人却只能按部就班做一些事务性的工作。因此是否能够做到因人施任对于后续绩效目标制定是否合理以及能否顺利达成影响重大。 &#160; 制定 做足上述准备工作后，经理们就可以坐下来与员工逐一制定合理的绩效目标了。何为合理的绩效目标？这是个见仁见智的问题。笔者认为一个合理的绩效目标至少应包含如下几个关键属性。 &#160; * 明确 绩效目标中应该包含明确的工作内容、职责范围以及时间约束；明确绩效目标达成的条件；明确实施过程中所能得到的各种支持；明确目标的达成程度与绩效的关系：何种情况为优秀、良好、一般或未达成(不及格)。 &#160; * 适配 经理们制定绩效目标可不是为了&#8220;刁难&#8221;员工，因此工作目标应与员工能力和意愿适配，才能最大程度上发挥出员工的潜力。 &#160; * 共识 在前期准备中，经理们已经做了初步的工作目标分解以及人选甄别准备工作，但这仅仅是经理们的&#8220;一厢情愿&#8221;。合理的绩效目标是需要经理与员工共同讨论、理解、认同并最终达成共识的，否则纯粹行政命令式的目标指派很难称得上&#8220;合理&#8221;，目标达成的效果也会大打折扣，很可能影响到组织全局目标的达成。 &#160; * 分阶段 虽说合理的目标应该是利于员工达成的，但往往因能力有限以及一些不确定因素等原因，我们无法对目标作出精确的估计，因此将绩效目标划分为若干个阶段将更有利于对员工的绩效目标达成情况进行跟踪、反馈、辅导和及时修正。 &#160; * 挑战 前面说过制定绩效目标的一个重要目的就是帮助员工在目标达成过程中做到自我提升，因此一个合理的绩效目标是应该具备一定挑战性的，否则员工每次都做同等难度或相似的工作，提升的幅度就会有限，导致成长缓慢。但绩效目标带来的挑战性也要适度，过于困难的目标将导致能力上的不适配，从而导致目标无法按预期达成。 &#169; 2012, bigwhite. 版权所有.]]></description>
			<content:encoded><![CDATA[<p>本文是笔者发表在《<a href="http://www.programmer.com.cn/">程序员</a>》杂志2012年11期上的那篇&ldquo;制定绩效目标的几个重要因素&rdquo;文章的完整版。</p>
<p><font color="#000000">软件开发是一种创造性的工作，这种工作的成果具有不确定性且很难量化，因此经理们在给员工制定绩效目标时多没有统一标准<font face="DejaVu Serif, serif">(</font></font><font color="#000000">即便有也不一定准确，而且在一定程度上还可能会扼杀创造性<font face="DejaVu Serif, serif">)</font></font><font color="#000000">，所采用的方法也是五花八门。不过即便如此，经理们也没有放弃寻找一种更为适合软件开发领域绩效目标制定的方法。笔者也是其中一份子，在这里我将就如何制定出合理的绩效目标，与大家分享一下我的工作实践。</font></p>
<p style="margin-bottom: 0cm; ">一般来说，一个绩效目标从无到有再到达成，至少包含三个关键阶段：准备、制定与实施。若单从绩效目标的制定来说，我们至少需要做好准备和制定这两个阶段的工作。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; "><strong>准备</strong></div>
<p style="margin-bottom: 0cm; ">在与员工进行绩效目标制定之前，经理们应该做足准备工作，这些工作将直接影响到绩效目标制定的优劣。这些准备工作至少包括：</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>深入理解组织全局目标</em></div>
<p style="margin-bottom: 0cm; ">个体绩效目标的制定是为组织内全局目标的达成而服务的。作为经理，自己应该首先对组织的全局目标做好深入的理解，要弄清楚全局目标的内容、自己所带团队的负责范围以及达成该目标的各种约束，如时间、人员以及其他资源配备等。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>明确绩效目标制定的目的和意义</em></div>
<p style="margin-bottom: 0cm; ">为每位员工制定绩效目标到底为了啥？对于这个问题经理们自己首先要做到心中有数。对组织而言，个体绩效目标是全局目标分解后的最基本单元，个人的绩效目标达成是全局目标达成的必要条件；对个体而言，绩效目标的达成过程也是自身知识和技能得以提升的过程；对于经理们而言，通过为员工制定有挑战性的绩效目标来发现和充分挖掘个体的潜力，通过观察员工在达成绩效目标过程中的表现，还可以进一步甄别员工的优劣。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>工作目标初步分解</em></div>
<p style="margin-bottom: 0cm; "><font color="#000000">在与员工进行绩效目标制定之前，经理们应先做好工作目标的初步分解。将团队所承担的大目标分解为员工个体所能承担的小目标。这方面有很多成熟的方法可以借鉴，这里不赘述。</font></p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; "><font color="#000000">*<em>&nbsp;</em></font><em>因人施任</em></div>
<p style="margin-bottom: 0cm; "><font color="#000000">工作有难易之分，人也有优秀与平庸之别。在与员工制定绩效目标前，经理们应该首先根据自己所掌握的情况对下属员工进行分类。有些人适合挑战高度和极限，而有些人却只能按部就班做一些事务性的工作。因此是否能够做到因人施任对于后续绩效目标制定是否合理以及能否顺利达成影响重大。</font></p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; "><strong>制定</strong></div>
<p style="margin-bottom: 0cm; ">做足上述准备工作后，经理们就可以坐下来与员工逐一制定合理的绩效目标了。何为合理的绩效目标？这是个见仁见智的问题。笔者认为一个合理的绩效目标至少应包含如下几个关键属性。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>明确</em></div>
<p style="margin-bottom: 0cm; ">绩效目标中应该包含明确的工作内容、职责范围以及时间约束；明确绩效目标达成的条件；明确实施过程中所能得到的各种支持；明确目标的达成程度与绩效的关系：何种情况为优秀、良好、一般或未达成<font face="DejaVu Serif, serif">(</font>不及格<font face="DejaVu Serif, serif">)</font>。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>适配</em></div>
<p style="margin-bottom: 0cm; ">经理们制定绩效目标可不是为了&ldquo;刁难&rdquo;员工，因此工作目标应与员工能力和意愿适配，才能最大程度上发挥出员工的潜力。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>共识</em></div>
<p style="margin-bottom: 0cm; ">在前期准备中，经理们已经做了初步的工作目标分解以及人选甄别准备工作，但这仅仅是经理们的&ldquo;一厢情愿&rdquo;。合理的绩效目标是需要经理与员工共同讨论、理解、认同并最终达成共识的，否则纯粹行政命令式的目标指派很难称得上&ldquo;合理&rdquo;，目标达成的效果也会大打折扣，很可能影响到组织全局目标的达成。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>分阶段</em></div>
<p style="margin-bottom: 0cm; ">虽说合理的目标应该是利于员工达成的，但往往因能力有限以及一些不确定因素等原因，我们无法对目标作出精确的估计，因此将绩效目标划分为若干个阶段将更有利于对员工的绩效目标达成情况进行跟踪、反馈、辅导和及时修正。</p>
<p style="margin-bottom: 0cm; ">&nbsp;</p>
<div style="margin-bottom: 0cm; ">* <em>挑战</em></div>
<p>前面说过制定绩效目标的一个重要目的就是帮助员工在目标达成过程中做到自我提升，因此一个合理的绩效目标是应该具备一定挑战性的，否则员工每次都做同等难度或相似的工作，提升的幅度就会有限，导致成长缓慢。但绩效目标带来的挑战性也要适度，过于困难的目标将导致能力上的不适配，从而导致目标无法按预期达成。</p>
<p style='text-align:left'>&copy; 2012, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2012/11/17/several-important-factors-in-making-performance-goals/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>知识管理的几点野路子经营策略</title>
		<link>https://tonybai.com/2012/11/04/the-amateur-way-of-knowledge-management/</link>
		<comments>https://tonybai.com/2012/11/04/the-amateur-way-of-knowledge-management/#comments</comments>
		<pubDate>Sun, 04 Nov 2012 15:02:03 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[思考控]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[KM]]></category>
		<category><![CDATA[MediaWiki]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[SNS]]></category>
		<category><![CDATA[weibo]]></category>
		<category><![CDATA[Wiki]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[微博]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[智库]]></category>
		<category><![CDATA[知识库]]></category>
		<category><![CDATA[知识管理]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[管理]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1081</guid>
		<description><![CDATA[时间真是过得飞快，遥想一年前的这个时候我们在产品线的知识管理试水有了一点成绩，便在组织内力推知识管理。领导经过权衡后，也认同了知识管理的重要性， 并随即安排人在组织内部快速建立起了知识库。在最初的一两个月里，临时的知识管理负责人热情很高，做得还算不错，初步地将知识库是什么、如何使用以及组织 知识管理的第一版规范和大家交待清楚了。但随着热情的消逝，知识库管理也随波逐流了，知识管理开始变得名存实亡，这种状态持续了大半年。 领导层的原因我这里不去分析。领导自然有生存问题要考虑。知识管理这等重要但不紧急的事情，还是留给我们去考虑吧。知识管理没有预想中的那样在组织内形成 工作风气，究其原因还是缺少持续的运营。大家知道即便是再好的事物如果缺少了持续经营和关注，也会逐渐消亡的。试想如果新浪微博没有持续的宣传投入哪会有 今天这种地位。 上周和几位组织内的资深同事一同讨论了知识管理的现状，不能再这样下去了，我们要在民间做点工作。由于都不是专业搞知识管理的，所以把我们讨论出来的策略暂且称为&#8220;野路子&#8221;^_^。我这里也将我们产品线兼职做知识管理的MM&#8220;贡献&#8221;给组织，协助做组织知识管理的经营工作。 以下是初步确定的几点经营策略： 1、团队经营 之前只是有一个临时知识负责人，除了职责范围不明确外，一个人&#8220;单打独斗&#8221;也确实心有余而力不足。因此知识管理的经营必须要有一个团队，可以是实体专门团 队，也可以是虚拟团队。团队必须有专门的负责人，专职也好，兼职也罢，有胜于无。团队应该按照做项目或做产品的方式去对待知识管理，有计划、有目标、有阶 段步骤的去经营；另外团队内部人员有分工，有些负责策划、有些负责技术、有些负责推广等，总之团队经营是一个组织搞好知识管理的必要条件。 2、借鉴和效仿 我们不是专业的知识管理团队，但业界却有好多已经做得很成功的知识管理策略值得我们借鉴和效仿，比如智库(MBAlib)等。另外一些知名SNS服务的提供商的经营策略也是值得我们学习的，即便知识管理与通常的SNS有很大不同。 以下列举一些参考策略： - 培养达人(名人)，影响长尾。新浪从其博客开始一直就是这么做的，后期微博更是复制这一策略，腾讯微博也是照搬效仿。在组织内部，培养分享和总结知识的达 人，树立他们在知识库贡献中的领袖地位。并在这一过程中，通过宣传和引导，逐渐让更多人了解知识库，效仿达人们形成总结和分享知识的良好工作习惯。 - 持续让大家被动关注。通过各种手段让大家持续感受到知识管理在组织内的存在，比如定期全员发送知识简报、组织知识管理达人秀活动、白板宣传等方式。&#160; - 持续改善页面体验。一个易用和好用，可以快速上手的知识库是让大家积极参与到知识管理中的一个前提条件。因此作为知识管理重要环节的知识库，我们务必做到对其使用体验的持续改善。通过各种技术手段，让大家易访问、易编辑、易归类、易检索等等。 3、引入竞争机制，激发荣誉感 在知识管理过程中引入竞争机制。就像新浪微博勋章系统一样，为知识达人们分级，让大家产生知识分享的荣誉感。另外如果组织内部由多个子部门组成（就像我所在的组织那样），还可在子部门间引入竞争机制，这块具体采用何种机制就要看具体情况而定了，比如通过排名，或也给部门授予类似勋章的机制。 4、善用行政手段 知识的来源有随机自发的，也有规定必须的。因此有些知识整理和分享是在组织行政规定之下必须要做的，这部分内容也不能忽略，这可以让知识库内容更加丰满。另外还可以从长远考虑，将子部门对组织知识库的贡献纳入到子部门的业绩当中去。这手段有些别扭但可能真的有效。 &#169; 2012, bigwhite. 版权所有.]]></description>
			<content:encoded><![CDATA[<p>时间真是过得飞快，遥想一年前的这个时候我们在产品线的<a href="http://tonybai.com/2011/11/23/those-things-about-knowledge-management/">知识管理试水</a>有了一点成绩，便在组织内力推知识管理。领导经过权衡后，也认同了知识管理的重要性， 并随即安排人在组织内部快速建立起了知识库。在最初的一两个月里，临时的知识管理负责人热情很高，做得还算不错，初步地将知识库是什么、如何使用以及组织 知识管理的第一版规范和大家交待清楚了。但随着热情的消逝，知识库管理也随波逐流了，知识管理开始变得名存实亡，这种状态持续了大半年。</p>
<p>	领导层的原因我这里不去分析。领导自然有生存问题要考虑。知识管理这等重要但不紧急的事情，还是留给我们去考虑吧。知识管理没有预想中的那样在组织内形成 工作风气，究其原因还是缺少持续的运营。大家知道即便是再好的事物如果缺少了持续经营和关注，也会逐渐消亡的。试想如果<a href="http://weibo.com">新浪微博</a>没有持续的宣传投入哪会有 今天这种地位。</p>
<p>	上周和几位组织内的资深同事一同讨论了知识管理的现状，不能再这样下去了，我们要在民间做点工作。由于都不是专业搞知识管理的，所以把我们讨论出来的策略暂且称为&ldquo;野路子&rdquo;^_^。我这里也将我们产品线兼职做知识管理的MM&ldquo;贡献&rdquo;给组织，协助做组织知识管理的经营工作。</p>
<p>	以下是初步确定的几点经营策略：</p>
<p>	<b>1、团队经营</b></p>
<p>	之前只是有一个临时知识负责人，除了职责范围不明确外，一个人&ldquo;单打独斗&rdquo;也确实心有余而力不足。因此知识管理的经营必须要有一个团队，可以是实体专门团 队，也可以是虚拟团队。团队必须有专门的负责人，专职也好，兼职也罢，有胜于无。团队应该按照做项目或做产品的方式去对待知识管理，有计划、有目标、有阶 段步骤的去经营；另外团队内部人员有分工，有些负责策划、有些负责技术、有些负责推广等，总之团队经营是一个组织搞好知识管理的必要条件。</p>
<p>	<b>2、借鉴和效仿</b></p>
<p>	我们不是专业的知识管理团队，但业界却有好多已经做得很成功的知识管理策略值得我们借鉴和效仿，比如<a href="http://wiki.mbalib.com">智库</a>(MBAlib)等。另外一些知名SNS服务的提供商的经营策略也是值得我们学习的，即便知识管理与通常的SNS有很大不同。</p>
<p>	以下列举一些参考策略：</p>
<p>	- <strong>培养达人(名人)，影响长尾</strong>。新浪从其博客开始一直就是这么做的，后期微博更是复制这一策略，腾讯微博也是照搬效仿。在组织内部，培养分享和总结知识的达 人，树立他们在知识库贡献中的领袖地位。并在这一过程中，通过宣传和引导，逐渐让更多人了解知识库，效仿达人们形成总结和分享知识的良好工作习惯。</p>
<p>	- <strong>持续让大家被动关注。</strong>通过各种手段让大家持续感受到知识管理在组织内的存在，比如定期全员发送知识简报、组织知识管理达人秀活动、白板宣传等方式。&nbsp;</p>
<p>	- <strong>持续改善页面体验。</strong>一个易用和好用，可以快速上手的知识库是让大家积极参与到知识管理中的一个前提条件。因此作为知识管理重要环节的知识库，我们务必做到对其使用体验的持续改善。通过各种技术手段，让大家易访问、易编辑、易归类、易检索等等。</p>
<p>	<b>3、引入竞争</b><b>机制，激发荣誉感</b></p>
<p>	在知识管理过程中引入竞争机制。就像新浪微博勋章系统一样，为知识达人们分级，让大家产生知识分享的荣誉感。另外如果组织内部由多个子部门组成（就像我所在的组织那样），还可在子部门间引入竞争机制，这块具体采用何种机制就要看具体情况而定了，比如通过排名，或也给部门授予类似勋章的机制。</p>
<p>	<b>4、善用行政手段</b></p>
<p>	知识的来源有随机自发的，也有规定必须的。因此有些知识整理和分享是在组织行政规定之下必须要做的，这部分内容也不能忽略，这可以让知识库内容更加丰满。另外还可以从长远考虑，将子部门对组织知识库的贡献纳入到子部门的业绩当中去。这手段有些别扭但可能真的有效。</p>
<p style='text-align:left'>&copy; 2012, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2012/11/04/the-amateur-way-of-knowledge-management/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>改善技术布道效果的几个实践</title>
		<link>https://tonybai.com/2012/10/26/some-practice-on-improving-tech-preach/</link>
		<comments>https://tonybai.com/2012/10/26/some-practice-on-improving-tech-preach/#comments</comments>
		<pubDate>Fri, 26 Oct 2012 04:47:29 +0000</pubDate>
		<dc:creator>bigwhite</dc:creator>
				<category><![CDATA[技术志]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[Blogger]]></category>
		<category><![CDATA[CSDN]]></category>
		<category><![CDATA[Programmer]]></category>
		<category><![CDATA[博客]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[思考]]></category>
		<category><![CDATA[感悟]]></category>
		<category><![CDATA[技术布道]]></category>
		<category><![CDATA[期刊]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[程序员杂志]]></category>
		<category><![CDATA[管理]]></category>

		<guid isPermaLink="false">http://tonybai.com/?p=1070</guid>
		<description><![CDATA[本文是笔者发表在《程序员》杂志2012年08期上的那篇&#8220;改善技术布道效果的几个实践&#8221;文章的完整版。 &#160; 技术布道不易，想取得良好的效果就更难了。下面是笔者总结的几个有助于改善技术布道效果的有效实践,这里给大家分享一下。 &#160; 自我认知 &#160; 技术布道前,布道者首先要做好自我认知,这将有助于布道者确认自己是否胜任此次布道以 及采用何种布道策略以赢得更好的效果。认知的内容包括:自己是否精通这方面的技术。若 只知皮毛,布道效果将大打折扣;自己在组织内部是何种资历与角色。如果你是职场新人, 人微言轻,布道效果势必会受到影响。 &#160; 环境认知 &#160; 组织内的技术氛围对技术布道效果有着重要影响,因此布道前还要做好环境认知。这包括: 组织内成员是否拥有一个开放的心态,乐于接受新鲜事物;组织内部是否为大家建立起一个 有影响力的布道平台并设立奖励机制;管理者是否积极支持技术创新并接受因此带来的成本 损耗。最终布道者应根据环境认知的结果来选择适合该组织的布道策略和方式。 &#160; 精选主题 &#160; 技术布道的主题无疑是影响布道效果的最直接因素,因此在选择布道主题时务必谨慎而为。 选题时要把握住一个至关重要的原则,那就是你要布道的主题一定要能够给组织带来价值。 这些价值可体现在多个方面,比如解决了困扰大家已久的问题、提高了工作效率、降低了风 险或增进了理解等等。从笔者的多年布道的经验来看,从问题出发选题是个不错的选择。当 你对组织内部存在的问题深入分析和理解后,你的布道主题就很容易确定了。而且因为这个 主题与大家的日常工作息息相关,你可以相对容易地获得良好的布道效果。相比之下,那些 纯粹为了引入新技术而选择的主题就好比无源之水、无本之木,是很难获得良好效果的,其 布道的新技术在组织内也是不会有长久生命力的。 &#160; 受众分析 &#160; 技术布道的主题多数并不具备普适性,它只是在一定受众范围内是有生命力的,因此在谋划 布道之前要做好布道受众的分析,识别出适宜本次布道的受众。一旦确定了受众范围,布道 者就可以在布道之前先对受众以及他们所遇到的问题进行相关的分析和调查,使得布道更有 针对性,并取得事半功倍的效果。 &#160; 把握时机 &#160; 俗话说:&#8220;来得早不如来的巧&#8221;。技术布道也是一样:&#8220;布得早不如布得巧&#8221;。良好布道时机的 把握对赢得良好布道效果有着很大影响。如果你非要向一个下周就要做产品发布的产品线推广 JUnit,非要向一个工期仅有三个月、繁忙异常的产品线推广 CMMI 理论,那你肯定是自 找苦吃。人家都忙得脚打后脑壳了,你还给人家添乱,显然你选错了布道时机。 &#160; 制定策略 &#160; 制定一个适宜的布道策略对取得良好布道效果作用很大。这里介绍一些有效的策略,大家可 以参考。 &#160; - 以点及面。受众面越大,布道的效果可能越不理想。因此,最好先在小范围内进行试点,并在取得成果后再扩大布道范围。&#8220;事实胜于雄辩&#8221;,小范围布道取得的成功结果会让更多人见识到该主题的价值,并带着更加积极的心态参与到这个主题的后续布道中去。这点在说服上层管理者时也尤为有用。 &#160; - 划分阶段。如果布道主题涵盖范围较大,可将布道划分为多个阶段,并逐段实施。每实施一段后,还可以根据受众的反馈进行自我调整和完善,这有助于你在下一个阶段的布道中取得更佳的效果。 [...]]]></description>
			<content:encoded><![CDATA[<p>本文是笔者发表在《<a href="http://www.programmer.com.cn/">程序员</a>》杂志2012年08期上的那篇&ldquo;改善技术布道效果的几个实践&rdquo;文章的完整版。</p>
<div>&nbsp;</div>
<div>技术布道不易，想取得良好的效果就更难了。下面是笔者总结的几个有助于改善技术布道效果的有效实践,这里给大家分享一下。</div>
<div>&nbsp;</div>
<div><strong>自我认知</strong></div>
<div>&nbsp;</div>
<div>技术布道前,布道者首先要做好自我认知,这将有助于布道者确认自己是否胜任此次布道以</div>
<div>及采用何种布道策略以赢得更好的效果。认知的内容包括:自己是否精通这方面的技术。若</div>
<div>只知皮毛,布道效果将大打折扣;自己在组织内部是何种资历与角色。如果你是职场新人,</div>
<div>人微言轻,布道效果势必会受到影响。</div>
<div>&nbsp;</div>
<div><strong>环境认知</strong></div>
<div>&nbsp;</div>
<div>组织内的技术氛围对技术布道效果有着重要影响,因此布道前还要做好环境认知。这包括:</div>
<div>组织内成员是否拥有一个开放的心态,乐于接受新鲜事物;组织内部是否为大家建立起一个</div>
<div>有影响力的布道平台并设立奖励机制;管理者是否积极支持技术创新并接受因此带来的成本</div>
<div>损耗。最终布道者应根据环境认知的结果来选择适合该组织的布道策略和方式。</div>
<div>&nbsp;</div>
<div><strong>精选主题</strong></div>
<div>&nbsp;</div>
<div>技术布道的主题无疑是影响布道效果的最直接因素,因此在选择布道主题时务必谨慎而为。</div>
<div>选题时要把握住一个至关重要的原则,那就是你要布道的主题一定要能够给组织带来价值。</div>
<div>这些价值可体现在多个方面,比如解决了困扰大家已久的问题、提高了工作效率、降低了风</div>
<div>险或增进了理解等等。从笔者的多年布道的经验来看,从问题出发选题是个不错的选择。当</div>
<div>你对组织内部存在的问题深入分析和理解后,你的布道主题就很容易确定了。而且因为这个</div>
<div>主题与大家的日常工作息息相关,你可以相对容易地获得良好的布道效果。相比之下,那些</div>
<div>纯粹为了引入新技术而选择的主题就好比无源之水、无本之木,是很难获得良好效果的,其</div>
<div>布道的新技术在组织内也是不会有长久生命力的。</div>
<div>&nbsp;</div>
<div>
<div><strong>受众分析</strong></div>
<div>&nbsp;</div>
<div>技术布道的主题多数并不具备普适性,它只是在一定受众范围内是有生命力的,因此在谋划</div>
<div>布道之前要做好布道受众的分析,识别出适宜本次布道的受众。一旦确定了受众范围,布道</div>
<div>者就可以在布道之前先对受众以及他们所遇到的问题进行相关的分析和调查,使得布道更有</div>
<div>针对性,并取得事半功倍的效果。</div>
<div>&nbsp;</div>
<div><strong>把握时机</strong></div>
<div>&nbsp;</div>
<div>俗话说:&ldquo;来得早不如来的巧&rdquo;。技术布道也是一样:&ldquo;布得早不如布得巧&rdquo;。良好布道时机的</div>
<div>把握对赢得良好布道效果有着很大影响。如果你非要向一个下周就要做产品发布的产品线推广 JUnit,非要向一个工期仅有三个月、繁忙异常的产品线推广 CMMI 理论,那你肯定是自</div>
<div>找苦吃。人家都忙得脚打后脑壳了,你还给人家添乱,显然你选错了布道时机。</div>
<div>&nbsp;</div>
<div><strong>制定策略</strong></div>
<div>&nbsp;</div>
<div>制定一个适宜的布道策略对取得良好布道效果作用很大。这里介绍一些有效的策略,大家可</div>
<div>以参考。</div>
<div>&nbsp;</div>
<div>- <em>以点及面</em>。受众面越大,布道的效果可能越不理想。因此,最好先在小范围内进行试点,并在取得成果后再扩大布道范围。&ldquo;事实胜于雄辩&rdquo;,小范围布道取得的成功结果会让更多人见识到该主题的价值,并带着更加积极的心态参与到这个主题的后续布道中去。这点在说服上层管理者时也尤为有用。</div>
<div>&nbsp;</div>
<div>
<div>- <em>划分阶段</em>。如果布道主题涵盖范围较大,可将布道划分为多个阶段,并逐段实施。每实施一段后,还可以根据受众的反馈进行自我调整和完善,这有助于你在下一个阶段的布道中取得更佳的效果。</div>
<div>&nbsp;</div>
<div>- <em>善于借势</em>。如果你布道的主题在实施之前获得了管理层的认可,那不妨将你的布道过程名正言顺地打上官方之烙印。相比于职级对等的&ldquo;水平布道&rdquo;而言,借管理层之势的&ldquo;垂直布道&rdquo;势必更能引起大家的关注,提升大家参与的积极性。</div>
<div>&nbsp;</div>
<div><strong>心理建设</strong></div>
<div>&nbsp;</div>
<div>大多布道者都是技术专家,他们对技术充满热情,对布道乐此不疲,总是希望能够通过自己</div>
<div>持续不断的布道使得组织获得在技术能力等多方面上的提升。但布道的结果有成功也有失败，布道者也是人,失败的苦果并不容易下咽。因此布道者在布道前先要做好心理建设,最大可能地减少布道失败对自己的负面伤害。</div>
<div>&nbsp;</div>
<div>- <em>建立信心和耐心</em>。只要你认定某种布道会给组织带来价值,那么就不要放弃,要有些耐心,充分考虑使用上面所述的策略和方法。</div>
<div>&nbsp;</div>
<div>- <em>降低目标预期</em>。这是个心理把戏,在布道前适当降低些目标预期,那么即使布道效果未达到你的要求，带给你的伤害也不至于很大,有利于保留你热情的火种。</div>
<div>&nbsp;</div>
<div>(全文完)</div>
</p></div>
</div>
<p style='text-align:left'>&copy; 2012, <a href='https://tonybai.com'>bigwhite</a>. 版权所有. </p>
]]></content:encoded>
			<wfw:commentRss>https://tonybai.com/2012/10/26/some-practice-on-improving-tech-preach/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
