<?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>剁椒鱼头 &#187; 实施</title>
	<atom:link href="http://www.yanghui.org/tag/%e5%ae%9e%e6%96%bd/feed" rel="self" type="application/rss+xml" />
	<link>http://www.yanghui.org</link>
	<description>像随时要离开一样准备好，像永远要留下来一样用心</description>
	<lastBuildDate>Tue, 31 Jan 2012 13:35:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>有意思的培训&#8211;项目交付</title>
		<link>http://www.yanghui.org/2009/09/23/362.html</link>
		<comments>http://www.yanghui.org/2009/09/23/362.html#comments</comments>
		<pubDate>Wed, 23 Sep 2009 08:57:53 +0000</pubDate>
		<dc:creator>Felix</dc:creator>
				<category><![CDATA[企业信息化]]></category>
		<category><![CDATA[奇思妙想]]></category>
		<category><![CDATA[工作]]></category>
		<category><![CDATA[未分类]]></category>
		<category><![CDATA[随感&杂谈]]></category>
		<category><![CDATA[share]]></category>
		<category><![CDATA[培训]]></category>
		<category><![CDATA[实施]]></category>

		<guid isPermaLink="false">http://www.becxo.com/2009/09/23/362.html</guid>
		<description><![CDATA[最近一直忙着客户项目的交付，由于项目的特殊性需要给客户做培训，陆陆续续的客户做了三次培训，这个培训包括业务流程的，系统操作的，但是更多的还是操作培训，自己也当了三次培训助理，主要负责培训前一些资料准备（不包括培训用PPT）,现场的的辅导支持等，结合以前自己参与的一些培训，发现培训其实有很多有意思的值得思考的事件。 由于是就项目交付来培训，说白了就是培训用户如何来使用某套系统，对一些其他客户常见的问题的如何解决，所以整个培训的从课件设计到辅导只有一个目的：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。 培训课件设计 以前也参加过一些其他公司的各种培训、分享，培训讲师的课件大致分成两类：一类上来就是个Guider，然后照着条目往下讲，没有什么好看的图，也没有什么很玄的动画，但是这中讲师讲的内容往往很实在，一开始你就知道他要讲啥，而且该讲的绝对不会少；另外一类是上来就是一堆很玄的效果，然后开始给你讲一堆东西，但是这堆东西每一个你都有疑问，往往你对前一页的PPT内容有一些挑战的时候，下一页或者下几页就会出来答案，你不听到最后肯定不晓得他要讲啥。（可能是参加的少，反正就只是遇到这么两个类型。） 从听众的的角度来看，虽然第一类PPT的设计不美观，但是叙事方式很符合自己口味，因为一看Guider 我就大概知道这个培训是否有继续听下去，或者是继续认真听下去的必要。第二类如果听到最后发现讲了一通自己不关心的问题那就不好了。 &#160; 这三次培训的时候也试着就头写的ppt提一些建议，甚至还试着建议增删某些地方，这时候会设想自己是前来培训的学员，试着想如何才能了解这套系统，熟悉这套系统，进而利用这套系统来完成自己的工作，来提高工作效率。感觉这个时候不像是在做一个PPT，更像是在设计一个剧本，台上一分钟，台下十年工，果不其然啊。但是往往由于自己对系统太熟悉，很容易去忽视一些基本概念性东西的描述，而在培训现场往往很多的参与者因为这些概念性的东西提出一些意想不到的问题，从而需要再次加深其对这些概念的理解。 现场辅导 公司的项目有个特色：管理类项目，而且还是那种全员参与参与的管理类项目。 而往往负责确定需求的只是某个特定的部门或者某个特定的领导，而这个特定的部门或者领导也不会或者很少的将这些既定的需求去跟全员沟通，或者沟通的不够测地，特别是当调整原来业务流程的时候，参与培训的人员对整体的业务可能不熟悉。在培训的过程中尽管已经给他演示了这个业务流程有调整，但是这部分人中的个别人物还是会有一些不理解，不理解的直接后果就是认为你们的系统有错。如果这时候因为这个别人物会带动其他人对你这个系统的怀疑，一开始怀疑整个培训现场的就开始沸腾，OMG这个培训有多失败可想而知了，这时候我认为培训助理需要做的事情就是“搞定”这部分人，可以试着走到他/她跟前跟他/她沟通“您关于业务部分的困惑我们可以理解，关于这部分的业务问题，您可以在培训辅导后咱们再做一个交流，这里有一份调整后的业务流程图，您可以试着先根据这个流程照这老师的思路先熟悉下操作。”一般情况下，这些极个别人物都能很好的接受你的提议，按照流程图理解，基本都能很好的完成培训，实在不明白的，培训间隙或者培训后单独开小灶，补火！当然如果是刺儿，另当别论。 众所周知，是个系统就会有BUG，强大微软、google还是补丁不断，如果培训现场出现了Bug，只要不是致命的，统一都先跟学员沟通“请您描述下您刚才的操作，我们查询下原因。”同时记录下来，回去备查，修改bug。 对于从操作角度提出一些要求、建议的学员，无论建议好坏，我们需要满足他们的要求“您好，您的这个建议非常好，我们回去再综合讨论下，看能否做一些修改，当然也欢迎您提更多的好的意见。”记录下来，回去跟开发组讨论，需要分析一下提这个建议的原因，觉得好的建议采纳，觉得不好的建议，也要及时给提出建议人一个反馈。 记住我们的目的只有一个：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。 P.S.公司核心价值里的一条就是在正确的时间里做正确的事情，找对了目标，在培训时只有一件事儿：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。]]></description>
			<content:encoded><![CDATA[<p>最近一直忙着客户项目的交付，由于项目的特殊性需要给客户做培训，陆陆续续的客户做了三次培训，这个培训包括业务流程的，系统操作的，但是更多的还是操作培训，自己也当了三次培训助理，主要负责培训前一些资料准备（不包括培训用PPT）,现场的的辅导支持等，结合以前自己参与的一些培训，发现培训其实有很多有意思的值得思考的事件。</p>
<p>由于是就项目交付来培训，说白了就是培训用户如何来使用某套系统，对一些其他客户常见的问题的如何解决，所以整个培训的从课件设计到辅导只有一个目的：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。</p>
<p>培训课件设计</p>
<p>以前也参加过一些其他公司的各种培训、分享，培训讲师的课件大致分成两类：一类上来就是个Guider，然后照着条目往下讲，没有什么好看的图，也没有什么很玄的动画，但是这中讲师讲的内容往往很实在，一开始你就知道他要讲啥，而且该讲的绝对不会少；另外一类是上来就是一堆很玄的效果，然后开始给你讲一堆东西，但是这堆东西每一个你都有疑问，往往你对前一页的PPT内容有一些挑战的时候，下一页或者下几页就会出来答案，你不听到最后肯定不晓得他要讲啥。（可能是参加的少，反正就只是遇到这么两个类型。）</p>
<p>从听众的的角度来看，虽然第一类PPT的设计不美观，但是叙事方式很符合自己口味，因为一看Guider 我就大概知道这个培训是否有继续听下去，或者是继续认真听下去的必要。第二类如果听到最后发现讲了一通自己不关心的问题那就不好了。</p>
<p> <span id="more-362"></span>
<p>&#160;</p>
<p>这三次培训的时候也试着就头写的ppt提一些建议，甚至还试着建议增删某些地方，这时候会设想自己是前来培训的学员，试着想如何才能了解这套系统，熟悉这套系统，进而利用这套系统来完成自己的工作，来提高工作效率。感觉这个时候不像是在做一个PPT，更像是在设计一个剧本，台上一分钟，台下十年工，果不其然啊。但是往往由于自己对系统太熟悉，很容易去忽视一些基本概念性东西的描述，而在培训现场往往很多的参与者因为这些概念性的东西提出一些意想不到的问题，从而需要再次加深其对这些概念的理解。</p>
<p>现场辅导</p>
<p>公司的项目有个特色：管理类项目，而且还是那种全员参与参与的管理类项目。</p>
<p>而往往负责确定需求的只是某个特定的部门或者某个特定的领导，而这个特定的部门或者领导也不会或者很少的将这些既定的需求去跟全员沟通，或者沟通的不够测地，特别是当调整原来业务流程的时候，参与培训的人员对整体的业务可能不熟悉。在培训的过程中尽管已经给他演示了这个业务流程有调整，但是这部分人中的个别人物还是会有一些不理解，不理解的直接后果就是认为你们的系统有错。如果这时候因为这个别人物会带动其他人对你这个系统的怀疑，一开始怀疑整个培训现场的就开始沸腾，OMG这个培训有多失败可想而知了，这时候我认为培训助理需要做的事情就是“搞定”这部分人，可以试着走到他/她跟前跟他/她沟通“您关于业务部分的困惑我们可以理解，关于这部分的业务问题，您可以在培训辅导后咱们再做一个交流，这里有一份调整后的业务流程图，您可以试着先根据这个流程照这老师的思路先熟悉下操作。”一般情况下，这些极个别人物都能很好的接受你的提议，按照流程图理解，基本都能很好的完成培训，实在不明白的，培训间隙或者培训后单独开小灶，补火！当然如果是刺儿，另当别论。</p>
<p>众所周知，是个系统就会有BUG，强大微软、google还是补丁不断，如果培训现场出现了Bug，只要不是致命的，统一都先跟学员沟通“请您描述下您刚才的操作，我们查询下原因。”同时记录下来，回去备查，修改bug。</p>
<p>对于从操作角度提出一些要求、建议的学员，无论建议好坏，我们需要满足他们的要求“您好，您的这个建议非常好，我们回去再综合讨论下，看能否做一些修改，当然也欢迎您提更多的好的意见。”记录下来，回去跟开发组讨论，需要分析一下提这个建议的原因，觉得好的建议采纳，觉得不好的建议，也要及时给提出建议人一个反馈。</p>
<p>记住我们的目的只有一个：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。</p>
<p>P.S.公司核心价值里的一条就是在正确的时间里做正确的事情，找对了目标，在培训时只有一件事儿：让客户学会使用系统，更好、更快捷的完成他们的工作，让客户觉得系统有价值。</p>
]]></content:encoded>
			<wfw:commentRss>http://www.yanghui.org/2009/09/23/362.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

