8000字干货：从售前到交付，一场以交接为主的修行热博聚热点

　　很多项目制的工作中，团队在售前到交付的衔接非常“仓促”。本文作者以自己的工作经验，对如何更好地完成工作的阶段性衔接，更快的开展交付工作展开了分析，希望对你有帮助。
　　去年，我写过一篇关于工作交接的文章（工作交接中的“交”与“接”）。不过这篇文章比较概括性，真正的工作交接需要考虑很多场景和“工种”。
　　最近几年在工作中因为频繁参与售前、研发、交付等不同阶段，发现了大多数团队在售前到交付的衔接非常“仓促”。
　　所以，结合本人前些年的工作经验，以及所见、所闻、所学、所感，尝试一篇和产品经理似乎关系不大，但又有很多产品类同行，或者业务类同行在实际工作中会遇到的问题。同时也希望能给售前团队、交付团队工作者带来一些启发和参考，帮助我们更好的完成工作的阶段性衔接，更快的开展交付工作。
　　文章很长，建议收藏。
　　一、为什么要做好售前和交付之间的交接工作？
　　以我们常见的项目制合作为主，面对日益激烈的市场竞争，销售和售前拿新标的难度越来越大。
　　在公司销售同事、售前同事的不懈努力下，甚至于在整个售前过程协调了很多资源（如产品资源，研发资源，其他条线的配合等等）的情况下，终于把这个新项目给拿下了，真是可喜可贺。短暂的庆祝之后，新的问题便要尽快面对，也就是交付过程的整个项目周期要开始了。
　　本次主题的重点不是阐述项目交付过程各个阶段要面临的问题和应对的策略，而是在交付负责人（如项目总监、项目经理，或者产品经理、需求分析师）准备大显身手之前，售前到交付的交接工作应该怎样做才会更好？
　　俗话说，“不打没有准备的仗”。现实中很多团队由于缺乏了售前到交付之间的连接，导致交付前期的压力爆棚，原本可以避免的问题屡屡暴雷，让客户在项目初期就大失所望，失去信心。
　　而第一印象又会对今后的长期工作产生“牵一发而动全身”的影响，也许一个成功的项目和一个失败的项目，从这个项目开始之前，其命运就已经决定了。
　　首先，先来初步了解一个新项目在中标之前，大体会经历怎样的过程。
　　整体而言，新项目的形成包含了线索的收集获取、商机的挖掘转化、方案的沟通讲解（多轮多次）、客户演示及目标确认、招投标五大阶段。
　　这五个阶段并不是什么方法论，而是以个人经验总结的，可能和专业的售前阶段有出入。
　　其中，不同的阶段、不同的客户、不同的行业以及项目背景，每个阶段的工作任务也不尽相同，或者有些阶段会省略，有些会变得很长。
　　比如客户演示及目标确认这个阶段，早些年很多项目都没有这一步，售前人员靠一份PPT一份解决方案，经常做到“空手套白狼”。而近些年则越来越多的客户在售前阶段都要求，除了讲解你们的方案，现在的产品、案例、实际的软件，也要拿来看看，打打分，评估一下差异程度。而这一步又将在最终结果中占到很高的比例。
　　比如从线索到商机的转换，很多企业会把这两步合并为一步。但通过我最近的一些经历，认为线索和商机还是要区分开。而且销售团队如何把更多的线索转化为商机，也是一个非常值得研究和思考的话题。
　　总之，当经历了千辛万苦中标之后，如果只给交付团队甩一份标书，或者之前的售前材料，简单说说客户要干啥，那一定是对结果不负责任、对交付团队不负责任的表现。
　　另外，对于项目经理、产品经理来说，如果售前团队没有进行详细的交接，我们也不能被动等待和盲目开展，应该主动询问很多问题和现状。
　　所以，知道了中标之前经历的大致过程，在后续提问题时才会更有重点，知道哪些阶段的“故事”或“承诺”必须要了解，哪些信息必须要交接对齐。
　　而且交接是一个双向的过程，两个人、两个团队，或者多个团队应该有一个明确的内部交接计划表（清单）来指引这个关键过程。
　　最终的目的，还是把这个项目做好，把客户服务好，把售前吹的牛、挖的坑尽量落实。而真正在开干之前，双方对齐哪些信息，则是重点。
　　二、售前过程的工作交接
　　从整体来看，我觉得售前到交付的交接过程，可以分为以下四个方面：售前过程（售前经历）、需求范围、交付风险、其他补充。
　　本节先来看看售前过程中需要交接哪些内容。
　　1。本次项目的背景
　　其实就是客户基于什么原因要做这个项目，希望通过此项目达到什么目的，或者解决什么问题？
　　其中涉及到多客户部门的，要分别列举。比如业务部门想要怎样，而技术部门又想要怎样，两者之间是否存在冲突等等。
　　我认为项目的背景介绍要尽量详细，尽量不要按照销售、售前人员自己的理解表达，或者应该把信息同步完整之后，再发表个人见解。
　　因为大多数情况下，在售前阶段接触到的信息是不完整的，或者和一线诉求有偏差的。这时更应该客观的反馈信息，让交付团队有一个通篇认识，他们在与客户长期对接过程中逐步筛选和梳理，而非把个人的局部认知转嫁到下一个团队。
　　2。项目的预算和合同额
　　当然，这些数据可能比较敏感，但作为项目经理应该是要知道的。了解合同额方便项目经理进行人员安排、进度安排，以便更好地进行成本控制，做到心中有数。
　　而知道预算额，对于有些客户来说，已申请的预算如果剩余额度较大，在当年也会考虑花出去。所以项目经理也能了解到后续的可操作空间，尤其是遇到需求变更、需求蔓延等阶段，可以结合预算剩余额度，和客户方慢慢“磨”。
　　3。项目机会是怎么来的
　　一个销售线索的来源方式有很多，可能是客户主动联系、公司主动营销、其他项目同事挖掘、公开信息入围、同行推荐等等。
　　为什么要介绍项目机会的来源方式？因为这能够让交付团队更加理解本项目的“源头”，并通过源头理解和客户各条线对接人之间的关系，以及对本公司团队的认可程度等，为后续的交付细节进行评估和预演。
　　4。合同范围之外的附加承诺
　　这一点，很多售前团队会遗漏。而对于客户来说，很多其他形式的承诺会作为后续的验收标准。
　　如果不进行相关问题的交接，当客户主动询问时一脸茫然，或者在出现一些问题时项目经理与客户扯皮，都会造成后续很多工作的困难。
　　客户第一印象很重要，初期的印象最重要。如果能够在项目团队入场前期展现出自身的专业性和信息的全面性，能够为后续的工作打下良好的基础。
　　5。客户演示情况（如有）
　　如果本项目在售前阶段有产品演示环节，则一定要把演示的结果、竞争对手的情况，自身的不足以及在演示时客户重点关注的内容进行全面交接。
　　毕竟，在一次次的售前沟通过程中，都会经历几番“拉锯”，再成熟的产品，进行客户定制化交付时也会存在很多适配、个性化改造。而这些改造对于原产品的业务架构、技术架构都将或多或少的产生很多影响。
　　经历了售前过程中漫长的风雨，终于见到了彩虹，以上提到的“售前过程”便是交接的第一个范围。把“售前过程”交接清楚之后，能够让团队更加理解项目的目标和工作范围。这些内容都是在招标公告、投标文件中很难体现出来的。
　　三、需求范围的工作交接
　　想必大家都能意识到新项目正式实施之前，需求范围的重要性。无论我们的交接过程是否规范、完整，基本上都会包含“需求范围”的交接。
　　但作为后续整个项目团队的主要工作内容和工作边界，你觉得一份招标公告、一个投标文件、一版售前PPT够吗？。
　　下面我们一起看看，需求范围应该包含哪些内容，如果你作为交付团队的项目负责人，或者产品经理（需求分析师），你需要知道哪些信息之后，才有足够的底气开工呢？
　　我会把需求范围的交接简单分为五类，分别是整体情况、关联方情况、我们欠缺的内容、我们可利用的内容、其他补充。下面来逐一介绍。
　　1。整体情况
　　这一点不用过多赘述，如果一个团队连需求的整体功能点交接都没有的话，那你可以考虑跑路了
　　不过我来分享一个自己觉得效果更好的技巧：以讲故事的方式重新整理一遍需求的整体范围。
　　我不建议对照着word文档或者Excel列表一条条的确认，更习惯用思维导图，将功能分为三级，像剥洋葱一样以业务场景为核心路线，简单串讲各级功能情况。
　　这样做一方面更容易让听众理解，毕竟很多交付负责人或需求分析师之前并不了解这个业务；另一方面也能让自己在重新梳理的过程中产生新的思考，发现新的盲区。
　　因为我们知道，对照着文档讲解，思路一定是被文档中的内容带动的，很难真正独立思考其中的合理性和全面性。
　　就像做产品讲解之前一定要“试讲”一样，自己脑子里想的和嘴巴上说出来的，往往差异很大。
　　2。关联方情况
　　现在越来越多的项目不会是一个“业务孤岛”或者“数据孤岛”，都会或多或少和其他系统产生对接需求。所以需求交接的第二个重点便是关联方的对接情况。
　　而且关联方的对接情况很难做到标准化，因此这里的工作任务更多会反映到交付周期、交付工作量以及交付成本上，其重要性不言而喻。
　　很多团队都有这样一个不成文的规定：优先搞清楚对外的工作任务，毕竟涉及到很多沟通协调和特色化改造。而自己产品内所缺失的功能，实在不行就加班呗，起码“自主可控”。
　　3。我们欠缺的内容
　　为了交付团队方便梳理工作内容，讲我们现在具备什么功能，不如重点说我们欠缺哪些内容。因为欠缺的内容，都是后续最基础的工作。
　　欠缺的内容可能是场景和功能上，也可能是技术架构上，也可能是在设计层面或者文档层面。总之，在售前过程中能够预知的，交付之前我们没有的，都需要清晰的列出来。
　　之前我会梳理一个欠缺内容的思维导图给到项目经理，再和他一起整理一份Excel列表。这份Excel列表后续便可以作为第一个版本的“需求矩阵”或“任务矩阵”进行逐项跟踪。
　　好记性不如烂笔头，无论是交出人还是接手人，都需要把这些已经预见的事项。
　　写清楚！
　　4。我们可利用的内容
　　这一点我相信大多数团队在交接时都很少涉及。主要内容是基于售前团队对于现状的分析，结合客户各个对接部门、以及关联方错综复杂的关系，而识别出的机会。
　　比如项目周期很紧张，按照正常交付工作量来看几乎是不可能完成的任务。但是其中涉及到几个关联系统对接改造的任务，对方系统的配合度不足、或者任务排期很延后。这便是我们可以利用的，拉长交付周期的一个机会。
　　比如客户方涉及到多部门协作，且存在一定的沟通壁垒。虽然看起来会影响整个项目的进展，但对于交付周期未定、需求评审未定的情况下，不见得完全是一件坏事。
　　比如客户的技术方很支持我们，后续可以通过技术方的关键人帮我们协调哪些事情，尺度和张力是怎样的。
　　其实，就像《反脆弱》这本书中提到的观点一样。每一次危机对于脆弱的人或组织，可能都是致命性的，但对于反脆弱能力强的组织，很可能是个机会。
　　毕竟有句老话叫“乱世造英雄”。
　　5。其他补充
　　其余可能包含自己对于需求范围的工作意见或建议，可以列举客户方需求对接的责任人、负责部门，以及这些人的脾气性格，对我们前期的认可程度等（具体内容在“人情世故”交接那一部分）
　　总之能想到的都可以先写上。
　　我觉得交接不怕内容多，更怕遗漏和不确定性。
　　以上五部分，基本涵盖了需求范围的核心要素，其他内容可能会根据产品不同、行业客户不同形成很多差异，所以需要我们结合实际情况整理出适用于自己团队的“交接清单”。
　　四、交付风险的工作交接
　　售前过程中，其实我们能够预知到很多后续的风险情况，如果能够将“交付风险”做好交接，那一定是一件非常有价值的事情。
　　当我们在需求范围交接中，把“我们欠缺的”这部分内容梳理清楚，前期埋的雷应该能明确一大半。其他方面的风险可以大体分为以下几类：
　　1。人员风险
　　比如投标时对于人员的安排。可能很多标书中会写人员清单，但这些人员有几个是可以真正具备入场条件？如果不满足，需要找哪类人员进行置换？尤其是对于中大型的项目团队，临时组建一个10人以上的项目组，即便人数凑够了，但真正的团队战斗力又将如何？
　　项目组中人员梯队的建设、经验及年限的要求，人员入场时甲方是否有面试要求，入场后客户是否有一些管理要求会限制团队人员的稳定性？
　　比如前两年疫情，大多数项目组都会要求不允许跨市流动，对于长期出差的同事将是一个很大的考验。即便是现在疫情结束，客户方是否对于工作时间、着装等有严格要求，入场人员是否能够完全遵循。
　　这些看起来很小、很正常的事情，往往会对后续的实际交付产生不必要的影响。
　　之前我也遇到过一些从其他团队借调过来，或者新招的人员，因为不满意客户方的管理制度而离职。
　　频繁的人员变动会让客户方产生极大的不满。
　　2。成本与进度风险
　　很多项目受限于竞争压力，首次中标都会压低价格，进而导致成本不可控。再加上上述需求蔓延的问题，人员稳定性的问题，最终导致进度延期。
　　很多项目其实在真正启动之前，就已经注定要延期、要超支。那么面对这样一个难啃的骨头，怎样给交付负责人吃一颗定心丸？是否需要在交接时由领导出面给予一定范围内的授权？
　　记得之前参加一次项目管理培训，老师说：赚钱的项目、容易的项目很多负责人愿意做。但不赚钱甚至明知赔本的项目，从公司考核角度来看，是否应该进行特殊对待？怎样考核一个项目负责人的价值？
　　你做这个项目，能赔10个人月的工作量，我做能赔5个人月的工作量，这就是我的价值。但是我的价值在团队考核层面能体现出来吗？
　　这就像战争一样，将军派士兵出征前，这些问题要不要说清楚呢？
　　3。技术风险
　　很多客户对于技术栈的要求有自己的规范。比如数据库有很多种，数据标准化管理规范也有各自的要求，一款产品在客户方落地时，相应的技术组件改造也是一个非常大的工作量，而且是优先级较高的。
　　这类技术风险如果没有提前预判和交接，交付团队按照原有的习惯评估推进的过程中，很容易对这些“额外”工作产生反感情绪。
　　即预期与现实严重不符，导致军心涣散。
　　4。风险一定要前置
　　因为我不是技术出身，所以对于技术风险相关的内容可能整理的不全面。但我坚信这些风险一定要前置，并且以工作任务的形式系统化、具象化，并设定优先级和跟踪矩阵。
　　从时间管理的方法论上来说，风险都是重要但不紧急的事情，而我们更多的关注点可能在于当下已经暴露的问题（即紧急但不重要的事情）。
　　而因为已经暴露的问题占用我们全部精力之后，逐渐让重要但不紧急的事情发展成重要且紧急的事情，从而形成小团队内部的恶性循环。
　　毕竟，项目交付是一套成熟的、体系化的管理过程，而非像救火队员那样哪里出了问题解决哪里。
　　提前把问题梳理好，其背后隐藏的价值比表现出来的价值高很多。
　　5。没有解决建议的提案都是“耍流氓”
　　“反正问题就是这些，你们看着办吧”这是我听到过的非常不负责任的交接心态。
　　其实交付过程中的绝大多数风险，都是在售前过程中积累起来的。当然，这并不是说售前不能“挖坑”，因为本身两者的目标存在差异。
　　售前过程为了拿标，做出一些承诺和妥协都是正常的，但我相信每一次在妥协时，虽然觉得有风险，但依然存在希望或者信心，相信交付团队可以搞定。
　　所以这些亲手挖的坑，要么给一些建议，比如某个需求和我们在另一个客户那里的很像，可以找谁协助解决；比如哪些问题存在争议，客户方还没有完全确认，但其中的几个方案对于我们来讲，A最优、B次优、C能做、D很难。我们要保B挣A。
　　或者表个态（比如需要我后续怎样配合，我一定尽力之类的）。当然，这只是表态，到时做不做又是另一回事。
　　我们会发现很多团队的内耗及管理问题，就是这样一点点积攒的。
　　五、人情世故的工作交接
　　所有的交接内容，其实归根结底都是为了“知己知彼”。
　　上文提到的内容更多是客观的、不可更改的事实，而下面的内容，更偏向于主观的，讲究人情世故的内容。
　　1。客户方主要干系人的性格
　　通过售前过程的接触，相信我们的销售团队、售前团队对于客户方的主要对接人都有了一定的了解。通过对方言谈举止能够大体评判此人的性格以及后续接触过程中需要注意的事项。
　　对于这一方面的交接，我猜90以上的团队都会忽视。而这恰恰又是非常重要的一环。
　　比如有些客户比较务实，对于细节很看重，如果没有提前的心理准备，很多项目经理在实际工作中会有很大的压力。而这类客户反而能够通过专业的工作质量快速收获认可。
　　比如有些客户对于自己所负责的领域很精通，那么项目负责人或产品经理最好不要“忽悠”对方。哪些能做、哪些可以尽量做、哪些不可以做都要分清楚，而不是几次交流下来让对方觉得你不专业。
　　再比如，前期和哪些对接人关系比较好，对方是倾向、支持我们的。对于这类人一方面要更好的维系关系，另一方面也可以想办法和对方汇报一些实际情况，以求对方的建议和协助。
　　诸如此类，在交接过程如果能够把未来将要面对的这些人员做一个初步介绍和预判，相信对项目负责人和前期入场的产品经理会有很大的帮助。
　　2。客户间的组织关系
　　很多新建项目都不是一个部门在负责，涉及到主办、协办。客户方也是这样，尤其是一些大型企业、国有企业，部门间的职责分工很明确，部门间也存在或多或少的对接壁垒。
　　所以如果想更好的推进我们的项目交付，梳理客户方各对接部门之间的关系，也将是一件很有意义的事情。
　　比如某项目由A部门主办，B、C部门协办，但是A和B之间因为某些历史原因，在此项目上存在争论点，可能会造成B部门不配合的情况。
　　这些可预见的问题要提前说清楚，同时也可以提供一些建议，比如可以找到哪位关键人来推进事情的进展。
　　3。关联系统之间的关系
　　除了客户方的多部门对接，在交付过程中也经常遇到多个系统之间的技术对接。而因为都是第三方公司，也可能存在目标不同、利益不同的情况，甚至可能出现过直接竞争关系，导致在对接时对方不配合。
　　这三个方面，其实都属于“人情世故”的范畴。
　　项目交付既是做事，也是演出！
　　我们努力把项目做好，努力把角色扮演好，无论遇到哪些难题，最终的项目目标才是我们唯一为之奋斗的灯塔。
　　六、产品和交付何时介入售前流程？
　　通过上文的分享，我们可以结合自身团队情况和行业情况，整理一个标准化交接清单，为一个顺利的交付过程打下良好的基础。最后，则聊一聊在售前过程中，产品经理或交付经理应该什么时候开始介入呢？
　　其实大多数团队在售前过程中，或多或少会有产品经理的介入，尤其是针对一些大客户、重要客户，需要方案经理（售前）和产品经理结合客户的需求商讨定制化方案。
　　而交付经理很多都是在售前过程不介入的，除非在特定场景下需要技术支持，且研发团队抽不开身的时候。
　　这件事可以和项目开发过程中，测试人员何时介入工作进行类比。
　　比如，大多数团队都会在开发阶段的后期委派测试开展工作，这样可以降低人员成本。但较晚的介入会使测试对于项目的理解程度不足，进而引发测试覆盖度不足等情况。
　　所以很多团队开始将测试人员前置，前置到设计阶段，甚至是需求阶段。测试人员参与需求评审，为后续的测试工作打下夯实的基础。
　　然而这种方式又会提升人员成本，降低测试人员的利用率。有时参与需求分析的是张三，等到真正开始测试的时候张三在忙别的，或者离职了，只能派李四去参与，那么张三之前的工作也就白做了。
　　放到售前过程是同样的情况。面对不确定性极强的售前机会，公司要不要让交付经理参与支持？
　　参与，一定能够提高售前方案的健壮性和合理性，也能够在售前过程向客户展现我们的专业能力。但交付经理需要从现有工作中抽离出来，同时不确定付出的努力是否会保证项目中标。
　　有些团队会让交付总监提前参与售前过程，经过客户交流、演示、招投标几轮接触之后，交付总监便能直接开展后续具体工作。但是这种情况据我了解还是少数。
　　毕竟，售前客户的数量级是比较大的，交付团队无法按需匹配过多的资源支持，除非针对一些重要客户、战略客户。
　　另外，从“铁三角”工作模式来看，交付经理也应该与销售经理、方案经理一起介入客户营销的过程，提供应有的专业支持。但我觉得此时交付经理的介入程度很浅，因为他可能还有很多项目需要做，很难投入更多的精力放在这些“不确定”的项目机会上。
　　其实，说到底还是商业模式和人员成本的问题，这些问题不在今天的讨论范围之内。
　　所以，这个过程需要形成一种可执行的协作机制，大致梳理不同工种之间的分工和准入准出标准，同时要有相应的应急和考核指标。
　　用流程推动人的行为，而非由人驱动行为。
　　这句话是最近两个月从一位大领导口中听到的，印象深刻的两句话之一（另一句感兴趣的可以私聊）。
　　不过，说到这种机制的建立，对于大多数企业或团队而言，都属于重要但不紧急的事情，优先级排序一定是延后的，设立的过程也一定是缓慢的，最终的效果99是无效的。
　　但是，这并不代表我们忽略，或者不重视这个问题。毕竟精细化管理中的“精细化”，就是体现在这些细节构成的大框架内。
　　企业的降本增效和可持续发展，需要这些精细化流程作为支撑。
　　我们应该根据自身情况，结合华为“铁三角”方法论进行尝试，摸索出一套适合自身的售前交付的一体化管理体系。
　　七、写在最后
　　本文的题目：从售前到交付，一场以交接为主的修行。这是我思考很久之后决定使用的题目，其重点在于最后的“修行”二字。
　　不同的团队、不同的人、不同的性格，在面对不同的行业、市场、客户、产品等细分情况时，一定会延伸出很多千奇百怪的情形。
　　而修行，就是要耐下心来，从中抽丝剥茧、寻找规律，最终形成一个体系化的雏形，再通过实践逐步打磨，最终达到预期效果。
　　这个过程一定是以年为单位计算的。但如果想要做到自身经营管理的降本提效，这些精细化管理流程势必要改革、要行动。
　　如果读完本文，能够尽快形成一份相对标准的交接清单，也不枉我码字八千！
　　专栏作家
　　不想延期，公众号：不想延期，人人都是产品经理专栏作家。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累。
　　本文原创发布于人人都是产品经理，未经许可，禁止转载。
　　题图来自Unsplash，基于CC0协议。
　　该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。