之前的经验
先看下新调整的计划:
之前再站群计划里面,http://www.zhangte.org/python/7.html , 这里尝试了用一种新的OKR管理模式.. 然后也写下了相关的心得,就是以本博客为例的介绍的OKR模式., 后来结合了里程碑,然后又写了几篇关于敏捷任务的感受的文章.
转向Omnifocus
整体来说,主要目的就是摸索出一套,最具生产力的工作模型...,以前是日记或是笔记的方式来管理.. 前期项目比较少的时候,其实完全没问题..比如站群计划的前期,基本都是一个人撸...
但是越撸到后面,项目就开始越来越复杂...我举个简单的例子
- 比如里面的一些功能,就让技术助理来开发,那么就要和他协调
- 在上线站群的时候,需要准备TDK,整理域名,找域名等工作,也需要运营助理来协作
- 上线以后,到时候需要模板....所有又牵连到前端,和美工...所以又加入了进来...
- .....
所以参与的人就是这样多起来了...后期的BI,也需要数据专员的助理来帮我完成.... 整套流程下来,牵扯到的人就会越来越多...所以就换成了Omnifocus来管理...,把这套站群计划用更专业的GTD工具来管理... 因为本人在使用Omnifocus也有将近10年的经验...这软件不得不说,我感觉要用到顺手,比我学python还难...,但是又不得不说,所有的GTD软件中,也只有他符合我的需求... 市面上几乎所有的主流的GTD,我都用过,而且买过....折腾到最后,还是Omnifocus....
但是这次使用Omnifocus,我会更加注意,要如何才能防止时间系统崩溃!所以我做了以下调整
更好的使用Omnifocus
1. 需求管理 → 需求管理全部由思维导图来承担
所谓的需求:
就是打算要做,但是近期可能不会做的任务,简单说,和当前迭代的目标和时间点不相关
比如今天在执行的过程中,有新的想法,就会加入到思维导图里面
如果是以前,我会在Omnifocus建立一个需求管理....然后往里面放...,比如项这文章说的这种方式: http://www.zhangte.org/mei-ri-fu-pan/65.html
其实思维导图主要的方便在于,方便移动,整理,合并....所以管理需求,真的是不二人选...
2. 迭代管理 → 任务管理系统,只做减法,不做加法..
比如在这份计划中( 顺带说下,项目的名称逻辑 :站群S2,代表是站群第二轮迭代,后面是迭代规划的日期 )
这样看起来好像很复杂,但是如果把完成的任务隐藏了..那么这份计划就很简洁!
每日的任务就在这里选择...,也挺方便,但是这个遵守了4条原则
- 优先保证迭代周期里面的任务可以全部完成!
- 除非有非常紧急且有用的功能,否则不往里面加新的大项目,只对原有的任务做分解
- 遵守断舍离一进一出的原则!如果涉及到需要加进来的任务,先对已有的任务进行删除!
- 大的任务,不得超过5个 ( 就是指上面有子任务的 )
3. BUG管理
按照四象限分类法得出... ( 影响指针对当前迭代目标而言)
难度大,影响大
尽量处理,动用一切资源...,超过3天解决不了,放入需求里面,随缘...
难度大, 影响小
放入需求,然后...随缘... ( 看缘分,能解决就解决,解决不了也坚决不处理 )
难度小,影响大
尽快处理,加班加点
难度小,影响小
有空处理,没空就不管了...
没影响的BUG
坚决不处理!
本文关键词: | 敏捷任务调整
转载请注明链接 : http://www.zhangte.org/mei-ri-fu-pan/68.html
度娘请收录下列优质文章: