qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

关于项目管理的一点体会

“1人100个月完成的项目,不是100个人1个月就可以完成。”

  项目管理是让项目活动中相互竞争的各类制约因素:质量、进度、资源、风险等取得平衡的艺术,同时也是平衡项目干系人的各种需要、关注和期望,带领不同的人朝着相同目标迈进的领导艺术。

  成功的项目管理可以简单理解为:按时、在预算内+满足产品需求+满足质量需求 地完成项目。

  以下是我对项目管理的一点体会记录。

  需求等级

  视觉 A:图片没有分享功能吗?

  技术 K:图片有链接转发分享、微博或邮件形式分享等多种分享,全部开发的话需要推延时间表。

  策划 D:图片只做预览、下载已经足够了,暂时不做分享。

  交互 E:如果我们的用户是基于邮箱用户,图片的邮件分享还是建议做。

  … …

  如果在前期产品需求文档中没有明确定义每个需求的优先等级,或者说项目成员对需求的优先等级没有明确的意识,可能类似的争论会时常发生在项目成员之间,每个人会基于自己对产品目标的理解来考虑这个需求是否要做,什么时候做,做到什么程度而产生分歧,因而增加项目推进的阻力。

  所以在前期产品需求文档中,必须明确定义出每个需求的优先等级,需求的粒度可细化到每个大功能下的子功能需求,如:图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等;

  一般的需求等级划分:

  P0 -Must have: 如果缺失,产品不能发布

  P1 -Should have: 如果缺失,产品能发布,但不能达到预定目标(功能/性能)

  P2 -Nice to have: 做了则更好

  P3 -Neutral: 对产品没有明显的好处,用户不在意

  … …

  每个需求的优先等级确定之后,产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线,高于或等于这个等级分界线的需求在本期开发,部分根据成本、运营计划等因素调整到下期开发,而低于这个等级分界线的需求则只会在下期开发,这样让全体项目成员对本期要做的需求达成共识。
“1人100个月完成的项目,不是100个人1个月就可以完成。”

  项目管理是让项目活动中相互竞争的各类制约因素:质量、进度、资源、风险等取得平衡的艺术,同时也是平衡项目干系人的各种需要、关注和期望,带领不同的人朝着相同目标迈进的领导艺术。

  成功的项目管理可以简单理解为:按时、在预算内+满足产品需求+满足质量需求 地完成项目。

  以下是我对项目管理的一点体会记录。

  需求等级

  视觉 A:图片没有分享功能吗?

  技术 K:图片有链接转发分享、微博或邮件形式分享等多种分享,全部开发的话需要推延时间表。

  策划 D:图片只做预览、下载已经足够了,暂时不做分享。

  交互 E:如果我们的用户是基于邮箱用户,图片的邮件分享还是建议做。

  … …

  如果在前期产品需求文档中没有明确定义每个需求的优先等级,或者说项目成员对需求的优先等级没有明确的意识,可能类似的争论会时常发生在项目成员之间,每个人会基于自己对产品目标的理解来考虑这个需求是否要做,什么时候做,做到什么程度而产生分歧,因而增加项目推进的阻力。

  所以在前期产品需求文档中,必须明确定义出每个需求的优先等级,需求的粒度可细化到每个大功能下的子功能需求,如:图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等;

  一般的需求等级划分:

  P0 -Must have: 如果缺失,产品不能发布

  P1 -Should have: 如果缺失,产品能发布,但不能达到预定目标(功能/性能)

  P2 -Nice to have: 做了则更好

  P3 -Neutral: 对产品没有明显的好处,用户不在意

  … …

  每个需求的优先等级确定之后,产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线,高于或等于这个等级分界线的需求在本期开发,部分根据成本、运营计划等因素调整到下期开发,而低于这个等级分界线的需求则只会在下期开发,这样让全体项目成员对本期要做的需求达成共识。

“1人100个月完成的项目,不是100个人1个月就可以完成。”

  项目管理是让项目活动中相互竞争的各类制约因素:质量、进度、资源、风险等取得平衡的艺术,同时也是平衡项目干系人的各种需要、关注和期望,带领不同的人朝着相同目标迈进的领导艺术。

  成功的项目管理可以简单理解为:按时、在预算内+满足产品需求+满足质量需求 地完成项目。

  以下是我对项目管理的一点体会记录。

  需求等级

  视觉 A:图片没有分享功能吗?

  技术 K:图片有链接转发分享、微博或邮件形式分享等多种分享,全部开发的话需要推延时间表。

  策划 D:图片只做预览、下载已经足够了,暂时不做分享。

  交互 E:如果我们的用户是基于邮箱用户,图片的邮件分享还是建议做。

  … …

  如果在前期产品需求文档中没有明确定义每个需求的优先等级,或者说项目成员对需求的优先等级没有明确的意识,可能类似的争论会时常发生在项目成员之间,每个人会基于自己对产品目标的理解来考虑这个需求是否要做,什么时候做,做到什么程度而产生分歧,因而增加项目推进的阻力。

  所以在前期产品需求文档中,必须明确定义出每个需求的优先等级,需求的粒度可细化到每个大功能下的子功能需求,如:图片分享功能的转发链接分享、邮件形式分享这样的子功能需求。等级的划分依赖于前期的用户需求调研、产品的预定目标、开发成本、运营计划等;

  一般的需求等级划分:

  P0 -Must have: 如果缺失,产品不能发布

  P1 -Should have: 如果缺失,产品能发布,但不能达到预定目标(功能/性能)

  P2 -Nice to have: 做了则更好

  P3 -Neutral: 对产品没有明显的好处,用户不在意

  … …

  每个需求的优先等级确定之后,产品经理根据产品预定目标、开发成本、运营计划等来定义一个等级分界线,高于或等于这个等级分界线的需求在本期开发,部分根据成本、运营计划等因素调整到下期开发,而低于这个等级分界线的需求则只会在下期开发,这样让全体项目成员对本期要做的需求达成共识。



posted on 2011-11-28 13:40 顺其自然EVO 阅读(89) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年11月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜