俊恺的乱语
文章 标签 分类
俊恺的乱语

GTD From Kai —— 自我思考

bjkdtc 
       

如上一篇文章所说，开始准备自己的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. 不明确信息时间

事件并没有明确的信息，只是一些文字的描述或是抽象的记录

小结：生活中的事件比较少出现系列事件，一般都是比较零碎的事情，如果出现系列事件往往代表着一定的重要性。生活中的事情主要是源于自己的想法，用最不修饰的文字记录，然后再去提取其中的信息是比较方便的方案

 GTD From Kai, PM
 |