1，更换需求对接人时，需要将当前正在开发的需求开发完毕，在下个需求开展时进行需求对接人更换，以免打断正在开发的需求，导致需求方需求的延期、不满等。
2，项目对应需求，需求对应任务，任务必须是具象化的。例如：
注册需求下可能需要做的任务有：
（1），第三方短信平台对接；
（2），注册页面UI；
（3），注册接口联调；
（4），注册完成后续操作；
这里就涉及到WBS（项目分解）：
逐级分解：从项目级别开始，逐级将任务分解为更小的子任务；
范围分解：将项目的整体范围分解成可管理的部分；
产品分解：将项目的可交付成果（产品）分解为更小、更具体的组成部分；
组织分解：根据执行任务的不同团队或部门，将任务分解成不同的组成部分。
具体分解如下md：
# WBS工具概念和场景记录
## WBS是什么
### 概念
#### 项目管理的一种工具，将项目分解成可用时间去量化的任务；
### 目标1
#### 明确项目范围；
### 目标2
#### 清晰地、完整地显示项目目标的全部任务（最小颗粒度）；
### 目标3
#### 可通过最底层的任务量化目标进度，如进行时间估算、安排实施进度、分配资源和监控、风险识别；
### 目标4
#### 也是项目管理中最重要的一点，就是[任务分配]，通过WBS的最小颗粒度分解，将清晰的人物分配到团队或者具体人员；
## WBS在哪个阶段使用？
### 阶段1
#### WBS在项目规划阶段使用，项目整体实施/目标范围确定后，就需要对项目进行任务拆解；
### 阶段2
#### 项目规划完成后立马进行WSB分解；
## 如何使用WBS？
### 1，明确整体项目的目标范围，这样分解也有范围和边界；
### 2，确定最高层级，通常交付的成果或项目名称为最高层级，例如“内容管理系统”、“xx社交APP”；
### 3，确定第二层，通常为独立的模块或者相互独立的项目阶段，例如项目阶段（设计、开发、测试），模块（用户模块、课程模块、电商模块）；
### 4，确定第三层，对上一层级的每个元素继续分解，例如[用户模块]-(权限模块、个人信息模块、用户隐私模块)；
### 5，确定第四层，对上一层级的每个元素继续分解成任务，可以进行量化（时间、工作两）的任务，例如[权限模块-(注册、登录、修改密码、切换账户等)；
### 6，原则
#### 原则1，WBS分解范围必须是整个项目的目标范围，不能多也不能少；所有子层级的工作之和必须等于其父层级的工作；
#### 原则2，同一层级内的各个元素应该是相互排斥的，没有范围上的重叠；
#### 原则3，WBS的分解应基于“产出物”（名词），而不是“行动”（动词），虽然工作包本身描述的是工作；
### 7，为每个WBS元素分配唯一的标识符（如 1.1, 1.1.1），以清晰表示层级关系；
### 8，确保WBS分解的准确性、完整性并获得团队认同；
### 9，表现形式：可以是层级列表（如之前的 Markdown 示例）、树状图（组织结构图样式）或思维导图；
3，项目上下游任务交接的关联性。
任务交接的关联性，例如：
设计师跟开发的对接，设计师设计两个页面，表单提交页面和已提交内容的展示页面。
那么当设计按照自己任务去交付已完成页面的时候，首先交付给开发的页面应该是表单提交页面，其次是内容展示页面。根据逻辑而言内容不去提交是不会有内容展示的，所以可通过关联系分析上下游交付的优先级；
开发交付于测试亦是如此，需要各个员工自行判断任务的有限期，保证上下游任务能够紧密衔接。
4，需求（功能）的闭环思维。
（1），需求在设计、开发、测试全环节的时候，要有闭环思维，不能够有缺陷和漏洞；
（2），需求（功能）的提出、完成、落地使用、必须是一个闭环。
例如：
[1]，需求方输出的功能，产品经理需要认真沟通、调研他们所需要此功能的目的是什么，主要是为了解决什么样的问题，沟通清楚，避免开发的时候不及预期或后期开发完成后需求方不去使用；
[2]，当产品沟通清楚后，需要对需求进行设计，设计需要合理，遵循用户体验，多多跟技术进行沟通；
[3]，落地需要跟需求方再次沟通，告诉其使用流程或者后期出使用手册等；
[4]，落地的功能需求方使用后，带来了什么样的数据，需求方对此功能是否满意，此数据能够带来什么样的价值。
[5]，需求或功能的输出一定是要有目的性的，不能为了输出需求而输出需求，要么增加用户活跃度、增加激活、增加留存，要么就是增加GMV、增加效率或减少成本，包括时间成本和其他资源成本。
需求（功能）最终面向的是解决用户或使用人什么样痛点，最终带来了多少收益或者减少了多少成本，所以需求最终的目的还是商业化，要么增加收入要么减少成本。
例如：后台增加了统计和报表功能，能够让会计人员迅速的查看收入和支出，减少了会计人员的时间成本，增加了效率；
前台增加了线上充值业务，增加了老用户的留存，增加了新用户的激活率等。