本系列的前两篇文章分别介绍了售前到交付交接过程的必要性（从售前中标到项目入场，大多数团队都会忽视的关键过程），售前过程交接（售前到交付，交接过程四要素之“风雨彩虹”）上文提到，从整体来看我把整个交接过程分为以下四个方面：售前过程（售前经历）、需求范围、交付风险、其他补充
无论我们的交接过程是否规范、完整，基本上都会包含“需求范围”的交接。但作为后续整个项目团队的主要工作内容和工作边界，你觉得一份招标公告、一个投标文件、一版售前PPT够吗？下面我们一起看看，需求范围应该包含哪些内容，如果你作为交付团队的项目负责人，或者产品经理（需求分析师），你需要知道哪些信息之后，才有足够的底气开工呢？我会把需求范围的交接简单分为五类，分别是整体情况、关联方情况、我们欠缺的内容、我们可利用的内容、其他补充。下面来逐一介绍
这一点不用过多赘述，如果一个团队连需求的整体功能点交接都没有的话，那你可以考虑跑路了
不过我来分享一个自己觉得效果更好的技巧：以讲故事的方式重新整理一遍需求的整体范围我不建议对照着word文档或者Excel列表一条条的确认，更习惯用思维导图，将功能分为三级，像剥洋葱一样以业务场景为核心路线，简单串讲各级功能情况这样做一方面更容易让听众理解，毕竟很多交付负责人或需求分析师之前并不了解这个业务；另一方面也能让自己在重新梳理的过程中产生新的思考，发现新的盲区因为我们知道，对照着文档讲解，思路一定是被文档中的内容带动的，很难真正独立思考其中的合理性和全面性
就像做产品讲解之前一定要“试讲”一样，自己脑子里想的和嘴巴上说出来的，往往差异很大现在越来越多的项目不会是一个“业务孤岛”或者“数据孤岛”，都会或多或少和其他系统产生对接需求。所以需求交接的第二个重点便是关联方的对接情况
而且关联方的对接情况很难做到标准化，因此这里的工作任务更多会反映到交付周期、交付工作量以及交付成本上，其重要性不言而喻
很多团队都有这样一个不成文的规定：优先搞清楚对外的工作任务，毕竟涉及到很多沟通协调和特色化改造。而自己产品内所缺失的功能，实在不行就加班呗，起码“自主可控”
为了交付团队方便梳理工作内容，讲我们现在具备什么功能，不如重点说我们欠缺哪些内容。因为欠缺的内容，都是后续最基础的工作
欠缺的内容可能是场景和功能上，也可能是技术架构上，也可能是在设计层面或者文档层面。总之，在售前过程中能够预知的，交付之前我们没有的，都需要清晰的列出来之前我会梳理一个欠缺内容的思维导图给到项目经理，再和他一起整理一份Excel列表。这份Excel列表后续便可以作为第一个版本的“需求矩阵”或“任务矩阵”进行逐项跟踪好记性不如烂笔头，无论是交出人还是接手人，都需要把这些已经预见的事项这一点我相信大多数团队在交接时都很少涉及。主要内容是基于售前团队对于现状的分析，结合客户各个对接部门、以及关联方错综复杂的关系，而识别出的机会
比如项目周期很紧张，按照正常交付工作量来看几乎是不可能完成的任务。但是其中涉及到几个关联系统对接改造的任务，对方系统的配合度不足、或者任务排期很延后。这便是我们可以利用的，拉长交付周期的一个机会
比如客户方涉及到多部门协作，且存在一定的沟通壁垒。虽然看起来会影响整个项目的进展，但对于交付周期未定、需求评审未定的情况下，不见得完全是一件坏事
比如客户的技术方很支持我们，后续可以通过技术方的关键人帮我们协调哪些事情，尺度和张力是怎样的
其实，就像《反脆弱》这本书中提到的观点一样。每一次危机对于脆弱的人或组织，可能都是致命性的，但对于反脆弱能力强的组织，很可能是个机会
毕竟有句老话叫“乱世造英雄”
其余可能包含自己对于需求范围的工作意见或建议，可以列举客户方需求对接的责任人、负责部门，以及这些人的脾气性格，对我们前期的认可程度等。总之能想到的都可以先写上以上五部分，基本涵盖了需求范围的核心要素，其他内容可能会根据产品不同、行业客户不同形成很多差异，所以需要我们结合实际情况整理出适用于自己团队的“交接清单”
下一篇，我将继续总结交接过程中的第三个要素：交付风险，欢迎持续关注~
