Git Product home page Git Product logo

blitz-book's Introduction

极速写书法

为什么我想要开发「极速写书法」

我是一个想写书却讨厌写书的人。一直以来,我写文章的速度非常牛逼。顷刻之间,就能写好一篇文章。甚至灵感来的时候,一口气能写完一整个系列。

只是每当写完一个系列,下一个欲望想写书时,就一直跌跤。

写文章对我来说很简单 -- 因为我写文章的方式,都是日常想完一篇文章的架构,有灵感马上写。或者是我脑袋里的知识已经积累到一个程度,一股脑的倒出来。

但是写书对我来说真的很困难。我其实秘密写了几个系列,但是每一次都是写到最后断头。

上次出了一本"Growth Hack 这么做",简直是侥幸。原本连我编辑都觉得我不知道会断头到何年了。

我竟然在农历年春节的空档,生出来一本书。简直是奇迹。

上一次出书是侥幸

上次"Growth Hack 这么做"那本书,之所以能够完成,有几个原因:

  • GrowthHack 课程录了影。所以手上有大量逐字稿以及投影片
  • 因为有明确的架构稿,所以我做的只有编稿以及补段落而已

真正有大功劳的是我的编辑,Esor Huang。他帮我整本书做了大量章节中的润饰。

否则这本书,真的生不出来。

坦白说,我自己对我这样的状态很不满意的。

这次的新书 "闪电式开发",这个题目我想写非常久了。

会写写这本书的原因,主要是我对做项目非常有一套。我在公司也有一套练了八年的架构开发流程。这一套流程从一开始被人嘲笑是自 high 的妖术,到现在叠代到真的连续几次打下了惊人的战绩....(这次战绩终于很难被嘴了)。

多年以来我是真的很想把这一切都整理出来的。手上的零散手稿也非常多。(可能原始材料都有几十万字)。

但是每次整理,都会在几天内瞬间从开始到放弃。所以这次想趁写"闪电式开发"这本书,希望同时实验一个自创的新的写书法。

这本书是 2018/10/13 开始写,2018/11/06 写完。历经 24 天。

实验算是成功。所以我决定把这次的写书过程,也整理下来,变成一本新的指南 -- 极速写书法,造福身边想写书又老是写不了书的朋友。

STEP 1: 明确你的写作对象

OK。这次是怎么写书呢?

我先上网找了十本如何快速写书的教材。逆向出大家相同都在讲的一些误区。找到我之前会掉进的大坑。

第一个大坑是: -- 不知道写给谁看 -- 还想从头写到尾

这是大家最常犯的错误。通常很多人写书,是一口气想把自己故事写出来。但是,问题是根本不管看得人是谁。所以会出现几种状况

  1. 啥都想写,然后列出来看到目录就觉得写不完....崩溃
  2. 列出目录后,本来还觉得信心满满,但是开始写了之后。每一章展开之后都发现写不完....崩溃
  3. 开始写了三章之后,觉得这几章转折又拼不起来,于是想要重新改语气以及章节衔接。结果永远在写前面三章....崩溃

我每一次都是这样死掉的 Q_Q

所以这些写作书籍的建议是:你得先确定读者是谁,不管这本书卖不卖得出去。

你得很明确卖给一群人。不能谁都卖。

所以这次我定位很明确。就是软件创业者,或者是想软件创业的程序员。

我只想写给他们看(也就是六年前刚创业的我)。其他人不重要。

所以目标很明确。

STEP 2: 倒过来写大纲

第二大坑:-- 写了三章 -- 又改到面目全非

我在一本书里面找到一个写书套路。他强烈建议写作的方法是「逆向法」(又是逆向!)

他举了一个例子。假设你要写一本如何追到完美伴侣的书。那么你的章节得先倒过来规划。

  1. 先定义你完美的伴侣定义。
  2. 结婚
  3. 价值观的重要
  4. 她是哪种人,不是哪种人
  5. 约会
  6. 方法
  7. 去哪里可以遇到这种人
  8. 确定你的梦想目标

先设定终点,倒推回去你的起点在哪里开始。

接著把这个大纲再反过来。就是你的书脊

  1. 确定你的梦想目标
  2. 去哪里可以遇到这种人
  3. 方法
  4. 约会
  5. 她是哪种人,不是哪种人
  6. 价值观的重要
  7. 结婚
  8. 先定义你完美的伴侣定义。

确定了书脊就能在底下每一章里面至少切几个子目录。

这样规划的好处是不会中间写一写又歪到乱七八糟了。

所以我用这个方法整理出来了整本书的架构:

第一版是长这样

随著我一章一章的推进,后面的架构也越来越明确

最后我将这本书分为四大段

  1. 如何找到 IDEA
  2. 如何敏捷的迭代执行
  3. 如何提高产品留存率
  4. 启动增长引擎

当然,我不是一开始就想到要把这本书分成四大段的。只有一个比较粗糙的轮廓,就是要从 A 点走到 B 点。但是写完第一大章之后,我就比较有头绪后面的章节要如何整型了。

而且,我这次给自己设立一个比较低的目标就是:求写完,不求完美。先写完,后面要怎么改再怎么改。

STEP 3: 规划结构

第三大坑: -- 没办法控制每一章要写多少字,总觉得阿阿阿阿太多了我写不完了被淹没了

这是我以前每次写到第一阶段完稿时,最常遇到的恐惧症。所以这次我先将结构拆分。

经过统计,每一本非小说类的书籍最后大概总长是 10-12 万字比较合理。

所以拆分下来一章大概 7000-10000 字。看起来虽然很多。

但是内心的压力,远比一口气从头写 10 万字,压力还小的多。

每一大章通常至少有三小节。所以一小章的字数大概是 2000 字左右。

而2000 字就是我平常写一篇博文能够出的速度。

看到这个字数我终于内心平静了....。

而且,突然觉得那些旧文终于可以拿来拼接了。

所以整个书籍我的规划:

  • 大约是 10-13 章
  • 每一章大约有 7000-10000 字

STEP 4: 录制故事

第四大坑: --- 阿阿阿阿我不知道怎样起头

解决了字数恐惧之后。我却发现最大的难题好像不在写不出来。而是不知道怎开头。

每次我写了开头就扔掉。一直重写开头。

而且,我虽然手上有很多旧稿。但是真要组装时,我发现那些文章拼不起来。因为那些主题文章,当初每一篇写作初衷根本不一样,无法拼接拼不起来。所以开头超级难写。

于是,我就去逆向同一领域其他人的书,看他们怎么写开头。

结果我发现很多作者都有一个偷懒的密技,许多作者喜欢以故事开头。故事讲完了才开始重点 1,2,3,4,5。

我才发现原来可以节省时间。

我的旧读者还还跟我抱怨:「老师你每次都写论说文,写得很好但是很难分享。其实大家都喜欢听故事。你这次书多放点故事好吗?」

我不是不想写故事。我身上虽然有很多故事。但是倒不出来阿。每次当我想写故事时,总把把故事写的跟论说文没两样。

用直播录故事

后来我灵机一动。我发现我每次在直播时都会畅所欲言,讲一堆段子。那干嘛故事不用录的就好?

所以我用了一个大绝招。把每一个章节都列出来。

开了一个直播。连讲了 10 个故事。然后把这个直播下载下来,然后再用「迅飞听见」转写成文字。

于是这次这本书,每一个章节都至少有一个故事。

STEP 5: 用录音改善写作速度

第五大坑 --- 写太慢。还有很多东西已经讲过N 遍。大脑抗拒输出

大脑一天写作输出是有字数上限的

纯用键盘写作实在太慢了。我曾经统计过,纯用键盘写作,一小时写1000字差不多就是我的极限了。

即便状态最好的时刻,我一天顶多只能写作 3000字差不多。如果一天写作超过7000字。那那一周就会根本不想要再写了。

但问题来了,我写作也是有三分钟热度的。弃坑太久我会干脆放弃。

太熟悉的内容,不想要重写,但是可以用录的

还有某一些领域的文章,我已经讲太多遍到烂了不想要讲了。比如说 Growth Hack 相关的主题,我通通都不想重写。

因为这个领域我前前后后写了快20遍。即便我在增长领域多了很多范例,是从来没对外公布的细节,但是在公司内部已经讲过很多次。

所以在写作这些主题时,我大脑其实是拒绝输出的。

所以我用了一个变通方式。现在科技已经进步到能够转写。

我发现半小时我就可以讲10000字。所以我最后干脆....用讲的.....。

剪辑旧演讲以及旧投影片

一直以来,我有定期发表学术成果的习惯。而且不管是在内部发表或外部发表。

绝大多数有投影片或者录影。(这是三年前,我开始职业讲课后养成的习惯,每一场演讲都有录影)

于是我请助理去把我过去所有的录影都翻出来,全部送迅飞转写。果然直接转了高达 20 万字的原始材料。

使用这方法太有效率了。

我发现甚至一天录五集内容都做得到,缺内容就开直播用录的。

录完就剪粗稿(没编辑过直接进 markdown),只是粗切而已。

所以 github 上面暂存一大堆乱七八糟没编过的外星文,只有我自己看得懂。

但是光重构这些文章。每天进度就真的很不错。一天至少出 7000 字的完稿是可能的。

STEP 6: 使用 User Story 大法决定要怎么决定内容

第六大坑 -- 无法决定每一章重点是啥

每一个主题,面对不同人群,讲的深度不一样。原本我是担心没有材料可以写,现在改用这个方法后,手上一大堆材料。

所以我在面对海量材料时,很难抉择要放什么。

在这时我灵机一动。想到 user story 大法。所以我对每一章都写了 user story(对使用者有价值的事)

决定每一章的 must have 与 should have 是什么。

先剪 must have 进去。然后先编辑 must have,很神奇的, should have 细节就出来了。

而这些 should have,大多是「实做步骤」。而这些实做步骤,大多可以从我过去六年的博客里面,一一剪辑出来。甚至当时还是以 markdown 格式储存。

如此以来,进度就更快了。

所以我只是剪贴.....剪贴...剪贴 ....编语气.....

写不下去时再打开直播录新章节

STEP 7: 如何录直播

录直播也是一门学问。如果没有准备,录直播也容易吃螺丝。我过去曾经因为开全栈营,长期需要一口气连讲 30 分钟的课程,所以有一套演讲框架。

直播的重点不在于 PTT 的撰写。而是思绪的架构与展开。

所以我是这样写书的:

  1. 用15分钟进行该章 A4 自由书写,先把脑袋思路倒一下。
  2. 拿到 A4 自由书写的大纲点后,开始直播。直播大概录 20-30 分钟。
  3. 然后下载直播影片,倒到迅飞听见去拿转写稿。大概也 15 分钟。
  4. 进行听译稿编辑。大概 3-5 小时。

看起来多花很多功夫。但其实比传统写书相对"快" 很多。

这当中的因素在于

  1. 单纯直接写作几千字,除非当下非常有灵感,否则正常人是作不到干写的.....对我心灵会造成极大痛苦。

灵感来时可以直接写七千字没问题,没灵感七百都写不出来。

  1. 传统写作法非常痛苦,是因为边写边想边编辑,心智耗费过大。很多"灵感" 会被编辑掉。

海明威说 Write drunk, Edit sober。我不喝酒,所以没有办法用这招。但是我发现说话可以突破心灵上的节制。特别是我们在说话时,偏好讲故事,而非重点(直接写作偏写重点)。

人在看书也比较喜欢看故事。再加上说话速度是写作速度大概 10 倍快。所以用录的字数也是大概10倍。25 分钟大概录一万字没有问题。

  1. 把每个章节视为独立任务

以前我把每一章都看做是一整个完整独立挑战。但是一口气输出七千字,并且安排好文章架构是很困难的。改用这个方法后。

我只要先确立好这一章大概要录哪些主题的内容。

然后拿到之后,编辑加标题裁减成段就可以。

改重构的重构,该补图精修的补图精修。

整个写作环节不存在大章,而是每一章材料的排版与编辑。

顿时难度下降许多,变得跟打关卡一样。

STEP 8: 一边写作一边打电动

第七大坑 --- 太辛苦了 --- 坚持不下去

即使用了这些招数。写书真的还是很累。很多时候,一天编辑的次数太多,我就根本不想再继续下去了!!!

而且是好几天失去动力。只想打电动。

那怎么办呢?

我后来发现这件事情可以反过来搞。就是先去打电动。打到不想打电动了,打到有罪恶感。打到我今天再也不想打开 PS4 了。打到觉得写书比较轻松。这时候打开编辑器,简直心如止水,文思泉涌,刷刷刷的就写完了!简直神奇!

所以我在写作闪电式开发时,是每天一边打碧血狂杀 2 ,一边写书的。每当我写不下去时,就去打电动打到爽(大概1.5hr,并没有特别节制,但一定得打到自己厌倦电玩),然后再回去写书。当写书写到累时,再回去打电动。

我有一次神奇的经历是,我当天打了三次 碧血狂杀 2,回去编了三次书。当天产出 7000 馀字高品质的书稿。

但却还充满干劲。随时随地想回去「接受挑战」。

用这样方式写书,不仅压力平衡,写书很快,还挺有成就感。每天完稿字数一下多 7000-10000 字。就觉得自己还是挺有机会成功的。

说也奇怪,我破关碧血狂杀2的当天,书也写完了。

STEP 9: 完稿修饰

(这部分还在实验,没写进去,最后会用 Onboarding UX 法修)

总结

总结一下我这次写书的心得,其实是用了软件思维以及认知心理学去进行写作。

  1. 写书不是一口气直接从 0 到 10 万,而是可以拆解的任务。可以拆解成任务
  2. 人脑的暂存记忆区,只有五格,更遑论一次写10000字。大量逼自己存取暂存记忆区的话,大脑该周会关闭存取该功能的机会。
  3. 写作与说话速度不是等价的。说话速度至少是写作速度的10倍。而且说话没有「修改」的机制,而写作有。这就是为什么写作非常的痛苦,以及很难产出故事性内容。可以用直播做到 "Write drunk, Edit sober" 的近似效果。�
  4. 打电玩可以分泌大量的脑内啡,有助于降低写作的痛苦。同时,大脑也会把写作视为是「一个挑战关卡」,而非攀登一座高山。每天都有冲动想去挑战新关卡。

用这个方式,可以在写作上绕过许多被视为「需要极大意志力」的挑战,从而「相对」「轻松」的写出自己理想的大部头。

blitz-book's People

Contributors

xdite avatar

Watchers

 avatar  avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.