任务管理,项目管理和目标管理

我是一个工具控,经常尝试各种生产力工具。我发现任务管理App汗牛充栋,项目管理工具乏善可陈,而目标管理App更是少得可怜。

任务管理App

任务管理App,包括常见的Things 3,Todoist,Teambition,Trello。其中Things 3和Todoist,本质上就像是一个增强版的提醒工具,你要做什么事情,填上去,设置好Deadline,事情做完了勾掉。如下图所示。

但这种类型的App有一个缺点——任务只有未做完成两个状态,没有正在做的状态。

而Teambition与Trello稍微进步一点,引入了看板的概念,于是能够显示任务在各个阶段的状态,如下图所示。这张图是少数派的Trello看板,用来让作者选题。

这种类型的App有一个很大的问题:你做了很多任务,但是你不知道你做这些任务是为了什么。任务管理类App适合用来记录和追踪各种琐碎的任务和相关性不强的任务。就像是少数派的每一篇文章,文章与文章之间不是一个系列的关系,他们各自独立,谁都可以领选题写文章,哪个选题先写哪个选题后写,关系不大。

一旦要规划一个项目,对于规划项目的人和做项目的人,用任务管理类App都会让人觉得使不上劲。对于做任务的人,看到每一个独立的任务,对项目没有整体的概念;对于规划项目的人,不知道任务是不是已经切分得足够细,是否有遗漏。举一个例子,下面是一些任务:

  • 找IT申请服务器
  • 配置Dockerfile
  • 配置Docker Swarm
  • 搭建Jenkins
  • 配置Github Hook
  • 选择三个Repo测试

现在看到上面的几个任务,你知道我是想做什么吗?我想实现持续集成(CI),实现开发人员把代码一推到Github,系统自动使用Jenkins把代码拉到测试服务器,检查代码风格,做单元测试,做功能测试,自动生成Code Review申请发送给相关人员,Code Review以后自动把代码集成到主干并部署。但是对于做任务的人,却很难根据上面的任务发现要做这个事情。对于规划任务的人,也很难发现是否漏掉了任务,以及是否其中的一个或者多个任务可以继续拆分。

再一个问题,在为每一个任务设定时间的时候,任务一旦多,很难把控每个任务的具体时长。也难以发现哪些任务可以同时做,哪些任务有依赖必需先做这个再做那个,前置任务必需按时完成。即使设置了任务优先级,但是对于同级的任务谁先做谁后做,你却无法把控,只有看App上哪个排前面就先做哪个。

我曾经有一篇文章,就是因为考虑到Teambition的这个问题,所以把Teambition与大纲工具Workflowy结合起来使用。文章地址为:TeamFlowy——结合Teambition与Workflowy

项目管理

正是由于任务管理App存在诸多不便,于是在规划一个项目的时候,必需使用一些项目管理的方法或者软件来提高效率。

关于项目管理,我个人最推崇使用甘特图。在我的另一篇文章不用甘特图,你做什么项目管理中,我讲到了从一张甘特图里面,你将会额外获得哪些信息。

甘特图是一张二维的图表,它的横轴是时间,纵轴是任务。从甘特图上可以一目了然看到一个任务从什么时候开始什么时候结束,不同任务之间是否有时间重叠,以及哪些任务可以同时做哪些任务必需有先后顺序。

我个人认为,在项目管理中,任务周期是非常重要的,任务的开始时间和结束时间一定要把控好。使用甘特图就可以实现这样一个目的。

对于规划任务的人,在用甘特图规划任务的时候,如果你发现一个任务时间太长,无论怎么调整都会和后面的任务有重叠,那么你就会发现这个任务可能需要拆分为更小的任务。而且由于甘特图立足于项目的整体,你也可以更容易发现是否有任务漏掉了。

对于做任务的人,甘特图也可以帮他们了解到他们所做的任务在整个项目中处于一个什么样的位置,从而让他们知道自己正在做的任务是不是非常重要必需按时完成。

如果你是要开发一个App,或者是要写一本书,或者是要做一个其他什么项目,只要它是由一系列不同的任务构成的,那么你就可以考虑使用甘特图来帮你提高效率。

目标管理

今天是2018年第一天,不知道有多少人把2017年第一天许下的新年愿望原封不动的搬到了今天。为什么很多人的目标总是不能实现呢?因为他们没有做好目标管理。

关于目标管理,我推崇的是OKR系统。这虽然是一个发源于Intel后被Google发扬光大的企业管理系统,但是对个人依然有用。OKR的意思是Objective and Key Results目标和关键成果。很多人的目标之所以没有实现,是因为他们只设定目标,却不设定成果检查。例如一个人的目标是打算学好英语,但是由于没有设定结果,那么他在设定目标的第二天背了三个单词,在他的潜意识里面就会认为自己已经完成了这个任务,自然后面就会越来越松懈。但如果一个人设定目标为学好英语,再设定几个关键成果,例如:

  • 4月1之前,与10个以上美国人聊天
  • 在3月10日节之前,单词书随意翻开一页,这一页的单词至少认识90%
  • 在4月1日前面试三个国外的公司,不为工作就为面着玩

这样的目标,就更容易实现了。

使用OKR方法,用纸和笔就可以完成,在设定目标关键结果的时候,一定要使用Smart法则:

  • Specific-具体的
  • Measurable-可衡量的
  • Attainable-可实现的
  • Relevant-相关的
  • Time-based-有时限的

关键结果要足够具体,这样它才是可衡量的。而所谓的可衡量,自然就是可以量化的,可以用数字来定量的检查这个关键结果是否完成,如果没有完全完成,那么完成了多少。如果目标是学好英语,那么关键结果里面肯定不能是“每个月吃一次素菜”。因为这个关键结果和这个目标无关。最后也是非常重要的一点,设定Deadline,防止拖延。

如果你基于OKR系统订好了几个目标和他们的关键结果,然后你100%完成了所有目标。那么恭喜你,你的这个OKR系统是不成功的。100%完成的基于OKR系统的目标对你的帮助不会太大,因为你设定得太简单了。一个完美的OKR系统,应该是在你用尽全力绞尽脑汁的情况下,完成了70%的目标。这样它才会促使你不断挑战自己的极限,不断变得更好。

基于OKR系统的目标,时间也不应该设置太长,以季度为节点检查一次,增加新的目标或者关键结果。最长也需要保证半年至少检查一次,否则很容易出现赶Deadline的情况。

结合

一个目标,最终会被拆分为一个或者多个项目,每个项目又会被拆分为一个或者多个具体的任务。所以在我自己的实践中,我会把本文讲到的三个东西结合起来。通过OKR系统制定我的目标,使用甘特图来规划我的项目,而使用Todoist来做任务管理。

当我形成了这样一个工作流以后,我发现他们之间可以合作得很好,并不会让人手忙脚乱。我在季度开始的时候制定OKR,然后每周检查一次。在绘制好甘特图以后,我每天也只在下班的时候看一次,更新好项目进度,然后把明天要做的任务添加到Todoist里面。所以我每天使用最多的,更新得最多的还是Todoist。

原文发布于微信公众号 - 未闻Code(itskingname)

原文发表时间:2018-01-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯移动品质中心TMQ的专栏

快给你的用例做减法吧

前言 生活的智慧,有时不在于多,而在于少。 同理适用于测试用例的管理中。 一. 热身:数一数你的用例数 随着互联网时代节奏的日益加快,许多产品都会在版本迭代中对...

22810
来自专栏TAPD

总监突然把我拉进了一个群……

大噶好,又是我,TAPD的产品经理圆圆。 上周一上班的时候, 我发现隔壁组来了个巨帅的小哥哥。 ? 有多帅呢?可以说,是吴彦祖+金城武的那种帅。 我立马就去企...

1154
来自专栏Java学习网

你需要每天写代码吗?

你需要每天写代码吗? 就像运动员每天锻炼一样,每天练习写代码可以成就更优秀的你。 最近我看过的博客,基本上每篇都有提到,“你需要每天写代码”。什么主题不重要,关...

2867
来自专栏惶心 - 技术博客

用一年的时间,去遇见

白色而透明的屏幕里,像素点时刻变换着颜色。你看不见的黑暗里,只有风扇快速转动,发出微弱的响声。

1709
来自专栏SAP梦心的SAP分享

【域控管理】域控的必要性

题记:本来域控这玩意儿跟我没有半毛钱关系,毕竟我是做应用类的,域控纯属系统管理范畴。 以前在TTE和LDS,公司里有使用域控,几年来以使用者的角度在观察,觉得这...

2615
来自专栏blackpiglet

代码角度分析《旅行青蛙》:一

  17 年春节前,《旅行青蛙》火的不行,反应慢一拍的我最近才开始迷上这个游戏。最近我的青蛙出去旅行不知所踪好几天了,作为一个不甘心当“佛系青年”的程序员,我想...

1023
来自专栏腾讯移动品质中心TMQ的专栏

快给你的用例做减法吧

? 01 ? 热身:数一数你的用例数 随着互联网时代节奏的日益加快,许多产品都会在版本迭代中对功能做加法,于是累计的测试用例似乎都无可避免地越来越多。从小编自...

1792
来自专栏未闻Code

任务管理,项目管理和目标管理

我是一个工具控,经常尝试各种生产力工具。我发现任务管理App汗牛充栋,项目管理工具乏善可陈,而目标管理App更是少得可怜。

1551
来自专栏高性能分布式系统设计

从历史看未来,大规模微服务系统的困境----基于消息的架构的回归

在大规模分布式系统的架构上,微服务系统是现在很多大型互联网公司的架构方向。 这是一个务实的很好的方向,相对于旧的宏服务来说。 然而,像淘宝这种规模的系统,微服务...

3555
来自专栏Java架构

这些分布式知识,BAT的架构师都在用!一,通信二,伸缩性三,稳定性四,可维护性

2332

扫码关注云+社区

领取腾讯云代金券