厅长批示后的两周，日子像绷紧的弦。
林凡每天上班第一件事，就是打开内网系统，查看方案流转到了哪个环节。从办公室发出，到秘书处登记，再到各相关处室会签——流程的每一个节点，都像一道需要翻越的山。
第一周，建设处和规划处签回了意见。意见写得很有技巧：“原则同意，但建议充分考虑实际操作中的困难。”——同意是姿态，困难是实质。
财务处赵处长签得最痛快：“同意按会议讨论意见推进。”他兑现了承诺，但也把球踢了回来——会议讨论时大家提的那些困难，现在成了方案的一部分。
第二周，信息中心和法规处的意见回来了。信息中心的意见最具体，列了七条技术实现上的难点，每条都需要投入资源和时间。法规处的意见最严谨，指出方案中三处可能存在的合规风险。
林凡把这些意见整理成表格，逐条研究对策。每天下班后，他办公室的灯都亮到九点以后。
周三晚上八点，刘建军推门进来，手里提着两个盒饭。
“还没吃吧？”
林凡抬起头，这才感到胃里空得发慌：“刘处，您怎么……”
“我也加班。”刘建军把盒饭放在桌上，“顺便看看你。进展如何？”
林凡把意见汇总表推过去，苦笑道：“每个处室都同意，但每个处室都提了条件。把这些条件都满足，方案就得推倒重来。”
刘建军翻看着表格，看得很仔细。看完后，他说：“你知道这意味着什么吗？”
“意味着阻力很大。”
“不。”刘建军摇头，“这意味着大家都在按规则出牌。提意见是他们的权利，也是他们的自我保护。如果哪个处室不提意见就同意，那才不正常。”
“那我该怎么办？逐条修改？”
“分三类处理。”刘建军用笔在表格上画线，“第一类，技术性意见，比如信息中心提的数据接口问题——接受，写进方案，但注明‘后续由技术小组专项研究’。第二类，原则性意见，比如法规处的合规风险——必须修改，不能留隐患。第三类……”
他顿了顿：“推诿性意见。比如建设处说的‘实际操作困难’——不修改，但写个说明，解释为什么这些困难可以克服。”
林凡记下了。这就是刘建军说的“策略”：不是全盘接受，也不是全盘拒绝，而是区分对待。
“还有，”刘建军说，“你要开始主动沟通。不要等意见来，要带着方案去。”
“主动去找他们？”
“对。尤其是信息中心和法规处。技术问题和法律问题，越早沟通越好。让他们觉得你是去请教，不是去施压。”
接下来的三天，林凡开始了他的“拜访之旅”。
第一站是信息中心。中心主任姓吴，四十出头，技术出身，说话直接。
“林科，不是我不支持。”吴主任指着方案里的技术架构图，“你说的实时共享，理想很丰满，现实很骨感。我们现在的系统，十年前建的，各部门数据标准都不一样。要打通，得重新开发接口，这不是小工程。”
林凡没有争辩，而是拿出笔记本：“吴主任，您看这样行不行？我们不追求一步到位，分阶段实现。第一阶段，先用最笨的办法——每日定时导出数据，人工核对后上传到共享平台。虽然不实时，但至少能做到每日更新。”
吴主任想了想：“这倒是可行。但人工操作，容易出错。”
“所以我们设计严格的核对流程，双人复核。”林凡说，“等试点成熟了，再考虑系统对接。这样既推进了工作，也给技术升级留出了时间。”
这个折中方案打动了吴主任。他最终同意，在方案里加上“分阶段实施”的表述。
第二站是法规处。法规处长是位女同志，姓孙，五十多岁，戴着金丝眼镜，说话一板一眼。
“小林，你方案里这个‘数据使用授权’条款，表述不够严谨。”孙处长指着条文，“什么叫‘在必要范围内使用’？必要范围怎么界定？谁来界定？这些都必须写清楚，否则将来会有法律风险。”
林凡虚心请教：“孙处长，您觉得该怎么写？”
孙处长从抽屉里拿出一本《政府信息公开条例》，翻到某一页：“你看，这里对政府信息的使用有明确规定。你可以参考这个表述，把‘必要范围’具体化为‘履行法定职责所需’，并且加上‘不得用于与职责无关的用途’。”
“那如果某个处室认为他们需要某个数据来履行职责，但数据提供方不同意，怎么解决？”
“设立争议解决机制。”孙处长说得很清晰，“由办公室牵头，法规处、信息中心参与，组成数据共享争议协调小组。有争议，上会讨论，集体决策。”
这个建议很专业。林凡全部记下，承诺修改。
走出法规处，林凡感到一种奇特的成就感。这种一砖一瓦的沟通、修改、妥协，虽然缓慢，但每一步都扎实。他想起张怀民说过的话：“在机关里，最快的速度往往不是奔跑，而是一步一个脚印。”
周五下午，林凡正在修改方案，手机响了。是青江大桥项目组的老王。
“林科，出事了。”老王的语气很急，“大桥三号墩的施工方案，规划和建设两边又杠上了。规划说建设擅自改方案，建设说规划审批太死板。现在工地停工了，每天损失十几万。”
林凡心里一紧：“试点项目的协调机制没用吗？”
“用了，开过两次协调会。但两边都坚持己见，谁也不让谁。”老王说，“刘处让我直接跟你汇报，说这个事……可能是个机会。”
机会？
林凡瞬间明白了刘建军的意思。如果数据共享机制已经建立，如果规划处的审批意见和建设处的施工进度能实时同步，这种误会根本不会发生——规划能看到建设每一步的调整，建设能提前知道规划的要求。
但现在，机制还没真正运行，问题已经发生了。
“我马上过来。”林凡说。
半小时后，林凡赶到项目指挥部。会议室里烟雾缭绕，规划处的陈工和建设处的王工各坐一边，脸色都不好看。
看见林凡进来，陈工先开口：“林科，你来得正好。建设处这次太过分了，三号墩的地质情况有变化，他们调整施工方案，不报批就直接干。这是严重违规。”
王工立刻反驳：“我怎么没报批？一周前就打了报告，你们规划处压着不批。工地等不起，地下水都快涌出来了，我再等下去要出安全事故！”
“那你也不能先斩后奏！”
“我不先斩后奏，现在墩子已经塌了！”
两人越说越激动。林凡听明白了，问题的核心是信息流转太慢——建设处打了报告，规划处审批需要走流程，但工地情况紧急，等不起。
如果……如果施工方案调整的申请、审批意见、执行情况，都能在共享平台上实时更新呢？
如果建设处一提交申请，规划处就能看到，就能启动加急审批呢？
如果规划处的每一次审查意见，建设处都能实时收到，就不会有“压着不批”的误解呢？
林凡没有马上调解具体矛盾，而是问了一个问题：“陈工，王工，你们两位的意见，都愿意为了解决这个问题，尝试新的工作方式吗？”
两人都愣了一下。
“什么新方式？”
“数据实时共享。”林凡说，“如果建设处的方案调整申请，能实时同步到规划处的待办事项；如果规划处的审批意见，能实时推送到建设处的手机端；如果整个流程的每一个环节，都能在共享平台上看得一清二楚——今天这种误会，以后还会发生吗？”
陈工皱起眉头：“技术上能做到吗？”
“技术上可以分步实现。”林凡说，“最简单的，建立一个微信群，专门用于这个项目的紧急沟通。所有申请、批复、执行情况，都在群里同步，@相关人。这不算高科技，但至少信息不会丢失，责任不会推诿。”
王工先表态：“我同意。只要能把事办成，什么方式我都配合。”
陈工犹豫了几秒，也点了头：“可以试试。但要有记录，不能光在群里说。”
“当然。”林凡说，“群里的所有沟通，都会导出归档，作为正式文件的补充。”
接下来的一个小时，林凡建了群，把项目相关人都拉进来。他在群里发了第一条消息：
【青江大桥项目紧急协调群建立。从即日起，所有紧急事项均在本群同步。建设处提交三号墩方案调整申请，请规划处接办。@陈工】
王工立刻拍了申请文件照片发上来。
陈工回复：【收到。启动加急审查，两小时内给出初步意见。】
会议室里的紧张气氛，肉眼可见地缓和了。虽然问题还没解决，但沟通的渠道通了。
两小时后，规划处的初步审查意见发到群里：【原则同意调整，但需补充两项安全验算报告。请建设处今日下班前提交。】
王工回复：【收到，立即安排。】
一场可能升级为责任事故的冲突，就这样被一个简单的微信群缓解了。虽然不是林凡设想的那种高大上的数据共享平台，但原理是一样的——信息透明，流程可视，责任可溯。
晚上七点，补充报告提交了，规划处也给出了最终批复。工地恢复施工。
林凡坐在回厅里的车上，看着窗外流动的灯火。他忽然意识到，刘建军说的“等待时机”，可能已经来了——不是惊天动地的大事，就是这样一个具体的、紧迫的、需要用新方法解决问题的时刻。
他拿出手机，给刘建军发了条信息：“刘处，今天青江大桥的事，用临时群聊机制解决了。我有个想法，能否以这次事件为契机，向厅长汇报试点机制在解决实际问题中的价值？”
十分钟后，刘建军回复：“明天上午，带着完整材料来我办公室。时机到了。”
林凡握紧手机，看向窗外。
东风来了。
不是狂风暴雨，而是一缕恰好能鼓动帆船的风。
而他，已经张满了帆。
接下来的航行，不会平静。但至少，船已经动了。
回到办公室，林凡没有下班。他打开电脑，开始整理今天的全部材料：冲突起因、协调过程、群聊记录、问题解决的时间线。他要写一份简明扼要的案例报告，用事实说明，信息共享机制不是理论设想，而是现实需求。
键盘敲击声中，夜色渐深。
这座城市有无数盏灯亮着，每一盏灯下，都有人在为各种事情忙碌。而林凡的这盏灯，今晚格外明亮。
他知道，明天将是另一个开始。
一个用实践证明理论，用案例推动变革的开始。
而他，已经准备好了。