未来写软件,就像现在画PPT

未来编程会和开车、外语、写PPT一样,成为必备的技能,而不是一个专业。

【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,虽然看似每个人都会;但要做得好,还是要找专业公司和专业人士。 

广告等商务合作,请点击这里

本文为转载内容,授权事宜请联系原著作权人。

打开界面新闻APP,查看原文
界面新闻
打开界面新闻,查看更多专业报道

热门评论

打开APP,查看全部评论,抢神评席位

热门推荐

    下载界面APP 订阅更多品牌栏目
      界面新闻
      界面新闻
      只服务于独立思考的人群
      打开