【PPT时代，我们都在写PPT】

微软公司的OFFICE套件太伟大了，尤其是三大核心组件，几乎成为全人类日常工作的通用工具。人们用Word编辑文档，用Excel处理数据，那么PowerPoint这个生产PPT的工具，又扮演着什么角色呢？

第一类PPT是用于整理思路，甚至于扮演"思维脑图"（MindManager）的角色。写作者将主要内容简单扼要地罗列出来，就形成了备忘录，提纲挈领，记录重点。这个时候的PPT多是文字，相对于长篇大论字斟句酌的Word文档，简洁的PPT显得更有效率。

第二类PPT图文并茂，主要用于传播，简单明了的图片结合清晰准确的文字，再把配色美学都加进来，表现形式大于实质内容。发布会上业界大佬对着美轮美奂的PPT口吐莲花，由台下观众自行把看到的内容和听到的演讲整合在一起，传播效果非常好。

第三类PPT，图片多，文字更多，这种美观不足而又内容丰富的PPT，往往是在内部关系复杂的体系中，进行沟通的工具。

一种情况是演讲者不是PPT的作者，因此PPT的作者需要把内容充分体现出来，生怕演讲者对内容不熟悉，或者产生信息疏漏。

另一种情况是听的人不专业，甚至连文字准确转述的能力都不具备，作者把海量信息写在PPT里，便于真正的读者看得更仔细。

有人说，以前外企里最受重用的是两种人：一种是PPT写得好的，一种是EXCEL用得棒的；这两个技能是职场必备，别的都不重要。

【多层级的体系里，PPT文化盛行】

在多层级的组织中，PPT主要以三种方式出现：下行、上行和枪手。

所谓下行，就是向下布置工作。由于组织层级多，工作任务需要层层分解，上级单位在布置工作时，往往需要把具体要求说清楚，这样便于监督和落实。相对于正式文件，PPT的效率还是相对高些，所以经常被采用。

所谓上行，就是向领导汇报。多层级的组织中，越是强调细节和专业的领导，就会催生越多的PPT。因为即便领导以前是基层做过具体工作，当领导久了，管的事儿多了，自然难以顾及很多具体细节；然而多年的工作习惯、对掌控细节的偏好，以及进行决策的需要，都需要了解一线情况，他的信息获取就主要依赖下级的汇报。领导下面的领导可能也是类似情况，需要通过下级的汇报才能满足上级对他的要求。以此类推，每一级都是领导，都需要汇报和决策；而如果得不到领导的认可和支持，就难以获得推进工作的资源和机会。在实际工作中，资源是有限的，为了在与同级的竞争中获取更多的资源，往往取决于你是否能写出更好的PPT。

所谓枪手，就是替领导或者客户写PPT。如今的竞争已经从PPT开始了，形式内容模板色调都要高质量，绝不能只靠演讲者的思路和内容来争胜。就像以前秘书给领导写稿子一样，现在需要替领导写PPT，帮客户写PPT，枪手可能还不止一个。经常有这样的场景：领导侃侃而谈，旁边的助手奋笔疾书做记录，甚至将录音带回去给枪手们进行场景重现，模拟领导的思维和观点，把PPT画出来。

【软件开发环节多，导致效率低】

如今很多行业的信息化、数字化还处于初级阶段，IT技能还是高大上的专业。企业内部的分工协作往往是，先由业务部门将需求提交给IT部门，然后IT部门完成开发，再交付给业务部门。两个部门之间经常会出现扯皮问题：IT部门嫌业务部门的需求不明确，业务部门嫌IT部门不支持。

如果业务和IT是两个独立的部门，那么这两个部门之间的衔接，主要靠完整的"需求文档"。对于业务部门来说，做一个完整而不变更的需求是非常困难的；而在IT部门眼中，不能依据一个有不确定性的需求文档进行开发。因此两部门经常会围绕需求进行争论，即便达成妥协的结果，也往往会消耗大量的时间。

而互联网企业的先进性就体现出来了，几个人组成的小团队里既有业务人员又有IT人员，甚至根本就不区分业务和技术。组合方式轻灵，业务的试错和优化周期非常短，既有活力又有效率。

比如同样是数据分析类的需求。传统企业里业务部门提出分析需求，然后让IT部门去实现，IT部门做完之后将结果反馈回业务部门，业务部门再提出变更需求要IT部门继续做，几个来回之后，大家都烦了。而在互联网企业呢？早就自己去写SQL了。

传统企业的软件开发，是一个环节完成之后再进入到下一个环节，流程越长，效率越低。可笑的是：这种长周期长流程是软件工程教科书里的标准动作，而以稳定可靠为目标的软件开发模式已经难以适应发展。

【写软件将成为未来的基本技能】

大企业的组织架构，传统软件的开发模式，一个是纵向，一个是横向，都体现为多环节，越来越制约生产力的发展。从发展的角度看，这是一定要改变的，否则难以适应未来。

设想一下，如果企业里各个环节的领导不需要下属写PPT，而是自身就能将自己的思想以图文并茂的方式展现出来，是不是效率会高些？

设想一下，如果业务人员自己都能写代码，不必再把自己的想法告知给IT人员，再由他们琢磨怎么开发，是不是效率会高些？

DevOps就是从传统软件工程向快速迭代演进的路径之一，打破了"开发"和"运维"的边界，让IT更加敏捷；然而这还远远不够，链条还是太长，还有很多值得优化的地方。

设想一下，如果软件实现了充分解耦，上层的应用全部依托底层的高扩展性平台实现敏捷开发、快速迭代，是不是软件的开发效率会大大提升？

设想一下，如果企业里对下级授权，不必全由领导决策，PPT会不会少很多，企业的运作效率是不是也就大大提升？

这些设想，都是有很多前提的。如果企业内部管理和授权模式得不到有效管控，那么授权可能变成失控，变得越快，死得也越快。

类似的，如果软件架构不合理，平台能力不足，解耦不充分，各个组件模块之间还有复杂的关联关系，那么就没有人清楚修改会影响到什么，有多大风险，只有等死这一条路。

【后记】

一个朋友给孩子报志愿的时候找我，问软件工程专业未来的发展前途。我的回答是：未来编程会和开车、外语、写PPT一样，成为必备的技能，而不是一个专业。但如果学到高精尖，也就会成为领域的顶尖专业人才。

你看现在的PPT，虽然看似每个人都会；但要做得好，还是要找专业公司和专业人士。