一种需求梳理的方法

         **一种需求梳理的方法**
今日我们讨论如何有规律的将需求梳理清晰。我把在工作中遇到的需求梳理问题，如何解决的；横向比较遇到的不同类型运营商对需求的明确程度，并对需求确认的影响也做说明。

首先说一下需求确认的重要性，需求明确了才能明确项目范围边界，才能够进行明确的任务分解。如果项目需求不明确，会出现项目总是很紧张的救火。XX需求很重要，需要XX时间完成，第一需求还没有完成，第二需求又来了，第一需求开发的bug也来了，造成整个项目团队总是忙忙碌碌救火的样子。
在需求梳理的过程中总结了一套个人的方法，希望对各位有用。
一、需求梳理模板
如果有完备的业务需求规范，建议对技术规范进行阅读，标识出对应的业务需求点。再根据业务需求点，列入到需求Excel中。需求梳理模板如下：

图一
该模板可以用于梳理业务规范或招投标中约束的功能点、性能等需求，列入到需求梳理模板中。
二、需求确认模板
上面对正向的业务需求进行了梳理，这样并不算完，虽然有明确的业务需求，但对事务或数据处理流程不清楚，需要PM收集或确认。这个确认是双向的，我方研发的疑问确认及客户业务要求(不含在规范中的)。我建立了一个需求确认模板，该模板是对上一个文档的补充，这两个是相辅相成的，需求确认模板如下：

图二
针对不同的运营商还需要有特别注意的地方，根据运营商的技术实力我大体分了三类：
第一类，顶级运营商，接口规范定义完备，业务规范清晰的，例如：天威。这里就要特别提醒了，一级运营商给的业务规范比较晚上，勿要以为规范完全，直接发给研发即可，要切实的将业务需求进行拆分，落实到具体可执行人。如果不监督执行需求落实，会产生需求、接口遗漏，甚至有责任划分不清晰的地方。
从需求完整的大蛋糕到每一个可入口的小块都落实清楚后，项目60%成功的把我就有了。这里衍生一个小问题，切蛋糕应该是PM or专门部门，个人认为大项目应该由专门部门来主持，PM参与；部分项目PM可以主导，其他部门参与。这个不是本篇文章重点，不在此详述。
第二类，技术实力稍弱些的运营商，需要确认的需求就要多些了。客户(有时甚至是多个部门的人)提的需求不多，就需要PM打起精神了。客户未说，隐含的需求就多了，考验PM的知识储备了。这类运营商的项目要特别注意多问，努力挖掘隐含需求。
第三类，维护类项目的运营商，客户提出的是个别的修补需求。这时，若有以往完备的需求模板、需求确认模板，那就往上累加就好了。若没有，建议在Redmine上建立一个需求确认历史记录的单号，有需求便在上面累计更新，便于项目组查看跟踪。
另外隐含需求不要忘记，对客户无感知的需求，如：网络架构、产测需求等。这些容易忘记，如果忘记了，临时再处理就会很忙乱，出现开头我说的项目现象。
再来辩证一下，不按照上面的方法做，可以完成项目，做好项目吗？答案：当然可以。这是我个人总结的适合我的一套方法，你觉得好用就拿去，不好用也不需要强求，当然还是希望对您有帮助。期待与大家一块交流；
需求确认是一步方向性棋子，项目走的稳不稳、好不好，全看这一步。该篇文章一种需求确认的思路供参考，希望有帮助。