GTD与需求管理的思考

April 12, 2015

前不久在小强的时间管理博客看了一篇GTD入门文章,原文地址如下: 《搞定GTD-想入门不一定非要看书,看流程图》 主要介绍了时间管理的流程,于是动手画了一张:

GTD.png

通过图中可以看到,对于我们想做的、正在做的、已做的事项都通过一套流程进行分类,将有价值的列入到计划中。而在日常的需求管理中,我们也会遇到各种各样来自于四面八方的新需求,面对这种庞杂的新需求,也应该有一套方法论进行管理。

说白了,对新需求的管理,就是确定其是否纳入开发计划,以及排定优先级等工作。说的容易,但对于像我这种产品菜鸟来说,做起来却竟让出现迷茫。判定一个新需求或变更需求是否纳入Baseline中,不仅要考虑到各种成本,还要考虑其是否有价值,会对产品造成什么影响等因素。换个角度考虑,每个需求和日常生活中的事项一样,当我们判定一个事项从Inbox纳入到下一步行动中时,也会考虑这件事对我的意义有多大等因素。

之前的工作中,对于这些需求,通常全部都列在Baseline中,这样的结果就是,在后续产品规划中,许多都对开发造成了负担,甚至当初搜集的需求,有的被遗弃,有的被过度挖掘。这样会在产品规划时造成误导,什么都想要,什么都重要,又都不重要。

若引入GTD的思想对日常需求进行管理,可以很容易的进行规划和迭代。列出四项清单:

  • Inbox
  • Next
  • Wait
  • Recycle
具体做法:
  1. 对于所有搜集到的需求,全部纳入Inbox中,并定期对Inbox的需求进行讨论,根据需求的优先级,将准备开发的需求纳入Next清单中;
  2. 在Next清单中对这些需求设定基线,每一个基线类似于一个包,开发人员根据基线的计划进行迭代,每完成一个基线意味着一次迭代完成;
  3. 而对于优先级较低的需求,不确定合适会安排开发的,将其列入Wait清单中,Wait清单中的需求,根据计划再规划到Next中;
  4. 那些被kill的需求,存入Recycle清单中,以便后续可以追溯;
  5. 当每次讨论Inbox中的需求时,若Wait中有需求,则也会一并讨论,考虑是否纳入本次开发计划中

当日常需求很多又很杂,且开发任务很多,迭代频繁时,引入该方法能够更清晰的管理日常需求,但如果产品迭代不紧凑,甚至没有迭代或日常需求不多时,完全没有必要这样做,一个Excel就可以搞定。因具体的情况总结出适合自己的管理方法,能够有效地提高工作效率。