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