用 GitHub 做时间管理

谈到时间管理,最先映入脑海的恐怕是番茄工作法了。我不是番茄工作法的粉丝,我有一套自己的时间管理工具和方法。简单来说,所有的任务被分成两类:有明确时间期限且耗时较短的,和时间期限模糊或耗时较长的。对于第一类任务,便签/日历/定时提醒就可以胜任;而至于第二类,时间本身变得不那么重要,对任务追踪的要求凸显出来。在各类任务管理工具中,GitHub 的 issue 和 project 给我留下了深刻的印象。即便不是程序员也没关系,我们不需要写一行代码,不需要有提交记录,就能享受那些工具带来的便利。

我相信,谁也不愿意向全世界公开心里想做的事情,所以需要开设一个 GitHub 私有仓库。不过,倘若仅仅为了时间管理摊上每个月 $7 的费用,确实有些得不偿失。另一些 git 仓库托管厂商,比如 BitBucketGitLab 等都免费提供了类似的工具,各位看官不妨一试。


启程

GitHub issue 从邮件列表进化而来,主要用于讨论问题。我们借鉴过来,改造成故事板,记录每件要做的事。照理来说,每个新的任务都该由一个单独的 issue 管辖(好比每个话题在贴吧新开一个帖子)。不过,实践中我们不必严格执行——跟着感觉走就好了。像给同事回邮件这种事不值得单列一个 issue,这样付出的时间管理成本太高了;学习单反摄影技术也不适合,因为它的周期太长,内容又很多,在 GitHub 盖楼很容易爆吧,最后落得个“被字淹没、不知所措”。以我的经验,像撰写论文开题报告这样,需要数小时至数天完成的任务,适合创建单独的 issue。对于长期和庞大的任务,则适合分解成多个部分,为每一块创建 issue 之后,再用后文提及的 project 工具统一管理。



GitHub issue 面板


考虑到显示宽度的限制,理想的 issue 标题应该足够简短而又不失区分度,最好能让使用者一眼回想起任务的内容。任务的背景介绍、执行流程、检查点和验收条件等最重要的内容,应放在 issue 帖子的一楼。写完之后,点击 submit new issue,这件事就算顺利记录在案了。

创建 issue 的时候,在右侧能看到几个重要的选项。label 是筛选任务的必备神器,强烈推荐为每个 issue 配置。关于 project 和 milestone 的用法请见后文的讲解。

GitHub 的帖子除了普通的文字,还可以使用 Markdown 格式化文本。GitHub 支持的 Markdown 语法十分强大,可以勾选和取消列表中的项目,这简直就是为检查点量身打造的。不过,只有一楼的复选框会以进度条的形式显示在 issue 面板下,所以请记得把所有的检查点都挪到一楼。下面展示了这种特别的 Markdown 语法。

1
2
- [x] 一个已勾选的复选框
- [ ] 一个尚未勾选的复选框

通常,伴随着任务的新进展,执行记录一层层堆叠在帖子下方。不用怕写错了什么,因为咱们总有修改和删除任何帖子的机会。等任务做完,就可以点击 close issue 关闭这个帖子了。关闭的帖子依旧可以编辑和评论,必要时可以回来看看。


追踪

像学习单反摄影这样的长期任务,如果拆分成好几块,各部分间经常会出现依赖关系。比如,尝试不同光圈和快门的组合与练习构图可以同时进行,但建筑写生就要等它们都完成之后才好开展。在 project 工具中,我们可以更细一步描述和管理大型任务。



GitHub project 面板


project 面板允许我们自由地添加、删除和拖拽“列”,以及列中的 issue。每个列代表了任务执行的一个阶段。issue 从左到右划过整个流水线,完成它的生命周期。同时,issue 在列中的上下位置代表了其优先级。我建议每个 project 至少含有以下 5 个列:

  1. To Do
  2. Blocked
  3. In Progress
  4. Review
  5. Done

在 issue 面板中指定一个 project 后,相应的 project 就会出现一个需要 triage(分拣)的 issue。在多数情况下,新 issue 将被扔到 To Do 或是 Blocked 里面,其中 Blocked 就是用来记录和整理依赖关系的。任务开始执行后,便可调整至 In Progress 列。对于需要事后反馈与总结的任务,应当在完成后置于 Review 状态,否则可以直接移动至 Done。我的个人偏好是关闭处于 Review 状态的 issue,你也可以等到 Done 了再关闭它们。当然,定期把已关闭的 issue 从 project 中移除也是一个好习惯。

上面是一个最基本的五级任务管理流水线。实际的大型任务可能需要更加复杂的结构。凭借各位的聪明才智,创作出一个合适的框架,肯定不是什么难事。


轮回

在 GitHub 提供的工程管理工具中,我最喜欢的是 issue 附属的 milestone 特性,这个特性让 issue 回归了时间管理的本质。无数事例已经证实,对普罗大众来说,deadline 才是第一生产力。打上里程碑的印记,就如同标记了 deadline 一样,有助于我们战胜拖延症,限期完成任务。

milestone 和 label 一样,在 issue 面板下创建和编辑。每个 milestone 都有固定的期限,半个月或者一个月是合理的长度。我们的目标是,每个标记了 milestone 的任务,都应该在这个期限结束前关闭。每到月中或是月底,请打开当前的 milestone,逐一清理还没有关闭的 issue。尚未开始的任务,也许干脆取消更好。已有进展的任务,要不要考虑中止呢?实在无法割舍的,就不得不转移到下个 milestone 了。重复几次清理的过程,就会对自己的执行力有比较透彻的了解,有助于挖掘生产力的潜能。


进化

GitHub 原生的工具完全可以满足我对第二类任务的时间管理的需要。如果你想寻求一站式的编辑体验,以及长叙事、燃烧图等高级功能,可以为 GitHub 加上 ZenHub 插件。该插件对个人用户免费开放。更多功能,有待你的逐步探索。