原创 技术演讲

    上周四的时候，对着公司很多人做了一个相对简短的Presentation，是给其他工程师科普一些相关的技术知识。虽然在小组里练过两次，在大组里头练过两次，还是有些紧张和失误的地方。今明2天在公司里头被培训REDX，觉得想要讲好一个东西并不容易。谈谈我个人对于此的一些看法：

1.做一个Presentation的前提，就是你必须对某个主题有着相对深入的认知或者本身你就得有足够的经验和体会。在讲一个方面的内容的时候，演讲者本人的思绪就是跳跃和浮动的，如果思绪在某个地方停顿和卡住，那么这个地方就会成为一个败笔；更有可能出现的情况是，本身谈的一些内容就是错误和片面的，这个事情就大了。所以，你即使自己很清楚的知道整个事情的运行，也得花时间去看研究一些与之联系的理论（书本）、业界情况（论文）和其他材料。因此首要做的事情，在圈定主题以后，得整理相关的资料使得信息更为全面。

2.做一个结构清楚、信息干练和图文结合的PPT材料。

2.1 结构清楚：由于演讲的时间有限，而且必须把演讲和问答的时间设置为6：4甚至更少，实际的情况，你会遇到听者更多的问题，互动环节也是能够把演讲讲精彩，把材料讲清楚的一个重要的事情。结构清楚可以让听者清楚的知道涉及的内容，避免在开始就遇到后面需要涉及的提问问题；也能让读者在听之前就有机会概览整个演讲内容，找出自己感兴趣的地方。

2.2 信息干练：事实上，如果索引材料有着太多的信息，很容易让听众产生只需要阅读就能获取较多信息的判断，而忽略了演讲者需要添加的细节和分析过程，这部分内容比结论更为重要。更何况这其中产生的思辨，能够给人以更为直观的感受。

2.3 图文结合：图给人以浅显的直观印象，文给人以主干和节点性概述；两者的结合使用将使得主题脉络跃然纸上，为体会和提问产生足够的铺垫。

   我个人对这方面做得比较糟糕，不过我相信用心做用心改，仔细体会容易得到一些自己的风格。

3.找同事进行试讲

   做完了PPT材料和自己的演讲稿，重要的就是找人练了。一方面是对材料本身的修正，你在讲的过程中容易得到更多的反馈和问题，使得材料可以更快的被改好；另外一方面就是演讲本身的细节问题，这方面建议大家可以google一下，关键字为Presetation技巧，一篇典型的文章为：口头报告(presentation)技巧。

   再聊点相关的问题，在我工作前后的两个公司，就有人前仆后继的想要推进形成Presentation的文化。搞到后面，这个事情就从交流知识演变成为政绩工程，或者干脆就完全消失了。这里不妨探究一下这个事情的几个关键的点：

1.多长的周期，多广的范围：这个事情的问题在于，你要让多少人去涉及，听的人的范围和讲的人的范围。首先确定的事情，间隔周期不能过短，也不能过长，要让人有时间准备也要让人有时间去听。

2.选题和激励：确定主题是个很让人难办的事情，很多主题可能有人很了解，但是对其他的人可能并没有太多的意义。因此需要让人去选择合适的话题，也要激励人去做抛砖引玉的材料。

3.改进和意义：事实上，做一个交流，对演讲者本身是有意义的，对听众也是有意义的。我发现大部分的人，都不对身边发生的事情进行记录，其中的思考、感悟和问答，就那么匆匆的溜掉了；在整个过程中也没有人记录，以把一些精彩的东西整理出来，给大部分不记录的xdjm一些“纪念”，整个改进的空间就没有了，Presentation的意义就少了很多。

   我个人觉得，很多团队创造力的问题，归咎于体制是没有出路的。在小范围内，不断尝试和创新，可以把一个团队塑造的很好。当然，前提是你得有人带着去做，就如同个人没有在工作以内和以外的时间，去看一些新东西，去思考和总结些材料，总是在原地打转转，说不定还不进则退呢。

PS：

1.请容忍我的絮絮叨叨，我的思绪现在一直颇为散乱，可能以后把这些随想杂文细细重读一遍，分头整理，说不定还能投投稿。

2.2天的REDX培训，半天的考试，折腾完以后我打算写个概览出来，虽然我们这里参加的大部分是产品工程师和质量工程师，不过我想把这个方法放到设计中的Validation也会是个好主意。我个人已经离硬件工程师，离电子设计有些距离了。当初来整车企业之前，苑领导给我的建议是过早进入整车企业并不是一个很好的选择现在看来，真是有得有失；站得巨人的肩膀上，看得东西越来越多，触目所及的可下手的地方却有些模糊了。