小明传:面对一大堆需求我好方
当面对各方的需求时,小明这下可方了:这可怎么办呢?...
导读
小明是互联网公司的一位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
长按识别二维码关注我们
关注 深圳敏捷部落
微信扫一扫关注公众号