[xueshan007050]的博客:
http://jackspade.mypm.net
一种需求管理的方法

一种需求梳理的方法

今日我们讨论如何有规律的将需求梳理清晰进行沟通,我把在工作中遇到的问题,如何解决的,再横向比较遇到的几个不同类型运营商对需求的明确程度进行分类,并对需求确认的影响也做说明。

首先说一下需求确认的重要性,需求明确了才能明确项目范围边界,才能够进行明确的任务分解。如果项目需求不明确,会出现项目总是很紧张的救火。XX需求很重要,需要XX时间完成,第一需求还没有完成,第二需求又来了,第一需求开发的bug也来了,造成整个项目团队总是忙忙碌碌的。

在需求梳理的过程中总结了一套个人的方法,希望对各位有用。

对于完备的业务需求规范,建议对技术规范进行阅读,标识出对应的业务需求点。再根据业务需求点,列入到需求Excel中。模板如下:

 

 

 

图一

上面对正向的业务需求进行了梳理,这样并不算完,虽然有明确的业务需求,但对事务或数据处理流程都不会描述,需要PM收集或确认。这个确认是双向的,我方研发的疑问确认及客户业务要求(不含在规范中的)。我建立了一个需求确认模板,模板如下:

 

 

图二

需求确认的模板,在针对不同用户的时候如何进行施展,并根据不同的运营商需要的注意事项还是需要注意,我大体分了四类:

第一类,顶级运营商,接口规范定义完备,业务规范清晰的,例如:天威。这里就要特别提醒了,一级运营商给的业务规范比较晚上,勿要以为规范完全,直接发给研发即可,要切实的将业务需求进行拆分,落实到具体可执行人。如果不监督执行需求落实,会产生需求、接口遗漏,甚至有责任划分不清晰的地方。

从需求完整的大蛋糕到每一个可入口的小块都落实清楚后,项目60%成功的把我就有了。这里衍生一个小问题,切蛋糕应该是PM  or专门部门,个人认为大项目应该由专门部门来主持,PM参与;部分项目PM可以主导,其他部门参与。这个不是本篇文章重点,不在此详述。

第二类,技术实力稍弱些的运营商,需要确认的需求就要多些了。客户(有时甚至是多个部门的人)提的需求不多,就需要PM打起精神了。客户未说,隐含的需求就多了,考验PM的知识储备了。

第三类,维护类项目,客户提出的是个别的修补需求。这时,若有以往完备的需求模板,需求确认模板,那就网上累加就好了。若没有,建议在Redmine上建立一个需求确认历史记录的单号,便于个人和后续研发、PM查看跟踪。

另外隐含需求不要忘记,对客户无感知的需求,如:网络架构、产测需求等。这些容易忘记,如果忘记了,临时再处理就会很忙乱,出现开头我说的项目现象。

再来辩证一下,不按照上面的方法做,可以完成项目,做好项目吗?答案:当然可以。这是我个人总结的适合我的一套方法,你觉得好用就拿去,不好用也不需要强求,当然还是希望对您有帮助。

需求确认是一步方向性棋子,项目走的稳不稳、好不好,全看这一步。一种需求确认的思路供参考,希望有帮助。

 

xueshan007050 发表于 2018-7-12 13:52:42 阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志

发表评论:

    昵称:
    密码:
    主页:
    标题:
公 告
登 陆
日志日历
搜 索
日 志
评 论
链 接
统 计