小明传:面对一大堆需求我好方

 

当面对各方的需求时,小明这下可方了:这可怎么办呢?...



导读

小明是互联网公司的一位PM,他在工作当中,常常听到一句话:PM,这个需求帮忙安排一下;帮忙插一下这个需求,比较急;我的需求怎么还没给排到啊……

当面对各方的需求时,小明这下可方了:这可怎么办呢?

不要方,我们给他找了一位项目管理大牛,大牛听了他的情况,听听大牛怎么说:

第一步:了解需求

作为PM不能仅仅只是简单的把需求排给开发人员,首先必须要先了解每个需求的内容是什么,优先级如何。这会决定这个需求安排在哪个迭代,给谁去做。

l 了解内容:这就要求pm要对项目的内容非常熟悉,虽然小明你不是产品,但是你必须要全面了解整个项目的所有内容,这样新来一个需求的时候,你就能知道这个需求在整个产品中的位置是什么,有什么关联系统。

l 了解优先级:这个优先级首先是负责的产品同学给到,当然每个产品都会说自己的需求是最紧急的。

老大与产品、运营同学会根据所有内容讨论给出优先级。PM这个时候主要会把日常中大家的意见传达给到老大做决策。

所以PM的第一步,主要是需求的收集和排序,这个时候,PM手上就有了一堆排好序、分好类的需求池子。所有新增的需求,都讲放在这个池子里。



第二步:了解每个版本节点的要求

版本节点的要求也有两部分:

l 时间点:这个决定你版本开发的时长,能决定你能排多少内容。

l 版本重点:每个版本,产品和运营端都会有需要侧重的内容。

第三步:具体安排人员

这里安排不能像分猪肉一样,随意分配,有几个注意的点。l 每个新需求的安排,会和开发一起商量哪个开发人员合适,这里要根据每个开发人员手上的工作量以及系统熟悉程度进行安排。

l 每个优化需求都会有以前的开发人员,根据时间,安排合适的需求量。

l 一些必须优化的需求,原人员如果来不及,则需要协调其他人员进行。

l 安排完之后,需要整体再看一遍大家的内容和时间是否合适,最后核心组成员最终确认,并同步给到项目组全员,让大家知道自己下一步的工作需求。

l 需求安排的时候,需要预留一些buff时间,不要安排得太满,因为经常会忽略联调时间、改bug时间、需求变化等情况。

小明同学听完拍手叫好,正准备感谢大牛呢,被叫住了:“喂,还没说完呢,瞧你这么猴急”,喝了口水,大牛继续说了起来:



第四步:临时需求安排

当出现临时需求的时候,不要方:

l 拒绝新增临时需求。

l 当确认这个需求必须要插入的时候,则从原有未开始的需求进行挑选进行替换。

l 允许存在一些bug的情况存在。

l 版本节点往后,确保新增需求的开发时间。

l 看看有没有可以协调其他人力进行支持。

这种是比较正规的做法,因为新增量,只能通过砍其他确保总量不变;或者新增时间或人力确保开发;再或者就是牺牲版本质量来支持。

利弊:这种处理,如果能严格坚持下来,对整个项目组将会起到比较积极的作用,因为大家养成良好的习惯之后,临时需求变更将会变少,开发过程会更加顺利,前期准备工作会更加充分;但是对版本安排的灵活度会打折扣,另外都严格走流程,PM会显得没有人情味,人本身就不喜欢走流程。

这次交流让小明受益良多,在谢过大牛之后,小明就应用到自己的项目当中了,至于效果如何,请大家继续收听吧。

深圳敏捷部落

微信号:sz_agiletour



长按识别二维码关注我们


    关注 深圳敏捷部落


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册