作者简介：汪名亮，智能建筑公司项目管理副总裁、上海市智能建筑协会青年专家委员会委员、港珠澳大桥一站式通关项目一站式通关系统项目总指挥（获詹天佑奖、鲁班奖））。
项目管理的核心在于如何在项目中平衡好资源和人际关系，既要满足项目中不同干系人的需求，也要确保项目在有限资源下如期、保质、保量完成。
项目中人与人的沟通很复杂，也很微妙，既不能机械的照搬书本上的沟通技巧或方法，也不能只靠能说会道、三寸不烂之舌实现预设沟通目标，而是要从项目实际出发、因地制宜的裁剪出针对性的沟通策略或方法。如何确保信息对称和透明，如何满足各方利益、诉求，如何在博弈中有理有据，在项目这个螺蛳壳里做道场是对项目经理的综合能力的考验，更是对项目经理的沟通管理能力的挑战。
我有幸参与港珠澳大桥珠海口岸项目的核心系统建设，作为该项目的总指挥，临危受命，在一个工期超短、系统及其复杂、干系人众多、项目管理出现重大危机的情况下，我接手项目后只花了10天左右的时间，深入一线、快速了解项目现状、识别出项目重大风险要素，根据项目管理知识和实战经验，快速裁剪出一套针对性的沟通管理策略，在几个月里带领团队稳打稳扎，步步为营，最终完成项目管理的大扭转，不但成功交付出项目，还受邀参加了港珠澳大桥通关仪式。
本文提炼出对本项目成功逆袭起到决定性的几个沟通协调策略和方法，在此抛砖引玉，期待和大家一起切磋和交流。
项目全称为港珠澳大桥珠海口岸口岸通关监管管理(含弱电)项目（简称：一站式通关项目）,主要负责内容为建设珠海口岸一站式车辆通关系统，确保香港、澳门和内地三地持有通关资格的货车、客车在珠海口岸快速出境或入境，核心目标是实现粤、港、澳区域通关一体化格局下的客货通关车辆一站式监管核放。
这里的一站式通关指的是符合出入境条件的车辆在口岸实现“一次申报、一次查验、一次放行”的新型监管模式。
（2）建设体量大，涉及到客车和货车的出境、入境，包含了人工岛8个大区域的上百条车道建设。
（3）单车道系统多，设备和设备之间有严格的逻辑关系，系统和系统之间有大量交互，软件和软件之间相互连通。
（4）新建系统还需和多个参建单位原有的平台、数据库实现互联互通、实现数据的共享和实时交互。
（5）该通关模式属全国首创，国内外尚未有可以借鉴的成功案例或技术应用，如：尚未有持有粤、港、澳三地牌照的车辆在口岸实现过真正意义上的一站式通关。
上百个设备安装在安装空间存在限制的车道上，安装不到位，调试不充分，系统就很难实现既定功能，施工周期短，调试难度大。
一站式系统主要用户是海关、国检和边检三家联检单位，每家联检单位都有独立成体系的监督管理模式和完整的监管系统，车道上一站式系统的采集设备根据设计规则自动从车道上采集通行车辆的数据，按照监管需求上传到联检单位的数据库和监管系统中，监管系统自动将收集的数据和数据库内的数据来进行比对，不符合/符合放行条件则发送拒绝/放行指令到一站式系统，只有三家监管系统都发出了放行指令，一站式系统的前端执行设备才执行相应的抬杠、放行、恢复初始状态的动作。在整个通关过程中，前端数据的采集、上传、分发、后端数据的比对、指令下放、设备抬杠、放行，恢复初始状态等整套动作一气呵成，整一个完整的过程维持的时间不到一分钟。任何一个环节出问题，该车道就会出现放行失败，后续的通关车辆都会拥堵在该车道上。
港珠澳大桥项目涉及到珠海、香港和澳门三地口岸建设。三地同时建设，也需同时通关。珠海口岸项目能否如期建设完成，取决于一站式系统是否如期完成，因此一站式系统建设受到了上至中央，下至地方的高度关注，建设期间也成为口岸上着重关注和监管的对象。
常规的工程建设项目，参建方一般由建筑设计企业、勘察单位、设计单位、监理单位、实施工程单位组成，项目验收完成后需完成五方签字。实施工程单位一般由一家总承包单位、若干专业分包单位组成，每个系统原则上只有一家专业分包单位。
珠海口岸项目体量大，参建单位众多，口岸项目总承包单位就多达四家，监理单位和设计单位也均不止一家。格力作为代建单位，是建设合同上的甲方，市大桥办和市口岸局作为政府的代表，对整个项目进行监管、协调和推进。一站式系统建设完成后，海关、国检和边检三家单位是该系统的使用单位。
一站式项目建成后参与正式验收单位多达12家，每家单位的验收代表都深入参与了项目，对最终验收通过投出了关键的一票。
海关、国检、边检三家单位作为重要参建方，参建的同时还需同步推动自身配套系统的建设，涉及到内部原有系统的整合、升级和改造，在项目建设期间，每家单位参与到该项目中的部门和人员众多，以海关为例，参与项目建设的部门就有技术、监管、业务、风控等多个部门，均由各部门领导或骨干带队。
在项目建设期间，每个参建方的诉求和角度都不完全相同，譬如：在这一个项目中，客户和用户们来自不同职级体系，沟通过程中文来文往非常频繁，彼此在项目中的诉求或遇到的问题也各不相同，如何满足并平衡好各方的诉求，如何高效协调各方求同存异、如何让项目信息透明和对称是本项目建设的难重点之一。
在我正式接手之前，一站式项目已完成了基础管线的施工，设备正在紧锣密鼓的安装过程中，因为项目环境复杂等多种因素，项目一直推进不顺利，随着既定通关时间的临近，项目上出现了很多不和谐的声音，甚至传言该项目必然不能成功的预测，一时间项目风声鹤唳，团队人心惶惶，大家顶着巨大的身心压力，忙得人仰马翻，身心俱疲，但是风向一直在朝着不好的方向发展，随着传言的持续发酵，团队情绪低落，项目进入岌岌可危状态。
我通过十天左右的深入调研、走访和分析，总结出造成这个局面的几个核心因素：
（1）为实现真正意义上的一站式通关，该项目采用了很多新方案、新技术、新工艺，无可借鉴的项目经验或成功案例，在这么短的时间内攻坚克难挑战难度大，大家信心不足。
如：口岸通关业务中已经有粤港两地互通，粤澳两地互通，但是粤港澳三地互通尚属首次，其时国内光学单一牌照识别率已达到了99%，但三地车牌识别率主流厂家均无测试数据，光学车牌识别率高低对通关车辆能否一次顺利通关影响很大。
（2）一站式系统涉及到大量软件定制开发，大量的硬件集成以及多个系统之间的互联互通，系统还需对接三家联检单位的原有平台和数据库，在这么短的时间内完成上百条车道建设、多个系统的互联互通，对于任何一家实施单位都是重大的挑战。只要有一个环节未打通或测试未通过，如期通关存在不确定性。
（3）一站式系统建设涉及到的对接和协调面广，各个参建单位的干系人都格外的重视，上至单位一把手，下至各个部门的负责人。
骨干均对该项目给予了格外的重视和全力支持，来现场实地视察和调研也是平常之事，联调联试过程才是一站式系统的核心，也是重难点，在项目尚未进入测试阶段，现场的情况对于各方犹如一个黑盒，各级领导拿不到一手数据，只能听下属或施工方汇报，项目信息的真实性和项目团队的能力均受到了质疑和重大挑战，谣言由此就有了传播的温床，各方由一开始的将信将疑变成了怀疑，最后演变成了不信任，有些单位已经着手找备用或替代方案。
正如前文所述，正常的工程建设项目只需五方主体验收，本项目正式验收时超过12家单位，在项目实施期间，参建单位众多，各个单位人员你来我往，轮番上阵也是很平常的事，项目团队每日奔波于系统的安装、调试、测试等工作，无暇逐一接待和汇报。再加上大家专业分工不一样，每个人对项目的进展描述不完全一样，大家的认知差和信息差无时无处不在。
对于部分干系人来说，一站式系统建设可能仅仅是他日常工作中临时多出来的一个任务或项目，他们可能没精力来仔细甄别项目上的各种信息，也很难深入去了解项目的推进细节。但是项目成功与否又和他们的考核息息相关。一方面拿不到能验证信息真伪的数据，一方面又要对最后的结果承担重大责任，这就如一个司机在没有灯光的情况下开夜车，一方面要避免车辆撞到障碍物，一方面车子还不能停下来，在这种情况下很难做到不焦虑，在互联网的加速下，各种猜测、以讹传讹的信息开始满天飞。
项目部上报上去的数据是项目已完成了40%，项目部听到的反馈是目前项目进度尚不到20%，项目上明明投入了100个人，参建方代表在会上反馈现场只有零星几个人。
在这种情况下，必须要有一个统一的信息发射源，确保信息及时、准确的发射出去，让各方都能够实时看到并得到及时的反馈。
作为项目负责人，在前期排查阶段，我主动拜访了各个参建单位的重要干系人，并分别添加了他们的微信。于是我决定启用项目日报制度，我紧急抽调一个对项目掌握比较全面的骨干，他每天晚上22:00前收集各个小组当日的人员数据、测试数据，故障数据等，一边是项目部拼命的加班加点、赶进度（每天至少加班到22:00），一边是我和这个同事连夜对收集的数据来进行甄别、澄清、统计和分析，我将收集的数据整理成日报，在第二天上午8:30前完成对重要干系人点对点的信息推送，最高峰时每天发送的日报对象多达三十人。
主要干系人每天上班后第一时间就能清楚看到前一天的日报，对项目的进展情况有了一个直观的印象和判断，如果有所怀疑，能够最终靠找下属询问或亲自去现场查验，这就等于给驾驶室里建立了一套信息雷达地图，有了这张日更信息雷达地图，大家再也不怕黑暗中开车撞到障碍物了。
初始的数据并不具有可比性，随着项目的推进，数据越积越多，数据之间就有了强烈的差异性和可比性，项目的推进情况，每天测试通关成功率，问题的数量和当日解决的障碍等都数据能够最终靠多张日报的比对来获得，在透明的信息面前，谣言失去了生存的土壤，慢慢就灭亡了。
日报的撰写工作颗粒度非常细，对管理资源的消耗很大，如果项目短时间内变化不大，一段时间内数据不能呈现立竿见影效果，不建议采用日报，推荐使用周报。
日报常用格式可以类似于周报，包括当日完成工作情况，明日工作规划，当日需要协调解决的问题等。
当日需要协调的事项需要精确到前置条件、谁来解决，何时一定要解决、不解决的影响是什么等信息，便于决策者快速决策和调动资源。
日报内容宜言简意赅，一目了然，确保非专业人员或不熟悉现场的人员也能一看就懂。
项目参建方多，信息散播快，每个干系人都会正在自己的立场和视角去定义、传播和验证信息，在信息满天飞的时候，人们更倾向于听进那些小道消息来佐证自己的判断，如果你正处在信息的漩涡中，一味的通过拍胸脯、发誓、表决心、打感情牌来验证自己能达成目标往往是苍白无力的，击败谣言最好的方式是用数据说话，在详实的数据面前谣言往往不攻自破。
按照当时的技术方面的要求，粤港澳三地车光学车牌识别率应达到96%以上，口岸上不具备测试环境，我们在深圳口岸和珠海拱北口岸均搭建了真实的测试环境，两个技术团队每天将测试数据发到厂家的研发部门，研发部门持续对测试参数进行修正和调整，从而提升读取车牌的精准度，大家都明白我们在测试识别率，也陆陆续续获得我们的测试消息。每日的信息量太大，参与的人太多，大家对信息的真实性和准确性一直半信半疑，我接手项目后，第一时间整理了当日测试数据，并以表格的方式呈现在日报中，每日更新。
车道测试数据的好坏决定了车道能否按时通关，在车道测试过程中，联检单位全程参与测试，参加各方均对整个测试情况非常关心，于是我每天都将测试结果记录到日报中，如果有干系人对测试数据的真伪有疑惑，只需要针对性的去核实，包括询问现场的参与人员或调阅临时数据库中的数据，就能快速获得验证。随着持续的修改测试方案和优化技术参数，车道的故障率在急剧下降，测试通过率在快速、稳步上升，我用数据证明了项目正在有序推进中且进展良好，增加了各方对项目成功的信心，也侧面证明了我们的专业能力和执行力。
一站式通关系统建设成功与否必然的联系到大桥能否如期开通，政治意义和经济意义巨大，任何单位或个人都很难承受这个压力，在终点和冲刺之间，在0-1之间，我们都没有十足的把握如期交出项目。随着通关节点慢慢的接近，可供我们腾挪的时间也慢慢变得少，岛上的气氛也慢慢变得凝重，会上各种质疑的声音也慢慢变得多，让我们疲于应付。
我紧急召集项目组和技术组的骨干进行了深入讨论，大家的思路也不完全统一，有乐观的，也有悲观的，我果断决定将原来的进度节点进行二次拆解，增加了稳定性测试、硬件疲劳测试、联调联试。实车测试等多个里程碑节点，然后将上述里程碑节点计划、测试方案、验证标准等上报主要参建单位，获得通过后，项目部严格按照进度计划推进，因项目冲刺时间很短，个别节点存在延期或重叠，但是大多数都在偏差的容许范围内。基本上十天一个节点，半个月一次大的突破，参见方都欣喜的看到了项目成功的曙光，质疑声变少了，支持和力挺的声音变多了，随着项目里程碑一个接一个的实现，项目上的氛围越来越轻松了，项目团队开始苦中作乐了。
通过拆解关键目标，各方重新对齐了项目的时间和冲刺目标，原来需要开会讨论或文来文往的协调工作在各级领导们的支持下快速解决，一站式系统碰到的问题都能在24小时内就解决，最长不超过48小时。
才聚的康俊鹏老师说过：“要通过PMP的考试，首先要把自己当做圣人，其次要把项目干系人都看作圣人。”
在项目实战中，如果也用这句话，项目很难取得成功，因为中国的项目环境是一个关系微妙的人情社会。
在这么短的工期内要完成需求收集、定制开发，假如没有一个好的规则，项目推进过程极易出问题，尤其是在项目后期，恰逢海关和国检在通关前需整合成新海关政策的发布，已经开发完成并陆续测试的一站式系统要做相应的紧急调整，原海关、原国检内部的系统也需要做一次重大调整，由此引发的变更需求非常多，每个部门都会从自身分管角度提出新的需求，他们的需求毋庸置疑都是合理且迫在眉睫的，如果不满足轻则担责，重则影响到系统的安全，触发监管风险。
作为实施工程单位，我们没办法从业务层面判断哪些需求必须在通关前完成，哪些需求可以放在通关后优化，哪些功能能通过非技术手段也能实现，技术团队持续不断地接收到新需求，所有人员都在积极努力配合做调整，随着项目的快速推进，新的需求提交速度只增不减，大家天天加班加点，通宵达旦，但是产出并不明显，长时间疲劳作战使得有些同事出现发热症状，还有一个同事突发脑溢血，现场眼看快顶不住了，技术负责人才不得不把问题上报给我。
我意识到这是一个系统性的问题，必须要用系统性的解决方案。首先我让技术组停止接入新需求，只专注已有需求的开发和测试工作，所有的新增需求都需要经过我审核后下发。其次我把这样的一个问题整理成报告写在了日报里，陈述了现状、风险和由此引发的担忧，让各方领导层都同步看到并意识到了这个重大风险源，虽然有些提需求的人因为需求没有即时满足有一些不满情绪，大部分干系人还是对我们给予了理解和支持。此操作让研发人员得到了喘息机会，开发代码质量和工作效率明显上升。
在接下来一次关键的项目沟通会上，我把问题和合理化建议抛了出来：在有限的时间、有限的资源下，到底哪些需求要满足，需求的轻重缓急需要海关内部统筹和筛选。
大家认真讨论后接受了我的建议：海关后期所有的需求都先完成内部评审，评审通过后的需求将通过书面的指令专人下发给我们。在需求讨论期间，我们的核心骨干作为技术评审专家，一起参加内部的评审工作，我们从估算开发工作量、技术开发难度、工时数等专业视角帮助海关确定需求的排序和优先级。
在最紧张的那一段时间里，我带着技术骨干天天和海关的领导们一起开会，讨论到凌晨1-2点是常态，非紧急重要的需求在开发前期就提前筛选掉了，最大限度释放了开发团队的压力，减轻了大家的焦虑和不安。
真实的项目环境中，我们都不是圣人，有一些需求一度排在了通关后，甚至有些需求就没有上会讨论，但是当事人异常焦虑，反复和我们私下协商，动之以情，晓之以理。我们也尝试着进行换位思考，在评估工作量和团队工作状态后，我们分批次，分阶段逐步解决了他们的诉求，消除了他们担心需求不满足，功能没办法实现的焦虑，也让我们之间建立了更好的信任。在项目建设后期，我们变成了并肩作战的大团队，革命的友情高涨。
在项目实施期间，一味的做好人有时候得不偿失，弄不好会变成“滥好人”，累死自己是小，把项目弄砸了，客户那边也无法交代，最后的结局往往适得其反。
对客户来说，每个需求可能都是小需求，对研发人员来说，当需求持续增加、堆积成山，应接不暇的时候，小需求可能就是压死骆驼的最后一根稻草。
在中国的项目管理环境里，一味的坚持原则，会给人一种不近人情的感觉，容易失去对方的信任，甚至造成双方立场或情绪的对立，关键时刻通过升维的方式解决当下的难题不失为一个好的策略。同时在规则框架内、在自身能力范围内尝试着解决对方关心的需求、换位思考才能更好地合作和产生信任。
每个项目成功都会有一定的偶然因素，这一个项目也不例外，我临危受命接手该项目，在那么短的时间里，就没有精力去熟悉或掌握该项目的有关技术，团队还是那个团队，技术还是那些技术，系统还是那些系统，最大的不同在于我因地制宜的调整了项目沟通管理策略，在技术团队的加持下，我们最终完成了项目的逆袭。
因为篇幅有限，本文重点仅聚焦外部沟通管理策略。内部激励方案将从“压力疏导、目标拆解、正向反馈”三方面展开，详见下次分享。返回搜狐，查看更加多