1，更换需求对接人时，需要将当前正在开发的需求开发完毕，在下个需求开展时进行需求对接人更换，以免打断正在开发的需求，导致需求方需求的延期、不满等。
2，项目对应需求，需求对应任务，任务必须是具象化的。例如：
注册需求下可能需要做的任务有：
（1），第三方短信平台对接；
（2），注册页面UI；
（3），注册接口联调；
（4），注册完成后续操作；
这里就涉及到WBS（项目分解）：
逐级分解：从项目级别开始，逐级将任务分解为更小的子任务；
范围分解：将项目的整体范围分解成可管理的部分；
产品分解：将项目的可交付成果（产品）分解为更小、更具体的组成部分；
组织分解：根据执行任务的不同团队或部门，将任务分解成不同的组成部分。
3，项目上下游任务交接的关联性。
任务交接的关联性，例如：
设计师跟开发的对接，设计师设计两个页面，表单提交页面和已提交内容的展示页面。
那么当设计按照自己任务去交付已完成页面的时候，首先交付给开发的页面应该是表单提交页面，其次是内容展示页面。根据逻辑而言内容不去提交是不会有内容展示的，所以可通过关联系分析上下游交付的优先级；
开发交付于测试亦是如此，需要各个员工自行判断任务的有限期，保证上下游任务能够紧密衔接。
4，需求（功能）的闭环思维。
（1），需求在设计、开发、测试全环节的时候，要有闭环思维，不能够有缺陷和漏洞；
（2），需求（功能）的提出、完成、落地使用、必须是一个闭环。
例如：
[1]，需求方输出的功能，产品经理需要认真沟通、调研他们所需要此功能的目的是什么，主要是为了解决什么样的问题，沟通清楚，避免开发的时候不及预期或后期开发完成后需求方不去使用；
[2]，当产品沟通清楚后，需要对需求进行设计，设计需要合理，遵循用户体验，多多跟技术进行沟通；
[3]，落地需要跟需求方再次沟通，告诉其使用流程或者后期出使用手册等；
[4]，落地的功能需求方使用后，带来了什么样的数据，需求方对此功能是否满意，此数据能够带来什么样的价值。
[5]，需求或功能的输出一定是要有目的性的，不能为了输出需求而输出需求，要么增加用户活跃度、增加激活、增加留存，要么就是增加GMV、增加效率或减少成本，包括时间成本和其他资源成本。
需求（功能）最终面向的是解决用户或使用人什么样痛点，最终带来了多少收益或者减少了多少成本，所以需求最终的目的还是商业化，要么增加收入要么减少成本。
例如：后台增加了统计和报表功能，能够让会计人员迅速的查看收入和支出，减少了会计人员的时间成本，增加了效率；
前台增加了线上充值业务，增加了老用户的留存，增加了新用户的激活率等。