怎样的计划靠谱些?

我们都做过个人规划。这时候我们想的是最近几天、最近三个月的、半年的、全年的计划。这个计划里可能有这几天要做的事情,或是年度的大目标(我要和老婆出去玩一趟)。其实做开发的计划,和这个差不多,只是我们可以更有方法地来做这件事情。

目标明确

这个计划是为了什么?它解决的是什么问题?目标不明确,执行一定有问题。这个目标则是从老板到码农都要清楚的。

制定计划项目列表

阻碍目标的实现有哪些问题,换句话说,解决哪些问题就实现了目标?现在要做的就是把这些的所有问题写下来。这些问题可能是一个具体的用户使用场景上的问题,可能是一个BUG,可能是需要做的一些技术或业务实验,也可能是一个具体的功能。
反正先把它们写出来。

现在你可以看到你列出来的问题,有的是很详细的(比如:“常用的功能A居然要两次点击才能进去”),有的则是比较粗旷的(比如:“我只是到这个页面打酱油逛逛的,居然没有对我胃口的内容”)。

现在试着把这个列表按每个条目价值的高低做个排序。
这里的“价值”是很讲究的,也就是说,排序的这个人,要能对这个条目的价值拍板。比如开发经理可能觉得“全站代码重构”是件很重要的事情,但老板完全不care,老板会觉得解决“注册表单太复杂了”是件更重要的事情。
如果一个人不能决定,那就一伙人决定,总得定个价值高低,优先顺序吧。
开发团队会照着这个顺序走,这样保证开发出来的东西始终是最有价值的东西。

排完序了。现在看看这个列表有啥问题没有。
如果要保证开发团队最近的工作能执行得起来,那么就要保证最近的这些计划要够详细是吧。所以如果你价值高的那些任务看上去像是一个假大空的任务,那么就把它细化拆解到一个可具体执行可衡量可验收的程度。或是学术点说,这类的任务必须是SMART的(Specific明确性、Measurable可衡量性、Attainable可达成性、Relevant相关性、Time-bound时限性)。
然后再后续一些的任务可以更粗旷一些。
然后再再后续一些的任务可以更更粗旷一些。

为什么我们不把所有的任务都列得很细,而只把最近要做的价值最高的细化出来呢?

因为计划是会变动的!我们通常做着做着,会有些新的产品方向,那我们在一个月后规划出来很细的东西就没用了。既然它可能完全用不着,就不用一开始就把这部分规划得很细,对吗?特别是目前的互联网节奏,动次打次,节奏很快的!

所以一个好的计划应该是有一个DEEP的特征的:
Detailed Appropriately,最近做的最详细,晚做的不太详细,最后做的最简略。
Estimated,项目是可以估算规模的,这样团队会知道我大概要做多少事情。
Emergent,刚刚说了,这个列表不是一个死列表,它是变化的,是会增减项目的。
Prioritized,每个项目应该判断价值高低,然后从高到低排序。

在Scrum里,这个产品计划叫做Product Backlog。它看起来很可能像是这个样子的。Backlog Prioritization

Copyright © 2014. All Rights Reserved.

发表评论

电子邮件地址不会被公开。 必填项已用*标注