文件啊，最重要的還是層次感

親愛的姑娘，我的血為你流，汗為你流，我的淚也為你流，還有，還有我所有其他的一切也都為你流…

大家不要慌，你沒走錯地方，這是我青春時期最喜愛的作家馮唐。馮唐有很多標籤，協和醫學博士、托福滿分、emory mba、麥肯錫合夥人、華潤醫藥ceo、中信資本董事總經理等等。

為什麼講寫作技巧時要談馮唐呢?

記得馮唐在一篇文章裡說，他進麥肯錫後被訓練的第乙個玩意兒，叫做金字塔原則，並且「後來證明，這也是之後諸多訓練中，最寶貴最有用的玩意兒。」

所以《麥肯錫教我的寫作技巧》這本書售價30塊，「金字塔原則」這個章節大概能值回29塊。

書中是這樣介紹金字塔結構。

簡單來說，金字塔結構就是用一種見樹又見林的方式來呈現出內容框架，讓人有很直觀的感受。

其實多年以來，我就將這種金字塔結構歸納為層次感。看到這個章節後，很喜歡這個名字，它比層次感這個詞更加具象。

金字塔結構應用的地方非常多。有人的地方就有江湖，我想說，有內容的地方，就有金字塔結構。

事實上，最直觀的例子就是這本書，它的內容就是按照直列型金字塔來安排的。第一章節講資訊大致分類，第二章講具體的句式，第三章拓展到文件總體的框架脈絡。

聯想開來，我們日常的工具就呈現了這種結構。

你看，這是word中的文件結構圖。

這是pdf的書籤。

還有我最喜愛的markdown也是乙個十分方便呈現邏輯結構的編輯工具。

此外，對於開發者來說，甚至細微到了**更新日誌，也需要認真地來勾勒金字塔結構。

關於金字塔原則的運用，書中提到了乙個特別重要的注意事項。也是我在這篇心得裡，特別要分享的乙個觀點。

那就是化繁為簡，抽象小標題的能力，似乎很多人都缺少這種必要的資訊加工能力。

有乙個讓我印象特別深刻的例子，兩年前遇到乙個國內某大型空調公司的定製任務。前面的乙個同事全職做了三個月，還是沒能順利結束。

這個功能文件總共有4頁多，經歷過了技術->研發->測試等多個部門，中間卻沒人梳理下功能點。也許幾個環節的人都在艱難地消化了這份文件後，接受了它。但對於我這個新接手的人，又得花費和前人一樣的時間精力來梳理這份文件。至今回想起來這件事，還是會帶上一些情緒，對這樣的事情很想吐槽一番。

這些冗長的段落擺放在那裡，就這樣影響了團隊間的交流。大家知道完成了幾個功能點，還剩下幾個功能點嗎?反饋某個問題時，大家能定位到哪個功能點嗎?還能想到的情況是，在後續**審核、專案交接時，每個涉及的人都要被折磨一番。

我想這個專案之所以有點亂，多半和這份指導性的文件有關係。如果能有個人化繁為簡地加工下，抽象出功能點的小標題，也許會對專案情況改觀不少。

這樣處理下，是不是感覺清晰了很多，這樣所有人都知道，這個專案無非就是這5大功能點。

另外乙個例子，是我們團隊成員小p。(之所以會寫下這篇文章，也是答應小p分享下金字塔原則。)

小p最近加班加點地完成了乙個比較大的定製專案，梳理了乙份自測報告。

我對這份報告提了點意見：在具體自測部分，用了碎片化的記錄方式，用具體某些條件測試得到某些結果。這樣就缺少了對總體功能的把握。你想，測試組同事拿到這個任務時，要怎麼開始測呢?

好的內容結構可以是這樣呈現：

它的金字塔結構是這樣：

第一層是總述

第二層是逐個功能點：傳輸、維護、心跳、火警、防拆

第三層是單個功能點的具體測試情況

好了，例子就說到這裡。這兩個例子，表面上都是文件結構，其實背後更多的是對內容的邏輯思考。

在我看來，開發者最應該成為整個團隊的靈魂人物。作為銜接前端、後端的紐帶，應該是對功能點有最透徹理解的人。在考慮**前，就應該梳理清楚邏輯結構。對外輸出的設計方案、測試報告如果不體現出這邏輯關係，壞的情況，可能會導致整個專案的人跟著混亂不清。

希望這篇文章能對你有所啟發，或許你不是開發者，這也沒關係。

如果立志成為團隊的靈魂人物，那當下就可以注意自己的內容輸出，嘗試將金字塔原則運用到你的日常工作中去。

也許會有一些收穫。

這篇分享收錄在我的文章合集「成長之路」中。我正在從文件習慣，知識體系管理，專案管理等多個技能角度，分享一些心得。幫助自己梳理總結，也希望能對他人有所啟發。