一个好的敏捷项目的需求是循序渐进迭代的，项目过程包含价值和流程的可视，需求开发结果可集成、可测试验证，软件基本一直处于可用状态，用户价值实现的流程贯穿于整个团队运转。要实现以上内容，需要团队成员在项目的各个环节实践敏捷方法。
下面将从用户的需求开始到最终的价值交付为止，分期为大家讲述如何实践敏捷项目，今天的话题是需求收集环节。
图源：网络
准确的收集需求是确保团队最终交付价值的基础，两段内容相同的对于开发需求的描述，背后所包含的业务角色、业务价值、时间紧迫度有可能大相径庭；准确、完整地收集需求并传递给团队，是确保项目敏捷的关键因素。这里我们通过设想一个真实项目、以一个需求分析师的视角来看看需求收集需要哪些工作。
预设案例：你从公司的商务售前获悉，某银行财富中心希望一款数字化产品来提升员工在保险销售中的各种问题，籍此来提升员工销售能力及该财富中心整体销售业绩——现需要你了解客户需求，为客户设计产品功能，并推动团队的敏捷交付。
你应该通过你的PM，售前人员，尽可能多的去了解业务，准备尽量多的业务背景知识，了解甲方的组织架构、业务规模、业务发展趋势、市场规模（这是你后面创新方向的基础）。
通过了解你得知：
我们的客户是保险业务中的第三方业务代理（银保渠道）；
在行内是属于银行零售条线、财富管理，零售是客户的最强优势，保险是零售价值贡献的中流砥柱，银行渠道主导保险公司配合，全行近9000人销售；
规模增长速度是年30%，大环境是政策严控理财型保险。
这些都是你在入场前需要尽可能了解的知识，以便于可以预先设想出客户的解决方案大方向，为整个需求收集、方案设计打下基础，对于价值的逐步实现开始形成意识，同时在后续的机会点和创新方案梳理枯竭、选择困难时，还可以回头来看这些大背景。
作为一个有经验的需求分析师，在开始正式客户沟通前确定好你的团队人员是必须的，在没有PM的情况下这个工作通常都会由你来承担。ToC的业务具有复杂的体验设计，及时配备好人员，对于人员的能力、数量和需求设计阶段可能的工作量，要有一个预先的匹配。
通过背景了解，保险项目是一个非常注重用户体验、面向客户的产品，内容界面和使用用户的类型非常多，因此在前期就需要配备双BA、双UX的人员阵容；TL的人选也是非常重要的，当你认为TL的缺失、技术瓶颈限制了你的业务输出、TL的沟通和胜任力不足的时候，应该尽早提出并且获取外部帮助，适时的时候甚至需要暂停手头的工作。
一定要注意，干系人的管理里，包括了甲方的技术负责人（在业务主导的项目中邀请我们做需求设计时，甲方的技术很可能是一个隐藏人物），业务和技术的利益关系，技术方的硬性要求等，都需要你的TL尽早排查，举个极端的例子，“当你的业务线框图已经输出后，TL告知界面要从web变成H5“，那对整个项目和团队的士气将是灾难性打击。
上述的人员配备决定了你是否合适继续项目。一旦暂停，随之而来的风险往往不可避免，因此我们尽可能去排查，一个项目能否开始，这里面最重要的是，你的客户：客户方的PO，客户对于业务的理解，对于资源的协调能力，以及产品的构想、运营落地，都是项目能否成功的关键，试着总结一套你自己的工具——在项目的起点，用它来判断，这个客户、这个项目，是否应当开始或继续。
在进行内部协商沟通时，我们需要注意以下几点：
与客户沟通前，需要内部先讨论达成一致，避免在和客户沟通的时候发生分歧，尽可能多做假设和预演；
业务的整体框架要有唯一的人输出，最好由BA画出来呈现，BA在画的过程中也方便BA梳理业务流程；不要试着一人一部分然后团队拼凑在一起，团队对于业务术语、流程、界面的认知在这个阶段并没有达成统一！
团队分工一定要明确，避免出现大家等活干的情况，如果没有人推动，你就要去主动的推动、分配任务，可以参照我们的需求设计报告中的输出内容（也许呈现形式有差异，但这就是我们要做的工作）。
在做好了以上步骤后，接下来就该开始真正的需求收集与设计了，具体内容我们下期再聊。
