文档啊,最重要的还是层次感

亲爱的姑娘,我的血为你流,汗为你流,我的泪也为你流,还有,还有我所有其他的一切也都为你流…

大家不要慌,你没走错地方,这是我青春时期最喜爱的作家冯唐。冯唐有很多标签,协和医学博士、托福满分、emory MBA、麦肯锡合伙人、华润医药CEO、中信资本董事总经理等等。

久仰大名

为什么讲写作技巧时要谈冯唐呢?

记得冯唐在一篇文章里说,他进麦肯锡后被训练的第一个玩意儿,叫做金字塔原则,并且“后来证明,这也是之后诸多训练中,最宝贵最有用的玩意儿。”

所以《麦肯锡教我的写作技巧》这本书售价30块,“金字塔原则”这个章节大概能值回29块。

金字塔结构的介绍

书中是这样介绍金字塔结构。

简单来说,金字塔结构就是用一种见树又见林的方式来呈现出内容框架,让人有很直观的感受。

其实多年以来,我就将这种金字塔结构归纳为层次感。看到这个章节后,很喜欢这个名字,它比层次感这个词更加具象。

金字塔结构的应用

金字塔结构应用的地方非常多。有人的地方就有江湖,我想说,有内容的地方,就有金字塔结构。

事实上,最直观的例子就是这本书,它的内容就是按照直列型金字塔来安排的。第一章节讲信息大致分类,第二章讲具体的句式,第三章拓展到文档总体的框架脉络。

联想开来,我们日常的工具就呈现了这种结构。

你看,这是word中的文档结构图。

这是pdf的书签。

还有我最喜爱的markdown也是一个十分方便呈现逻辑结构的编辑工具。

此外,对于开发者来说,甚至细微到了代码更新日志,也需要认真地来勾勒金字塔结构。

特别重要的一点,化繁为简

关于金字塔原则的运用,书中提到了一个特别重要的注意事项。也是我在这篇心得里,特别要分享的一个观点。

那就是化繁为简,抽象小标题的能力,似乎很多人都缺少这种必要的信息加工能力。

有一个让我印象特别深刻的例子,两年前遇到一个国内某大型空调公司的定制任务。前面的一个同事全职做了三个月,还是没能顺利结束。

这个功能文档总共有4页多,经历过了 技术->研发->测试 等多个部门,中间却没人梳理下功能点。也许几个环节的人都在艰难地消化了这份文档后,接受了它。但对于我这个新接手的人,又得花费和前人一样的时间精力来梳理这份文档。至今回想起来这件事,还是会带上一些情绪,对这样的事情很想吐槽一番。

这些冗长的段落摆放在那里,就这样影响了团队间的交流。大家知道完成了几个功能点,还剩下几个功能点吗?反馈某个问题时,大家能定位到哪个功能点吗?还能想到的情况是,在后续代码审核、项目交接时,每个涉及的人都要被折磨一番。

我想这个项目之所以有点乱,多半和这份指导性的文档有关系。如果能有个人化繁为简地加工下,抽象出功能点的小标题,也许会对项目情况改观不少。

这样处理下,是不是感觉清晰了很多,这样所有人都知道,这个项目无非就是这5大功能点。

另外一个例子,是我们团队成员小P。(之所以会写下这篇文章,也是答应小P分享下金字塔原则。)

小P最近加班加点地完成了一个比较大的定制项目,梳理了一份自测报告。

我对这份报告提了点意见:在具体自测部分,用了碎片化的记录方式,用具体某些条件测试得到某些结果。这样就缺少了对总体功能的把握。你想,测试组同事拿到这个任务时,要怎么开始测呢?

好的内容结构可以是这样呈现:

它的金字塔结构是这样:
第一层是总述
第二层是逐个功能点:传输、维护、心跳、火警、防拆
第三层是单个功能点的具体测试情况


好了,例子就说到这里。这两个例子,表面上都是文档结构,其实背后更多的是对内容的逻辑思考。

在我看来,开发者最应该成为整个团队的灵魂人物。作为衔接前端、后端的纽带,应该是对功能点有最透彻理解的人。在考虑代码前,就应该梳理清楚逻辑结构。对外输出的设计方案、测试报告如果不体现出这逻辑关系,坏的情况,可能会导致整个项目的人跟着混乱不清。


希望这篇文章能对你有所启发,或许你不是开发者,这也没关系。

如果立志成为团队的灵魂人物,那当下就可以注意自己的内容输出,尝试将金字塔原则运用到你的日常工作中去。

也许会有一些收获。

这篇分享收录在我的文章合集“成长之路”中。我正在从文档习惯,知识体系管理,项目管理等多个技能角度,分享一些心得。帮助自己梳理总结,也希望能对他人有所启发。


你可能感兴趣的:(软技能,金字塔原则,层次感,小标题)