“公司经常用 TAPD 来进行需求管理与敏捷迭代，那么针对 TAPD 上的第一步需求记录应该怎么写呢？本人就做了一个小小的总结与归纳，助力产品更加方便准确地完成需求的填写！”
什么是需求
需求 = User Story，用户故事是从用户角度来描述用户渴望得到的功能。 用户故事包括三个要素：
- 角色：谁要使用这个功能；
- 活动：需要完成什么样的功能；
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
这些知识在我们日常的产品工作中都能接触到，大家或多或少都会理解到这个意思，但是实际做起来的时候总是发现这个功能很难做，那个东西没考虑到，然后手忙脚乱的一通补救，最后发现，做了很多没用的东西也浪费了很多时间。
需求挖掘是常说的一个词汇，很多产品经理也知道要去挖掘这个需求，知道用户真正要的是什么，但是为什么还是很多人挖掘不到真正有效的需求呢？我总结一下，大概有以下 2 点原因：
认识不清楚什么是需求
需求的定义在上方已经说清楚了，但是很多人往往看了一眼然后就记住了一个大概就忘了，感觉需求好像就是用户需要什么，然后要求什么的，这个应该就是需求吧！
需求 = User Story
需求 = User Story
需求 = User Story
说了三遍后，我们知道了需求就是用户故事，好的，现在我们记住了：需求就是用户故事，那么用户故事是什么呢？
不知道什么是用户故事
用户故事我们也在上面说了：「用户故事是从用户角度来描述用户渴望得到的功能。 用户故事包括三个要素……」
用户故事是从用户角度来描述用户希望得到的什么功能，然后像讲故事一样说出用户的需求和期望的功能。那么这样的话，用户故事的重心又来到了——故事，这个词上面。于是我们有了用户故事的三要素，其实就是告诉我们，要怎么去讲好一个用户的故事：
As a… (作为…角色或岗位)
I want… (我想…希望做什么)
So that… (以便…达到什么目的或商业价值)
知道了用户故事后，我们来谈谈需求沟通
一般情况下，我们公司有几种需求沟通的情况：
- 口头沟通或者描述；
- 填写需求申请表，让用户进行描述需求，然后期望怎么样；
- 产品自己现场了解，然后记录相关需求；
- 其他方式记录需求；
这里的方法在不同的公司都不一样，但是大体上来说，需求的收集很多时候都是较为快捷或者是短促的，我们并没有更多的时间去针对一个需求与用户或者当事人交谈很久。于是，很多时候，我们记录了需求之后，自己想想差不多是这样的，这样搞应该没问题，然后就开始动手画流程，画原型，出文档，然后就去评审或者先评审了再去画原型和出文档。
这里我想说的是需求的收集可以有多样性，但是产品一定要学会用 User Story 的方式来核实需求，当你用这种方法填写到 TAPD 里面的时候，你就可以知道这个需求大概要怎么做或者是有什么没有考虑清楚的。
例如：当你要新增一个导出功能的时候，你当时可能只是想到了用户需要这个数据，然后说我要给他做一个导出功能，这样好像没问题。然后问问要导出什么字段，要什么格式等等。但是如果你没有用 User Story 的方式去梳理的话，有可能就会遗漏一些东西。
导出功能的用户是谁？是谁提出的这个需求？没提需求的用户也是这个功能的用户么？
用户想要这个功能干嘛？是想导出数据，然后制作报表，还是只是想用这些数据来看看进展或者是其他。导出功能除了要这些字段之外，是否还需要其他字段，用户使用的时候要怎么点击，然后怎么反馈？
用了这个功能后用户达到了什么目的？收益是否大于开发的成本支出？这个功能是否满足了用户的需求？是否让用户提升了效率或者带来了舒适的体验感？
USer Story 虽然简单，但是日常工作中还是很多人会忽略掉它所内含的东西，而导致需求分析不到位，产品做出来遗漏的点也会少了很多。
其实正常的工作中，更应该让用户按照这种模式去提出需求，让产品经理更好的梳理这些东西！同时在需求池里面按照这样的模式填写之后，还会让开发更准确的知道开发这个的目的，同时还能根据这个思路来反推，看看产品设计的东西是否科学合理，还有没有漏洞！
