# GTD From Kai —— 自我思考
如上一篇文章所说，开始准备自己的GTD计划，一晃过去了两个礼拜，这两周中各种烦心琐碎的事情之多也是近两年以来的极致，可能之前预料的2017的压力开始进入顶点。不过无论如何，还是总结了自己在工作和生活中所需的一些GTD场景。对于这样一个自己做客户的产品，这也算是需求调研吧。
## 工作中的需求场景
### 需求描述
1. 新接到一个项目，从立项开始准备立项报告，在写立项报告时需要整理出文档结构，之后在准备提交立项申请。立项申请在项目管理平台上注册新项目，同时准备开立项评审会，立项评审会时再开展准备需求文档。有时需要自己画原型，再开需求评审会（需要预定相关会议室，联系他人）。开完会和UED开始设计交互，之后进行交互设计评审会，然后是视觉设计，视觉设计评审会，交由开发，跟踪开发，然后提测，测试时跟踪多轮回归。
> _备注：_ 有时候个别流程会被省略以加快进程
2. 突然接到领导通知去完成一些额外工作，例如开会，接待等（非长期）
3. 部门内部**定期**的例会，以及**定期**的绩效等内容
4. 有一些工作是部门其他同事完成的，需要**跟踪**
5. 提前通知和约定**有准确时间和地点**的工作
### 需求分析
按照上述描述，大致可以分为四种类型的事件：
#### 1. 长期事件（工作流）
st=>start: Start
e=>end
op=>operation: Meeting
cond=>condition: Work Done?
st->op->cond
cond(yes)->e
cond(no)->op
`Meeting` 在这里指代一种事件模板，`Meeting`本身又可以拆分成一个工作流：
st=>start: 开会
e=>end: 开会完毕
op1=>operation: 预约会议室
op2=>operation: 召集参会人
st->op1->op2->e
#### 2. 突发事件（普通事件）
发生事件后，描述目标之后执行，周期和时效都非常短
#### 3. 周期事件
隔一段**确定**的时间后，重复执行工作
#### 4. 跟踪事件
需要标注**固定对象**来跟踪事件，事件可能是一个突发（普通）事件，也有可能是一个周期事件
> _小结：工作中的事情比较多是成workflow形式的，主要原因是工作中大部分任务都需要一定的周期去完成，所以将事情拆分成workflow的各个阶段会比较有利。不成workflow的事件往往比较不重要_
## 生活中的需求场景
### 需求描述
1. 买装修材料，只是知道要买什么，但是并不知道具体买的顺序和时间
2. 偶尔有活动要参加，需要记录时间、地点、任务、想通过手机的日历或者是提醒事项生成提醒
3. 突然有一些灵感，没有具体方案但是可以用文字先记录下来
4. 有一些想要买的东西会记录下来，以后再买。可能只是东西的名称型号也可能是一个地址
5. 有一些事情的解决需要通过好几个步骤，比如去办房产证需要先找中介、再去开税务证明等等、之后再去找中介，有一定的流程
6. 出去旅游要准备一些东西，作为一个checklist（会有重复的情况）
7. 办事需要准备一系列材料，有些材料是现成的有些需要重新去准备
### 需求分析
按照上述的需求描述，大致上可以有这样的划分
#### 1. 系列事件（workflow)
事件有多个节点组成，必须完成上一节点才能进入下一节点，每个节点可能有指定的deadline或是办事地点；
同时存在一种可能，类似于checklist，有明确的组成内容，需要确保每一项都已经完成
#### 2. 明确信息的事件
事件有非常明确的时间或地点或人物（或是兼具），需要在日历或提醒事项中加入相关内容；
#### 3. 不明确信息时间
事件并没有明确的信息，只是一些文字的描述或是抽象的记录
> _小结：生活中的事件比较少出现系列事件，一般都是比较零碎的事情，如果出现系列事件往往代表着一定的重要性。生活中的事情主要是源于自己的想法，用最不修饰的文字记录，然后再去提取其中的信息是比较方便的方案_