一种需求梳理的方法

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

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

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

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

图一

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

图二

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

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

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

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

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

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

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

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