不知道大家是否有这样的经历，每天的时间也就24小时，事情也有缓急轻重之分，不可能同时间处理很多事情。但协同部门又有很多需要解决的大需求，小需求，小建议和漏洞bug等，需要跟进解决。一般来说，都会将信息列入需求池的待处理需求中。
需求池的详细程度也决定了需求池的维护成本，在这里，我推荐一种“单项需求卡片”的记录方式，搭配需求池进行使用。可以有效解决同时间解决不过来的需求事物，并能在日后启动需求时，快速的找到相关人员及相关内容等。
当然了，一句话能描述清楚的事情，也没必要动用“单项需求卡片”这么重的东西，灵活变通，切勿浪费大家的时间。
“单项需求卡片”是干什么的？
“单项需求卡片”类似我们去银行办理业务，领个号后，开始填写的业务相关表格。到柜台时，方便柜员进行一系列的资料录入工作。回到工作的场景，就是让需要提需求的同学填写一份表，然后自己根据表上的内容就可大概了解这位同学需要提个什么需求。
“单项需求卡片”需要什么内容？
需求编号
一般需求编号使用大家都懂编写，且看到都能快速转译的方式比较合适。
如：年月日（YYYYMMDD）+姓名。可根据实际需要添加其他大家都懂编写的标签。
需求类型
-
功能需求
-
非功能需求
填写的人不一定都非常熟悉产品结构，尽量的易懂即可。
来源
此信息比较重要，方便追溯根源。
产生需求的用户和该用户的相关信息，描述清楚即可。
场景
产生该需求的时间，地点和环境等场景信息。
描述
尽可能使用（主语+谓语+宾语）的表达形式，不要加主观修饰语句。
原因
这也是非常重要的信息，作为产品经理，此时此刻必须保持怀疑的心态，因为有很多的理由是假想出来的。
为什么会有这样的需求？发起者的解释是什么？
验收标准
这个需求要怎样才算是满足了，定义一个标准，好让产品同学和开发同学以及设计同学有个底
-
尽可能使用可量化的语言；
-
无法量化的标准要举例解释。
需求的生命周期
这个属于需求的紧迫度和可持续性内容。
-
需求的紧迫程度；
-
上线后使用周期和持续性等。
参考材料
对此需求有一定参考价值的材料及有用的相关资料，不一定需要封装压缩，引用说明，能找到即可。
需求关联
与此需求有关联关系的各种
-
人：与此需求相关联的任何人；
-
事：与此需求相关的业务、相关功能及事件等；
-
物：与此需求相关的系统，设备和其他产品等。
竞品对比
-
竞争对手是如何实现该功能的
-
竞争对手该功能获得的评价。（大众用户角度，公司内部角度，产品设计角度等层面进行考虑）
给出规范定义“1分”差到“10分”好，有个评分概念。
需求重要性
需求的重要性建议产品经理自己内部团队定义，开放填写此栏目，容易造成所有需求都是紧急需求，重要需求。
除非公司有个提交需求系统，可以针对系统设定一些规则，去制衡乱填需求重要性。
小结
还是那句，一切的模板，套路都是死的，灵活应用即可。在不同的团队，不同的公司，甚至不同的时间周期，可能模板都会纯正各种变异和差异，只要问题能解决，这东西甚至没有存在的意义。在此，希望此单项需求卡片能对大家有帮助。