关于需求文档

有很多人说些产品文档很累赘，开发看起来也很累，但其实产品文档对于产品人员梳理产品需求有很大的帮助，在编写的过程中产品人员会对自己的思路做一个全面的整理，也会发现很多之前拍脑袋时没想到的问题。所以在开发某个功能的时候我还是会将该功能的开发目的、背景、范围等信息写在tapd中，让开发在做需求前先明确究竟我们为什么要做这个需求以及要做成什么程度。这部分内容会放在wiki里做整理。 
具体到需求层面，我对于父需求和子需求会根据不同的侧重点进行编写。对于父需求，我会在详情里加入需求介绍的wiki链接，整个大需求的规划框架、以及父需求开发的进度规划。对与子需求我可能更侧重去添加需求具体内容、交互样式和视觉效果等。值得注意的是，产品人员必须在规划需求时考虑到各类情况，避免出现开发完成后又反复更改的情况。

一、目的

本文目的: 写出自己实操中是如何将业务需求划分用户故事的.  想请各位帮忙分析, 这种方式是否正确, 有哪些需要修改的, 理由是啥? 

本文出自于 对敏捷开发的特别热衷的人 , 但对用户故事应该长什么样,按照什么标准进行分解, 一直在收集与提炼 总结中.

 

二、实例

业务需求: 
行政部小王,今天接到主管电话, 说公司领导李总要去深圳出差, 让小王安排行程. 

具体的要求: 7月6日12点要到深圳南山某个酒店 - 8号晚上6点可以返回. 

需求调研: 
小王接到这个任务后进行 5w2h 的方式 与 李总核对 
1. how : 出行方式有要求不 火车 , 飞机 
             住宿有要求不 
2. who: 出行人数 , 是否是您一个人, 确定 
3. where: 从哪里出发, 住哪里 , 酒店有要求要早餐不 
4. when: 几点出发 , 几点到哪里深圳 , 几点到住的地方 

通过上述沟通, 确定大致的出行计划

1. 8号中午10:00 定返回的票 

2. 出行方式没有要求都可以, 基本当天都可以随时出行

规划需求:
假设上述事件是个项目, 我们规划需求, 从业务需求中提炼用户故事

A. <作为> 小王 <想要>了解李总的出行情况, <实现> 规划好李总的出行计划表 
B. <作为>李总 <想要>在出发前确定好自己的出行安排<实现>提前安排好自己的出行计划,按时到达目的地 

对用户故事A 进行任务分解 
A1. 确定出行人数 
A2. 确定出行方式 
A3. 确定住宿环境, 提前预约 
A4. 确定返回的计划 与 方案 
A5. ... 

对用户故事B 进行任务分解 
B1. 确定出发前的准备 
B2. 确定出发时间与目的地 
B3. 确定到达深圳的时间, 与去住宿的方式 预计到达酒店的时间 
B4. 确定办事的位置与准备事项等 
B5. ... 

之前团队整理业务需要的时候 , 使用<作为>... <想要>.. <实现>... 的方式, 提炼产品需求
后来越提炼越细 将feture 细分到 task , 比如下面 用户故事A1, A2 做为子用户故事

 

三、争议

按照上述方式需求是这样的

A1. <作为> 小王 <想要>了解李总的出行人数情况, <实现> 好订票与住宿安排

 

A1. 确实是个需求, 但不具备独立性, 且划分的太细  , 为此我觉得A1 应该算任务. 有明确的答复与验收标准

 

问题:

1. 你觉得A1 是问题,还是需求 ,A1对应的验收结果应该是啥?

2. 这个项目怎么用需求跟踪矩阵进行管理,  (与本议题无关)